OMERO ROIs improvements : filtering visible and adding all

[Rdornier]

Fixes #628

When clicking on Load ROIs, only ROIs that can be added (i.e. intersecting the viewport) are displayed in the list. This makes the interface more clear and when the mouse is passed over the ROIs, they can all be seen. The number of available ROIs vs total ROIs is also displayed.

Additionnally, a button Add all is added to insert all visible ROIs at once, to not have to add them all manually.

[Rdornier]

I was wondering if having also a field to filter ROIs by comment can be beneficial. I guess yes. Users could enter text and only ROIs which contain the specified text will be displayed. In that scenario, Add all will add all ROIs according to the text filter.

The scenario I have in mind is coming from QuPath. Users create annotations of different classes and then may want to get only those from specific class. I'll have a look on that once the Label on ROIs PR is merged, as it requires to get access to text attribute.

[pwalczysko]

@Rdornier Thank you. With how many ROIs have you tested this please ? The reason I am asking is that we have already pondered such feature and went back to the drawing board because of performance issues.

[Rdornier]

Hi @pwalczysko

Thanks for your feedback. I wsn't aware that this was already tested. I was testing with 10-20 ROIs and it worked fine. I've given a try with 280 and now, I begin to see a bit of lagging when adding them all (15s). Also, after saving them, when changing dimensions of the panel, the responsivity is also not the best.

One thing I could add it to enable Add all option only if the number of visible ROIs is lower than a certain number (ex: 200), to avoid having such lagging issue. And also working only on the current page (not loading all ROIs from all pages).

I really would like to add this feature to add all ROIs at once because this is a scenario that is asking more and more often. Users are using QuPath and would like to display annotations, of a with a certain name, in their figure. That's why I also would like to implement the text filter.

[will-moore]

#430 was my attempt at this a while back, and #335 was the original issue.

I think the performance issues in both cases come from testing the intersection with the viewport by creating each shape in shapeEditor first. We probably need to figure out a way to do a rough filter by shape coordinates. It might be hard to know if a line/arrow with the start and end points outside of the viewport actually intersects with the viewport, or if an ellipse with a particular rotation might intersect or not. But, we should still be able to rule out many shapes.

Then let's set a limit on the number we allow users to add, e.g. test with 100 or 200.

Filtering by text would be nice too.

[will-moore]

Hi Rémy,
I think the nicest way to do the filtering is on the server, so that we don't get the strange pagination behaviour above (showing only 1 ROI from the first page). This should also be more performant than loading a large number of Shapes in the browser and testing each one at a time in ShapeEditor. It would also be much nicer for when you're looking at a small region of a Big image which could have a large number of ROIs that aren't in your viewport.

This will be a bit more work (maybe too much?), because currently we use the JSON API endpoint. So we'd need to reuse some of that code in figure and add the python based filtering or (preferably) add region-based filtering to the JSON API. I imagine if the URL included ?region=x,y,w,h e.g. ?region=100,100,500,500 then we could generate an sql query that would use those coordinates to exclude points, rectangles, lines (arrows) and text shapes that are outside that region. For polygons and polylines, we'd probably need to do some manual filtering in python.
It will need some initial investigation of what's possible in sql. E.g. I think it would be reasonable to exclude a line that has neither ends within the region (even though the line may pass through the region).

[will-moore]

Need to discuss a bit with @jburel to decide the best approach here...

[Rdornier]

I think the nicest way to do the filtering is on the server, so that we don't get the strange pagination behaviour above (showing only 1 ROI from the first page).

I agree, yes. That would be nice. What about the filtering by ROI comments ? That's something I also would like implement because it can be helpful. I guess this filtering will also be part of the sql query, right ?

[will-moore]

I've removed the include label for now to avoid merge conflicts while we try to move the Zarr work forward.