Improper sorting of PET slices.

[luissantosHCIT]

Describe the bug

dcm2niix fails to convert PET dataset. The utility warns about reordering dataset based on FrameReferenceTime and then complains about "First spatial position repeated 1 times." No nifti is generated.

I read issues #577 and #529 .
PR #624 contains changes that introduces the issue for PETs.
I was able to convert the same PET volume with a version of dcm2niix prior to 2022.

Compiling with -DmyInstanceNumberOrderIsNotSpatial generated a nifti with slices in the wrong order.
The volume in question is not a 4D dataset, so we expected it to be converted.

A few other notes here.

The dataset we wanted to convert is a partial dataset containing the head slices of a parent full body scan. The parent scan is also not a 4D dataset.

The challenge dataset had the following tag values

FrameReferenceTime

AcquisitionTime

InstanceNumber

I lightly reviewed the code base and noticed that FrameReferenceTime checks like the one in ensureSequentialSlicePositions() caused the issue.
Specifically, commenting the FrameReferenceTime check turns off the sorting by FrameReferenceTime and yields a nifti with the correct slice order. Presumably, this is because the InstanceNumber reflects the spatial relationship in this dataset.

Per the PR, removing the PT check so the utility could skip calling ensureSequentialSlicePositions() also worked, but I understand this is not desirable. I am thinking dcm2niix could at least check for repeated FrameReferenceTime here, issue a warning, and default to the InstanceNumber ordering.

From my perspective, sorting by the FrameReferenceTime may not be reliable if the dataset has repeated values.
Do you think that any of the checks should consider if there are repeated FrameReferenceTime values in the volume? Then, default to the usual slice ordering by the InstanceNumber, which appears to be working?
Should the reordering be limited to 4D datasets?
Should we expect the FrameReferenceTime to be unique?

Let me know what you think about this issue. For now, I am disabling the FrameReferenceTime ordering in our dcm2niix build since we do not need it for our purposes.
Dr. Rorden, how many slices would you like me to deanonymize and send to your institutional email?

Thank you for your previous help with the 12bit data conversion issue. Let me know how I can be of further assistance!

To reproduce

Steps to reproduce the behavior:

1. Make sure the input dataset has slices sharing the same FrameReferenceTime values and some slices sharing a different value (see screenshots).
2. Run the command 'dcm2niix -x i -p n -z n -b n -v 1 -o ./ -f <volume_name> <input_dir>'
3. See error ...

Expected behavior

1. A nifti gets generated.
2. The nifti has the slices in the correct order.

Output log

Version

Please report the complete version string:

Chris Rorden's dcm2niiX version v1.0.20230308 GCC4.8.5 x86-64 (64-bit Linux)

Troubleshooting

Please try the following steps to resolve your issue:

• Is this the latest stable release? If not, does the latest stable release resolve your issue?
• If the latest stable version fails, and you are using Windows. Does the latest commit on the development branch resolve your issue? You can get a pre-compiled version from AppVeyor (click on the Artifacts button).
• If the latest stable version fails, and you are using macOS or Linux. Does the latest commit on the development branch resolve your issue? You can build this using the recipe below:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix ....

[neurolabusc]

@luissantosHCIT my first concern is that The dataset we wanted to convert is a partial dataset containing the head slices of a parent full body scan. The parent scan is also not a 4D dataset. In general, dcm2niix assumes you are converting an entire DICOM series, with missing slices typically indicating an error with the reconstructor or the file transfer. dcm2niix really developed to aid analysis of 4D PET time series, so its development has had very little exposure to 3D PET scans.

You need to be exceptionally careful when using the Instance Number (0020,0013) as the DICOM standard does not require it to be sequential or even unique. Philips tends to jumble instance number (presumably reflecting when images were returned from a parallel reconstructor) and Siemens will use the same instance number for both the phase and magnitude image. dcm2niix tends to fall back on this in situations where the acquisition time is known to be suspect (e.g. Siemens XA often uses bogus values) but it should be considered a method of last resort.

Feel free to send a sample dataset to my institutional - please send the entire series as in some situations it is hard to understand the data without the full context.

[luissantosHCIT]

I understand. I will try to get the full body scan anonymized and sent.

Perhaps, ordering of the subvolumes based on ImagePositionPatient and ImageOrientationPatient might be useful to consider. For 3D volumes, our pipeline system does a spot check and renames the DICOM files in ascending or descending order based on the IPP. To avoid confusion here, the system would only modify the file name. It helped tremendously with making sure the slice order was consistent on conversion from dicom to nifti and later back to dicom. At the time, we did that to correct an inconsistency with one of our scripts. However, I wonder if a similar strategy might be helpful here. The scan is taken in a direction relative to the subject's position and these tags are required by the standard.

[neurolabusc]

Yes, we can certainly use IPP. However, for 4D brain imaging (fMRI, DWI) we need to be careful to preserve the temporal acquisition of slices to allow slice time correction. Therefore, stacking slices as head->foot versus foot->head makes a difference.

[luissantosHCIT]

Good morning Dr. Rorden. Like you indicated in your email, the current version of the development branch appears to work well for both the full body and partial versions of the problem volume. I am going to test a few other PETs just to make sure, but I think the problem might be resolved. Would you be kind to explain what changed since last month that seems to have corrected the slice ordering?

Thank you for your help! I will post a final comment today after I do a bit more testing.

[neurolabusc]

Feel free to examine the commits to the development branch since the last stable release to identify the crucial change.

[luissantosHCIT]

Everything looks like it is working right!
Again, thank you!

For documentation purposes, I think #622 and commit 6928d76 might have helped.
To me, it looks like the check for sequential slice ordering returns from ensureSequentialSlicePositions(). I did not look at the full new version of the function, but I am assuming the return happens prior attempting to sort based on FrameReferenceTime, which means we effectively skip reordering for 3D PETs altogether (unless the slices are truly jumbled up).

Have a great day!