Sct_crop_image -ref result is one pixel smaller?

Dear SCT Experts!

I have a weird error using sct_crop_image with the -ref option. I have CoilQA data, which in my case results in an anatomical scan of 256x256x13, and an SNR map of 256x256x13x6. What I want is to crop the SNR map down to the size of the anatomical scan, such that a coregistered segmentation can be applied to the SNR map.
My steps are to:
1, Split the SNR map along the fourth dimension

52_coilQA_sag_FH_1p5x1p5x2mm_largeFOV.nii.gz -split t 

2, Crop the first split image with the anatomical scan of the CoilQA data:

sct_crop_image -i 52_coilQA_sag_FH_1p5x1p5x2mm_largeFOV_T0000.nii.gz -ref 53_coilQA_sag_FH_1p5x1p5x2mm_largeFOV.nii.gz

Which results in a cropped image, which, when opened in FSLeyes, does properly overlay with the anatomical, so far so good. However, further investigating, the size is off by one, where the x direction is 255, when it should be 256:

fslinfo 52_coilQA_sag_FH_1p5x1p5x2mm_largeFOV_T0000_crop.nii.gz
data_type	INT16
dim1		255
dim2		256
dim3		13

Subsequently, when I coregister a nice segmentation with the anatomical, it cant be used for sct_extract_metric with the cropped SNR map, because the two image sizes are not identical.

I have looked into the output of sct_crop_image, and I notice that the x and y bounding boxes are not identical, which might be the issue

sct_crop_image -i 52_coilQA_sag_FH_1p5x1p5x2mm_largeFOV_T0000.nii.gz -ref 53_coilQA_sag_FH_1p5x1p5x2mm_largeFOV.nii.gz

Bounding box: x=[129, 384], y=[128, 384], z=[0, 13]
Cropping the image...

Is there any way to solve this?

sct version is:

(base) danielpapp@Daniels-MacBook-Pro-2 COILQA_SAG_LARGE % sct_version 

Data is here, in case it helps:

Many thanks!


Hi @Daniel_Papp

It looks like this is a known issue: Wrong image dimensions when cropping image with a reference image · Issue #2768 · spinalcordtoolbox/spinalcordtoolbox · GitHub

There is some discussion in that issue about the intended usage of -ref, and whether sct_register_multimodal -identity 1 might fill that role instead. Could you try this function and see if it fits what you are trying to do?

If -identity 1 doesn’t fit your needs, then I can take a closer look to fix the bug, and clear up any confusion about the use-cases. :slight_smile:

Kind regards,


The -identity 1 flag does do the trick as far as I can tell.



1 Like