CMRR SBRef complex/multi-echo series sorting is broken

[bpinsard]

Summary

Warning: super weird edge case.

When acquiring mag+phase data with CMRR bold MB sequence, the SBRef get exported as a single series with both mag+phase dicoms, same goes if using multi-echo and/or combining the 2 ( eg. mag+phase * 3 echoes = 6 dicom files) However, MosaicWrapper.is_same_series will take into account the dicoms ImageType in signature, and thus each file is considered a separate series at that point: https://github.com/nipy/heudiconv/blob/cb2fd912b8310d7022e9358a84c3b589fe3c07e8/heudiconv/dicoms.py#L230 because ImageType will have M/P , TE1/TE2/.../TEn, even if they still generate a single Seqinfo with heudiconv default grouping here: https://github.com/nipy/heudiconv/blob/cb2fd912b8310d7022e9358a84c3b589fe3c07e8/heudiconv/dicoms.py#L115-L117 So there is a discrepancy between the grouping in heudiconv and nibabel, not sure if and where it should be fixed.

This results in the last dicom file of the series being used to create the seqinfo of that series (due to the dict creation below with repeated keys), leading to inconsistent Seqinfos. https://github.com/nipy/heudiconv/blob/cb2fd912b8310d7022e9358a84c3b589fe3c07e8/heudiconv/dicoms.py#L250

This issue is related to https://github.com/nipy/heudiconv/issues/519 and https://github.com/nipy/heudiconv/pull/535 In such cases, the Seqinfo values will depend on the order of the provided files, and that for instance when data are stored based on SOPInstanceUID, Siemens ones are of variable length and not reliably related to the acquisition/reconstruction timing when sorting alphabetically (so one cannot assume mag/phase or TE orders). Example:

MR.1.3.12.2.1107.5.2.43.123456.2022032116191110159432266
MR.1.3.12.2.1107.5.2.43.123456.202203211619119969932265

I think the results of heudiconv should be independent of the order of the files provided. Maybe the files within a series should first be sorted with ContentTime, so the order is consistent with the acquisition and reconstruction order? The other option would be that I code a custom grouping that will match nibabel one (splitting series based on ImageType), but it will require to rewrite all the logic for complex, multi-echo, ... that is already implemented in heudiconv.

Let me know if that is clear or not. I know this is very convoluted. Even if there is no obvious solution, I post it as a reference for anyone having the same problem and not being stubborn enough to read and trace what happens in the code.

Platform details:

Choose one:

• [x] Local environment

• [ ] Container

• Heudiconv version:

0.10.0