Closed gdevenyi closed 7 years ago
The shrink factors specified in the second to last stage are your problem:
--transform BSplineSyN[0.1,26,0,3] --metric CC[nifti/brain2_0.5_t1.nii.gz,nifti/brain1_0.5_t1.nii.gz,1,4] --convergence [100x100x100x0,1e-6,10] --shrink-factors 16x8x4x2 --smoothing-sigmas 3x2x1x0 --masks [NULL,NULL] \
--transform BSplineSyN[0.1,3,0,3] --metric CC[nifti/brain2_0.5_t1.nii.gz,nifti/brain1_0.5_t1.nii.gz,1,6] --convergence [20,1e-6,10] --shrink-factors 1 --smoothing-sigmas 0 --masks [nifti/brain2_0.5_mask.nii.gz,nifti/brain1_0.5_mask.nii.gz]
The last level of that stage will have a shrink factor of 2. The program doesn't automatically upsample the resulting displacement field so when it tries to combine the two displacement fields of different resolutions, it throws that error. You should do this:
--transform BSplineSyN[0.1,26,0,3] --metric CC[nifti/brain2_0.5_t1.nii.gz,nifti/brain1_0.5_t1.nii.gz,1,4] --convergence [100x100x100x0x0,1e-6,10] --shrink-factors 16x8x4x2x1 --smoothing-sigmas 3x2x1x0x0 --masks [NULL,NULL] \
--transform BSplineSyN[0.1,3,0,3] --metric CC[nifti/brain2_0.5_t1.nii.gz,nifti/brain1_0.5_t1.nii.gz,1,6] --convergence [20,1e-6,10] --shrink-factors 1 --smoothing-sigmas 0 --masks [nifti/brain2_0.5_mask.nii.gz,nifti/brain1_0.5_mask.nii.gz]
Cheers! That's a crazy corner case!
Yeah, it's not one which anybody else has pointed out before. I've thought about doing something (a warning, perhaps) but I'm reluctant to make an assumption of intended usage on the part of the user. But given how often it comes up, it's not a priority to deal with at the moment.
SimpleITK on python gives a similar bug. I'm using the MICCAI BRATS database. Here's my code:
def N43D(fl):
im = SimpleITK.ReadImage(fl)
msk = SimpleITK.BinaryThreshold(im, 0, 0)
msk = SimpleITK.BinaryNot(msk)
msk = SimpleITK.Cast(msk, SimpleITK.sitkUInt8)
im = SimpleITK.Cast(im, SimpleITK.sitkFloat32)
im_n4 = SimpleITK.N4BiasFieldCorrection(im, msk)
SimpleITK.WriteImage(im_n4, os.path.splitext(fl)[0]+'_n4.mha', useCompression=True)
Also, I'm using multiple cores for a list of files:
dview.map_sync(N43D, fl)
The program runs fine for about 40 files. Then I get this error on all my engines:
[0:apply]:
RuntimeErrorTraceback (most recent call last)<string> in <module>()
<ipython-input-56-03a02a993653> in N43D(fl)
c:\users\shreyas_v\anaconda2\lib\site-packages\SimpleITK\SimpleITK.pyc in N4BiasFieldCorrection(*args, **kwargs)
43368
43369 """
> 43370 return _SimpleITK.N4BiasFieldCorrection(*args, **kwargs)
43371 class NaryAddImageFilter(ImageFilter_3):
43372 """
RuntimeError: Exception thrown in SimpleITK N4BiasFieldCorrection: c:\d\vs9-pkg\simpleitk-build\itk\modules\core\common\include\itkImageToImageFilter.hxx:248:
itk::ERROR: SubtractImageFilter(00000000065D8220): Inputs do not occupy the same physical space!
InputImage Origin: [0.0000000e+000, -2.3900000e+002, 0.0000000e+000], InputImage_1 Origin: [-5.9750000e+001, -5.9750000e+001, -3.8500000e+001]
Tolerance: 1.0000000e-006
InputImage Spacing: [1.0000000e+000, 1.0000000e+000, 1.0000000e+000], InputImage_1 Spacing: [5.9750000e+001, 5.9750000e+001, 3.8500000e+001]
Tolerance: 1.0000000e-006
This looks like an N4 issue as opposed to a registration issue although the same exception is being thrown in the parent itkImageToImageFilter class. Can you reproduce this using the latest N4BiasFieldCorrection
from the ANTs repo?
I'm sorry, I'm using Windows server 2012 standard edition. I don't know how to use ANTs on it.
Okay, there's a couple other things you can do:
1) Contact the people who created SimpleITK and ask them about this issue. 2) You can try temporarily changing the header of the input image to have an origin of 0x0x0 and an identity direction matrix during processing and then changing it back after processing. Sometimes that helps.
Actually, I did contact them but have yet to find a solution. If you look at my code, the mask was created using the image itself, so there's no way that the headers would change. Still I'll check it.
If you look at my code, the mask was created using the image itself, so there's no way that the headers would change. Still I'll check it.
You're not understanding what I'm saying. I'm suggesting that you change the orientation/position of the input image prior to processing. Also, see here.
Yes I did change the origin to 0x0x0 still:
[0:apply]: RuntimeErrorTraceback (most recent call last)
Followup to my comment on #74.
Built on current HEAD
The run command:
Example files used: https://www.dropbox.com/sh/5ea8lff1nb0skmr/AADughEXzPYWhQ1Q5uCw653Ga?dl=0
The log