Wrong TimeZero in certain cases

[ChristianHinge]

Hi Chris - thanks for this awesome tool!

issue modified from this issue at PET2BIDS

Describe the bug
dcm2niix uses AcquisitionTime in cases where SeriesTime should be used. I believe this is a bug, 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. So if we do a 20minute PET acquisition, but reconstruct the image based only on the last 15 minutes, then the AcqusionTime will be 5 minutes bigger than SeriesTime. Also note that DecayCorrection is performed by Siemens to SeriesTime. 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", ## Should be 16:20:16
    "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
I used pypet2bids, to perform the conversion, but this grabs the values directly from dcm2niix sidecar. I reproduced with dcm2niix as well.

Version

Chris Rorden's dcm2niiX version v1.0.20241211 (JP2:OpenJPEG) (JP-LS:CharLS) GCC8.4.0 x86-64 (64-bit Linux)

[neurolabusc]

@ChristianHinge this is specific to Siemens PET. Note for Siemens MR we use the CSA header for timing. I have spent a lot of time acquiring MR and CT datasets for validation, as we describe here. Currently, we have validation datasets for many MR/CT manufacturers. The key here is to have the input DICOM as well as a reference standard of what the correct solution is. This allows us to conduct regression tests and helps others develop tools.

However, I do not have expertise nor access to PET data, so I am reliant on community feedback to support these conversions. The good news is that the OpenNeuroPET team has the resources to support this endeavor. I see they already have some reference DICOMs, though they have not yet provided the gold standard BIDS solutions. Happy to address this if someone wants to provide a validation dataset (ideally with a pull request to support the desired conversion).

@CPernet may have thoughts on this.

[CPernet]

@ChristianHinge will the new phantoms include this info? (@neurolabusc we'll update the dataset asap)

[ChristianHinge]

@CPernet @neurolabusc We will make sure to send some appropriate phantom data! Thanks for the quick reply

[neurolabusc]

@ChristianHinge closing as there are no concrete examples or validated solutions. Happy to revisit for a future release.

[CPernet]

@neurolabusc did you get the new phantoms? https://datacatalog.publicneuro.eu/dataset/PN000001%20OpenNeuroPET%20Phantoms/V2

[ChristianHinge]

Thanks Cyril. The biograph One phantom series contains an example where SeriesTime!=AcquisitionTime. I am awaiting help from our department to reconstruct a phantom in a way that captures more of the discussed edge cases. According to the PET physicists at our department, the use of SeriesTime is not just a Siemens PET thing - it is the same for all PET scanners regardless of vendor.
https://dicom.innolitics.com/ciods/positron-emission-tomography-image/pet-image/00080032

For PET, AcquisitionTime will often vary between DICOM images of a single series as stated in the above standard.

But I have not worked with other scanners than Siemens myself.

Best
Christian

[neurolabusc]

@ChristianHinge the validation BIDS dataset sub-SiemensBiographOneNRU7_pet.json specifies the same TimeZero as dcm2niix (10:57:58). If this is wrong, you should get this fixed in the validation dataset. I am not a PET expert, but the experts with the PET2BIDS team are supported via NNF20OC0063277; MH002977-01 to develop these datasets. If you can convince the experts that their validation values are in error, and ideally provide the logic to detect these situations from the DICOM, I will change dcm2niix.

@CPernet where should I post issues with the validation dataset. There are some cases where the validation datasets differ from the explicit public DICOM tags listed in the BIDS specification. If the validation datasets are correct, we should at least provide an explanation to guide users for these differences.

Here are just a couple examples:

sub-CanonCartesionPrimeNIA_pet.json

• BIDS: "ScatterFraction": [0.3165],
• DICOM: (0054,1323) DS [0.3189] # 6, 1 ScatterFractionFactor

sub-SiemensBiographVisionQuadraRigshospitalet_pet.json

• BIDS: "FrameDuration": [300],
• DICOM: (0018,1242) IS [60000] # 6, 1 ActualFrameDuration

sub-SiemensBiographOneNRU7_pet.json

-BIDS: "FrameDuration": [300],
-DICOM: (0018,1242) IS [301000] # 6, 1 ActualFrameDuration

[ChristianHinge]

Hi @neurolabusc

Regarding the current JSON, I think @CPernet has access to it, however, I have been notified that the difference between SeriesTime and AcquisitionTime in that example is due to a bug in the Siemens Software, and not one of the aforementioned edge-cases. I want to do a correct phantom scan that captures the edge cases discussed, but the scanner has been busy. I hope to get it done this week! Thank you for your patience.

[CPernet]

I have pushed @ChristianHinge updated source and nifti
https://doi.org/10.70883/RGNV3768

[ChristianHinge]

Thank you @CPernet
A bit of information on the phantom scan. It is reconstructed with frames intended to reproduce the current SeriesTime/AcquisitionTime discrepencies.

1. The start time of the PET scan (SeriesTime) does not coincide with the Start time of the first frame (AcquisitionTime for that frame). That is, the first n seconds of the scan are not used to reconstruct any PET frames (delayed recon).
2. It is a dynamic scan with varying frame durations. I have also added delays between some of the frames to capture possible edge cases.
3. Note that Siemens does ScatterCorrection on a per frame basis.