Thank you for your previous help with “funky” thoracic warping and improving the functionality of the center line viewer.
In all of my thoracic datasets, I have identified the most rostral and caudal vertebral levels and also identified the center line manually. However, despite manually entering control points and identifying the center line, there are still issues with accurately warping to the spinal cord template in about 1/3 of the data sets. The attached figure summarizes what I am seeing. I’m really not sure what happened in [a] (sheering and stretching), [b] exhibits compression equal to almost an entire vertebral level, [c] exhibits compression and sheering, and [d] exhibits sheering despite having nice contrast between the cord and CSF. In addition to manually labeling vertebral levels and identifying the center line, are there other things that I can do to help the function sct_register_to_template ?
hum, that could be caused by several things. I’m leaning towards a problem with the straightening. Would you be able to share one of the funky data and the associated segmentation & label you use as input of sct_register_to_template?
Thank you, @jcohenadad. I just shared the data and syntax with you. All data were processed in the same way; while some registrations were beautiful, others need some TLC. If there is something that I’ve done incorrectly, then I would appreciate the guidance so that all data may be processed correctly. And - as always - thank you for creating a great tool for this community and also providing support for its use.
So, the first thing I noticed is that the sagittal data have thick slices (2.5mm according to the qform). Any binary segmentation at this R-L resolution will be inaccurate, and so will be the straightening. So it is always very important to resample the data to isotropic resolution:
sct_resample -i t2.nii -mm 0.5x0.5x0.5 -o t2r.nii
However, even after doing so, the automatic segmentation fails quite a bit, even in regions where the cord/CSF contrast is fairly good. So I looked further at the images, and noticed an unusual compression of the image in the RL dimension. See e.g., the RL diameter of the cord is about 2.5mm, which seems surprisingly small (compared to the AP diameter, which I estimated at ~6mm):
I suspect something is fishy with the qform of your data… was it acquired with non-product sequence? Maybe a dcm to nii conversion issue? Do you have phantom data with known dimension so you can rule in/out that possible issue?
Thank you for the detailed reply! Indeed, I also noted that the cord appeared to be compressed in one of the datasets. These data were acquired several years ago by another group; while I don’t know the exact acquisition protocol, I am not aware that any non-product sequences that might have been used. I converted the dcm to nii myself, and the same code was used across datasets. Some of these datasets were not healthy controls, so perhaps, in addition to partial volume effects, there is spinal stenosis.
I have modified my preprocessing code to resample to 0.5-mm isotropic at the beginning; thank you for pointing this out. Much of the “funky” warping persists after interpolation, so I can exclude the tip of the cord in specific subjects.
I have run this code on 55 thoracic datasets, and it works on 54 of them. Curiously, on one subject it segments the cord beautifully but then fails to register it to the template. I re-defined the control points and center line several times, but it keeps failing with the output:
/Users/rob/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/numpy/core/fromnumeric.py:3373: RuntimeWarning: Mean of empty slice.
out=out, **kwargs)
/Users/rob/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/numpy/core/_methods.py:170: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)
I noticed another forum post on non-integer labels not matching (which I have also observed when reprocessing my data), and am not sure if this is the same issue or something different…
Update: I just re-ran this one subject with the SCT version downloaded this morning (git-master-e408b6589689ce2685d2a2cb83901db5b5aed017) and it worked. Perhaps the recent updates fixed the issue, or perhaps the code prefers running on a Friday?
Awesome news. The RuntimeWarning you posted above is not necessarily related to the label matching issue in DTI PAM50 template registration. Note that e408b6589689ce2685d2a2cb83901db5b5aed017 does not include the fix (we had unexpected delays from the CI before being able to merge on master so I counted my chickens before they were hatched , as I am writing these lines the PR is still not merge). But it is indeed possible that the most recent version included a related bug fix.
, as I am writing these lines the