-initz flag and label value correction

[PaulBautin]

In the current implementation (b5d01bd), when specifying -initz, the value corresponds to the upper vertebral level whereas it should be the lower levels. E.g., Label 4 is interpreted as C4/C5 disc, whereas it should correspond to the C3/C4 disc.

The bug occurred when user used -initz flag but not when automatically finding c2c3 disc. This is because automatic c2c3 used the precedent label value convention (label value 2).

I've updated sct_label_vertebrae to use the new label value convention (label value 3).

However I've left vertebral_detection (core.py) use the precedent convention and shiftted it's init_disc value by one (should it be done in sct_label_vertebrae?). This could have for consequence to crash other programs still using the precedent convention.

DONE:
-No change in the usage
-modification in core.py: label value is shifted by one
-flag -initz takes correct label value
-C2_C3 automatic detection now takes label value 3
-Could the modification in core.py crash other scripts?

Fixes #2608

[jcohenadad]

to be consistent, if you remove the explanation you also need to remove the code that actually does the "minus one"

[PaulBautin]

-I've changed sct_label_utils for Image(fname_initlabel).save(fname_labelz). It seems to work fine.
-Responding to second comment. vertebral_detection in core.py uses the precedent convention. Should I shift label value in core.py and see what happens or shift label value in sct_label_vertebrae

[jcohenadad]

-I've changed sct_label_utils for Image(fname_initlabel).save(fname_labelz). It seems to work fine.

I don't see your change. Which commit are you referring to? But regardless, my point was that you should not do this "minus one" operation anymore (for the same reason you removed the comment)

[jcohenadad]

-Responding to second comment. vertebral_detection in core.py uses the precedent convention. Should I shift label value in core.py and see what happens or shift label value in sct_label_vertebrae

I don't know which "second comment." you are referring to (there is only one comment in this thread). If you are referring to another post in this PR, a good habit within Github is to add a hyperlink to the post you are referring to.

[jcohenadad]

Could the modification in core.py crash other scripts?

good question-- i guess we (incl. you) need to find out :-)

[jcohenadad]

I've tried running 913c04a and noticed that the labeling below the specified z value is now wrong (see image below: C4 should be followed by C5, not C6):

To reproduce:

sct_download_data -d sct_testing_data
cd sct_testing_data/t2
sct_propseg -i t2.nii.gz -c t2 -qc qc
sct_label_vertebrae -i t2.nii.gz -s t2_seg.nii.gz -c t2 -initz 34,4 -qc qc

[jcohenadad]

I've tested the following options and the script works as expected (i.e. no bug introduced by this PR):

 -initz <list of: int>
 -initcenter <int>
 -initlabel <file>

[PaulBautin]

Program fails when using "initlabel" on "sct_label_vertebrae".
When "fname_labelz" takes "fname_initlabel" path, "isct_antsAppllyTransforms" does not find "labelz.nii.gz" anymore.

See error:
log-error-sct_label_vertebrae.txt