Siemens AcquisitionTime weird jumps

,
1

Hi everyone,
I have somewhat of a question or observtion regarding the AcquisitionTime in dicoms of Siemens data (I did not check for other constructors).
That value is generally spaced by the TR between 2 different volumes, but suddenly that value jumps by 40s, and thus do not show the true time of acquisition. (see example with code below).
This is the case for Siemens product sequence and CMRR MB, so it seems more related to the scanner. I checked on data from another scanner ( DataLad Repository) and it’s the same.
It seems to always be 40s jumps.
I am mostly posting here for documenting, as I didn’t find any info about that anywhere.
Any opinions about that oddity that do not match dicom specs?
Tagging @neurolabusc as you are of course very knowledgeable about dicoms.

import pydicom, glob, numpy as np
acq_times = np.sort(np.asarray([pydicom.read_file(f, stop_before_pixels=True).AcquisitionTime for f in glob.glob("/path/to/dicom/series/*") ], dtype=np.float))
np.diff(acq_times)                                                                                                                                                                                                                                        
array([ 0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785, 40.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785, 40.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
        0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,  0.785,
....
2

@bpinsard Acquisition Time 0008,0032 uses the Time ™ VR which is A string of characters of the format HHMMSS.FFFFFF; where HH contains hours (range "00" - "23"), MM contains minutes (range "00" - "59"), SS contains seconds (range "00" - "60"), and FFFFFF contains a fractional part of a second. It is a string, not a floating point number. Note the range of hours (0…23), minutes (0…59) and seconds (0…59) is less than 0…99.

>>> tm = pydicom.read_file(f, stop_before_pixels=True).AcquisitionTime
>>> type(tm)
<class 'str'>

Hence, in your example: since a minute has 60 not 100 seconds, you see 40 second jumps. A thorough solution needs to handle this for seconds, minutes, hours and even consider the day if the acquisition crosses midnight.

As an aside, not all manufacturers and systems set AcquisitionTime to the physical acquisition time, but rather the time that data returns from a parallel reconstruction system and a clock with a less than millisecond accuracy tick. Indeed, Siemens has a couple of different clocks that are different from each other, so you want to be especially careful which clock you use if you want to lock physiological recordings (e.g. pulse and respiration) to your imaging data.