Fetch AcquisitionTime from dicom header and encode it in json sidecars

[jcohenadad]

Context

Some applications (e.g. realtime shimming) require information about acquisition time of each volume, from EPI or GRE sequences.

Currently, multiple Dicom files corresponding to a single series are saved into a single NIfTI file (and, de facto, a single JSON file). The JSON file does have a field AcquisitionTime, however it only corresponds to the first volume. The information of the other volumes is lost.

Suggestion

Suggestion 1: Use the existing field AcquisitionTime to encode a list of acquisition timestamp for each volume.

• pros: use existing field
• cons: probably not BIDS-compatible (this field should be a scalar-- this is my guess...)

Suggestion 2: Create a custom field, e.g. AcquisitionTimeList that would encode a list of acquisition timestamp for each volume

• pros: does not conflict with BIDS convention

Testing data

Testing data: echo_2.46.zip

Syntax:

dcm2niix -v 2 echo_2.46 | grep 0008,0032

Result: Outputs acquisition time per volume

``` 0008,0032 14@638 TM 121821.960000 0008,0032 14@638 TM 121822.745000 0008,0032 14@638 TM 121816.452500 0008,0032 14@638 TM 121817.240000 0008,0032 14@638 TM 121818.025000 0008,0032 14@638 TM 121821.172500 0008,0032 14@638 TM 121820.385000 0008,0032 14@634 TM 121818.812500 0008,0032 14@638 TM 121819.600000 0008,0032 14@638 TM 121823.532500 ```

The additional feature of dcm2bids would be to fetch that information and encode it in the JSON file.

[neurolabusc]

dcm2niix considers acquisition time personal data. If you create a bids file without BIDS anyonymization (dcm2niix -ba y -b y ~/Path/ToDICOMs) the tag AcquisitionTime will report Acquisition Time (0008,0032) for the slice of the first (saved) volume in the series. The timing between volumes should match the TR, and the timing between slices is provided BIDS SliceTiming field. Just be aware that other private data like PatientName and PatientBirthDate will be populated.

[jcohenadad]

Thank you for your input @neurolabusc ! The reason I prefer to not rely on the first volume AcquisitionTime and TR to get the timing of subsequent volumes, is that for sequences such as the gre (ie non-EPI), the TR refers to the time between two RF excitations (which as you know is different from the "TR" of the EPI, which is the time between two volumes). So, in order to get the right timing for subsequent volumes, we need to account for the number of phase lines, parallel imaging, partial fourier, introduction, etc. and I feel like this is opening a Pandora box vs. the strategy of simply fetching the AcquisitionTime pertaining to each DICOM file.

[jcohenadad]

@neurolabusc would you be open to the idea of having dcm2niix output an optional file (CSV, JSON, etc.) that contains these AcquisitionTime per volume?

[neurolabusc]

@effigies the BIDS specification defines RepetitionTime as The time in seconds between the beginning of an acquisition of one volume and the beginning of acquisition of the volume following it .. and is derived from DICOM Tag 0018, 0080 and converted to seconds. What gets precedence when these two definitions differ, as in this case? I realize BIDS is trying to describe EPI-based DWI and fMRI data, so this is an edge case.

@jcohenadad if you compile the latest version of the dcm2niix development branch and run it on your data, you will see that the BIDS JSON file lists a new field TimeBetweenVolumes. This field is only populated if the difference between the DICOM RepetitionTime (0018, 0080) differs from the measured time between volumes by a value greater than the toleranceSec (which is set to 50ms). The TimeBetweenVolumes is estimated based on the first AcquisitionTime (0008,0032) of the first volume and the first AcquisitionTime of the last volume, divided by the number of volumes minus one.

    "RepetitionTime": 0.0069,
    "TimeBetweenVolumes": 0.786667,

There are two independent issues with your data:

1. The RepetitionTime (0018, 0080) is not related to the TimeBetweenVolumes. Therefore, TimeBetweenVolumes must be determined from AcquisitionTime (0008,0032).
2. The AcquisitionTime (0008,0032) is not precise, and suffers rounding errors. Therefore, it suggests stuttering times between volumes.

The AcquisitionTime (0008,0032) is sampled with low precision. You can demonstrate this by connecting a trigger pulse detector to the optical output of your scanner. You will find that the scans are actually being acquired at very regular intervals, despite the jitter in the reported AcquisitionTime (0008,0032).

If you decrease the toleranceSec to a very small value (e.g. 1.0/1000.0 = 1ms) a new BIDS field will be populated, FrameTimesStart, which will reveal the variance reported by the DICOM AcquisitionTime (0008,0032):

    "FrameTimesStart": [
        0,
        0.7875,
        1.5725,
        2.36,
        3.1475,
        3.9325,
        4.72,
        5.5075,
        6.2925,
        7.08    ],

Again, I would discourage this, in my evaluations the variabilities in these timings reflect variability in the time stamp inserted in the DICOM, not variability in the actual acquisition.

Due to the inaccuracy of AcquisitionTime (0008,0032), our estimate of TimeBetweenVolumes will always have some inaccuracy. However, using the times for the first and last volume minimizes this.

[jcohenadad]

@neurolabusc this is awesome!!! 🎉 Thank you so much for the quick changes.

I was able to successfully reproduce your results (from this commit)

Yes, I am aware of the poor precision of the AcquisitionTime timestamp on the Dicom files. Your suggestion to average over all the volumes is smart, and I agree it is a good idea to make it the default (and if, for some reasons, people still want the AcquisitionTime, they can still do it with your implementation by reducing the tolerance).

Again, thank you so much for the quick support. I'm sure this feature will be useful for many people in our community.

[effigies]

@effigies the BIDS specification defines RepetitionTime as The time in seconds between the beginning of an acquisition of one volume and the beginning of acquisition of the volume following it .. and is derived from DICOM Tag 0018, 0080 and converted to seconds. What gets precedence when these two definitions differ, as in this case? I realize BIDS is trying to describe EPI-based DWI and fMRI data, so this is an edge case.

I don't really know the context of this edge case, but if I'm looking at a 4D series, the pixdim[4] should be the time between consecutive volumes, and RepetitionTime is considered to be identical to pixdim[4].

For qMRI cases, BEP-001 is introducing RepetitionTimeExcitation and RepetitionTimePreparation metadata fields. Does the mismatch fit one of those cases?

[jcohenadad]

@effigies indeed, for the dataset posted in https://github.com/UNFmontreal/Dcm2Bids/issues/90#issue-721753912, the RepetitionTime field currently populated by dcm2niix follows the definition of RepetitionTimeExcitation (and corresponds to (0018, 0080)).

So anticipating that BEP001 will be adopted soon, it might be wise to revert the recent changes in the development branch of dcm2niix, and replace TimeBetweenVolumes by RepetitionTime (which would take the value of the "approximate" time between volumes based on calculation proposed in https://github.com/UNFmontreal/Dcm2Bids/issues/90#issuecomment-710402803), and add the field RepetitionTimeExcitation which corresponds to (0018, 0080).

[effigies]

That sounds reasonable to me. Along with BEP-001, we should modify the text of RepetitionTime (if they haven't already done) to ensure that (0018, 0080) is only used for appropriate sequences.

[neurolabusc]

@jcohenadad this sounds reasonable. When the measured time between volumes differs dramatically from 0018, 0080, one would use the time between volumes for the BIDS tag 'RepetitionTime' and the value from 0018, 0080 as RepetitionTimeExcitation.

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.

[jcohenadad]

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.

I guess these BEP initiatives could (should) also serve as incentives for vendors to update what goes in their DICOMs. The "enhanced DICOM" is probably a step in that direction. It should also be mentioned that while DICOMs are popular and convenient (for good reasons), vendor-agnostic formats such as ISMRMRD are also a means to get NIfTIs out. But this comment is probably a bit out-of-scope...

[effigies]

@neurolabusc Can you comment on BEP001 with this concern? I think it's worth bringing up while the BEP is being finalized.

[neurolabusc]

@jcohenadad The latest patch to the developmental branch will generate RepetitionTimeExcitation. I have created dcm2niix issue 439 to describe this change.

As an aside, I am an advocate of vendor-agnostic formats. However, I think we also need to advocate for big data friendly formats. As scientists, we need to be very careful in creating and curating formats so that they retain high performance (the era of big data is only beginning), retain precision, and are simple to describe so they can be accessed by many tools. By these metrics, I am not a fan of the ISMRMRD format. The choice of HDF5 has profound implications. I remain a critic of storing floating point data as ASCII text (this includes BIDS). Beyond the speed and size considerations, moving data back and forth between machine native binary and ASCII representations has implications. As Kernighan and Plauger note Floating point numbers are like piles of sand; every time you move one you lose a little sand and pick up a little dirt. We saw with the MRI vendors the consequences associated with rounding errors in the text input boxes and the binary representations.

@effigies I have posted a comment noting I remain uncertain how to distinguish RepetitionTimePreparation. I think this is as far as I can go based on my understanding and Sample DICOM datasets available to me.

[jcohenadad]

@neurolabusc Thank you for making these changes, and for sharing this interesting perspective about the HDF5 format.

[jcohenadad]

Closing as the change is now implemented in a stable version of dcm2niix