Add dcm2nii flavors #1131
Description
Description
Tasks
The DICOM datasets I acquired include the permissive BSD-2 Clause license that allows you to distribute them however you wish
https://github.com/neurolabusc/dcm_qa_asl
I spent many hours attempting to provide robust equipment, including getting research sharing agreements for all the ASL sequences available for my system, acquiring data and attempting to translate the sequence parameters (stored in custom fields that vary across sequences) to extract as many fields specified by BEP005 as possible (with a lot of help from the developers who created the sequence).
-
I do not think that the BIDS examples you are sharing are particularly useful for developers of DICOM-to-BIDS tools (dcm2niix, dicm2nii) and wrappers (dcm2bids, heudiconv), or end users
https://github.com/bids-standard/bids-examples
The issue here is that it is unclear to people which BIDS fields are available from the DICOM, and how the un-specified fields are determined. The BIDS 005 specification group really need to close the loop here and provide worked examples that start with DICOM images and take these to BIDS005 compliant BIDS images. This will allow users who are not familiar with your nomenclature (or familiar with manufacturer specific terms) to generate curated datasets that fit the standard.
While I think a standard is better than no standard, and have devoted a large part of my career to supporting BIDS, I despair that the emphasis of BEP teams is on developing specifications that allow reproducible analyses without much consideration for what data is available in the source images, providing vendor specific translation of terminology, meeting with the DICOM work groups to harmonize and extend meta data. -
The BEP005 ASL team may want to look at the wrappers developed by the BEP009 PET team. This wrapper uses dcm2niix to do an initial conversion and then allows the users to provide templates for required parameters that are not stored in the raw DICOM/PET data.
https://github.com/openneuropet/PET2BIDS -
You suggest that I could take my own DICOM data and provide a BIDS conversion.
https://github.com/neurolabusc/dcm_qa_asl
I urge the members of the BEP005 team to do this, rather than me.While I have tried my best to ensure that dcm2niix reports all the BIDS tags available for each sequence, I am not an ASL expert and my work has not been validated by an expert. I also think there is a difference between a dataset that passes the validator and one that has all the parameters expected by BEP 005 required. I think the developers of exploreASL and BASIL are better placed to determine what additional meta data must be added by hand to ensure well curated data. Again, worked examples of DICOM to BIDS created by the creators of the BEP are important, and may even help resolve ambiguities in nomenclature. -
The product GE ASL sequences only provide the derived ASL label-tag contrast (computed in K-space), so these do not seem BIDS compliant. The Philips data is massively under specified. I have spent a lot of time on wild goose chases attempting to infer values like total readout time and slice timing, and now can confidently say these can not be derived from the DICOM images. When I am consulted on new MRI purchases. The Philips DICOMs are bloated, underspecified and moribund DICOM, consistent with the investigative reporting of Mann and Gryta (who suggest that Philips wants to sell their medical division, which would explain deferred investment in R&D). I would be happy to see ASL DICOMs from UIH, Bruker, Mediso and Canon.
How to test
Optional: insert description about how to test the code changes here
Release notes
Required: summarize the changes for the release notes here