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

brian avants stnava at gmail.com
Wed Nov 5 11:58:50 EST 2014 

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/community/attachments/20141105/13ad0acc/attachment-0001.html>
-------------- next part --------------
_______________________________________________
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

More information about the Community mailing list