Errors when converting Canon Aquilion ONE multi-frame CT series

[RasmusRPaulsen]

Thank you for this amazing tool!

We are acquiring cardiac CT scans with a Canon Aquilion ONE CT scanner.
Recently, the scanner (after update) starts producing multi-frame images (1.2.840.10008.5.1.4.1.1.2.1 enhanced CT image storage). These can be converted using:

import pydicom as dicom
import dicom2nifti as d2n
dcm = dicom.dcmread(dicom_file)
d2n.convert_dicom.dicom_array_to_nifti([dcm], file_out, reorient_nifti=True)

We also get temporal sequences of volumes where there can be four (or more) DICOM files in a directory. All volumes have the same dimensions (for example 512x512x140) and they can be read into Slicer (with the usual multi-frame warning about missing geometric information).

When I try to convert the individual volumes into NIFTI files, the first DICOM file is converted nicely while the following files fails. I get an out-of-bounds exception in:

data_4d[z_location, :, :, t_location] = block_data

where z_location=140 and t_location=1 . I do believe the correct values are z_location=0 and t_location=0, for the first iteration.

z_location and t_location are both derived from the DICOM group "FrameContentSequence".

In the first (succesfull series) a tag dump gives:
...
[0020,9111] FrameContentSequence SQ 150
[fffe,e000] Item na 134
[0018,9074] FrameAcquisitionDateTime 20220223164321.715 DT 18
[0018,9151] FrameReferenceDateTime 20220223164321.715 DT 18
[0018,9220] FrameAcquisitionDuration 275 FD 8
[0020,9056] StackID 1_3355_00007_0 SH 14
[0020,9057] InStackPositionNumber 1 UL 4
[0020,9128] TemporalPositionIndex 1 UL 4
[0020,9157] DimensionIndexValues [3] 1, 1, 1 UL 12
[0020,9113] PlanePositionSequence SQ 58
...

In the second (failed series) the same dump gives:
....
[0020,9111] FrameContentSequence SQ 150
[fffe,e000] Item na 134
[0018,9074] FrameAcquisitionDateTime 20220223164321.776 DT 18
[0018,9151] FrameReferenceDateTime 20220223164321.776 DT 18
[0018,9220] FrameAcquisitionDuration 275 FD 8
[0020,9056] StackID 1_3355_00007_0 SH 14
[0020,9057] InStackPositionNumber 141 UL 4
[0020,9128] TemporalPositionIndex 2 UL 4
[0020,9157] DimensionIndexValues [3] 1, 2, 141 UL 12
[0020,9113] PlanePositionSequence SQ 58
...

I do believe that the z_location and t_location are derived from the "InStackPositionNumber" and "TemporalPositionIndex" and in the case of the second series this will lead to out-of-bounds values.

Is there something obvious that I am missing?
Is it a problem with the Canon DICOM conformance or should there be a fix in dicom2nifti?

Any help appreciated!
I thought about "hacking" the following series by resetting the InStackPositionNumber and TemporalPositionIndex but I am not comfortable with this approach.

Update: I tried to convert the series using dcm2niix and it is able to correctly convert them. I do prefer to use dicom2nifti since I have more fine grained control with that tool.

Thanks!
Rasmus