Enhanced DICOM no gradient table

hello

Im working with new data set obtained from Philips scanner.
I have one Dicom file for all my raw data. In dicom to nifti i get only one nii file without bvecs and bvals files.

when trying to run dwipreproc i get this message: No diffusion gradient table found

Any suggestion to how I should handle this type of data?

Thanks

a

I recommend you have a read through our DW gradient scheme handling page: I reckon the final example in this section is exactly what you’re after. To cut a long story short, use the -export_grad_fsl option

Hello

i sent you example of my data set. This is DICOM enhanced file from Philips scanner

I’m trying mrinfo, but with no success:

i get this message:

mrinfo: [100%] reading DICOM series “DTI 1_MB2_sense1”
mrinfo: [ERROR] unable to load series due to inconsistent data scaling between DICOM images
mrinfo: [ERROR] error opening image “08_DTI_1_MB2_sense1.dcm”

do you know what might be the problem?

Thanks

A

Thanks for the data, I haven’t come across this before…

The problem is that every frame is scaled differently. See the output of this command (I’m only showing the first few lines out of 11,400 frames):

$ dcminfo hardi-mb2.dcm -a | grep RescaleSlope
[DCM] 0028 1053 DS       16    11564         RescaleSlope                     [ 0.48840048840048 ]
[DCM] 0028 1053 DS       16    12338         RescaleSlope                     [ 0.48840048840048 ]
[DCM] 0028 1053 DS       16    13728         RescaleSlope                     [ 0.04859584859584 ]
[DCM] 0028 1053 DS       16    14502         RescaleSlope                     [ 0.04859584859584 ]
[DCM] 0028 1053 DS       16    15892         RescaleSlope                     [ 0.05470085470085 ]
[DCM] 0028 1053 DS       16    16666         RescaleSlope                     [ 0.05470085470085 ]
[DCM] 0028 1053 DS       16    18056         RescaleSlope                     [ 0.05641025641025 ]
[DCM] 0028 1053 DS       16    18830         RescaleSlope                     [ 0.05641025641025 ]
[DCM] 0028 1053 DS       16    20220         RescaleSlope                     [ 0.04981684981684 ]
[DCM] 0028 1053 DS       16    20996         RescaleSlope                     [ 0.04981684981684 ]
[DCM] 0028 1053 DS       16    22386         RescaleSlope                     [ 0.05689865689865 ]
[DCM] 0028 1053 DS       16    23162         RescaleSlope                     [ 0.05689865689865 ]
[DCM] 0028 1053 DS       16    24552         RescaleSlope                     [ 0.05201465201465 ]
[DCM] 0028 1053 DS       16    25328         RescaleSlope                     [ 0.05201465201465 ]
[DCM] 0028 1053 DS       16    26718         RescaleSlope                     [ 0.05860805860805 ]
[DCM] 0028 1053 DS       16    27494         RescaleSlope                     [ 0.05860805860805 ]
[DCM] 0028 1053 DS       16    28884         RescaleSlope                     [ 0.05543345543345 ]
[DCM] 0028 1053 DS       16    29660         RescaleSlope                     [ 0.05543345543345 ]
[DCM] 0028 1053 DS       16    31050         RescaleSlope                     [ 0.05323565323565 ]
[DCM] 0028 1053 DS       16    31826         RescaleSlope                     [ 0.05323565323565 ]
...

This shows each frame is scaled differently. But the MRtrix3 DICOM handling backend assumes the scaling parameters are constant for each series. This is the first dataset I’ve seen where this assumption doesn’t hold.

For reference, I note this is from a Philips Ingenia Elition X running release 5.4.0.

This will require fixing, but I’ll have to think hard about how to do this within the current framework…

thank you for checking teh data

is there anything I should do on my end? changes to the scanner settings or report it to Philips?

Thanks

A

Good question. I’m not sure how well other DICOM converters would handle this, my guess is most of them will either not detect the different scale factors, or abort with a similar error. The only way to obtain a reasonable NIfTI out of this is to apply the scale factors to the data before storing it, and when doing this, the only way to avoid loss of precision is to store the data as floating-point. So if your converter produces 16-bit unsigned integers with these data (which is how data are typically stored in DICOM), I’d assume either the different scale factors have been ignored, or there’ll be rounding errors / loss of precision in there. If you get floating-point output, then it’s cleverer than ours…

So from that point of view, you’d be best advised to see if you can get the scanner to produce its DICOM with constant scaling parameters. I’ve no idea whether this is possible and if so how you might get that set up, so I’d encourage you to talk to your Philips applications engineer about it.

Otherwise, I’ll try to come up with a fix from our end, but it might be a while before I find the time…

OK, I’ve just pushed what I think is a fix for this issue - at least it seems to handle your data OK now. It’s currently awaiting review, but even then it won’t make it to master until the next release, which could be a few weeks/months away.

Note that it’s currently on our development branch, so using it means you’ll be using code that might differ somewhat from master. Assuming you’d rather keep your main install as-is, you can set up another parallel install of MRtrix3 alongside your current one, and use that just to convert your data:

git clone https://github.com/MRtrix3/mrtrix3.git ~/mrtrix3_dev
cd ~/mrtrix3_dev
./configure
./build

You can then invoke commands from that version by providing the full path to the executables, for example:

~/mrtrix3_dev/bin/mrconvert hardi_mb2.dcm dwi.mif

Let me know if that works for you.
Cheers,
Donald.