DICOM Image writer for MR

[ckolbPTB]

I tried to save reconstructed MR images as dicom/nifti images but I ran into a couple of issues.

Here is the script which I ran on v3.2:

import sirf.Gadgetron as pMR
import sirf.Reg as pReg
import sys

path_out = sys.argv[1]
file_out = 'mr_sirf_data_out'
path_raw = pMR.examples_data_path('MR')

rawdata = pMR.AcquisitionData(path_raw + '/' + 'simulated_MR_2D_cartesian.h5')
rawdata = pMR.preprocess_acquisition_data(rawdata)
rawdata.sort()

recon = pMR.FullySampledReconstructor()
recon.set_input(rawdata)
recon.process()
img_data = recon.get_output()

img_data = img_data.abs()
img_data /= img_data.as_array().max()
img_data *= 2^16

img_data.write(path_out + '/' + file_out + '.dcm') # writer 1
img_data.write(path_out + '/' + file_out + '.nii') # writer 2
img_data.write(path_out + '/' + file_out + '.png') # writer 3

nii_img = pReg.NiftiImageData(img_data)
nii_img.write(path_out + '/' + file_out + '_nii_im_data.nii') # writer 4

print('Shape of image data ', img_data.as_array().shape)

This code runs without any obvious error messages but the results are not as expected. The image dimensions displayed in the last line are 2 x 256 x 256.

Writer 1 yields two dicom images each with a size of 256 x 256 but with a content which looks different depending on how it is openend:

In ImageJ:

in OSIRIX

in MIELE LXVI

I know that dicom is not an easy format but I think it is important that the dicom output of SIRF can be interpreted by a viewer which is commonly used in radiology.

Writer 2 and 3 also create files with the extension .nii and .png but are not nifti or png images. I would have expected this to lead to an error message about unsupported file types.

Writer 4 yields a nifti images which I can open and looks (almost) as expected:

Almost because it only yields one nifti image of size 256 x 256 but the image shape was 2 x 256 x 256.

[DANAJK]

Just a guess, but have you tried scaling to 1 below 2^16, i.e. img_data *= (2^16 - 1) and then rounding to integer values? The range of uint16 is 0 - 65535 (not 1 - 65536).

[ckolbPTB]

@DANAJK no, this does not change the images much

[KrisThielemans]

dcmdump or gdcmdump will output dicom header info to stdout

[KrisThielemans]

@evgueni-ovtchinnikov throw error or warning in NiftiImageData when it's not a 3D image

[KrisThielemans]

@evgueni-ovtchinnikov please check these:

• throw error or warning in NiftiImageData if not 3D volume
• extension processing here https://github.com/SyneRBI/SIRF/blob/cb4d251e0e8960365c3f63eeac2c5cf0ec7346e2/src/xGadgetron/cGadgetron/include/sirf/Gadgetron/gadgetron_data_containers.h#L501

[evgueni-ovtchinnikov]

I spent some time investigating this issue, and so far as I have understood, the constructor of a NiftiImageData object can take only one image as the input. In Christoph's script, img_data contains two images for two repetitions, so the second one is ignored. I tried to stack them together into one 3D image, and the script produced desired output, but some tests failed, and I actually do not believe it would be a good idea to make a pseudo-image out of two repetitions.

[evgueni-ovtchinnikov]

Regarding dicom output: I am not sure the dicom files produced by Christoph's script were ok as there was a bug in SIRF fixed by PR #1143. @ckolbPTB: if you can get a server running Gadgetron 4.1.2, then could you please re-run your script using SIRF on branch try-fix-ip-chain?

My laptop opens dicom files with MicroDicom, and each of the two dicom images in question look like this:

[ckolbPTB]

@evgueni-ovtchinnikov thank you for looking into this. I will give it a try but might take some time as I am organising a small workshop next week.