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

Mon Nov 3 12:30:14 EST 2014

Hi Brad,

I realize the problem associated with adding another
cmake variable. Currently, most of my processing is
done on the university cluster and this issue can pop up
in the different programs we have for ANTs as well as
with specific programs I've built outside of ANTs but which
still depend on ITK.  What I do currently is change the
tolerance in both locations in ITK to something much
larger.  Given that use case, I'm hoping that a solution would
be easy to manage and system-wide such as a global
tolerance level (or an on/off flag).  My initial thought was to
add it as a cmake variable but I'm open to anything.

By the way, I was just at LONI talking to one of the computer
guys who has also run into this issue quite a bit on their cluster
and this is the solution I recommended.  It would be nice if
there were something less kludgey.

Nick

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

> Brian,
>
> I was thinking that those methods should be added to the
> ImageToImageFilter.
>
> While the Displacement filter can certainly use those values. I would like
> to further consider that that is an issue with the way the displacement
> fields are created.
>
> I have discussed with Hans the correctness of preserving the center vs
> preserving the location before with the shrink image filters. I have a
> patch with an alternative approach (which I thought I had done as a
> optional flag) [1],
>
> I have a thought that the ShrinkFilter and adaptor used to scale the
> displacement fields aren't symmetric. This will need exploration.. but if
> this error is as common as is indicated, then I am suspicious.
>
> Brad
>
>
> [1] http://review.source.kitware.com/#/c/8179/1
>
> On Nov 3, 2014, at 12:04 PM, brian avants <stnava at gmail.com> wrote:
>
> 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/3aab6a55/attachment-0001.html>