[ITK-dev] [ITK] image and deformation field physical space check

Bradley Lowekamp blowekamp at mail.nih.gov
Wed Nov 5 14:28:53 EST 2014 

I'll pick up this issue of adding these new methods to better control the tolerances.

Brad
On Nov 4, 2014, at 9:54 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> 
> Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly?
> 
> The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries.
> 
> Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since.
> 
> 
> 
> 
> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41
> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87
> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46
> 
> 
> On Nov 4, 2014, at 9:28 AM, brian avants <stnava at gmail.com> wrote:
> 
>> so - just to be clear ... same thing needs to be done here:
>> 
>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h
>> 
>> and how does Get/SetGlobalDefault  differ from  Set/GetCoordinateTolerance  Set/GetDirectionTolerance  
>> 
>> which already exists in the image to image filter (but not displacement field)?
>> 
>> 
>> 
>> brian
>> 
>> 
>> 
>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> I agree that would be good.
>> 
>> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one?
>> 
>> Brad
>> 
>> On Nov 4, 2014, at 9:21 AM, brian avants <stnava at gmail.com> wrote:
>> 
>>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere.   
>>> 
>>> 
>>> brian
>>> 
>>> 
>>> 
>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO?
>>> 
>>> Brad
>>> 
>>> 
>>> On Nov 4, 2014, at 3:51 AM, <M.Staring at lumc.nl> <M.Staring at lumc.nl> wrote:
>>> 
>>> > Hi all,
>>> >
>>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy?
>>> >
>>> > Regards, Marius
>>> >
>>> >> -----Original Message-----
>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On
>>> >> Behalf Of Matt McCormick
>>> >> Sent: maandag 3 november 2014 18:39
>>> >> To: brian avants
>>> >> Cc: Insight-developers at itk.org
>>> >> Subject: Re: [ITK-dev] image and deformation field physical space check
>>> >>
>>> >> Hi Brian,
>>> >>
>>> >> Thanks for discussing this.
>>> >>
>>> >> I think a combination of fixing the underlying issue that is being brought up by
>>> >> the exception, relaxing the tolerance, and improving the documentation is a
>>> >> good approach.
>>> >>
>>> >> 2 cents,
>>> >> Matt
>>> >>
>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants <stnava at gmail.com> wrote:
>>> >>> This email is motivated by this issue:
>>> >>>
>>> >>> https://github.com/stnava/ANTs/issues/74
>>> >>>
>>> >>> but it is not isolated to ants.   Worth a read for additional context.
>>> >>>
>>> >>> ITK currently enforces a relatively strict check that image and
>>> >>> displacement fields "occupy the same physical space."  However, for
>>> >>> some unclear (to me) reasons, the direction matrices or origins of
>>> >>> images can lose precision when passing through ITK pipelines (
>>> >>> especially through resampling or resolution-changing filters ).  This
>>> >>> results in filters aborting and this can occur at various different
>>> >>> places in a complex series of ITK-based operations.
>>> >>>
>>> >>> My concern with this is that it can lead to a very severe loss of
>>> >>> productivity when this somewhat unpredictable error occurs.   For instance,
>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic,
>>> >>> brainsfit, joint label fusion, etc).   The user expects registration or
>>> >>> segmentation filters to "work well" especially when the data is of a
>>> >>> standard sort.   Then, after some oft-substantial execution time, this
>>> >>> mysterious error appears:
>>> >>>
>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy
>>> >>> the same physical space!
>>> >>>
>>> >>>
>>> >>> While I am all for correctness, when the impact on productivity exceeds a
>>> >>> certain threshold, I think it is useful to bend the rules a bit.   Perhaps
>>> >>> one of these would improve the situation:
>>> >>>
>>> >>> 1)    change:
>>> >>>
>>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField
>>> >>> Transform.hxx
>>> >>>
>>> >>> and
>>> >>>
>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx
>>> >>>
>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4
>>> >>>
>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F
>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L
>>> >>> 454-L457
>>> >>>
>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C
>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41
>>> >>>
>>> >>> and change the documentation too:
>>> >>>
>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C
>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87
>>> >>>
>>> >>> 2)  Change the exception to a warning.  This would at least allow
>>> >>> complex pipelines to execute while notifying the user of a possible issue.
>>> >>>
>>> >>> 3)  Document all of the places that the user/developer should call:
>>> >>>
>>> >>> Set/GetCoordinateTolerance  Set/GetDirectionTolerance  .
>>> >>>
>>> >>> This last solution would require adding Set/GetCoordinate and
>>> >>> Direction tolerance to:
>>> >>>
>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F
>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h
>>> >>>
>>> >>> as well, for consistency.
>>> >>>
>>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost
>>> >>> by this check.
>>> >>>
>>> >>> Not once has this check actually helped us, in any measurable way,
>>> >>> avoid errors.
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Powered by www.kitware.com
>>> >>>
>>> >>> Visit other Kitware open-source projects at
>>> >>> http://www.kitware.com/opensource/opensource.html
>>> >>>
>>> >>> Kitware offers ITK Training Courses, for more information visit:
>>> >>> http://kitware.com/products/protraining.php
>>> >>>
>>> >>> Please keep messages on-topic and check the ITK FAQ at:
>>> >>> http://www.itk.org/Wiki/ITK_FAQ
>>> >>>
>>> >>> Follow this link to subscribe/unsubscribe:
>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>>> >>>
>>> >> _______________________________________________
>>> >> Powered by www.kitware.com
>>> >>
>>> >> Visit other Kitware open-source projects at
>>> >> http://www.kitware.com/opensource/opensource.html
>>> >>
>>> >> Kitware offers ITK Training Courses, for more information visit:
>>> >> http://kitware.com/products/protraining.php
>>> >>
>>> >> Please keep messages on-topic and check the ITK FAQ at:
>>> >> http://www.itk.org/Wiki/ITK_FAQ
>>> >>
>>> >> Follow this link to subscribe/unsubscribe:
>>> >> http://public.kitware.com/mailman/listinfo/insight-developers
>>> > _______________________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Kitware offers ITK Training Courses, for more information visit:
>>> > http://kitware.com/products/protraining.php
>>> >
>>> > Please keep messages on-topic and check the ITK FAQ at:
>>> > http://www.itk.org/Wiki/ITK_FAQ
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/insight-developers
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/d064b78e/attachment.html>

More information about the Insight-developers mailing list