Scalability limits of OMERO (large datasets ~500TB) and channel handling limitations for high-dimensional images (100+ channels)

[ZYsAccount]

We are currently deploying OMERO in a large-scale spatial proteomics / multiplex imaging environment and evaluating its suitability as a long-term data management and visualization platform.

During our testing with OMERO (Docker-based deployment), we encountered two important questions that are not clearly addressed in the current documentation.

We would greatly appreciate clarification from the development team.

1. Data scale / system limits (~500TB)

We are planning to manage very large imaging datasets, potentially reaching hundreds of terabytes (~500TB total storage).

We would like to understand:

Is there any practical or architectural limit for OMERO in total managed dataset size?
Would OMERO remain stable and performant at ~500TB scale?
Are there known bottlenecks in:
OMERO.server performance under large metadata load
PostgreSQL scalability (number of images / datasets)
ManagedRepository / Pixels storage layer
Web viewer or API performance at large scale
Are there recommended best practices for such scale, e.g.:
multiple OMERO servers
distributed storage backend
database tuning strategies

Any guidance or real-world deployment experience at this scale would be very helpful.

2. Channel number limitation (high-dimensional imaging)

We are working with highly multiplexed imaging data.

We successfully imported a pyramidal OME-TIFF containing 184 channels.

Observations:
Import completes successfully without errors
Image is accessible in OMERO
However, OMERO.web / iviewer does not allow practical visualization of all channels
Channel rendering becomes unusable / incomplete in UI

3. Environment
   openmicroscopy/omero-server:5
   openmicroscopy/omero-web-standalone:5

[will-moore]

A few immediate points, but I'll ask others for more details since I'm not a sysadmin...

1. OMERO is used for https://idr.openmicroscopy.org/ which is run by the OME team. It has comparable numbers to your use-case. See https://idr.openmicroscopy.org/about/deployment.html for some details, but this is designed to handle public access (potentially high access loads).
   The most resource-intensive operation for most OMERO deployments is image import, since a lot of database updates are happening. We also found "search" type queries (using omero-mapr to query Key-Value pair annotations across all images in the DB) to be a limiting factor as the Database got larger. We have since moved to using an elasticsearch based solution.
   Other performance (web, api etc) doesn't seem to suffer as OMERO scales.

2. We currently limit omero-iviewer to viewing 10 channels at once (this is configurable). What does "practical visualization of all channels" mean? Is it really possible to view an image and distinguish more than a handful of channels at once? Or is it the ability to group channels into collections that you can turn on/off together at once?

[will-moore]

The image.sc forum is a good place to ask the community. E.g. see https://forum.image.sc/search?q=omero%20at%20scale
finds a bunch of relevant topics, including https://forum.image.sc/t/omero-production-server-current-best-practices/71074/6

[ZYsAccount]

Hi Will,

Thank you very much for the clarification.

I think I did not explain the channel issue clearly enough in my previous message.

Our problem is not that we want to visualize all 184 channels at the same time. We fully understand that displaying only a limited number of active channels at once, such as 10 channels, is reasonable.

The issue we are seeing is different:

We imported a pyramidal OME-TIFF with 184 channels
The import completed successfully
However, when opening the image in OMERO.iviewer / OMERO.web, the viewer fails to load the image
The error message is:
Failed to load tiles. Please try refreshing the page.

So the practical question is:
Can OMERO.iviewer open and browse an image that has 184 channels, even if only a few channels are enabled at a time?
In other words, we are not asking whether OMERO can render 184 channels simultaneously. We are asking whether OMERO has a limit on the total number of channels in an image that can be opened by the viewer at all.

Could you please clarify:

1、Is there a hard-coded or practical upper limit on the number of channels per image in OMERO.iviewer / OMERO.web?
2、If such a limit exists, is it configurable?
3、For images with 100–200 channels, is the recommended workflow to keep them as one multi-channel image, or to split them into smaller channel groups?

Our intended use case is to upload high-dimensional spatial proteomics images as a single pyramidal OME-TIFF, and then allow users to selectively turn on/off only a small number of channels at a time for visualization.

So ideally, even if the image has 184 total channels, we would like OMERO.iviewer to load the image and allow the user to select a subset of channels for viewing.

Please let us know whether this is expected to work, whether there is a configurable setting we should modify, or whether this currently exceeds the intended design of OMERO.iviewer.

Thank you again for your help.

[will-moore]

There is no limit on the number of channels that OMERO / iviewer can support.
E.g. here is iviewer showing an image with nearly 40 channels: https://idr.openmicroscopy.org/webclient/img_detail/15179838/
The viewer is configured to allow a max of 10 active channels at once, but that can be configured to a higher number if desired.

So, your image is expected to work. Did any tiles get loaded at-all? Did OMERO manage to generate a Thumbnail of the image when it was imported?
If you have an image you can share then we could try to reproduce the problem? The best way to share it is to upload to bio-formats community on zenodo: https://zenodo.org/communities/bio-formats/

[ZYsAccount]

Thank you for the clarification.

I have uploaded an example dataset to Zenodo for testing:

https://zenodo.org/records/20824472?token=eyJhbGciOiJIUzUxMiJ9.eyJpZCI6ImZhZTBkMWNkLWQxZWItNDUyOC1hM2FhLTc1NjQzMzNmMmQ2MiIsImRhdGEiOnt9LCJyYW5kb20iOiI5NGFhZTE3NTlkMWY2ZDY0MWJlNmQzYmQ4M2E5NWViZCJ9.ekmmLZ2Hi6PYVwBqRsw8r9_ZhIKRUf0qdQZDghcSWln1PmrXTR0xSFrPzM4zsbNHW0KiRGr77PB3Nj-PNJCAow

Thank you for your help.

[will-moore]

Hi - apologies for the delayed response.
I downloaded the linked file and imported it onto my local OMERO test server. It displayed in the iviewer with no problems:

I'm trying to think why you are having issues with viewing the image, but these are not reproduced on my system.
Can you check the OMERO.server Blitz.log log under $OMERODIR/var/log/.

[knabar]

I think this issue may just be that iviewer includes all channels and their settings (active and inactive) in the tile request URIs, which produces URIs that are too long. Since the maximum allowed length depends on the server configuration, the same image may work on one server, but not another:

As a workaround, increasing the maximum URI length in nginx may work, but this is probably an issue that needs addressing in iviewer.

[will-moore]

Thanks for that @knabar - I've opened a PR to fix that at #541