I’m looking at 30 direction data from an Agilent 9.4T scanner. I’ve been provided with some software that does a reasonable job of converting the fdf files into dicoms. (Not the built in agilent conversion). However there is one dicom image per direction. mrconvert is able to import the b0 ok, but ignores the rest of the data. So what tags is it looking for? The old mrtrix2 discussions suggest that series and acquisition number should be enough, but perhaps that has changed.
The SeriesDescription, SeriesInstanceUID, SeriesNumber are identical.
AcquisitionNumber increments from 1 to number of directions.
The various mediastorageSOPinstanceUID fields are also identical - will that cause issues?
Any summaries of the import algorithm anywhere?
I had a similar issue a couple of weeks ago, which was due to an empty SeriesTime - fix committed here. Is your installation up to date? If you’re still having issues, maybe you can send me the data, I’ll take a look.
By the way, if you’re really interested in how MRtrix3 handles these things, the first place to look would be the
DICOM::QuickScan class - that will tell you which entries are actually read initially to sort the data, prior to doing a deeper scan through the particular series to be loaded.
Briefly, the process is to scan through all files in the specified folder (recursively if nested folders are found) using the
QuickScan class, which only reads those tags necessary to work out the contents of the folder. It then sorts these small entries into a tree structure by Patient / Study / Series / Image (code here). The code then allows the user to select one or more series (code here), and then performs a full scan of the files in that series to grab the information required to read the images as such - this is done via the Image & Frame classes, which read a lot more tags than the original quick scan (code here).
The most recent git version seems to work OK. Apologies for this - I was using a 2016 version and didn’t expect the dicom code to change often…
No worries, good to hear. You’re totally right to assume that the DICOM code doesn’t change much. It’s a total coincidence that I happened to come across another dataset with the same problem recently - also generated by third party software, as it happens…
I’m using an anonymised dicom dataset and fail to successfully apply
mrconvert on it. The error message that returns is:
[ERROR] error converting string " "
It is likely due to anonymisation, as the non-anonymized version responds just fine to mrconvert. I am therefore looking for the necessary fields to retain in the dicom header. I tried the links you supplied here Essential dicom tags for mrconvert but they seem to be (re)moved. Is there somewhere else a list of tags that should be retained in the dicom?
OK, that would be an internal error in converting a presumably now empty string to integer or float. Probably easiest if you could send me the anonymised data so I can look into it…
Thanks for the help Donald.
As you suggested SliceThickness (dicom group 0018) was indeed crucial.
I also found that dicom group 0029 was important to get the dimensions right after conversion (at least for this Siemens example). Problem solved