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

[brian avants]

Brad,

I think that you are right in suggesting that nifti is particularly
susceptible to this.  But I dont know the data type.

Where would the global Set/GetGlobalDefaultCoordinateTolerance (and Set/
GetGlobalDefaultDirectionTolerance ) exist?  I would be happy if they could
be called once within a given code base ( like Nick's suggestion ) but it
might be ok to call once for each executable.


brian



On Mon, Nov 3, 2014 at 11:59 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Nick,
>
>
> Wouldn't a settable global default value be preferred? ie.
> Set/GetGlobalDefaultCoordinateTolerance.
>
> Adding yet another CMake variable is rarely preferred, IMHO.
>
>
> Also, you mention in the ANTs issue, that it may be related to specific
> filters such as the Shrink filter. Do you have more specifics or
> reproducible sequence for this? There are some complexities with how some
> of the multi-scale filters compute the changing origin, it would not
> surprise me if there is a minor bug some place for certain more complex
> images.
>
> Also related does the nifti file format store this information as doubles
> or floats?
>
> Brad
>
> On Nov 3, 2014, at 11:44 AM, Nicholas Tustison <ntustison at gmail.com>
> wrote:
>
> Added to this list of suggestions, would it be possible to set a tolerance
> in the list of cmake options?
>
> Nick
>
>
>
> On Nov 3, 2014, at 8: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! <https://github.com/stnava/ANTs/issues/31>
>
> 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/itkDisplacementFieldTransform.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/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457
>
>
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41
>
> and change the documentation too:
>
>
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/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/Filtering/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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/5eb86582/attachment.html>