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

[Bradley Lowekamp]

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