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

brian avants stnava at gmail.com
Tue Nov 4 15:37:17 EST 2014 

this example exhibits the problematic behavior (CentOS release 6.3 )

https://copy.com/6imJcj9ZuAGoQVtG

reg_subject_deform.sh  KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST




brian



On Tue, 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
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20141104/e31e88b8/attachment.html>
-------------- next part --------------
_______________________________________________
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

More information about the Community mailing list