[ITK-dev] [ITK] image and deformation field physical space check
brian avants
stnava at gmail.com
Wed Nov 5 13:59:49 EST 2014
brilliant, brad ... i think you've nailed one part of the problem.
i will check and see if anyone has encountered this when using double
precision.
brian
On Wed, Nov 5, 2014 at 1:55 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:
> 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/1a68ae4d/attachment.html>
More information about the Insight-developers
mailing list