# Convert MRI from DICOM (exported by syngo.via) to NRRD
**URL:** https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555
**Category:** Support
**Created:** [April 10, 2018, 9:06am UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555 "2018-04-10T09:06:03Z")
**Posts on this page:** 9
**Page:** 2
### Author:  [@Tommaso\_Di\_Noto](https://discourse.slicer.org/u/Tommaso_Di_Noto)
#### Post date: [April 12, 2018, 7:25am UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/21 "2018-04-12T07:25:22Z")
Thanks a lot @fedorov. I’ll try to modify it manually. Just one questions:
1. I understood that sys.argv[1] takes the first command line argument passed to my script, but how can I pass my image as first argument? Should I do it in command line or like in python IDLE?
Thanks again!
---
### Author:  [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [April 12, 2018, 1:49pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/22 "2018-04-12T13:49:30Z")
Sorry for the lack of usage instructions… You can save that code in a (for example) `converter.py` file, and then run it as follows from the command line:
```bash
$ python converter.py input_dicom_image_slice output.nrrd
```
Typically, I do not use python IDE, so I cannot give you instructions on how to run this code from an IDE.
---
### Author:  [@Tommaso\_Di\_Noto](https://discourse.slicer.org/u/Tommaso_Di_Noto)
#### Post date: [April 12, 2018, 2:55pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/23 "2018-04-12T14:55:37Z")
Thanks a lot @fedorov! It seems to work!
The .nrrd image that is now created has the same pixel spacing of the original dicom one. There’s still a funny fact though: while in Slicer the pixel spacing is correct and in _mm_ (as the original), in ImageJ the pixel spacing is correct, the size is also correct (it was modified to 512,512,1) but the unit of measure is still in _microns_…maybe it’s really just an ImageJ bug!
Anyway, this leads us to my initial question I asked in PyRadiomics to @JoostJM:
Now that the pixel spacing is preserved during the conversion to nrrd, but my images have different pixel spacing, is there a rule to decide the resampling with `imageoperations.resampleImage`? I mean…if I have some images with a pixel spacing of (0.89, 0.89) _mm_ and others with a pixel spacing of (1.2,1.2) _mm_ should I just resample them to a mean pixel spacing? Should I choose the smallest spacing and resample all images to that?
Thanks a lot in advance for your amazing support!
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 12, 2018, 3:39pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/24 "2018-04-12T15:39:27Z")
ImageJ is mostly used for microscopy imaging and ignores most DICOM metadata, so it is not surprising that it blindly assumes unit is always microns.
In general, in medical image computing algorithms, visualization and analysis is always performed in physical space, so it does not matter much what was the resolution of the input images. @JoostJM can confirm if pyradiomics properly takes image spacing into account when computing metrics.
---
### Author:  [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [April 12, 2018, 4:28pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/25 "2018-04-12T16:28:45Z")
One example where units may matter in pyradiomics is smoothing filter sigma is defined in mm, which will be a problem if defaults are used and the actual units are microns.
I agree with @lassoan - it is likely ImageJ just assumes microns. That image is a human head, right?
> [@Tommaso\_Di\_Noto](#):
>
> Now that the pixel spacing is preserved during the conversion to nrrd, but my images have different pixel spacing, is there a rule to decide the resampling with imageoperations.resampleImage? I mean…if I have some images with a pixel spacing of (0.89, 0.89) mm and others with a pixel spacing of (1.2,1.2) mm should I just resample them to a mean pixel spacing? Should I choose the smallest spacing and resample all images to that?
There is not really a “correct” answer to this. As a general rule you will lose information by resampling. As another general rule, harmonized acquisition protocol is recommended for this kind of studies. The rest is your decision that you need to make based on your application, your data, and your analysis of the relevant literature.
Welcome to the world of research with no ground truth! We are here to help you get started with the tools, but the rest is up to you.
---
### Author:  [@Tommaso\_Di\_Noto](https://discourse.slicer.org/u/Tommaso_Di_Noto)
#### Post date: [April 16, 2018, 6:29am UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/26 "2018-04-16T06:29:08Z")
hehe ok sure! Thanks a lot again! @fedorov
---
### Author:  [@JoostJM](https://discourse.slicer.org/u/JoostJM)
#### Post date: [April 16, 2018, 10:30am UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/27 "2018-04-16T10:30:43Z")
@Tommaso_Di_Noto, What you can also try is to `export stack` instead of `export image` in syngo via, if I’m correct, this will export the entire volume and maybe prevents the conversion to secondary capture.
As to your other points, I agree with @fedorov, with the small addition that, especially for texture features, ‘common’ protocols is advised. Specifically for image spacing, this means that you are looking at the same level of texture (i.e. fine or coarse) and there is some literature available that has shown that some features are dependent on the voxel size (although this is usually due to some interaction with volume, the true dependency is the number of voxel in the VOI)
---
### Author:  [@lkcl](https://discourse.slicer.org/u/lkcl)
#### Post date: [June 18, 2025, 6:20pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/28 "2025-06-18T18:20:33Z")
hello all,
i just got an MRI scan using a Siemens Tesla 1.5 and
asked for CDs with the DICOM data on it. turns out it
is also syngo - an autorun.exe installation of syngo is
on the CD, which i extracted avoiding windows entirely
with:
```auto
dd if=/dev/sr0 bs=1M of=mri1.iso
mount -o loop /mnt/cdrom ./mri1.iso
```
was able to copy the files from /mnt/cdrom,
umount /mnt/cdrom, and then import the dicom
data directory… which failed.
an hour’s investigation shows that they simply
blast the JPEG2000 data onto the end of the
DICOM data - no end-tag, no length indicator,
nothing.
therefore, the simple (and absolutely dreadful)
hack below was “successful” in simply assuming
that the rest of the DICOM file was the JPEG2000
raw data. note that i assume that the read of 10mb
will succeed: there is nothing sophisticated here.
```auto
+ logger_debug("Reading undefined length data element"
+ f"{fp_tell():08X}")
+ value = (True, fp.read(100000000))
+ logger_debug("Read %d bytes" % len(value[1]))
+ #value = read_undefined_length_value(
+ # fp, is_little_endian, delimiter, defer_size
+ #)
```
anyone wishing to make a similar hack to their installation
of Slicer, of course taking full responsibility for doing so,
would need to modify this file:
./lib/Python/lib/python3.12/site-packages/pydicom/filereader.py
p.s. note, if you have a newer version of Slicer you need this instead
```auto
value = fp.read(100000000)
logger_debug("Read %d bytes" % len(value))
```
---
### Author:  [@lkcl](https://discourse.slicer.org/u/lkcl)
#### Post date: [December 24, 2025, 6:00pm UTC](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555/29 "2025-12-24T18:00:15Z")
folks was this actioned and resolved in future releases?
checking Slicer-5.11.0-2025-12-15-linux-amd64 the answer is “no”
[Previous page](https://discourse.slicer.org/t/convert-mri-from-dicom-exported-by-syngo-via-to-nrrd/2555.md?page=1)