search

tlambert03 / napari-omero

Browse your OMERO database from within napari.
GNU General Public License v2.0
33 stars 10 forks source link

Use plugins to save ROIs to OMERO #20

Open will-moore opened 4 years ago

will-moore commented 4 years ago

See https://github.com/tlambert03/napari-omero/pull/17#pullrequestreview-441080882 Use napari_write_shapes and napari_write_labels writer plugins to allow saving ROIs to OMERO. This has the advantage that we don't need to clutter the UI with "Save to OMERO" buttons and it will be available without having to launch with $omero napari view

will-moore commented 4 years ago

Having looked at this a bit more, I see that the main issue is that a newly created Shapes or Labels layer won't have any OMERO Image:ID metadata associated with it, so that the plugin won't know where to save the ROIs. Maybe that's what @tlambert03 meant with "it may not be immediately straightforward at the moment".

The way that the current $ omero napari view Image:1 plugin handles this currently is to add a "Save ROIs to OMERO" button and a reference to the OMERO image is kept in the click handler. But this requires additional image opening logic. It could be possible to add something similar within the UI logic where we open an Image from the tree (somehow saving some global state that is accessible from the napari_write_* plugins??? But, even if this works, then it wouldn't be handled with $ napari Image:1.

One alternative is that the omero reader plugin could return extra shape, label and points layers along with the Image channel layers. These could contain any existing ROIs from OMERO, or just be blank (but still have the Image:ID in their metadata, so that when they are edited and saved, we know where to save them. But that still doesn't handle the case where a user does some processing and creates new layers then saves them. They will have to enter "Image:ID" into the layer save dialog. I guess this isn't so bad when they've just opened an image by ID, eg. `$ napari Image:1``` but if they've opened an Image from the UI tree, they won't even know it's ID.

Any thoughts?

joshmoore commented 4 years ago

somehow saving some global state that is accessible from the napari_write_* plugins???

The alternative would be for the layer saver to be able to detect the image(s) which the layer is on, get it's metadata, and see that it should be saved to OMERO ??

but if they've opened an Image from the UI tree, they won't even know it's ID.

I would have thought with https://github.com/tlambert03/napari-omero/issues/16 we'd have IDs for images opened from the tree.

tlambert03 commented 4 years ago

I see that the main issue is that a newly created Shapes or Labels layer won't have any OMERO Image:ID metadata associated with it, so that the plugin won't know where to save the ROIs. Maybe that's what @tlambert03 meant with "it may not be immediately straightforward at the moment".

Yeah exactly. I have a local branch where I had started to implement writer plugins for ROIs, and realized that the current code was making the assumption that we only ever had a single image open, and that it had been loaded via the plugin. That's what prompted the https://github.com/tlambert03/napari-omero/pull/14#discussion_r446664444 that led to #16.

I'd like to do this in as general of a way as possible ... meaning you should be able to load a naive image (not from OMERO), create a new layer with annotations, and then save them to OMERO. but that of course requires a lot more user input than the napari plugin architecture is capable of collecting at the moment. We can attack this from the napari side as well, but in the meantime, I was envisioning "cheating" a bit and opening a GUI that would prompt the user to complete any missing information such as which open Image to associate the ROI with (and if that image is not already on OMERO, save it to a user-specified destination on OMERO... or if we have some images with IDs in their metadata from #16, we can offer those in a dropdown)

This would be similar to what I'm doing with the reader plugin here. Note that if you run viewer.open('Image:1'), while not logged into OMERO, the get_gateway function in the plugin here will actually popup a blocking GUI that has you login, and then continues with the execution.

It's a fair amount of work to create those GUIs, but I think I have a clear view of how it could all work in a general way. We should start with #16 though (even if it's just Image:ID for now)

tlambert03 commented 4 years ago

Also want to point out that in addition to the napari_write_<layer_type> hookspecs, there is another one called napari_get_writer that is called when saving multiple layers. This one is much more "open ended" and lets the plugin combine information from multiple layers as desired. So if a Labels and Image layer were selected when the user selects "Save Layers"... then we would be much closer to knowing how to handle it on the OMERO side.