Add PDT2 handling

[yarikoptic]

• Add PDT2 as valid multi echo sequence type #345

added _PDT2 suffix into multi-echo sequences. Then e21a9ba generalized it further (no explicit handling for PDT2). So we would add _echo-1 and _echo-2 for any dual echo image.

Since then, or just now, BIDS recommends in https://bids-specification.readthedocs.io/en/stable/modality-specific-files/magnetic-resonance-imaging-data.html#non-parametric-structural-mr-images

If separated into 3D volumes, the PDw and T2w suffixes SHOULD be used instead, and an acquisition entity MAY be used to distinguish the images from others with the same suffix, for example, acq-PDT2_PDw.nii and acq-PDT2_T2w.nii.

So, I think that if we encounter dual echo ( _echo-1 and _echo-2) with echo1 < 30 ms, and 70 < echo2 < 120 on _PDT2 we might want to rename accordingly to _PDw and _T2w (am I correct in the order/assignment @tsalo @bpinsard @kodiweera that short echo is PDw here and longer one T2w? are better ranges to use?)

edit: ATM we store a single TE for a sequence. I am reviewing the case (do not have direct access to data) for PDT2 where sorting does not separate into two sequences and we have a single TE value but then dcm2niix to separate... we might need to adjust/fix code to allow for multiple TEs and pass those into heuristics.

FWIW - -confirmed on a sample PDT2 data laying around (`dicoms/dcm_qas/dcm_qa_pdt2`) that we get multiple echos in the same sequence

❯ heudiconv -f ~/proj/heudiconv/trash/DK-atlases/convertE3_v4.py -b --minmeta -s E1600121J -ss 03 --files dcm_qa_pdt2/ -c dcm2niix -o dcm_qa_pdt2-bids --overwrite
...
❯ tree dcm_qa_pdt2-bids
dcm_qa_pdt2-bids
├── CHANGES
├── dataset_description.json
├── participants.json
├── participants.tsv
├── README
├── scans.json
└── sub-E1600121J
    └── ses-03
        ├── anat
        │   ├── sub-E1600121J_ses-03_echo-1_PDT2.json
        │   ├── sub-E1600121J_ses-03_echo-1_PDT2.nii.gz
        │   ├── sub-E1600121J_ses-03_echo-2_PDT2.json
        │   └── sub-E1600121J_ses-03_echo-2_PDT2.nii.gz
        └── sub-E1600121J_ses-03_scans.tsv

4 directories, 11 files
❯ grep EchoTime dcm_qa_pdt2-bids/**/*json
dcm_qa_pdt2-bids/sub-E1600121J/ses-03/anat/sub-E1600121J_ses-03_echo-1_PDT2.json:  "EchoTime": 0.011,
dcm_qa_pdt2-bids/sub-E1600121J/ses-03/anat/sub-E1600121J_ses-03_echo-2_PDT2.json:  "EchoTime": 0.092,

so there is some mystery remaining since in another case (again - no access to data) where we had them sorted into two sequences, and thus might need immediately to name appropriately as _acq-PDT2_{T1,PD}w at heuristic level... inquiring... may be there is some option on console to send separated?

[bpinsard]

I think that is possible to split series with the "Multiple Series" option set to "each measurement".

With that setting, sorting at the heuristic level should be possible, but we cannot expect that to be the default in protocols.
I had to code another post-heudiconv fix to rename to the recommended BIDS pattern.

[yarikoptic]

Thank you @bpinsard !

Would there be some common UUID between those multiple series to see that they are coming from the same scan? looking at a dicominfo*.tsv sample I have -- unfortunately I do not see a bullet-proof way to group besides a "heuristic" that they are "consecutive" in series_id, have the same protocol_name and TR (dcm_dirname is not to rely on I guess):

so

• it would be up to a specific heuristic to handle "multiple series" if it knows that they are separate
  • generic heuristic like reproin should be smart and identify such split groups (per above heuristic) and potentially adjust the name (protocol_name would be the same).
    • either make it anat-PDT2 specific, or allow for some flexible specification in general for multiechos, like anat-me:PDw+T2w_acq-PDT2 signaling that multiecho must produce two suffixes, while adding _acq-PDT2 entity.
• heudiconv, when observing a case of dual-echo with heuristic provided suffix _PDT2 should internally rename (ideally it should be optional, but unfortunately we do not yet have config system to add to :-/).
  • @bpinsard what other post-heudiconv renames you do? ;)

[bpinsard]

I have an example where I had activated that option for the ihMT sequence from Marseille, in order to facilitate conversion to the BIDS MT spec.
The common ID tag on XA are PerformedProcedureStepID , SeriesDescription is the same in all series (as it is not series generated by the sequence recon but by Siemens stack) but could be repeated in the program.

I have 4 post-heudiconv fixes, mainly to deal with multiples files generated by dcm2niix from a single series and thus not managed by heudiconv:

• the pdt2 above: convert with PDT2 suffix and echoes, rename to _acq-PDT2_[PDw|T2w]
  pretty much .replace("_echo-1_PDT2", "_acq-PDT2_PDw").replace("_echo-2_PDT2", "_acq-PDT2_T2w") with git renaming for datalad, and rename in _scans.tsv
• fix_complex_events: delete events for part-phase bolds, remove part-mag from the other to be generic.
• fix_fmap_phase: BIDS does not allow phase data in fmap, so when updated within heudiconv from dcm2niix outputs, I have to remove phase files, and remove part-mag from the magnitude ones.
• fix_fmap_multiecho: remove echo-? from epi fmap, add it to acq- entity as this is not allowed in the spec.