Hi,
Was there once a tool for flipping spinal cord data (sct_flip_cord.sh)? Or did I imagine it?
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
Hi,
Was there once a tool for flipping spinal cord data (sct_flip_cord.sh)? Or did I imagine it?
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
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
Hi Julien,
I think I can see the advantage of not touching the metadata - I hope !?
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
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
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
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
No worries - sorry to give you more workâŚ
Jon