Hi all,
Hope it is ok to start a new topic on dcm2niix. I think I did my homework by looking at others discussions and attempts on DWI images
{ i.e.,
}
Using 3DSlicer 4.10.2 / Windows 64
My problem:
Reading of raw DCM files from a DWI scan from viewer NilRead.
“Diffusion-weighted DICOM Import (DWIConvert) standard error:
…
…
E: can’t change to unencapsulated representation for pixel data
E: can’t determine ‘PhotometricInterpretation’ of decompressed image
E: mandatory attribute ‘PhotometricInterpretation’ is missing or can’t be determined
Error: no DICOMfiles found in inputDirectory: C:/Users/jkelly/AppData/Local/Temp/Slicer/SlicerTemp
Unable to create converter”
As expected, this method didn’t work either:
3D slicer → DICOM import → Advanced → examine → load as Diffusion volume
Error “Could not load: axDTI_30_64ch - as DWI Volume as a Diffusion Volume”
So I tried dcm2niix version v1.0.20190902 in MRIcron using these options
It loads the nrrd output as a diffusion weighted file but scrambles the image
If instead I use dcm2niix to output NIFTI with default parameters (using command line)
I get a coherent image but 3Dslicker thinks it is a scalar volume, and I cannot process the data.
I see the json file spits out important information of which here are a sample:
“ImagingFrequency”: 123.23,
“Manufacturer”: “Siemens”,
“ManufacturersModelName”: “Prisma_fit”,
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“ConversionSoftware”: “dcm2niix”,
“ConversionSoftwareVersion”: “v1.0.20190902”
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“ConversionSoftware”: “dcm2niix”,
“ConversionSoftwareVersion”: “v1.0.20190902”
Can I suggestion you run dcm2niix from the command line with logorrheic verbosity -v 2 and ignoring derived images -i y, e.g. dcm2niix -v 2 ~/DICOMS/. It would also help to see the fslhd output of the NIfTI file created or more details from the BIDS header, in particular the ImageType tag. My first guess is that you are having problems with a derived image, e.g. the color FA map. Slicer wants scalar images and tends to handle derived color images oddly. I would suggest that you adjust your sequence to not save derived images (e.g. on the Prisma "Diffusion’ tab, uncheck any derived images (FA, ADC, Trace, etc). You can always create better derived images after post-processing (de-Gibbs, de-noise, Eddy, TOPUP). If you still have issues, feel free to post an issue on the dcm2niix Github web page.
For settings up DWI scans on a Prisma, you may want to look at this page, albeit your 64 channel head(40)/neck(24) coil will allow more aggressive multi-band. I would recommend the CMRR diffusion sequences - be aware that the Siemens Product diffusion sequences have a bug in such that if you copy references between a A-P and a P-A scan the second series will be rotated 90-degrees (e.g. R-L) nor 180 degrees (P-A). With the CMRR sequences, you will be able to set “reversed RO/PE” to reverse phase encoding for proper phase encoding reversal (for TOPUP/Eddy). Also be aware that the default diffusion schemes for Siemens are half-sphere, so if you have a research license you will want to insert your own whole-sphere schemes for optimal use of Eddy.
If you have the 32-channel head-only coil, I would suggest you test it to see if it provides better performance than the 64-channel head/neck coil. The page I list above describes how to compute SNR. The 64-channel has some inherent limitations: the integrated neck coil forces a rotation to the head such that the cheek bones hit the coil and the frontal lobes are pushed away from the small coils. I would also check if the smaller coils had sufficient SNR in deep regions of the brain (e.g. main white matter tracts). I believe the 64-channels also required bandwidth compression at one stage, and I am not sure if this was resolved. You may want to check if de-selecting the neck channels (from the System tab) improves SNR. When we purchased our Prisma, we did not get this coil, as we believed that the problems were inherent to the design. You may want to contact other teams that have both this and the 32-channel to see if they have any advice.
Your images use Transfer Syntax (0002,0010) JPEG2000Lossless. The version of dcm2niix included with the slicer extension does not support this, while the version included with MRIcroGL does. Be aware that the DICOM standard only requires DICOM-compliant tools to support uncompressed images. Therefore, using a compressed transfer syntax can prevent you from using many popular DICOM tools. Furthermore, be aware that the JPEG2000 standard was not heavily used. In particular I believe OpenJPEG is the only open source (albeit unwieldy) library to support the 16-bit precision used in medical images. Therefore, for both short term and archival purposes, I would suggest using lossless transfer syntaxes and use conventional file or disk based compression if file size is an issue.
Your anonymization scripts removed the Siemens CSA headers from your images. These are crucial for Siemens EPI images, specifically to determine number of images in the mosaic, slice times, gradient directions, phase encoding polarity, etc. Without these details your images will be underspecified for diffusion analyses. I would check the providence of your images and convert a copy of your images before these details were stripped out. Alternatively, you will need to acquire a new dataset with these sequences, export the data directly from the console and extract the CSA information.
@ihnorton it might be worth updating the Slicer dcm2niix extension to include a version of dcm2niix compiled to handle compressed transfer syntaxes (using OpenJPEG for JPEG2000 and CharLS for loco JPEG-LS):
git clone https://github.com/rordenlab/dcm2niix.git
cd dcm2niix
mkdir build && cd build
cmake -DZLIB_IMPLEMENTATION=Cloudflare -DUSE_JPEGLS=ON -DUSE_OPENJPEG=ON ..
make
Just a note to conclude my part of the discussion -
I am certain this is a vendor specific issue for downloading DWI data sets (scalar volume export of T1, T2, etc is fine). I have raised this issue with the NilRead (Hyland is company name) but I have no idea if it will be addressed in the future.
I suspect these enterprise level cloud-based PACS systems will become more popular in the future. Indeed for our organization, end-users outside of Radiology have to use this system (I am in Ophthalmology analyzing visual cortex, so I need to use it).
JPEG options are already enabled in Slicer Preview Releases:
However, Slicer-4.10.x extension index still referred to an older version of the extension. I’ve updated it now to use the latest version of SlicerDcm2niix, too.
I figured out a work around to my problem with inadequate DICOM export for DWI files. I will post my approach in case someone else comes along with a similar problem (windows 10 64-bit)
create a batch file in the folder with the DICOMs that runs dcm2niix on the folder (no switches needed)
e.g., C:\MRIcron\Resources\dcm2niix C:\myFolder_with_DICOM\
IF it ran correctly, then you will have an output of 4 files
[series namexxxx].nii
[series namexxxx].bval
[series namexxxx].bvec
[series namexxxx].json
open the nii file with DSI-Studio (http://dsi-studio.labsolver.org/dsi-studio-download)
If it worked, you will see a correct table of b-values and b-vectors for each image (click ok) and it will create a file [series namexxxx].nii.src.gz
In DSI-Studio click reconstruction, which shows the brain mask. Do File -> Save 4DNifti file will now be
[series namexxxx].nii.src.gz.nii.gz with associated .bvec and .bval files
in Slicer, open Diffusion -> import export ->DWIconvert
-Pick FSLtoNRRD
-Create new diffusion weighted volume as …
-In NIFTI to NRRD conversion parameters pick the NIFTI file [series namexxxx].nii.src.gz.nii.gz
-pick the corresponding .bvec and .bval files for the other two choices
-Click apply and hopefully you have yourself a DWI series in 3D Slicer.
