Flip image data L/R


#1

Hi,

Was there once a tool for flipping spinal cord data (sct_flip_cord.sh)? Or did I imagine it? :blush:

What is the recommended way of taking data into PAM50 space whilst performing a L/R flip? Is it to use sct_image? Any drawbacks?

Cheers,

Jon


#2

Hey Jon,

one way to modify the data sorting without touching the metadata (q/sform) is to use sct_image -setorient-data. First, check what dimension you’d like to flip:

sct_image -i t2.nii.gz -getorient
> AIL

Then flip it:

 sct_image -i t2.nii.gz -setorient-data AIR -o t2_AIR.nii.gz

Cheers,
Julien


#3

Hi Julien,

I think I can see the advantage of not touching the metadata - I hope :wink: !?

I tried this approach on a single volume that was already registered to PAM50 space:

$ sct_image -i elec_SC_mcf_tmean_reg.nii.gz -getorient
RPI
$ sct_image -i elec_SC_mcf_tmean_reg.nii.gz -setorient-data LPI -o test.nii.gz
Generate output files...
WARNING: File test.nii.gz already exists. Will overwrite it.

Done! To view results, type:
fsleyes test.nii.gz &

$ sct_image -i test.nii.gz -getorient
LPI

I’m not sure I understand the output. If the header remains unaltered, shouldn’t -getorient still return RPI?
When looking at the original and flipped data in fsleyes they look identical - unsurprising if the data and the header have both been flipped.

Trying to flip the orient of the metadata in the output from the previous step i.e.

$ sct_image -i test.nii.gz -setorient RPI
Traceback (most recent call last):
File "/Users/jon/sct_4.0.0-beta.5/scripts/sct_image.py", line 626, in <module>
main()
File "/Users/jon/sct_4.0.0-beta.5/scripts/sct_image.py", line 244, in main
im_out = [msct_image.change_orientation(im_in, arguments["-setorient"]).save(fname_out)]
File "/Users/jon/sct_4.0.0-beta.5/spinalcordtoolbox/image.py", line 426, in save
raise RuntimeError("Don't know where to save the image (no absolutepath or path parameter)")
RuntimeError: Don't know where to save the image (no absolutepath or path parameter)

Didn’t work as expected - I thought it would only touch the input, so not require an output. So tried:

$ sct_image -i test.nii.gz -setorient RPI -o test_RPI.nii.gz

which did change the handedness in the header:

$ sct_image -i test_RPI.nii.gz -getorient
RPI

But when looking in fsleyes the data (elec_SC_mcf_tmean_reg.nii.gz and test_RPI.nii.gz) still look identical. I wonder if fsleyes is looking at something else in the header and confounding my efforts to flip things around?

Let me know if you’d like me to share the data - I can send you a link.

Cheers, Jon


#4

Following up on this:

fslswapdim input -x y z output

seems to work as expected (with FSL version 5.0.11), the q/sform information is unchanged but the image data stored on disk are flipped. Images now look the wrong way round in fsleyes, which is right :wink:

The reason I gave the FSL version is that there was apparently a bug in FSL 6.0 with both fslswapdim and fslcpgeom, which might catch you out. I think it’s fixed in FSL 6.0.1 (released March 2019).

Best wishes,

Jon


#5

Jon,
you’re right, this is a known bug (which I forgot about, even if it was labeled with “HIGH PRIORITY”).
I’ll add it to my list of things to do for 4.0.0.
Thank you for the feedback and sorry for not thinking this was related to an opened issue.
Julien


#6

No worries - sorry to give you more work…

Jon