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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 
>> 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 <[email protected]> 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 <[email protected]> 
>>> 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, <[email protected]> <[email protected]> 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:[email protected]] On
>>> >> Behalf Of Matt McCormick
>>> >> Sent: maandag 3 november 2014 18:39
>>> >> To: brian avants
>>> >> Cc: [email protected]
>>> >> 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 <[email protected]> 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
> [email protected]
> http://public.kitware.com/mailman/listinfo/community

_______________________________________________
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

Reply via email to