itk::ERROR: ImageToImageFilter(0x352ff90): Inputs do not occupy the same physical space! #74
Comments
|
I found an earlier post that suggested the problem is related to the use of --float That appears to be the case here too - it is currently running successfully without the --float option. |
|
Hi Phil, I don't think the issue is isolated to the use of float. I encountered this problem so frequently on my cluster that I finally increased the tolerance to 10^-2 in two places (in addition to the imageToImageFilter, there's also a similar tolerance check in the DisplacementFieldTransform. I think the issue is in the ShrinkImageFilter (as you noticed, it always happens at the beginning of a level) The shrink filter does some manipulation of that image information in order to maintain the geometric center consistent. Hans did a whole case study on this issue awhile back and so he might have something to add to this. Anyway, in addition to the kludge described above, I've also found (for the single image case) that if you change the direction cosines to the nearest canonical orientation and you change the origin to all zeros, that alleviates the problem as well. Nick |
|
All, First, I want to apologize and clearly state that I will not be able to work on this problem very much until after May 15th (my teaching load is taxing me greatly this year). This problem is not isolated to ANTS, it shows up a lot in my diffusion work as well. The maintenance of physical space consistency and the sub-sampling of data can not always be guaranteed to be within tolerance. Regarding Nicks suggestion to "change the direction cosines “ and “change all origins to all zeros” does circumvent the problem, but is completely unacceptable for any of my medical imaging needs. When I run into this problem, where I feel the results are good enough I don’t change the tolerance because that is a fix that does not propagate to other tools, but instead I pick one of the images as a reference image, and use a nearest neighbor resampling to numerically align the point sources. This solution persists to other programs when saving the images out to disk. Hans From: Nick Tustison <notifications@github.commailto:notifications@github.com> Hi Phil, I don't think the issue is isolated to the use of float. I encountered this problem so frequently on my cluster that I finally increased the tolerance to 10^-2 in two places (in addition to the imageToImageFilter, there's also a similar tolerance check in the DisplacementFieldTransform. I think the issue is in the ShrinkImageFilter (as you noticed, it always happens at the beginning of a level) The shrink filter does some manipulation of that image information in order to maintain the geometric center consistent. Hans did a whole case study on this issue awhile back and so he might have something to add to this. Anyway, in addition to the kludge described above, I've also found (for the single image case) that if you change the direction cosines to the nearest canonical orientation and you change the origin to all zeros, that alleviates the problem as well. Nick — Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. |
|
Thanks guys. Sounds like a tricky problem. So far I am doing OK by not using --float, but since that's not really the root cause I will keep an eye out for this error. |
|
This problem is cropping up seemingly more often for me. A hack solution is to edit: ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx and ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx changing direction tolerance and coordinate tolerance to 1.e-4 then recompile ANTs ---- obviously not a real solution. |
|
@hjmjohnson - i have some time to work on this ... am wondering if it might be possible to implement a SetDirectionTolerance and SetCoordinateTolerance within the offending filters. is there a better solution? |
|
@stnava I'm wondering whether you have had any final thoughts on this? as I'm experiencing this problem on a subset of my data. I get this in antsCorticalThickness.sh script, where ImageMath comes in: |
|
See my comments above: "A hack solution is ..." That's all we have for now ---- Hans proposes something else which you might do if you understand it. Nick sometimes uses ClosestSimplifiedHeaderMatrix in ImageMath which may help. |
|
actually in this particular case, CopyImageHeaderInformation may help - you brian On Mon, Oct 13, 2014 at 8:42 AM, Arman Eshaghi notifications@github.com
|
|
thanks On Mon, Oct 13, 2014 at 5:21 PM, stnava notifications@github.com wrote:
|
|
I had an idea that I haven't had a chance to test yet. If you run the T1 image through ANTs before calling antsCorticalThickness, you might be able to avoid the problem. I've observed that derived images tend to be slightly but consistently different from the original input. I believe this is because of a data type conversions that happen when the Nifti transform is read / written by ITK, introducing small floating point errors. But they seem to be stable after one pass through the ANTs I/O. So for example: PrintHeader input.nii.gz | grep srow PrintHeader copy.nii.gz | grep srow See how copy.nii.gz is slightly different to the input it was supposedly copied from. But, CopyImageHeaderInformation copy.nii.gz copy.nii.gz copy2.nii.gz 1 1 1 0 PrintHeader copy2.nii.gz | grep srow copy2 appears to be identical to copy, at least to the precision printed out. Thus if you were to do something like: CopyImageHeaderInformation t1.nii.gz t1.nii.gz t1_headerFix.nii.gz 1 1 1 0 antsCorticalThickness ... -a t1_headerFix.nii.gz it might avoid the problem. On Oct 13, 2014, at 10:19 AM, Arman Eshaghi notifications@github.com wrote:
|
|
interesting - it's true that the ITK nifti I/O is consistently buggy. small but irritating bugs. i also wonder if nrrd or mha would avoid this. brian On Mon, Oct 13, 2014 at 10:43 AM, Philip Cook notifications@github.com
|
|
Phil, what I did based on your very first comment: changing the input to FLOAT32 solved the issue. |
|
@cookpa - did you ever find a good work around for this bug? |
|
I have not found a workaround that works for all cases. I think we've minimized the likelihood of seeing this in antsCorticalThickness by being careful about the choice of reference image for ImageMath operations etc. I've heard via Ted that this error can arise during template construction. @jeffduda and I have both observed the issue when using antsMalfLabeling. In that case I'm not sure if we can really do anything by fiddling with the headers, unless one is willing to try Nick's "nuclear option" of changing all the matrices to identity and all the origins to zero, and dealing with the various problems that can cause elsewhere. |
|
Thanks - @dorianps https://github.com/dorianps has seen this too. I proposed this to ITK developers: ITK currently enforces a relatively strict check that image and My concern with this is that it can lead to a very severe loss of itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the While I am all for correctness, when the impact on productivity exceeds a
ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx and ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx changing direction tolerance and coordinate tolerance to 1.e-4 and change the documentation too: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87
Set/GetCoordinateTolerance Set/GetDirectionTolerance . This last solution would require adding Set/GetCoordinate and Direction as well, for consistency. Anyway, I raise this issue b/c of the many man and computer hours lost by Not once has this check actually helped us, in any measurable way, avoid |
|
Just ran into this as well with Running this without -s1 (using whatever the default -s value is) succeeds. |
|
do you have a reproducible example for this? we want to solve this issue once and for all and are trying to collect brian On Wed, Nov 5, 2014 at 6:41 PM, Gabriel A. Devenyi <notifications@github.com
|
|
I'll do some tests to see if it happens at the same point every time. Gabriel A. Devenyi B.Eng. Ph.D. On Wed, Nov 5, 2014 at 7:30 PM, stnava notifications@github.com wrote:
|
|
thanks much! we are tired of this bug and want to exterminate it. but we brian On Wed, Nov 5, 2014 at 8:06 PM, Gabriel A. Devenyi <notifications@github.com
|
|
Here is a reproducible error: Example file at https://dl.dropboxusercontent.com/u/307000/input.mnc |
|
Key to triggering this is the |
|
Update: other key to triggering this is high-resolution files, essentially, crunching lots of voxels with no shink value triggers the exception. |
|
just as a note - this cropped up running antsCorticalThickness with the float option. Exception caught:
itk::ExceptionObject (0x3a5cba0)
Location: "unknown"
File: /data/software/sources/build/ITKv4-install/include/ITK-4.7/itkImageToImageFilter.hxx
Line: 248
Description: itk::ERROR: ImageToImageFilter(0x3b08df0): Inputs do not occupy the same physical space!
InputImage Origin: [-1.0227216e+02, -1.4657317e+02, 1.0400308e+02], InputImage_1 Origin: [-1.0227216e+02, -1.4657318e+02, 1.0400308e+02]
Tolerance: 1.9865040e-06
ERROR: command exited with nonzero status 1
Command: /data/software/ANTS//antsRegistration -d 3 -u 1 -w [0.025,0.975] -o antsCT_BrainExtractionPrior -r antsCT_BrainExtractionInitialAffine.mat -z 1 --float 1 -x [/data/scripts/templates/T_template0_BrainCerebellumExractionMask.nii.gz] -m
MI[/data/scripts/templates/T_template0.nii.gz,antsCT_N4Corrected0.nii.gz,1,32,Regular,0.25] -c [1000x500x250x100,1e-8,10] -t Rigid[0.1] -f 8x4x2x1 -s 4x2x1x0 -m MI[/data/scripts/templates/T_template0.nii.gz,antsCT_N4Corrected0.nii.gz,1,32,Regular,0.25] -c [1000x500x250x100,1e-8,10] -t Affine[0.1] -f 8x4x2x1 -s 4x2x1x0 -m CC[/data/scripts/templates/T_template0.nii.gz,antsCT_N4Corrected0.nii.gz,0.5,4] -m CC[antsCT_BrainExtractionTemplateLaplacian.nii.gz,antsCT_BrainExtractionLaplacian.nii.gz,0.5,4] -c [50x10x0,1e-9,15] -t SyN[0.1,3,0] -f 4x2x1 -s 2x1x0 |
|
yes - double may prevent ... or follow one of the other suggestions above. i havent encountered this issue w/recent versions which may be due to some recent changes in ITK. |
|
I ran into this problem and it is due to internal transformations applied to the q/s forms by ITK. It is not an ANTS bug. The only way I could get around it was to modify antsCorticalThickness.sh, antsBrainExtraction.sh and antsAtroposN4.sh to use fslcpgeom to copy the geometry from the input files at every processing stage. I have posted about this problem to the ITK bug system. |
|
This is great. Thanks for finding this. Can you post a link to the post that you made to ITK? Thanks again. |
|
Sure my bad, https://issues.itk.org/jira/browse/ITK-3346 |
Short answer is this is needed to fix long-standing registration bug that has plagued neuro-imaging community for several years. The main issue is described in detail on the ANTs issue tracker, but it is present in other applications as well. ANTsX/ANTs#74 Description: itk::ERROR: ImageToImageFilter(0x352ff90): Inputs do not occupy the same physical space! InputImage Origin: [9.5322963e+01, -1.1251340e+02, -1.3474442e+02], InputImage_1 Origin: [9.5322960e+01, -1.1251340e+02, -1.3474442e+02] ^ Tolerance: 1.8750000e-06 Several conversations exist that discuss changing the tolerance, but that is unsatisfactory, because it solves the symptom rather than the root problem. The crux of the problem is that we need to have a **LOSSLESS** conversion for displacement (and BSpline) transforms between their itk::Transform and thier itk::Image representations. The method that has been employed since is that the image physical space definition is serialized and stored as the Transform::FixedParameters of the transform type, and the displacement values are stored as the Transform::Parameters. For Images, the physcal space variables are always double precision. For Transforms, a recent enhancement allows the Parameters to be stored as either float or double precision. This is critical for many displacemnt field transform applications because disk storage and memory are often critical concerns when writing these applications. It should be noted that the size of paramters for displacement fields is often 256^3*3 values stored. In the recent enhancement of Transforms to allow for both float and double Parameters, the FixedParameters were also hard coded to the same scalar type. This introduced the intermitant problem (it does not manifest very often, only when the physcial space of an image is not accurately stored after 32bit truncation, AND subsequent use with pre-truncation values). It probably would have been better to just force the FixedParameters to always be double precision, but now that the other code has been "in the wild" this patch provides a completely backwards compatible solutions for allowing users to migrate to have a transform that has Parameters of type float, but FixedParamters of type double. ====== Use consistent names for template parameters Various names were used for template parameters that all refered to the same concept. TInternalComputationValueType -> TParametersValueType TScalar -> TParametersValueType TScalarType -> TParametersValueType ScalarType -> TParametersValueType were all used for representing the storage type for the Parameters of a transform. Use TParametersValueType consistently in all Transform files. Change-Id: Ieb55a6afb6a8316da218231f69ef55182bed1b5d
Short answer is this is needed to fix long-standing registration bug that has plagued neuro-imaging community for several years. The main issue is described in detail on the ANTs issue tracker, but it is present in other applications as well. ANTsX/ANTs#74 Description: itk::ERROR: ImageToImageFilter(0x352ff90): Inputs do not occupy the same physical space! InputImage Origin: [9.5322963e+01, -1.1251340e+02, -1.3474442e+02], InputImage_1 Origin: [9.5322960e+01, -1.1251340e+02, -1.3474442e+02] ^ Tolerance: 1.8750000e-06 Several conversations exist that discuss changing the tolerance, but that is unsatisfactory, because it solves the symptom rather than the root problem. The crux of the problem is that we need to have a **LOSSLESS** conversion for displacement (and BSpline) transforms between their itk::Transform and thier itk::Image representations. The method that has been employed since is that the image physical space definition is serialized and stored as the Transform::FixedParameters of the transform type, and the displacement values are stored as the Transform::Parameters. For Images, the physcal space variables are always double precision. For Transforms, a recent enhancement allows the Parameters to be stored as either float or double precision. This is critical for many displacemnt field transform applications because disk storage and memory are often critical concerns when writing these applications. It should be noted that the size of paramters for displacement fields is often 256^3*3 values stored. In the recent enhancement of Transforms to allow for both float and double Parameters, the FixedParameters were also hard coded to the same scalar type. This introduced the intermitant problem (it does not manifest very often, only when the physcial space of an image is not accurately stored after 32bit truncation, AND subsequent use with pre-truncation values). It probably would have been better to just force the FixedParameters to always be double precision, but now that the other code has been "in the wild" this patch provides a completely backwards compatible solutions for allowing users to migrate to have a transform that has Parameters of type float, but FixedParamters of type double. ====== Use consistent names for template parameters Various names were used for template parameters that all refered to the same concept. TInternalComputationValueType -> TParametersValueType TScalar -> TParametersValueType TScalarType -> TParametersValueType ScalarType -> TParametersValueType were all used for representing the storage type for the Parameters of a transform. Use TParametersValueType consistently in all Transform files. Change-Id: Ieb55a6afb6a8316da218231f69ef55182bed1b5d
Short answer is this is needed to fix long-standing registration bug that has plagued neuro-imaging community for several years. The main issue is described in detail on the ANTs issue tracker, but it is present in other applications as well. ANTsX/ANTs#74 Description: itk::ERROR: ImageToImageFilter(0x352ff90): Inputs do not occupy the same physical space! InputImage Origin: [9.5322963e+01, -1.1251340e+02, -1.3474442e+02], InputImage_1 Origin: [9.5322960e+01, -1.1251340e+02, -1.3474442e+02] ^ Tolerance: 1.8750000e-06 Several conversations exist that discuss changing the tolerance, but that is unsatisfactory, because it solves the symptom rather than the root problem. The crux of the problem is that we need to have a **LOSSLESS** conversion for displacement (and BSpline) transforms between their itk::Transform and thier itk::Image representations. The method that has been employed since is that the image physical space definition is serialized and stored as the Transform::FixedParameters of the transform type, and the displacement values are stored as the Transform::Parameters. For Images, the physcal space variables are always double precision. For Transforms, a recent enhancement allows the Parameters to be stored as either float or double precision. This is critical for many displacemnt field transform applications because disk storage and memory are often critical concerns when writing these applications. It should be noted that the size of paramters for displacement fields is often 256^3*3 values stored. In the recent enhancement of Transforms to allow for both float and double Parameters, the FixedParameters were also hard coded to the same scalar type. This introduced the intermitant problem (it does not manifest very often, only when the physcial space of an image is not accurately stored after 32bit truncation, AND subsequent use with pre-truncation values). It probably would have been better to just force the FixedParameters to always be double precision, but now that the other code has been "in the wild" this patch provides a completely backwards compatible solutions for allowing users to migrate to have a transform that has Parameters of type float, but FixedParamters of type double. ====== Use consistent names for template parameters Various names were used for template parameters that all refered to the same concept. TInternalComputationValueType -> TParametersValueType TScalar -> TParametersValueType TScalarType -> TParametersValueType ScalarType -> TParametersValueType were all used for representing the storage type for the Parameters of a transform. Use TParametersValueType consistently in all Transform files. Change-Id: Ieb55a6afb6a8316da218231f69ef55182bed1b5d
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. Fixes #74
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. Fixes #74
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. This uses a temporary ITK branch until the changes are formally included after the June 30 release of version 4.8. Fixes #74
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. This uses a temporary ITK branch until the changes are formally included after the June 30 release of version 4.8. Fixes #74
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. Fixes #74
|
I think this is fixed since @hjmjohnson 's ITK patch is now included in the ANTs' ITK build. |
This provides a working version of ANTS for convering displacements to/from itk::Image and itk::Transform without loss of precision. Fixes #74
BUG: ITK fix for resolution bug This fixes #74 issue
|
Fantastic. From: Nick Tustison [mailto:notifications@github.com] — This email has been scanned by the Symantec Email Security.cloud service. If you have any questions, please contact MCRI IT Servicedesk for further assistance. This email has been scanned by the Symantec Email Security.cloud service. |
|
I'm afraid I'm still seeing this :( I built version 6db2e19 (August 10) on Linux. ImageMath 3 headerTest2.nii.gz m headerTest1.nii.gz 0 PrintHeader headerTest1.nii.gz | grep srow PrintHeader headerTest2.nii.gz | grep srow PrintHeader headerTest3.nii.gz | grep srow These errors accumulate - for example I warp an image and then mask the result. It's causing antsJointFusion to fail with the physical space error. On Jul 3, 2015, at 5:31 PM, Nick Tustison notifications@github.com wrote:
|
|
Just ran into this as well: With version 9e1c52e Building HEAD now to see if ITK-4.11 fixes this. |
|
Your two images are very different---look at the spacing. The filter is working as intended. |
|
Then antsRegistration went way off the rails... |
|
That's really interesting. I don't think I've ever seen that before. Can you put together a complete example so I can investigate? Thanks. |
|
See example in #375 |
|
Thats intersting. I have this problem as well, while running N4BiasFieldCorrectionImageFilter in python. |
|
I wonder if this is related? https://issues.itk.org/jira/browse/ITK-3513 |
|
I just got while using Paul's hippocampal subfield scripts...I think during label fusion. Any ideas? |
|
It's the same issue described above. In terms of specifics, you'd have to trace the data processing through Paul's scripts yourself to figure out what is causing this problem. Or, perhaps, email Paul and ask him if he's seen this pop up. |
I'm getting an error when running a registration as part of antsCorticalThickness. It happens in the segmentation warp at the deformable stage.
To check that it wasn't bad initialization, I ran the affine part separately, then the deformable part. The affine initialization looks good. When I run the deformable part,
'''
antsRegistration -d 3 -u 1 -w [0.01,0.99] -o inputprefix_BrainSegmentationPriorDeformableOnly --float 1 -r [inputprefix_BrainExtractionPrior0GenericAffine.mat] -x [inputprefix_BrainSegmentationMaskDilated.nii.gz] -m CC[inputprefix_BrainExtractionBrain.nii.gz,inputprefix_ExtractedTemplateBrain.nii.gz,1,4] -c [100x100x70x20,1e-9,15] -t SyN[0.1,3,0] -f 6x4x2x1 -s 3x2x1x0
'''
It finishes the first level and then says
'''
Current level = 2 of 4
number of iterations = 100
shrink factors = [4, 4, 1]
smoothing sigmas = 2.0000e+00 vox
required fixed parameters = [128, 128, 96, 95.32296, -112.5134, -134.74442, 1.875, 1.875, 1.6999999, -0.05405264, -0.059213325, -0.9967809, 0.9985381, -0.0032052274, -0.053957522, -9.497458e-8, 0.99824023, -0.05930001]
Exception caught:
itk::ExceptionObject (0x352e7f0)
Location: "unknown"
File: /home/pcook/bin/ants/ITKv4-install/include/ITK-4.6/itkImageToImageFilter.hxx
Line: 248
Description: itk::ERROR: ImageToImageFilter(0x352ff90): Inputs do not occupy the same physical space!
InputImage Origin: [9.5322963e+01, -1.1251340e+02, -1.3474442e+02], InputImage_1 Origin: [9.5322960e+01, -1.1251340e+02, -1.3474442e+02]
Tolerance: 1.8750000e-06
'''
The difference in the origins appears to be less than the stated tolerance. I'm also confused why this would happen at this point after the affine and first level registration complete successfully.
The text was updated successfully, but these errors were encountered: