Optimizing efficiency of an OMERO Server

We have set up an OMERO Server to host images to be accessed via Qupath and use OMERO.insight to upload large (about 50 MPixel) that are natively in TIF. When we access the images later via QuPath, we have seen that the refresh rate is largely limited by the CPU performance of the server (i.e. not the internet speed or RAM) and adding cores seems to increase performance. This suggests that pyramidal images are generated on the fly by the server. Is there a way to pre-process the images either prior to upload or on the servers itself to optimize efficiency and increase the refresh rate?
Thanks for your help!
Chris

Hi @ChristianFreudiger , you may want to have a look at the Glencoe tools for creating properly tiled/pyramided OME-TIFF images. They work well for me: Converting Whole Slide Images to OME-TIFF: A New Workflow

3 Likes

Hi @ChristianFreudiger and welcome to the forum. Adding one clarification: pyramidal levels are never generated on-the-fly in OMERO. Either the original data contain pyramidal levels in a supported multi-resolution file format in which case the native sub-resolutions will be used when accessing the data, or the data import will trigger the generation of a pyramid using the internal legacy OMERO format above a plane size threshold.

If your data belongs to the second case, we strongly recommend to generate the resolution levels and store the data into an open multi-resolution pyramidal format prior to import. There are several tools allowing to perform efficiently this conversion, notably the pipeline suggested by Damir in Optimizing efficiency of an OMERO Server.

Update: also added #qupath to the tag list so that the QuPath developers can chime in with their knowledge.

2 Likes

Hi @ChristianFreudiger if you open the image in QuPath (either directly or via OMERO), you can check under the ‘Image’ tab what the ‘Server type’ is. This should indicate if QuPath is generating a pyramid dynamically itself.

If it is, then that suggests QuPath would need to request the whole image from OMERO before it can display it properly. As described above, making sure the image is pyramidal before importing it to OMERO should help.

3 Likes

Thanks for all your answers. We have tried creating various types of pyramidal images but cannot seem to be able to avoid the ~15s overhead of going to the next image in a QuPath project. This may be a silly question but are we supposed to select “Auto-generate pyramids” when creating a new project if the files on Omero are already pyramid?

Also, is there an open OMERO server with sample images that are “ideally formatted” so we can test the base-line performance to expect? We are hoping to build an annotation project with 200 images that are about 100MB each and want to be able to jump between images quickly. Thanks again and have a great weekend!

If the image is already pyramidal, it shouldn’t make any difference. What is the ‘Server type’ you see when you open the image in QuPath?

Sorry I didn’t respond to this earlier. It is “OMERO web server”.

1 Like

Thanks, it looks like it is indeed being recognised as pyramidal on the OMERO side then.

It is a bit odd though, since the image is actually quite small by pyramidal standards (they are often >100,000 pixels in width and height), and the pixel width/height of 100µm is surprising. I’m not sure so many pyramid levels are helping; if it is pyramidal at all, I think levels 1 & 4 would be sufficient – rather than 1, 2, 4, 8, 16, 32.

Does the image open quickly in OMERO when viewed through a web browser? It might be that QuPath’s doing something particularly unoptimized for this kind of moderately-sized image with lots of pyramid levels. Lots of levels suggests QuPath will be needing to request more image tiles that it would perhaps otherwise need to.