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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[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
