Update spinal segments using Frostell et al. paper

[jcohenadad]

Context

After discussing with several researchers (incl. Nawal Kinany, Ilaria Ricchi, Rob Barry, Olivia Kowalcyk), and verifying the validity of the current spinal levels of the PAM50 template, we came to the conclusion that there is a 'missing' level at around C7, shifting all the caudal levels upwards. Consequently, the PAM50 spinal level file needs to be corrected.

Solution

A consensus strategy to update it, is to rely on the article by Frostell et al. Figure 1 from the paper is a good illustration of the spinal vs. vertebral segment location:

Methods

Table 3 from Frostell et al. indicates the location of spinal segments as a proportion of the cord:

So the plan is to identify the beginning of C1 and the end of S5 from the PAM50, and then place the spinal levels from these two upper/lower reference points.

The most rostral location of the C1 nerve rootlets seem to correspond to slice z=984:

The most caudal portion of the spinal cord seems to be located at the L1-L2 disc (which is also what is reported in Frostell et al.'s article), at slice z=40:

Implementation

My plan is to update the script that were used to generate the previous version of the spinal levels based on the Cadotte et al. article.

Related to #3 (issues #10 #12)

[jcohenadad]

Question: should I modify the script under this sct-dev repos or instead should we create a script inside this repos? (I would go for the latter) @joshuacwnewton @mguaypaq

[mguaypaq]

Since the sct-dev repo is intended as an archive, I would go with your second option as well. You can do it this way to have a useful git history:

1. Make a new branch as usual so that there can be a PR review later.
2. Copy the unmodified scripts you need from the sct-dev repo into this repo. Make a commit with this, and in the commit message, you can put a link to the sct-dev repo and mention the exact commit id, so that it's easy to trace.
3. Make whatever modifications you want as extra commits.

Also, I'm noticing that the sct-dev repo is currently private, is this intentional? I would assume that we can make it public, and then archive it (so that it becomes read-only, and clearly marked as historical).

[jcohenadad]

Also, I'm noticing that the sct-dev repo is currently private, is this intentional?

I suppose it is intentional, but I don't remember what was the intention. Maybe @joshuacwnewton remembers

[joshuacwnewton]

I don't recall the intention either. The only reason I could think of is... perhaps something was moved to sct-dev that was originally in a private repo? But I don't think that's the case, as looking at the history of the repo, it looks like all files in sct-dev are ones that were originally a part of the mainline spinalcordtoolbox repo.

Because of this, I support Mathieu's suggestion of making it public + archived. I'll do that right now.