Entitly `part-` presents after `desc-` in output file

[htwangtw]

Version: 20.2.3

In my own code I am using a lazy way to find the relevant confound file by replacing the suffix of a bold image from sub-<subject_label>_[specifiers]_space-<space_label>_desc-preproc_bold.nii.gz to sub-<subject_label>_[specifiers]_desc-confounds_timeseries.tsv based on fMRIPrep documentation.

However we encounter a case today where they have entity part in the file name with data processed with fmriprep v20.2.3:

sub-01_ses-001_task-stuff_space-T1w_desc-preproc_part-mag_bold.nii.gz

From my understanding of BIDS entity order, the functional derivative file name should be

sub-01_ses-001_task-stuff_part-mag_space-T1w_desc-preproc_bold.nii.gz

as the order roughly follows the order noted here: https://bids-specification.readthedocs.io/en/stable/99-appendices/09-entities.html ? By this logic, entity part should be a part of the [specifiers]

Is this a known issue fixed in the later 20.2.x patch? cc @bpinsard

[effigies]

We don't do anything with part-, so I'm a bit surprised that it's treated differently. I'd say this is a bug.

[effigies]

Could you provide a listing of an example subject, btw?

[htwangtw]

I don't have access to the raw data but here's the functional derivative:

sub-01_ses-001_task-stuff_desc-confounds_part-mag_timeseries.json
sub-01_ses-001_task-stuff_desc-confounds_part-mag_timeseries.tsv
sub-01_ses-001_task-stuff_from-scanner_to-T1w_mode-image_part-mag_xfm.txt
sub-01_ses-001_task-stuff_from-T1w_to-scanner_mode-image_part-mag_xfm.txt
sub-01_ses-001_task-stuff_space-fsLR_den-91k_part-mag_bold.dtseries.json
sub-01_ses-001_task-stuff_space-fsLR_den-91k_part-mag_bold.dtseries.nii
sub-01_ses-001_task-stuff_space-fsLR_den-91k_part-mag_bold.json
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-aparcaseg_part-mag_dseg.nii.gz
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-aseg_part-mag_dseg.nii.gz
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-brain_part-mag_mask.json
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-brain_part-mag_mask.nii.gz
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-preproc_part-mag_bold.json
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_desc-preproc_part-mag_bold.nii.gz
sub-01_ses-001_task-stuff_space-MNI152NLin2009cAsym_part-mag_boldref.nii.gz
sub-01_ses-001_task-stuff_space-T1w_desc-aparcaseg_part-mag_dseg.nii.gz
sub-01_ses-001_task-stuff_space-T1w_desc-aseg_part-mag_dseg.nii.gz
sub-01_ses-001_task-stuff_space-T1w_desc-brain_part-mag_mask.json
sub-01_ses-001_task-stuff_space-T1w_desc-brain_part-mag_mask.nii.gz
sub-01_ses-001_task-stuff_space-T1w_desc-preproc_part-mag_bold.json
sub-01_ses-001_task-stuff_space-T1w_desc-preproc_part-mag_bold.nii.gz
sub-01_ses-001_task-stuff_space-T1w_part-mag_boldref.nii.gz

[bpinsard]

As a side note, exporting phase data (more as an exploratory choice) and trying to put it in BIDS has been triggering a lot of problems in different parts of the pipelines that we use, including heudiconv. This is a part of BIDS and BIDS-apps that is maybe not covered by tests.

[bpinsard]

@tsalo is that something that is fixed by https://github.com/nipreps/niworkflows/pull/594 ? Should this be backported to the LTS, or it's too complex (depends on niworkflows/pybids changes) ? Thanks!

[tsalo]

I believe it should based on the changes to the filename patterns. However, the main goal of that PR was just to deselect phase data during the data collection step, so I don't know if this particular problem was tested. I don't know about interactions with pybids though. I think @effigies can speak to that better than I can.

[effigies]

Sorry, I haven't had time to figure out why this is happening. I vaguely recall writing tests and reproducing it, but if I opened a PR it seems to be lost.

I think we should be able to fix this in LTS, though.

[tsalo]

It looks like this is fixed now. I processed some complex-valued data with 23.2.0.dev39+g36404281 recently and the part entity was in the right position.