Convert MRI from DICOM (exported by syngo.via) to NRRD

Support
1

Hello everyone!
I have a series of MRI cardiac images (more specifically I have the most significant slice for each patient; i.e. one image for each patient). I have extracted all these images with the software Siemens Syngo Via in a DICOM format.

Since I want to mine these data with a machine learning approach, I wanted to use the open-source platform pyradiomics. In order to use this package I need the images in the .nrrd format, so I followed this guide and it worked well.

The only problem is that the new .nrrd images have a different pixel spacing from the original dicom ones. More specifically they now have a pixel spacing in microns and not in mm like before. Moreover, the spacing has been automatically re-set to (1,1) while before it was something like (0.89,0.89). Does 3D slicer automatically rescale images?

How could I solve this issue?

Thanks a lot in advance,
Tommaso

2

Slicer will use the data from the header (in mm) but you can change this in the Volumes → Volume Information fields and resave if you want.

1 Like
3

Hi Pieper and thanks for answering my question!

Maybe I have expressed myself wrong. I know that it is possible to modify the spacing in Volumes>Volume information…the fact is that if I open my DICOM image for instance in ImageJ I have a 512x512 matrix with a FOV of 460x460 mm^2 and hence a pixel spacing of about 0,89 (469/512), while both when I open the same DICOM image with 3D slicer and I save it to .nrrd I get (1,1,1) mm as pixel spacing and not for instance (0.89, 0.89, 0) as I would expect.

Is this normal?
Thanks a lot again

4

If you have access to the original DICOM I suggest loading that to Slicer and saving it as nrrd, without using Syngo Via’s export option. Slicer should interpret the original DICOM correctly and the nrrd file sohuld come out as expected.

1 Like
5

Hi Csaba!
I had to go necessarily through SyngoVia because the software they are using here at the hospital for the PACS is Agfa IMPAX and, unfortunately, doesn’t allow the DICOM extraction

6

I see, thanks for the clarification. I’m not familiar with SyngoVia, but maybe it has some export options to keep as much of the original DICOM metadata as possible.

@fedorov If I remember correctly you have worked with SyngoVia. Did you have an established protocol for DICOM export that worked well with Slicer?

7

On our installation, there is a standard DICOM export to file system feature. I cannot explain the discrepancy between Slicer and ImageJ that is happening in the case of @Tommaso_Di_Noto. Not sure how to debug it without access to a sample dataset.

2 Likes
8

If Imagej is writing out the spacing as .89, .89, 0 then ITK may think it cannot read valid spacing and default to 1,1,1.

9

@pieper the way I understood it, the issue is that image is read from DICOM both in Slicer and ImageJ, but the spacing interpreted from DICOM is different.

10

Yes, could be - @Tommaso_Di_Noto can you clarify?

1 Like
11

I’ve been helping @Tommaso_Di_Noto on this error as well, see also this issue in PyRadiomics.

As far as I can see, ITK (ITKsnap also misinterpreted the DICOM spacing) is having troubles parsing the spacing as it is encoded in the DICOM. In an example @Tommaso_Di_Noto sent, spacing was encoded as [5.0781200E-001\5.0781200E-001], maybe there is an issue with dealing with the E-001?

1 Like
12

@JoostJM no, this is a valid content for PixelSpacing (see http://dicom.nema.org/dicom/2013/output/chtml/part05/sect_6.2.html). I also made a fake dataset with exact same PixelSpacing, and confirmed it is read correctly into Slicer. Must be something else.

@Tommaso_Di_Noto can you run this DICOM validator on your dataset and let us know what it says: http://www.dclunie.com/dicom3tools/dciodvfy.html

13

I also checked that SimpleITK can read the dataset I created for testing, and it does not reset spacing to 1.

$ dcmdump image/IMG0001.dcm|grep Spacing                                                                                                                                                 2.3.6
(0028,0030) DS [5.0781200E-001\5.0781200E-001]          #  30, 2 PixelSpacing
...
In [3]: i=sitk.ReadImage("image/IMG0001.dcm")
In [5]: i.GetSpacing()
Out[5]: (0.507812, 0.507812, 1.0)
1 Like
14

Hmm, I rechecked the testset @Tommaso_Di_Noto sent, and I’m seeing that the ImageOrientationPatient (0020,0037) and ImagePositionPatient (0020,0032) are missing, could this cause the error perhaps?

15

Yes, that very likely could be a problem. I don’t know how it is handled by the libraries, but I am pretty sure this will render the dataset non-compliant with the standard.

16

Exactly, Slicer>Volume shows (1,1,1), while the ImageJ>Image Info says: Pixel Size: 0.8984x0.8984 mm^2

17

@pieper @fedorov Sorry if I’m only answering now, but my Slicer/gmail notification was turned off, so I only saw your replies now. I turned it on now! Anyway:

@JoostJM: Yes, I’ve also checked the cardiac images and the ImageOrientationPatient (0020,0037) and ImagePositionPatient (0020,0032) are missing there too.

As far as the feature extraction is concerned, do you think it’s a problem if I go forward with this .dcm to .nrrd conversion done in Slicer? I though that since it rescales ALL images to (1,1,1) and the .nrrd image created is read without errors in PyRadiomics, features shouldn’t suffer from different pixel spacing issues. I tried to explain more or less the same thing here.

Let me know if this makes sense :wink:

18

@JoostJM shared the pointer to the dataset. It is a secondary capture, and it doesn’t have to have the position/orientation. Probably ITK resets to spacing of 1 when those are missing, since it is not possible to know the 3d geometry of the image. Since ImageJ operates purely in 2d, it does not need to worry about geometry, and so this does not trigger an issue there.

@Tommaso_Di_Noto I think your options are:

  1. explore if you can export the dataset as MR, not secondary capture - have you tried export to file system option in syngo.via?
  2. modify the spacing manually or in a script to use the one from the secondary capture PixelSpacing

In-plane spacing matters for some of the radiomics features, so it can be important.

19

@fedorov

syngo_via
syngo_via1920Ă—1080 222 KB

In yellow I have highlighted the options I chose when I extracted the images;

(The white circles are just to shade the patient’s name)

What could I change?

Eventually, if I wanted to manually change the spacing, how could I do it? I mean…with which program? And should I do it on the original .dcm extracted from SyngoVia or on the .nrrd extracted from Slicer?

Thanks a lot!!

20

Indeed, that’s what I would do too. Not sure, perhaps secondary capture is what is on PACS.

$ pip install SimpleITK
$ pip install pydicom

Then you can use something like this script:

import SimpleITK as sitk
import pydicom, sys

i = sitk.ReadImage(sys.argv[1])
d = pydicom.read_file(sys.argv[1])
s = d.PixelSpacing[0]
i.SetSpacing([s,s,1])
sitk.WriteImage(i,sys.argv[2])
1 Like