Hello
We are using MRtrix for many different things in our tractography pipelines. At the moment, we are struggling a lot with DICOM data from Philips scanners. We are trying to use mrinfo to get gradient directions from the data, which works very consistently in general with other vendors, but with Philips it cannot seem to find the gradient information.
When we look manually through the DICOM headers, we also cannot find the gradient information. We are wondering if there are alternative reconstruction files we are missing from the data which are needed (we have read somewhere about .par and .rec files from Philips scanners)
We wonder if anyone in the MRtrix community has experience with DWI on Philips machines and can advise on how to track down the gradient information (we receive the data from many different MRI sites, so if we need extra files we need to make sure they send them in the future)
Many thanks
Matt
We use Philips here, without any issues. One of the problems with getting the DW information out of the headers is that different vendors store it in different places in different versions of their product… So MRtrix3 will check all the places it knows about, and extract the information if found. In your case, I wouldn’t be surprised if the data you have been supplied with has previously been ‘anonymised’ or otherwise converted via a third-party encoder. Anonymising DICOM data is actually a very difficult thing to do without messing up crucial information, most implementations that I’ve come across simply discard any non-standard tags, since they can’t guarantee that these tags don’t contain sensitive information. Unfortunately, that’s where most vendors store information like the DW encoding…
Happy to take a quick look at your data if you want to share them with me? You can send me a private message via this platform with a link to the data, or email to jdtournier@gmail.com.
Thanks for sending the data through. I had a look, and it seems the issue is that the data are stored using the JPEG transfer syntax:
[DCM] 0002 0010 UI 22 252 TransferSyntaxUID [ 1.2.840.10008.1.2.4.70 ]
which corresponds to JPEG Lossless, Nonhierarchical, First- Order Prediction, according to the DICOM standard.
So I’m surprised the issue only relates to the DW gradient information. I wasn’t able to read these images at all… Although I could read through the DICOM header using our dcminfo utility (using the -all switch), just to get a dump of the header entries. It looks like the information should be there, since it’s using the modern DICOM standard tags:
[DCM] 0018 9075 CS 4 2916 DiffusionDirectionality [ NONE ]
[DCM] 0018 9089 FD 24 3004 DiffusionGradientOrientation [ 0 0 0 ]
but as far as I can tell, none of the images report any diffusion directionality - despite the protocol advertising itself as a DTI scan:
[DCM] 0018 1030 LO 24 2252 ProtocolName [ Reg - DTI_high_iso SENSE ]
[DCM] 0018 9005 SH 6 2476 PulseSequenceName [ DwiSE ]
In any case, the recommendation from @maedoc is to use dcmtk to convert the data to a non-compressed format - as per this recent GitHub issue. I had a brief look into supporting JPEG transfer syntax, but it looks like a lot more effort than any of us have time for… And I’m not sure it would solve your original DW gradient table import issue either.
Hi,
I came across an interesting tool gdcmconv that could be a useful addition to mrconvert in case the DICOM transfer syntax UID is not one of the supported types listed here http://mrtrix.readthedocs.io/en/latest/tips_and_tricks/dicom_handling.html#error-unsupported-transfer-syntax.
A simple decompression of the dicom images would make them accessible by mrconvert:
gdcmconv dcm_in dcm_out -w
I tested it on some diffusion data that wouldn’t convert because of the transfer syntax, and after applying the decompression, mrconvert was happy to proceed. Given the simplicity, perhaps it would be a good idea to incorporate it into mrconvert?
Cheers,
Thibo
1 Like
Good find! Happy to document it and list it as a recommendation, but ‘including’ something like this into mrconvert is very unlikely to be simple, for the same reasons as dcmtk…
Thinking about adding a reference to this to the relevant documentation page. Can I just check one thing:
In the example above, do the dcm_in & dcm_out arguments correspond to individual files or full folders? Would users need to loop over all individual DICOM files, as in the dcmtk case…?
A loop would indeed be necessary. The command is applied on individual dicom files.
Also, dcm_in and dcm_out can be the same file (overwriting is possible) or dcm_out can be a new file (no need to create it beforehand).