Use plugins to save ROIs to OMERO

[will-moore]

See #17 (review)
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]

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]

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 #16 we'd have IDs for images opened from the tree.

[tlambert03]

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 #14 (comment) 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]

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.

[psobolewskiPhD]

This is referring to npe1 hook specs, so we should consider closing.
I'm not sure that if I opened an image from OMERO via the widget browser that I would expect File > Save to be the way to go to save something back to OMERO. I mean it makes sense when spelled out this way, but I don't think it's obvious at all to a user. I think having all the interactions within the menu of the plugin makes more sense and where I would look for such functionality.

In terms of scope, I think initially the biggest bang for the buck--at least for the users I support--is annotating or editing annotations of images already in OMERO, rather than arbitrary images -- I'll make an issue for this approach.