FrameTimeStart error in sidecar json with PET dataset

[bendhouseart]

The FrameTimeStart list produced after running dcm2niix on a PET dicom dataset does not align with the frame duration field. Something odd is happening, below are the values from the *pet.json output from dcm2niix

FrameTimeStart = [0, 86, 172, 323, 475, 626, 777, 1056, 1334, 1612, 1888, 2164, 2440, 2715, 2989, 3512, 4033, 4553, 5072, 5589, 6106, 7110, 8111, 9110, 10106]
FrameDuration = [15, 15, 30, 30, 30, 30, 60, 60, 60, 60, 60, 60, 60, 60, 120, 120, 120, 120, 120, 120, 240, 240, 240, 240, 240]

FrameTimeStart should align with Frame duration, currently doing a cumulative sum of FrameDuration to account for this error.

To reproduce

1. Acquire 'errant' dataset from bendhouseart, contact at 28850131+bendhouseart@users.noreply.github.com
2. dcm2niix -w 0 -o destination_path errant_dataset/
3. Inspect destination_path/errant_dataset.json

Expected behavior

FrameTimeStart = [0, 15, 30, 60, 90, 120, 150, 210, 270, 330, 390, 450, 510, 570, 630, 750, 870, 990, 1110, 1230, 1350, 1590, 1830, 2070, 2310]
FrameDuration = [15, 15, 30, 30, 30, 30, 60, 60, 60, 60, 60, 60, 60, 60, 120, 120, 120, 120, 120, 120, 240, 240, 240, 240, 240]

Output log

machine:console user$ ./dcm2niix -o ~/Desktop/ /Users/user/Documents/PET/Datasets/errant_dataset/
Chris Rorden's dcm2niiX version v1.0.20210616  Clang11.0.0 x86-64 (64-bit MacOS)
Found 9975 DICOM file(s)
Warning: Seconds between volumes varies
UINT16->INT16 Future release will change default. github.com/rordenlab/dcm2niix/issues/338
Convert 9975 DICOM as /Users/user/Desktop/errant_dataset (400x400x399x25)
Conversion required 19.527879 seconds (18.899076 for core code).

Version

• dcm2niiX version v1.0.20210317 Clang11.0.0 x86-64 (64-bit MacOS) v1.0.20210317
  • dcm2niiX version v1.0.20210616 Clang11.0.0 x86-64 (64-bit MacOS)

[bendhouseart]

tagging @mnoergaard for additional comments and visibility

[neurolabusc]

@bendhouseart the FrameTimeStart reflects your images AcquisitionTime (0008,0032), while FrameDuration reflects your DICOM FrameDuration (0018,1242). If your Frames were acquired without gaps between exposures, it reflects that your DICOMs are erroneous. dcm2niix assumes that DICOMs are accurate. You can confirm the DICOM AcquisitionTime with your favorite DICOM header viewing tool (dcmdump, Horos, etc). I requested a copy of the dataset 5 days ago, but have not heard a reply. However, I suspect the issue is with the DICOMs, not dcm2niix.

[mnoergaard]

The data can be found here:

https://drive.google.com/file/d/18IinfmbYhARTgtctQ8cp1WJz-IOmjQ-B/view?usp=sharing

[neurolabusc]

@mnoergaard thanks for the example. dcm2niix appears to be accurately reporting the BIDS FrameTimeStart as recorded by the DICOM AcquisitionTime. You may want to confirm that temporal gaps were not present between exposures. If no gaps were present, you will need to work with your Siemens Research Collaboration Manager to have the DICOMs accurately describe the acquisition.

[neurolabusc]

The result from dcm2niix looks like it matches the Excel file pretty well. The Excel file lists the final scan at 185 minutes, which is 11100s. dcm2niix lists the start of the final frame at FrameTimesStart as 10106s, while acquisition of the final slice of the final frame begins at 10852s with a FrameDuration of 240s, yielding 11092s for the end of exposure for the final frame of the final volume. I suspect the difference simply reflects a rounding error in the Excel spreadsheet to the nearest minute. Below is the relevant dcmdump with the DICOM TM VR in HHMMSS.FFFFFF format.

(0008,0032) TM [101615.000009] #  14, 1 AcquisitionTime (instance 1, 1st slice, 1st volume)
(0008,0032) TM [130440.999991] #  14, 1 AcquisitionTime (instance 9577, 1st slice, final volume)
(0008,0032) TM [101741.000025] #  14, 1 AcquisitionTime (instance 9975, final slice, final volume)

[mnoergaard]

Thanks a lot for looking into this @neurolabusc. Will pass this on. Feel free to use the data for testing and/or updating the PET part of dcm2niix. We plan to provide you with more test data soon.

[neurolabusc]

Great. dcm2niix will generate JSON fields that are direct translations of the PET Isotope Module Attributes. I have done my best to support BIDS BEP009, but in most cases there is not a clear mapping from the DICOM public tags to the BIDS BEP009 fields. I note that your images also contain a proprietary CSA header, but unlike MR this PET header contains very little information. Therefore, at least for Siemens my sense is that BEP009 support will not be done by dcm2niix automatically, but will require users to enter the required meta-data.

[mnoergaard]

Yeah, I agree with you - it is not likely that dcm2niix will be able to take care of everything (but it does great already now), and we will therefore try to make additional converters that can add the necessary information from external documents to the json file that dcm2niix generates. Since last time, the PET-BIDS specification has been merged with the main specification (https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/09-positron-emission-tomography.html), and therefore there are a few things that have been updated (mostly names) compared to the current version of dcm2niix.

[bendhouseart]

@neurolabusc thanks again. Wouldn't have noticed this error in such a timely matter without dcm2niix. As @mnoergaard we're in the process of creating additional converters for PET to better support its addition into BIDS, and in doing so trying not to diverge too far from some of the well established pattern in MRI to BIDS conversion. Naturally one of the first tools we turned to was dcm2niix.

I'll go ahead and close this out since it's an error with our dicoms and not dcm2niix.