ROI CLI plugin proposal

[dominikl]

Proposal for a 'roi' CLI plugin, open for discussion.

[dominikl]

As @mtbc just mentioned that on the call: ROIs could be attached to multiple images and part of multiple folders. So image id and folder id should actually be a list of Ids. Is it worth taking that into account or not relevant for 'real-world' use cases?

[mtbc]

Glencoe may have some thoughts here. At present the OMERO model is such that if you import OME-XML with a ROI on two images then (if I recall correctly) it ends up being on just one of them. I don't know how we plan to align the two models. (Folders should indeed work fine though.)

[manics]

Is there any existing work on serialising ROIs/Shapes as json that you could use instead of defining a new format?

[dominikl]

If there is a short/nice json definition for a shape, happy to use that. Otherwise typing in a huge, complicated json string on the command line would be quite painful.

[manics]

There have already been two formats in the past for defining points: https://trello.com/c/hJLlf1Xr/47-error-on-preview-rois can we at least make this new format something that's standard across most apps?

[manics]

A couple more thoughts about defining points in the form 10 10 20 20 30 30:

• it's prone to error if this is aimed at manual entry, since there's nothing to distinguish numbers inside a tuple from those outside, e.g. if a user inadvertently misses out one number there are no visual cues to help find where the error is
• if we support proper 3D ROIs/points in future you can't distinguish between 2-tuples and 3-tuples

[dominikl]

Shall we just forget about the manual entry and only have the import from a batch file option, which then can contain json or whatever existing ROI format we have?

[joshmoore]

There's also this format -- https://github.com/CellMigStandOrg/biotracks -- which is basically "read from a CSV" which may be appropriate here.

cc: @rleigh-codelibre

[dominikl]

So the current idea is, that the ROI plugin should extract the ROIs from the HDF file, which Roger's IDR tool will generate. Right? That means plugin will be very specific to the IDR case, nobody else would really be able to use it in a different scenario.

[rleigh-codelibre]

For the HDF I was going to create, I didn't envision this being anything but a one-off screen-specific file for processing with one-off scripts for creating it and then feeding the data into OMERO. While it's possible it might have parts we could reuse for other data import tasks, I don't think it will be all reusable.

[joshmoore]

Probably best to get the first example in place and we'll iterate from there. @rleigh-codelibre : if you don't have the code anywhere else, https://github.com/IDR/idr-metadata/tree/master/features might be a good starting point.

[dominikl]

I guess with https://github.com/IDR/idr-metadata/pull/292 this design PR can be closed now. Right?

[joshmoore]

Let's discuss. Some decisions to make on how this repo is used.

[joshmoore]

see https://github.com/openmicroscopy/design/pull/83#issuecomment-363841544 which could imply this is 006 :)

[rleigh-codelibre]

See https://github.com/openmicroscopy/design/pull/84 for the suggested numbering and naming conventions.

[sbesson]

As per https://github.com/openmicroscopy/design/pull/85, feel free to rename this as OME008/index.md.

[dominikl]

Still, I think it can actually be closed. The hdf files are so project specific, don't know how there could be a generic roi plugin.

[joshmoore]

Did this change to a ROIReader proposal? :smile: