populate metadata at image-level

[erindiel]

Adds an ImageWrapper to populate an OMERO.table at the image-level with ROI-level data. This requires an roi column containing ROI ID. Multiple rows per-ROI ID are allowed (see object-level case below), but ROIs with appropriate IDs must exist in image.

Note that the Tables dropdown is not populated at the image-level, but a bulk annotations file is added to attachments.

This can also be used to populate object-level analytics to refer to objects in a label image/mask associated with an ROI, where objects are encoded by their pixel value in the label image. There is currently no checking of this object column (for example, to confirm that these objects exist in the label image associated with the corresponding ROI), and this column need not exist at all. Once the label mask workflow is solidified, these checks might be helpful to implement.

An example has been added to README.

[sbesson]

Closing/reopening to use the new GitHub action

[imagesc-bot]

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/former-omero-help-site/44920/3

[sbesson]

Thanks for the contribution @erindiel. I successfully tested with a very minimal example:

Confirmed that the population script works as expected and creates an OMERO.table that is accessible via the client. If additional rows with non-existent ROIs are passed to the image, these rows are stripped from the table like the rest of the metadata population worfklow.

The API addition makes sense although it could benefit from a minimal integration test to prevent future regression.

A few general thoughts and questions:

• in terms of UI cross-referencing, similarly to how Well and Image columns are linking to the relevant ?show=.. URL, I would almost like to see the ROIs above linking to the /iviewer/?roi=413362 URL introduced in https://github.com/ome/omero-iviewer/pull/311. I understand the latter endpoints are specific to iviewer but would there a way to forward a webclient call @will-moore ?
• is it worth looking into a minimal integration test for the new functionality to prevent future regression?
• the worklow described above requires an a priori knowledge of the ROI IDs. My assumption is that it is driven by the use case where images and ROIs have been created on a server and derived analytics are run against it. A separate use case, that we are getting more on the publication/IDR side, is the one where ROIs with associated metadata have been pre-computed and would both need to be populated. In that case, a naive assumption is that the workflow above should be extendable to support and hande a roi name column similarly to image vs image name. Have you faced this use case and/or some experience with this use case?

[manics]

I would almost like to see the ROIs above linking to the /iviewer/?roi=413362 URL

If Iviewer is the default viewer it's loaded using the default /weclient/img_detail/<iid> endpoint: https://idr.openmicroscopy.org/webclient/img_detail/10560145/ So maybe you could pass additional query parameters ?roi=413362 and have them forwarded to whatever viewer is configured? Effectively this defines a new API that implementers of /weclient/img_detail/ should support (though they are of course free to ignore parameters)

[will-moore]

If iviewer is opened via /webclient/img_detail/18188/ or /iviewer/?images=18188 then in either case we have the Image ID, so that adding ?shape=123 is ignored. However, there is the makings of an API in that iviewer and the old viewer support e.g. rendering settings ?c=-1|0:2417.9873046875$0000FF etc. Also iviewer and pathviewer (I think) support ?dataset=3183.

[erindiel]

With 7c162daed7ed3088d3d815f0193a2d4b29c31b72, you should be able to use either an roi type column with ROI ID or s type column with Roi Name. The other will be appended automatically. If you use both, nothing will be appended. 25391af929012287967f753a8f79732d5b90b9fa adds some documentation of this.

96e9308394db3cc83c3292e188347b7a304cc901 errors if ambiguous names are used as the identifying column (ambiguous names are OK if IDs are there too).

Open to feedback on whether this covers your use cases @sbesson!