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

Bradley Lowekamp blowekamp at mail.nih.gov
Wed Nov 5 13:55:43 EST 2014 

Brian,

The first think I see is that the failure is dependent on the usage of "-float", which I believe changes the parameter type to be float. This also makes the fixed parameters float. For the BSpline and Displacement field transform the origin, spacing, orientation are not stored as floats resulting in a loss of precision. The problem particularly occurs with the TransformAdaptors which sets these values. While this error is not egregious, it is minor flaw which should be addressed. 

The Adaptors should be setting this information with double precision and not float.

Brad


On Nov 5, 2014, at 11:58 AM, brian avants <stnava at gmail.com> wrote:

> That's great - very helpful 
> 
> I also found ( not sure if you can reproduce ) that if I do:
> 
> MultiplyImages 3 S10.nii.gz 1 S10b.nii.gz 
> MultiplyImages 3 KKI2009-11-t1weighted.nii.gz 1 KKI2009-11-t1weightedb.nii.gz
> 
> and then run 
> 
> 
> ./reg_subject_deform.sh S10b.nii.gz KKI2009-11-t1weightedb.nii.gz TEST
> 
> it seems to work ok ... this was originally suggested by phil cook.
> 
> all multiplyimages does, as it suggests, is multiply by a scalar / convert to floating point type.   
> 
> not sure if this is illuminating, yet ... but a little more info.
> 
> 
> 
> 
> 
> brian
> 
> 
> 
> On Wed, Nov 5, 2014 at 11:55 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
> 
> I narrowed this example down alittle bit, and reduce the size so that is can be debugged. Here is the command line I came up with:
> 
> cmd="antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ $OUTPUT_ROOT , ${OUTPUT_ROOT}deformed.nii.gz ] -r [ $FIXED, $MOVING, 1] -t Affine[0.1] -m MI[ $FIXED, $MOVING, 1, 32, Regular, 0.25] -c [100,1e-8,10] -f 4 -s 4vox -t SyN[0.2,3,0] -m CC[$FIXED, $MOVING, 1, 2] -c [1x1,1e-9,10] -f 4x2 -s 2x1vox "   
> 
> 
> Having two stages in the SyN registration seems to be the critical parts.
> 
> Brad
> 
> 
> On Nov 5, 2014, at 10:07 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
>> Ahh yes, I see that in your original e-mail... I guess after downloading and building ANTs I forgot to go back to the original e-mail.
>> 
>> This looks like a regular ANTs run not a minimal example to illustrate the problem. Can you please share what are the requirements to reproduce this problem and what you ruled out in the process of narrowing down the problem?
>> 
>> I am hoping for something a little more isolated or easier to run than a long running registration process. Are all the iteration needed? Do the images need to be this big for the problem? I was thinking this was an issue with how the meta-data was propagate, computed or manage. Which would imply it some what independent of the size of the image.
>> 
>> Thanks,
>> Brad
>> 
>> On Nov 5, 2014, at 9:34 AM, brian avants <stnava at gmail.com> wrote:
>> 
>>> just to be clear:   it should be called in this way
>>> 
>>> reg_subject_deform.sh  KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST
>>> 
>>> i could not find an itk test that covers the 3D case of multiple stages ... if someone knows of one, let me know.
>>> 
>>> 
>>> brian
>>> 
>>> 
>>> 
>>> On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> Brian,
>>> 
>>> This does not look like a simplified test case to illustrate the problem. Also it didn't work for me:
>>> 
>>> [blowekamp at malawi  PhysicalSpaceError]$ ./reg_subject_deform.sh 
>>> antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox
>>> All_Command_lines_OK
>>> Using single precision for computations.
>>>  bad file name 
>>> Exception Object caught: 
>>> 
>>> itk::ExceptionObject (0x7fcb90f1ca88)
>>> Location: "virtual void itk::CenteredTransformInitializer<itk::Euler3DTransform<float>, itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform() [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float, 3>, TMovingImage = itk::Image<float, 3>]" 
>>> File: /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx
>>> Line: 42
>>> Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): Fixed Image has not been set
>>> 
>>> Brad
>>> 
>>> On Nov 4, 2014, at 3:37 PM, brian avants <stnava at gmail.com> wrote:
>>> 
>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> 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
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/2e47f7de/attachment-0001.html>

More information about the Insight-developers mailing list