[SyneRBI/SIRF] Image writer (Issue #1090)
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:
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
David Atkinson
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).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ckolbPTB
@DANAJK no, this does not change the images much
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kris Thielemans
dcmdump or gdcmdump will output dicom header info to stdout
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kris Thielemans
@evgueni-ovtchinnikov throw error or warning in NiftiImageData when it's not a 3D image
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kris Thielemans
@evgueni-ovtchinnikov please check these:
- throw error or warning in
NiftiImageDataif not 3D volume - extension processing here https://github.com/SyneRBI/SIRF/blob/cb4d251e0e8960365c3f63eeac2c5cf0ec7346e2/src/xGadgetron/cGadgetron/include/sirf/Gadgetron/gadgetron_data_containers.h#L501
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.