NITRC dcm2nii Forum: questions

RE: Issue converting dicom to nifti for diffusion GE data

Chris Rorden — Fri, 26 Jul 2024 14:43:11 GMT

Understood. I would suggest you reach out to the maintainers of the health portal to understand why these DICOMs lack the Software Versions (0018,1020) tag. It is a Type 3 (optional) public tag, so it is not required by a valid DICOM. However, this is not only required to determine slice timing, but is crucial for auditing errors or changes in sequences. I would not consider these images to be of archival qaulity.

RE: Issue converting dicom to nifti for diffusion GE data

Amy Jolly — Fri, 26 Jul 2024 7:09:08 GMT

Chris,
 
Thank you so much for your help. I suspect it is because the images are only provided via download from a 3DNet health portal, but I am guessing here!
 
Best wishes,
Amy

RE: Issue converting dicom to nifti for diffusion GE data

Chris Rorden — Wed, 24 Jul 2024 23:39:12 GMT

Amy
 
Thanks for the sample dataset. The problem is described here
  https://github.com/rordenlab/dcm2niix/issues/838
This problem is now fixed in the development branch - and will be included in the next major release. In the mean time, you can compile your own copy of the development branch. As a bonus, if you build with the USE_OPENJPEG option it will convert your rare DICOM compression transfer syntax. So the steps would be:
git clone --branch development https://github.com/rordenlab/dcm2niix.git cd dcm2niix mkdir build && cd build cmake -DZLIB_IMPLEMENTATION=Cloudflare -DUSE_JPEGLS=ON -DUSE_OPENJPEG=ON .. make cd bin ./dcm2niix /path/to/dicoms
This was a very unusual sequence, with a lot of derived images and RGB colored screenshots. Since the software version was stripped from the DICOMs, you will need to  manually insert the slice timing fields into your EPI data. You may want to check the provenance of these images to see why the public software version tag was removed from your data - that is helpful for audits and to control variability. Beyond these points, the images themselves look terrific - the GE Premier's name is truth in advertising.

RE: Issue converting dicom to nifti for diffusion GE data

Amy Jolly — Wed, 24 Jul 2024 15:12:08 GMT

I decompressed the DICOMs in this folder looping through using gdcmconv but still get a segmentation fault (without the Image Decompression issue). 
Chris Rorden's dcm2niiX version v1.0.20240202  (JP2:OpenJPEG) (JP-LS:CharLS) Clang12.0.0 ARM (64-bit MacOS)
Found 3960 DICOM file(s)
Segmentation fault: 11
 
Thanks,
Amy
 
Originally posted by Amy Jolly:
<blockquote>
Hi Chris,
Hope you are well. I am struggling to convert some clinical data I received from a GE Signa 750. I've ensured I've downloaded the lateset release for dcm2niix to handle some of the quirks of GE and it seems to convert some images but not others. The one image I want (dwi) is failing.
This is the current error message I get: 
Chris Rorden's dcm2niiX version v1.0.20240202  (JP2:OpenJPEG) (JP-LS:CharLS) Clang14.0.3 ARM (64-bit MacOS)
Found 3960 DICOM file(s)
Image Decompression is new: please validate conversions
Segmentation fault: 11
 
Would you have any suggestions on what to do?
 
Thanks,
Amy
</blockquote>

RE: Issue converting dicom to nifti for diffusion GE data

Amy Jolly — Wed, 24 Jul 2024 15:03:22 GMT

Hi Chris,
Sorry for the delay. Would I need to decompress each individual .dcm within a folder and then try to run dcm2niix again? 
For example in this folder alone there are ~3959 dicoms. I've just tried running gdcmconc -w command on a single .dcm file and it seems to have worked. Assume I just need to loop through them all to apply this decompression and then try dcm2niix again?
 
Thanks,
Amy

RE: Issue converting dicom to nifti for diffusion GE data

Chris Rorden — Fri, 19 Jul 2024 14:37:58 GMT

Does decompressing your DICOMs show errors with other tools? If not, can you convert the decompressed images with dcm2niix? You can use dcmdjpeg or gdcmconv to decompress your images, e.g.
gdcmconv -w in.dcm out.dcm

Issue converting dicom to nifti for diffusion GE data

Amy Jolly — Fri, 19 Jul 2024 8:48:03 GMT

Hi Chris,
Hope you are well. I am struggling to convert some clinical data I received from a GE Signa 750. I've ensured I've downloaded the lateset release for dcm2niix to handle some of the quirks of GE and it seems to convert some images but not others. The one image I want (dwi) is failing.
This is the current error message I get: 
Chris Rorden's dcm2niiX version v1.0.20240202  (JP2:OpenJPEG) (JP-LS:CharLS) Clang14.0.3 ARM (64-bit MacOS)
Found 3960 DICOM file(s)
Image Decompression is new: please validate conversions
Segmentation fault: 11
 
Would you have any suggestions on what to do?
 
Thanks,
Amy

RE: Philips enhanced dicoms

Chris Rorden — Tue, 11 Jun 2024 12:55:49 GMT

This question is underspecified, as I do not know what Philips warning is being referred to. However, it is worth noting that Philips DICOMs are impoverished, so the resulting BIDS sidecars will not contain the information you expect from other manufacturers.
  https://github.com/rordenlab/dcm2niix/tree/master/Philips#missing-information
More generally, the Philips enhanced DICOMs have a huge amount of redundant data, which makes the file sizes much larger than the enhanced images from Canon and Siemens, yet they lack the diversity of data required to fully analyze data. I would work with the Philips clinical scientists associated with your site to see if more data can be added. 
 
I would be particularly concerned about Philips DICOMs from R11.1 and later, as there are clearly examples where the data is not truthful.
https://github.com/rordenlab/dcm2niix/issues/809

Philips enhanced dicoms

Matthew Sherwood — Tue, 11 Jun 2024 0:22:17 GMT

I was just wondering if anyone could explain the Philips enhanced dicom warning?

RE: Cropping 3D acquisitions throwing error

hr3260 — Thu, 06 Jun 2024 1:49:03 GMT

Here's a snippet from the output log from a previous participant:

Chris Rorden's dcm2nii :: 2MAY2016 64bit BSD License :: (upgrade to dcm2niix suggested)
reading preferences file /home/USER/.dcm2nii/dcm2nii.ini
Data will be exported to /outdir/
Validating 1328 potential DICOM images.
Found 1319 DICOM images.

.....

Converting 123/1017 volumes: 1
file.dcm->MPRAGETRAT1.nii
For slice timing correction: the slice order is Siemens-even interleaved ascending (2,4..,1,3...)
brightest voxel was 1253: data will be saved as 16-bit signed integer.
Saving /outdir/MPRAGETRAT1.nii
Reorienting as /outdir/oMPRAGETRAT1.nii
Saving /outdir/oMPRAGETRAT1.nii
Cropping NIfTI/Analyze image /outdir2/oMPRAGETRAT1.nii
Saving /outdir/coMPRAGETRAT1.nii

.....

Where the command calling dcm2nii (older version from an older script) was:

subprocess.call('dcm2nii -d N -e N -f N -i N -4 Y -g N -n Y -o '+ExpLoc+' -v Y '+glob(Folder[Day])[0]+' > '+ExpLoc+'/conversion.txt', shell=True).

dcm2nii was updated to dcm2niix, but calling dcm2niix with:

subprocess.call(["dcm2niix", "-f", "%p", "-x", "y", "-o", ExpLoc, glob(Folder[Day])[0]])

doesn't seem to crop or rotate the .dcm file. The main issue is that only one file is not being cropped and reoriented. I've run the above dcm2niix command in the terminal on the single file and it prompts the error mentioned in my earlier post.

EDIT: Ignore this post, I've since resolved the issue.