Adding support for scanner-processed data in reproin ?

[neurorepro]

Summary

We are using heudiconv to automatically convert data from our Siemens scanner (Prisma) based on reproin. An issue arises when a sequence has different kinds of scanner post-processing operations, e.g. one volume without normalization and the same volume with normalization, etc. In this case reproin identifies the same volume processed differently by the scanner as duplicates, with the latest version kept as the correct one (although it is usually the non post-processed one).

Then what about adding support for Siemens scanner post-processed data annotation ? This processing is indicated in the single field ImageType which is quite helpful for any implementation. For example a T1 image can have "ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"] with normalization but no distortion (ND) correction, and "ImageType": [ "ORIGINAL", "PRIMARY", "M", "NORM", "DIS3D", "DIS2D"] for normalization and distortion correction.

Normalization and susceptibility distortion corrections are very common post-processing steps, so they could be individually coded in the BIDS filenames. However a more straightforward implementation could be to add the sorted list of post-processing steps as value to the rec BIDS key (or optionally the proc BIDS key). There is the question of the proper separator in between processing step names. Meanwhile, since all step names are capitalized, x could be used as a separator such as in sub-01_rec-DIS2DxDIS3DxNORM_T1w.

I would be happy to help working on a PR to address this issue if appropriate.

[yarikoptic]

I am confirming that it was intentional decision at some point to skip all preprocessed on the scanner volumes, besides motion corrected: https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py#L500 .
If there is desire/need to store also other processed, I guess we should do that, PR would be welcome.

• I think that _rec should be used only for the cases were we know that it was about "reconstruction" step and otherwise leave it to _proc (post-processing)
• do warrant skip_derived (which is pretty much a constant now)
  • move skip_derived to the level of entire reproin.py module so who needs could easily overload it and set to True
• x as separator sounds fine to me.

[yarikoptic]

related - recent question/discussion in ReproNim/reproin#58 (comment) since talks about derived data