RepetitionTime

[neurolabusc]

I understand that RepetitionTime for EPI-based fMRI and DWI scans is equal to the sampling rate, and this is not the case for anatomical scans.

However, reading BEP001 it is unclear to me how a tool determines from a DICOM whether 0018, 0080 refers to RepetitionTimeExcitation or RepetitionTimeInversion. An explanation and an example dataset would help. A frustrating aspect of many BEPs is that they provide sample datasets of correct BIDS/NIfTI images, but not the DICOMs from which they were derived. This makes it hard to validate conversion from DICOM to NIfTI and to have explicit examples of how to source the desired meta-information.

[agahkarakuzu]

@neurolabusc RepetitionTimeInversion is from an older discussion. It is now referred (to provide a more generic solution) RepetitionTimePreperation here.

You can find example datasets at https://osf.io/k4bs5/. I think MP2RAGE dataset would be a good example.

[neurolabusc]

@agahkarakuzu the osf archive only includes the NIfTI/BIDS files, not the DICOM files they were generated from. I can not validate conversion tools without examples of both the source DICOMs and the reference solution.

[agahkarakuzu]

I see, I guess most of us converted these datasets manually, or using scripts that are written without the intention of creating a "converter". Still, maybe @Gilles86, @lazaral and @ChristophePhillips can chime in to share the respective DICOMs.

I think a DICOM --> BIDS parameter mapping would be useful on a vendor by vendor basis, but I guess that discussion is bigger than BEP001.

[Gilles86]

Hi @neurolabusc,

I would have PARRECs for the MP2RAGE and ME-GREs, if you are interested. I don't use DICOMs.

Note that the implementation of MP2RAGE can be very different from vendor-to-vendor and even from site-to-site and, in the case of Philips, the key parameters cannot be extracted from the PARRECs.

-Gilles

[ChristophePhillips]

Hi @neurolabusc ,

I can only comment for the MPM protocol here but, yes, conversion from DICOM into BIDS-compliant NIfTI remains an issue. At the moment, for the public version of the hMRI toolbox, we proceed like this: DICOM is converted into NIfTI with a "dump" of the whole DICOM header in a JSON file, the code then proceeds by extracting the parameters in needs. What I did for the BEP001 effort on the public demo data and its BIDSified version on OSF, is to write some specific bits of code that extracted the necessary parameters and named them as BIDS wishes... This is indeed very ad hoc.

The RepetitionTime (and its variations) really stems from how BIDS started and who it targeted originally: vanilla fMRI + sMRI studies, for neuroscientists (i.e. OHBM crowd). Some naming is thus unfortunately not in line with the MR physicist world (i.e. ISMRM crowd). Bridging the 2 will require breaking some habits and convention...

[neurolabusc]

@Gilles86 I would heed comments from Philips engineers regarding storing data as PAR/REC. The format is not being updated and was designed for simpler times. This format is inherently limited. Further, since it is research specific, it eventually leads to a challenge for translational work.

@ChristophePhillips we already have a lot of vendor-specific conversions for BEP005 (ASL) and BEP009 (PET). The recent collaborations with Siemens (XA30) and GE (major version 28) allow better extraction of meta data into BIDS. In many cases, the engineers working for the vendors have documented private tags, while in some cases they have extended the information stored in the DICOMs. For this work, it really helps to have a reference set of DICOMs (e.g. for Siemens a set that can be Phoenixed onto a scanner). As a developer, While it is clear to me how to detect time-between volumes, and use 0018,0080 for RepetitionTimeExcitation if the values differ substantially, it remains unclear how to determine and discriminate RepetitionTimePreparation. I fear adoption of your tools will remain low if the data conversion remains vague and ad hoc.

[neurolabusc]

dcm2niix issue 439 documents how that tool attempts to extract RepetitionTimePreparation and RepetitionTimeExcitation as defined by BEP001 from DICOMs. As described there, this is vendor specific and current DICOMs do not provide all the desired information. I am open to any suggestions to improve support, but it seems like we will need help from the manufacturers.