[BUG] Wrong TimeZero in certain cases

[ChristianHinge]

Describe the bug
PET2BIDS and dcm2niix uses AcquisitionTime in cases where SeriesTime should be used. I believe this is an upstream bug in dcm2niix, or perhaps this is just unique to Siemens Scanners. In Siemens PET scanners SeriesTime describes the start time of the PET acquisition - not AcquisitionTime. AcquisitionTime describes the timepoint in the acquisition, where data was used to reconstruct the DICOM-file. Often AcquisitionTime==SeriesTime, but not in the following cases:

1. Dynamic acquisition: the AcquisitionTime changes for each time frame.
2. Multiple bed positions: the AcquisitionTime changes for each bed frame.
3. Static images reconstructed from a time-subset of a longer acquisition: For instance, a static reconstruction based on a 50-70min window of a 70minute PET acquisition. Here AcquistionTime will be 50min larger than SeriesTime.

Here is the example output for case 3 (FDG tracer injection and PET acquisition start at 16:20, and a static image is reconstructed from the 50-70min window):

{
    "SeriesTime": "16:20:16.000000",
    "AcquisitionTime": "17:10:15.000000",
    "DecayCorrection": "START",
    "DecayFactor": [
        1.45951
    ],
    "FrameTimesStart": [
        0 ##Should be 3000 (50min*60)
    ],
    "FrameDuration": [
        1200
    ],
    "TimeZero": "17:10:15",
    "DecayCorrectionFactor": [
        1.45951
    ],
    "ScanStart": 0,
    "InjectionStart": 0
}

We can also see from the DecayCorrectionFactor, that everything is decayed back to the SeriesTime.
log2(1.45951)*110=60min (the frame reference 50min + 20min/2)

Expected behaviour
FrameTimesStart should be 3000. From what I can see, pypet2bids extracts FrameTimesStart and TimeZero from the dcm2niix sidecar if they exists. Otherwise it sets it equal to AcquisitionTime.

To Reproduce

1. code/command used (copy/paste what you did)
2. error happening? (copy/paste the error)

Desktop (please complete the following information):

• Arch Linux
• python

[bendhouseart]

I just read same issue on the dcm2niix repo; have you provided some of those dicoms from the scanner in question to Martin or Cyril?

I also know that Siemens graced us with the undocumented ECAT format and even the dicom tag mentions that Series Time isn't tied to any real world event which just deepens my distrust of that tag.

Section C.8.9.1.1.2
C.8.9.1.1.2 Series Date, Series Time
For PET Series, Series Date (0008,0021) and Series Time (0008,0031) are specified to be Type 1. Series Date (0008,0021) and Series Time (0008,0031) are used as the reference time for all PET Image Attributes that are temporally related, including activity measurements. Series Date (0008,0021) and Series Time (0008,0031) are not tied to any real-world event (e.g., acquisition start, radiopharmaceutical administration) and their real-world meaning are implementation dependent.

All that said, the researcher/technician knows the most about their own scans, so for case 3 you should tell PET2BIDS it's making the wrong assumption and correct it with --kwargs TimeZero="16:20:16". If this isn't a one off it might we worth updating the logic of PET2BIDS to account for the specific model of scanner that's got a different series time, but I'm hesitant as these things vary so much across regions and research centers.

For instance, our HRRT here at the NIH outputs dicoms and the one at the NRU puts out ECAT files...

[ChristianHinge]

Hi @bendhouseart

Thanks for the input! Just to add to the interpretation of os SeriesTime, even though it does not necessarily coincide with a specific real world event per say, I believe that image and frame activities are always decay-corrected to the SeriesTime (please correct me if I am wrong on this). To me this is therefore the most important time point for PET images. Although its interpretation is implementation dependent, I have yet to come across an example where SeriesTime does not denote the start of listmode acquisition. Again please correct me if I am wrong. :-)