-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different sform between native image and derivatives #77
Comments
Hi @jcohenadad I have noticed that: for image sub-P001_UNIT1.nii.gz
It means that the image is aligned with the scanner coordinates and that an affine transformation is required for this alignment. I see in the image sub-P001_UNIT1_lesion-manualNeuroPoly.nii.gz
It means that the image is aligned with the scanner coordinates and that for this alignment there have been no transformations (perhaps that is why they are not aligned with sub-P001_UNIT1.nii.gz). (see https://nipy.org/nibabel/nifti_images.html) I am working on the same subject, in the
|
Ah! It seems that FSLeyes v1.6.1 and v1.5.0 don't deal with overlays in the same way. On v1.5.0: On v1.6.1: Additional info about the display in FSLeyes, although that doc probably refers to the latest version (1.8.3): https://open.win.ox.ac.uk/pages/fsl/fsleyes/fsleyes/userdoc/display_space.html#display-space. Sidenote: another cool feature of v1.5.0 is that the JSON sidecar is interpreted and read by FSLeyes: Interestingly, this difference in interpreting the sform_name/sform_code is not mentioned in the changelog: https://open.win.ox.ac.uk/pages/fsl/fsleyes/fsleyes/userdoc/changelog.html#thursday-23rd-february-2023 Although now, I am wondering if these differences come from the versions, or the way I access them:
Maybe @pauldmccarthy has some insights for us 😊 Moving forward, I think we should:
@Nilser3 can you please do that? |
Hi @jcohenadad @Nilser3, is there any chance that you could share the problematic images (and JSON sidecar files) so I can have a play? There have not been any intentional changes related to the handling of sforms/qforms or sidecar files since version 1.5.0 .... If you have two images which are voxelwise aligned, but are not aligned when viewed in FSLeyes, a good solution is to use FSL's For clarification, FSLeyes will use either the sform or the qform, depending on the values of the [s|q]form_code - this is detailed under the World coordinate system section of the FSLeyes display space page. |
Thank you for chipping in @pauldmccarthy. Here are the image (masked with a 15x15x1 mask centred at 145x195x91 voxel space for ethics reason)-- the mask is on a lesion so you can test the overlay with the lesion mask: sub-P001_UNIT1.zip. The image does not have a JSON sidecar. |
Hi @jcohenadad, Hmm, FSLeyes v1.8.3 seems to be behaving just fine for these images - the image and mask are aligned by default (and FSLeyes doesn't complain about them having different orientations/FOVs): I took another look at your screenshots, and noticed that FSLeyes is complaining about differing orientations/FOVs in your v1.6.1 screenshot. The code which controls whether this warning is displayed has not changed in several years (it is a simple routine which compares the shape and voxel->world affine of all loaded images), so I'm wondering if you were viewing the same two images in both screenshots? In FSLeyes 1.8.3, the JSON metadata for the mask is displayed in the info panel for me. One point which I should have made in my previous comment is that JSON information for an image will only be displayed if that image is selected in the overlay list - in your earlier screenshot demonstrating missing JSON metadata, it looks like sub-P001_UNIT1 was selected? |
One other comment on the use of the sform/qform affines (which I'm sure you're already aware of! but just for completeness :) ) - FSLeyes and FSL use the sform and qform interchangeably, and will use either depending on the values of the [s|q]form_codes, as outlined in the FSLeyes display space page (linked in an earlier comment). Because FSL uses the sform/qform interchangeably, some FSL tools may "normalise" the sform/qform when writing out an image, setting them both to be the same affine. However, other tools may follow different conventions, and may use and/or update the sform/qform using different conventions. This is important to take into account for a typical pipeline which uses tools from a variety of software packages. Whenever you invoke any tool which does things differently to the convention you have chosen, you will need to adjust the output images using |
yes, here is a screen recording: https://www.dropbox.com/s/kbgrocfb1fkr3e9/Screen%20Recording%202023-09-22%20at%209.15.33%20AM.mov?dl=0 |
I also confirm that upgrading to 1.8.3 (using However, I am wondering how to launch FSLeyes from the Terminal with a conda installation. I tried launching Terminal output(base) julien-macbook:~ $ ./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes
Traceback (most recent call last):
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/osmesa.py", line 22, in GL
return ctypesloader.loadLibrary(
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/ctypesloader.py", line 36, in loadLibrary
return _loadLibraryWindows(dllType, name, mode)
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/ctypesloader.py", line 89, in _loadLibraryWindows
return dllType( name, mode )
File "/Users/julien/miniconda3/lib/python3.10/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
OSError: ("dlopen(OSMesa, 0x000A): tried: '/Users/julien/miniconda3/lib/python3.10/lib-dynload/../../OSMesa' (no such file), '/Users/julien/miniconda3/bin/../lib/OSMesa' (no such file), 'OSMesa' (no such file), '/usr/local/lib/OSMesa' (no such file), '/usr/lib/OSMesa' (no such file), '/Users/julien/OSMesa' (no such file)", 'OSMesa', None)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/julien/./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes", line 5, in <module>
from fsleyes.filtermain import main
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/__init__.py", line 374, in <module>
from fsleyes.main import embed, shutdown # noqa
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/main.py", line 46, in <module>
import fsleyes.cliserver as cliserver
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/cliserver.py", line 37, in <module>
import fsleyes.actions.applycommandline as applycli
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/actions/applycommandline.py", line 28, in <module>
import fsleyes.parseargs as parseargs
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/parseargs.py", line 273, in <module>
import fsleyes.plugins as plugins
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/plugins/__init__.py", line 241, in <module>
import fsleyes.views.canvaspanel as canvaspanel
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/views/canvaspanel.py", line 20, in <module>
from . import colourbarpanel
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/views/colourbarpanel.py", line 15, in <module>
import fsleyes.gl.wxglcolourbarcanvas as cbarcanvas
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/gl/wxglcolourbarcanvas.py", line 17, in <module>
import fsleyes.gl.colourbarcanvas as cbarcanvas
File "/Users/julien/miniconda3/lib/python3.10/site-packages/fsleyes/gl/colourbarcanvas.py", line 21, in <module>
import OpenGL.GL as gl
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/GL/__init__.py", line 3, in <module>
from OpenGL import error as _error
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/error.py", line 12, in <module>
from OpenGL import platform, _configflags
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/__init__.py", line 56, in <module>
_load()
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/__init__.py", line 53, in _load
plugin.install(globals())
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", line 97, in install
namespace[ name ] = getattr(self,name,None)
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", line 15, in __get__
value = self.fget( obj )
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/osmesa.py", line 66, in GetCurrentContext
function = self.OSMesa.OSMesaGetCurrentContext
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", line 15, in __get__
value = self.fget( obj )
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/osmesa.py", line 60, in OSMesa
def OSMesa( self ): return self.GL
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", line 15, in __get__
value = self.fget( obj )
File "/Users/julien/miniconda3/lib/python3.10/site-packages/OpenGL/platform/osmesa.py", line 28, in GL
raise ImportError("Unable to load OpenGL library", *err.args)
ImportError: ('Unable to load OpenGL library', "dlopen(OSMesa, 0x000A): tried: '/Users/julien/miniconda3/lib/python3.10/lib-dynload/../../OSMesa' (no such file), '/Users/julien/miniconda3/bin/../lib/OSMesa' (no such file), 'OSMesa' (no such file), '/usr/local/lib/OSMesa' (no such file), '/usr/lib/OSMesa' (no such file), '/Users/julien/OSMesa' (no such file)", 'OSMesa', None) Note: I tried inside and outside conda's virtual env. |
@jcohenadad Depending on how FSLeyes is installed, sometimes the entry points don't get created correctly (this is an issue with conda). You may need to edit
change it to:
Regarding the orientation issue, perhaps this is due to a difference in nibabel version - can you check what versions of nibabel and fslpy you have installed for both your 1.5.0 and 1.6.1 FSLeyes installations? They should be listed in the FSLeyes about dialog. |
FSLeyes 1.6.1, nibabel [5.1.0], fslpy [3.11.2] Full outputFSLeyes version: 1.6.1
FMRIB Centre, Oxford, UK
Paul McCarthy
[email protected]
FSL version: None
FSL directory: /Users/julien/fsl
OpenGL version: 4.1
OpenGL compatibility: 3.3
OpenGL renderer: AMD Radeon Pro 5300M OpenGL Engine
FSLeyes was developed at the FMRIB Centre, Nuffield Department of Clinical Neurosciences, Oxford University, United Kingdom.
FSLeyes is a Python application which leverages the following open-source software libraries:
- fsleyes-props [1.9.3] (https://git.fmrib.ox.ac.uk/fsl/fsleyes/props)
- fsleyes-widgets [0.13.0] (https://git.fmrib.ox.ac.uk/fsl/fsleyes/widgets)
- fslpy [3.11.2] (https://git.fmrib.ox.ac.uk/fsl/fslpy)
- indexed_gzip [1.7.1] (https://github.com/pauldmccarthy/indexed_gzip/)
- IPython [8.12.0] (https://ipython.org/)
- jinja2 [3.1.2] (http://jinja.pocoo.org)
- Jupyter notebook [6.5.4] (https://jupyter.org)
- matplotlib [3.7.1] (http://www.matplotlib.org)
- nibabel [5.1.0] (http://nipy.org/nibabel)
- numpy [1.21.6] (http://www.numpy.org)
- pillow [9.2.0] (http://python-pillow.org/)
- pyopengl [3.1.6] (http://pyopengl.sourceforge.net)
- pyparsing [2.4.7] (http://pyparsing.wikispaces.com/)
- scipy [1.10.1] (http://www.scipy.org)
- six [1.16.0] (https://pythonhosted.org/six/)
- trimesh [3.21.5] (https://github.com/mikedh/trimesh)
- wxpython [4.2.0] (http://www.wxpython.org)
- wxnatpy [0.4.0] (https://github.com/pauldmccarthy/wxnatpy/)
- xnatpy [0.5.1] (https://bitbucket.org/bigr_erasmusmc/xnatpy) Unfortunately (or fortunately) I don't have access to FSLeyes 1.5.0 anymore because I just upgraded it to 1.8.3. |
I tried it (with both julien-macbook:~ $ ./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes
./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes: line 3: import: command not found
./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes: line 4: import: command not found
from: can't read /var/mail/fsleyes.filtermain
./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes: line 7: syntax error near unexpected token `('
./miniconda3/share/fsleyes/FSLeyes.app/Contents/MacOS/fsleyes: line 7: ` sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])' |
Yep, I think this explains the discrepancy - nibabel has some logic to decide whether a quaternion vector is valid, and thus whether or not to use a NIfTI qform affine. In version 5.1.0 this logic was changed, and this had a knock-on effect in FSLeyes, which I fixed in FSLeyes version 1.7.0. So
Looks like the |
Looks like I do have the interpreter:
Here you go:
|
And is
or
|
Looks like it's a copy:
Yup! That worked 🎉 I'll simply create an alias for fsleyes. Thank you so much for your help! |
Data version:
sform is different between the image and its derivatives. Example for
sub-P001
:sub-P001_UNIT1.nii.gz
sub-P001_UNIT1_lesion-manualNeuroPoly.nii.gz
This results in overlay issue when visualizing with FSLeyes (which uses sform):
Given that ground truths were made with FSLeyes, I am wondering why we did not observe this issue earlier? Maybe the derivatives data changed at some point?
@Nilser3 how are you able to observe the data and derivatives properly aligned in FSLeyes (eg as in #76)
The text was updated successfully, but these errors were encountered: