Traceback when attempting to open image after successful connection to omero #13
Comments
|
hi @dstabley, looks like you're in a somewhat old environment (based on that dask version error). I don't yet know what's going on here... but do you still do you get the same error if you work in a fresh environment as described here? (note, you'll need to pip install from github ... so use depending on how you installed |
|
@tlambert03 I had been using my project's dev environment, but I just confirmed this with a brand new environment following your instructions. I cloned the repo to my local drive, made an env from your yml file, then ran the setup.py script. I then launched napari_omero, got the gui, saw that it was connected and could see my images. However, when I double click an image I get the same error as previously. The only thing I can't test thus far is the direct pip install git+git//URL method as this linux server seems to have that route blocked (keeps timing out). |
|
oh actually... are you always double clicking? I can actually see why that might cause this bug (which is fundamentally a problem with the way I'm clearing the viewer when loading a new image). if you single click and wait does it change anything? |
|
@tlambert03 just confirmed that single click also does the same thing. I can navigate the entire tree but can't open anything. |
|
ok thanks for checking. one more question: The stack trace indicates this is a bug in napari with removing a layer (and napari-omero attempts to remove all layers before loading one). but I'm still a little confused why it would happen on the first load, and not 2nd+ ... do you happen to have any layers already loaded in napari when you do this? (not that you shouldn't be able to do that... just curious) |
|
@tlambert03 I don't have any layers loaded. I just ran an interesting test, though. I uploaded a new synthetic data TIFF I had to my server and it loaded fine. I then noticed the images I had been trying to access have a common bug we were having where the metadata Z and T series were swapped. I'm guessing that maybe the plugin can't handle this metadata mismatch. Omero handles it on the server side, but if you're pulling on the assumption of a given number of planes or data shape it may cause a problem. One other detail is that the image that worked is 8 bit and the one that crashed is 16 bit. |
|
definitely interesting. I can certainly see how that might create a problem. but i can't quite see how it would result in the |
|
Ok great, let me know. I'm happy to run additional tests. |
|
@tlambert03 one more question - what is the most efficient way to grab an image that is loaded into Napari as a numpy stack in the backend? I haven't done this yet but pulling an Omero image and doing an operation on it would be cool. |
|
all of the layers have a import napari
import numpy as np
with napari.gui_qt():
viewer = napari.Viewer()
# just as an example to get a layer... it doesn't matter
# where the layer comes from, could have been loaded from OMERO
napari.add_image(np.random.rand(16,128,128))
# once you have a loaded layer, you need to get the layer object, like the "first" layer
layer = viewer.layers[0]
# here's the actual numpy (or dask, in the case of napari-omero) array
layer.data |
|
@tlambert03 some more interesting behavior. When I load an image through the standalone napari_omero viewer it loads fine, but when I add the napari_omero extension as a dockable widget in the embedded napari viewer in my application as such: I get the following when trying the same operation (note that there were no layers in the napari viewer as it had just been initialized and no operations had been performed): |
|
@tlambert03 Further development on the previous post - if I pre-load a points layer into my application's embedded Napari viewer before clicking on the Omero image selection it works properly. This is reproducible. I suspect that maybe this comes from https://github.com/tlambert03/napari-omero/blob/master/src/napari_omero/widgets/main.py line 83 and 84: Where the function selects all layers - is it possible that because my window initializes with no layers that this is throwing an exception? It's all I can think of as for why creating a null points layer fixes the crash. |
|
It’s definitely related to those two lines, but it should still not be an error to call remove_selected with no layers in the viewer. I need to look closer at the napari events there to see why it might be happening |
I'm able to connect to our Omero server using the master branch pulled from GIT, but when I attempt to pull an image I get a crash. The minimal reproducible step for me is to launch napari_omero from my env, log in using my credentials, and then double click an image to load. I am running this through VScode on an Ubuntu server using a virtual desktop.
The text was updated successfully, but these errors were encountered: