Inconsistency between Slicer 3.6 and Slicer 4.10.2 in mhd header

Dear all,

When open exactly the same image (hdr + img format), and save into mhd format using Slicer 3.6 and Slicer 4.10.2 gives different .mhd file regarding RAI VS RPI and transformation Matrix as below and attached pic.

Slicer 3: RPI, 1,-1,1 matrix
Slicer 4: RAI, 1,1,1 matrix

The paired info above becomes consistent indeed for the raw data reading order.

But my confusion is, when viewing the image, Slicer 3.6 shows differently than Slicer 4.10.2.

So my questions are:

  • Why Slicer 3 and Slicer 4 has this difference when saving .mhd? any motivation for the update?
  • Why exactly the same image shows differently in Slicer 3 and 4?

Any advices are highly appreciated! Thank you very much.

Best regards, Xiaogai

Slicer4 header is compliant to the metaIO standard. Both files encode the same information. Maybe Slicer3 did not read AnatomicalOrientation tag but assumed to be RAI.

We tried to provide backward compatibility (you can read old scene files with new Slicer versions), but no forward compatibility (read scene files saved with older version of Slicer). Since Slicer3 is about 10 years old, it is a wonder that it can still run on a current computer.

1 Like

Thank you very much for your answer! I understand Slicer 3 is a bit too old, the reason still use it is due to some earlier work done years ago used Slicer 3, and now when using Slicer 4 found the difference.

Have done further test, seems to me that Slicer 4 always save mhd to AnatomicalOrientation RAI plus TransformationMatrix Identity, no matter what orientation was. But Slicer 3.6 indeed distinguish. Seems to me Slicer 3.6 is doing more correct things than Slicer 4. I also saved to nhdr format and compared Slicer 3.6 and Slicer 4.10, also seems Slicer 3.6 is more correct. See following capture tested with a image oriented not RAI.

Please correct me if I am wrong. Thanks a lot for your help.

Those nhdr files are describing different geometry (the AP directions are flipped). I see from your original post that you loaded these from Analyze format (.img and .hdr). Unfortunately Analyze format has well documented ambiguity about orientation and has mostly fallen out of use in favor of NIfTI or NRRD.

Probably the ITK code Slicer uses to read Analyze has been debugged over the years to better match the most common conventions, but realistically there no “correct” answer given that different packages have used the format differently.

You probably need to manually correct this flipping based on some extra knowledge about the source of the image files in question.

Hope that helps.

1 Like

Thanks indeed very helpful!

Yes the image was loaded from Analyze format (.img and .hdr). What you said seems a good explanation why Slicer4 and Slicer4 saved to flipped image: Due to ITK Analyze reader Slicer uses are different.

Then back to the mhd format which I am most interested in. As mentioned earlier no matter what orientation the original source of image is (RAI, LPS or others), when saved into mhd using Slicer4, the mhd header always write: RAI+TransformMatrix as Identity matrix. I would guess then the .zraw image order is adjusted accordingly to its original image. I will test more to confirm. At least now it is clear Slicer3 and Slicer4 behaves differently when save to mhd file for a good reason.

Thanks again for all the valuable discussions.

A couple of years ago we asked Kitware (developer and maintainer of metaimage file format) about Anatomical Orientation tag and they responded that it is informational only and it should not be used for updating direction cosines. We updated Slicer accordingly.

Interestingly, recently Kitware has revised this decision and now considering using AnatomicalOrientation tag to update axis directions after all. If Kitware ends up updating MetaIO library and mha reader/writer in ITK then Slicer’s behavior maybe become more similar to the Slicer3.

All these of course for your information only. To make your scenes usable in current Slicer, you need to follow @pieper’s recommendation above and fix up the header or apply a transform to your images as needed.

1 Like

Thanks a lot for all the info! Now all seems clear to me.