Consider an alternative YAML scheme for `sg_manual_correction`

[joshuacwnewton]

In spine-generic's docs, it recommends using this YAML scheme:

FILES_SEG:
- sub-amu01_T1w_RPI_r.nii.gz
- sub-amu01_T2w_RPI_r.nii.gz
- sub-cardiff02_dwi_moco_dwi_mean.nii.gz
FILES_GMSEG:
- sub-amu01_T2star_rms.nii.gz
FILES_LABEL:
- sub-amu01_T1w_RPI_r.nii.gz
- sub-amu02_T1w_RPI_r.nii.gz

This was a little challenging to work with over at SCT while developing a QC report interface (spinalcordtoolbox/spinalcordtoolbox#3253) for 2 main reasons:

1. Subjects are identified by filename only

This works for BIDS datasets, because the subject is encoded in the filename, so each file will be unique.

But, on the SCT side of things, if a non-BIDS dataset structure is used, it's very possible the subject is encoded in the directory name instead (with the files themselves being generically named), which means that the filename might not uniquely identify the file.

So, SCT uses the absolute path for the image. The problem is, this is currently not compatible with sg_manual_correction due to how the filenames are parsed:

spine-generic/spinegeneric/utils.py

Line 136 in 6d7a6a2

fname = os.path.join(path_data, sg.bids.get_subject(file), sg.bids.get_contrast(file), file)

2. The SCT function is identified using only 3 categories (FILES_SEG/FILES_GMSEG/FILES_LABEL)

Each of these categories maps to 1 SCT function each:

spine-generic/spinegeneric/cli/manual_correction.py

Lines 91 to 99 in 6d7a6a2

	def get_function(task):
	if task == 'FILES_SEG':
	return 'sct_deepseg_sc'
	elif task == 'FILES_GMSEG':
	return 'sct_deepseg_gm'
	elif task == 'FILES_LABEL':
	return 'sct_label_utils'
	else:
	raise ValueError("This task is not recognized: {}".format(task))

But, SCT tries to map all SCT functions to these categories: spinalcordtoolbox/spinalcordtoolbox@64f68be.

The problem with this on SCT's end is, 3 categories is quite limiting, because it means the same image can show up multiple times in the same category. (For example, once for sct_deepseg_sc, and then another time for sct_register_to_template, which we've also associated with FILES_SEG. Right now, it would be impossible to tell which is which.)

Because of this, it might be nice if we could coordinate between SCT and spine-generic to come up with a scheme that works for both projects.

[valosekj]

Maybe, we could also consider to transfer sg_manual_correction script directly to SCT and make it more versatile (it would reduce script's forks like this one)

Rationale:
I am now working on some BIDS organised data and I use this script for manual corrections. But due to fact that sg_manual_correction is part of spine-generic, I had to install besides SCT also spine-generic package.

[joshuacwnewton]

Maybe, we could also consider to transfer sg_manual_correction script directly to SCT and make it more versatile (it would reduce script's forks like this one)

😄 👍

See also: spinalcordtoolbox/spinalcordtoolbox#3353

[valosekj]

May be potentially closed since we have introduced spinalcordtoolbox/manual-correction repository including manual_correction.py.