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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> wrote:
>> Brian,
>>
>> This does not look like a simplified test case to illustrate the problem.
>> Also it didn't work for me:
>>
>> [blowekamp@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 <[email protected]> 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 <[email protected]>
>>> 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 <[email protected]> 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 <[email protected]>
>>>> 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 <[email protected]> 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 <[email protected]>
>>>>> 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, <[email protected]> <[email protected]> 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:[email protected]] On
>>>>> >> Behalf Of Matt McCormick
>>>>> >> Sent: maandag 3 november 2014 18:39
>>>>> >> To: brian avants
>>>>> >> Cc: [email protected]
>>>>> >> 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 <[email protected]> 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
> [email protected]
> http://public.kitware.com/mailman/listinfo/community
_______________________________________________
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
