Is there an upper limit for the number of ROIs for iviewer?

[Kouichi_C_Nakamura]

Hello.

I have prepared a stack of 35 images containing overall 2819 ROIs.
They were prepared as OME-TIFF files per Z slice.

I was able to confirm that those ROIs were associated with specific Z slices when opened with Fiji by using Bio-Formats Importer.

However, in the iviewer of OMERO server (https://demo.openmicroscopy.org/), while it says there are 2819 ROIs, the ROI list on the righthand panel show only a subset. And while all the items on the list were ticked, clearly a lot of them are not found on the current Z slice. Moreover, each Z slice shows only ~20% of ROIs that they are supposed to show (the number of ROIs shown per slice in Fiji was a lot more).

I suspect that in iviewer implementation, there might be an upper limit for the number of ROIs that can be handled. I even suspect that the value might be 500, because in one occasion iviewer showed 500 ROIs instead of 2819 ROIs.

If there is an upper limit, can I modify it?

Or should I just give the idea of uploading the whole data as a huge Z stack and treat individual Z slice independently? The advantage of the former data format is that I can use Z slider, which is much faster than clicking the thumbnails. See http://www.openmicroscopy.org/community ... 602#p20089

Best,
Kouichi

[mtbc]

Dear Kouichi,

Your suspicion is right on target: see https://trello.com/c/LdGRTtZI/7-omeroiv ... l-blockers. There is a omero.client.viewer.roi_limit configuration property but OMERO.iviewer always limits to 500. This is certainly an issue that's on our radar: we agree that it needs fixing.

Cheers,
Mark

[waxenegger]

Hello Mark and Kouichi,

I believe if you increase "omero.web.api.max_limit" (which is 500 at the moment) you can go up to 5000.

The above limit will always be applied regardless of what iviewer sets when it requests:

https://github.com/openmicroscopy/openm ... ery.py#L83

From the code it seems that 5000 is set as the upper limit:
https://github.com/ome/omero-iviewer/bl ... nfo.js#L41

It's worth a try at least
In terms of performance the one thing that might slow things down is actually the table, more so than the display of the shapes in openlayers.

Harald

PS: Failed to mention (as a word of caution) that this is the web api request limit. So it is going to apply to other web api requests if they themselves don't have a given limit/page size set.

[Kouichi_C_Nakamura]

Thank you both guys.

The main reason I wanted to show the data as Z stack was that the Z slider response was much faster than thumbnails. The data are not actual Z stack per se. They are consecutive sections of mouse brain with a regular interval.

But now I see the downside of this approach as well. Even if I manage to set the upper limit to 5000 somehow, the table view on the right-hand side won't just show the ROIs associated with the current Z slice. So it will be difficult to find the relevant ROIs in the table; eg. when section #20 (Z =19) is presented, the table shows a lot of ROIs in other Z slices (other sections). And there won't be a simple solution to this issue, I suppose.

So now I'm inclined to get back to the original plan of submitting individual images separately.