1

I have to mask a .nii MRI image for an internship I'm doing. The method I'm using involves multiplying the proton density weighted version of the image (captured during the inversion pulse) by the original mp2rage image. In order to do this I'm using Convert3D, however I'm getting a weird error that says "Images Do Not Occupy Same Physical Space". I am really lost here, and don't have much experience with this software, so if anyone knows how to fix this, or a better way to multiply .nii/nifti files, it would be really helpful. I am completely stuck. It looks like their origins are slightly different, maybe this is causing the problem, however I still have no idea how to fix it. I have tried setting the origin on both images to the same value 100x100x100mm using -origin, and then multiplying. This allows multiplication, however, I'm not sure if the result is what I want or if this is the right way to go about multiplying these images. I've attached the result below, as well as the commands I used to get it. Original Commands with Error

Result of Multiplication after manually setting origins

New Commands that allowed multiplication

JG98
  • 43
  • 5

2 Answers2

2

In ITK the images have to have all the same parameters before it will allow you to edit them. I.e, the same dimensions, spacing, origin, and orientation. Do the origins of your images differ by a lot? Or is it just a slight numerical error?

If they do not have the spatial parameters, the proper thing to do is to resample one image on top of the other. Using SimpleITK-Python, you could do something like this:

import SimpleITK as sitk

mri_image = sitk.ReadImage("your_mri.nii")
mask_image = sitk.ReadImage("your_mask.nii")

resampled_mask = sitk.Resample(mask_image, mri_image, interpolator=sitk.sitkNearestNeighbor)

masked_mri_image = mri_image * resampled_mask

If you just have a slight numerical difference between the image origins, spacings or directions, you could force them to be the same like this:

mask_image.SetSpacing(mri_image.GetSpacing())
mask_image.SetOrigin(mri_image.GetOrigin())
mask_image.SetDirection(mri_image.GetDirection())
Dave Chen
  • 1,905
  • 1
  • 12
  • 18
  • The difference seems to be very slight (the origins are in one of the images attached above), although I'm not really knowledgable enough to say for sure. I will try using .SetOrigin, .Setspacing, rather than -origin to set both to 100x100x100mm (which seems inaccurate). – JG98 Mar 23 '22 at 18:17
0

Doing pixel-wise multiplication requires the images to have the same size. To prevent errors, ITK's multiply image filter requires them to occupy the same physical space, too. For that they must have the same origin, spacing and orientation (direction), in addition to the same size. So indeed, it is a problem that their origins are slightly different.

You could open both in 3D Slicer, then modify the origin of one (e.g. the mask) to match the other, and save it. You can also use Slicer's Simple Filters module, and in there search for MultiplyImageFilter. That way you don't have to use Convert3D, and the results are visualized immediately.

enter image description here

Dženan
  • 3,329
  • 3
  • 31
  • 44
  • Thanks, I'll try this, I've also updated my post to show the result of manually setting each origin in convert3d using -origin at 100x100x100mm, however, I'm not sure if this is the correct way to go about doing this. It did allow the multiplication to occur though. – JG98 Mar 23 '22 at 17:46
  • Your result will have the origin of (100,100,100), which is different from both of your inputs. If you want to do any processing afterwards, this will likely cause issues. – Dženan Mar 23 '22 at 17:49
  • I just added a screenshot of Slicer's ability to modify metadata such as `origin`. – Dženan Mar 23 '22 at 17:50
  • Thanks, I will try slicer, and also in maybe in convert3d try setting the inversion image's origin to equal the mp2rage image (I believe the origins were given in the original multiplication step where I got the error), however the coordinates don't seem to be in the same format as the -origin command (since there are negative numbers). Do you think this would work, or should I just stick to slicer? – JG98 Mar 23 '22 at 18:04
  • ITK, ITK-SNAP and Convert3D use LPS coordinate system. Slicer (still) uses RAS, so first two origin coordinates are inverted. – Dženan Mar 23 '22 at 18:37
  • Hi, I'm actually getting the same error in slicer even when the origins are identical. What should I do? The error message is showing that the origins are the same, but still saying the inputs don't occupy the same physical space. It looks like whenever I change the origin in Slicer it doesn't actually save the changes. – JG98 Mar 24 '22 at 19:06
  • I was able to get it to work after multiplying in convert3d once the origins were changed in slicer, but for some reason slicer isn't allowing multiplication – JG98 Mar 24 '22 at 19:10
  • I guess that `convert3d` has lower precision requirements than Slicer. If you go to Slicer's options and increase number of decimal digits used to display numbers (origin coordinates), it is likely you will discover they differ at some further decimal place. See https://itk.org/Doxygen/html/classitk_1_1ImageToImageFilter.html#acc8f8667757385e7b607650620c58616 Default is `1.0e-6` from here: https://github.com/InsightSoftwareConsortium/ITK/blob/v5.3rc03/Modules/Core/Common/src/itkImageToImageFilterCommon.cxx#L26 – Dženan Mar 25 '22 at 13:49
  • Thanks, I will look into this, although I have to get the presentation on my findings today. I think I may also try to mask the mp2rage noise entirely in Slicer without using proton density weighted version of the image and just drawing an ROI. It seems that the origins being off center mess up the skull stripping process. – JG98 Mar 25 '22 at 18:17