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.