[ITK-dev] image and deformation field physical space check
brian avants
stnava at gmail.com
Wed Nov 5 09:34:16 EST 2014
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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/a1b45094/attachment.html>
More information about the Insight-developers
mailing list