Viewing slide scans from Operetta Perkin Elmer CLS as overview/montage images

Hi all,

we have an Operetta PerkinElmer CLS system, that we use for different plate types and also whole slide scans. The import of plates works perfectly in Omero, but we are troubling with the whole slide scans. Basically a plate is created and everything saved in the first well:

On the bottom left you can see, that the field positions are properly registered, but for some reason every field position shows the same image. So even if the field ID is changing by clicking on different images, the image looks always the same. I know that bio-formats doesn’t support everything around the Operetta, but does this work as intended? Should I avoid uploading those slide scans into Omero?

With Qupath and Fiji using bio-formats importer it looks a bit different. I can open the related xml-file which then offers all available single field positions as single images correctly, but I am not getting a montage or overview picture offered. I was actually hoping, this kind of data could be analyzed with Qupath, since Fiji will most likely trouble with the size of the data on local computers. Any idea if this is possible at all? Is there maybe some hack to get this work? Or did our users need to change the settings during the image acquisition in Harmony?

Sorry, for mixing the topics a bit, but this Operetta slide scans are a bit of a pain outside of the Harmony software, so I’m happy to get any hints to improve the situation for our users.


1 Like

Hi Anna,

Focusing on your first question about data access, my understanding is that the metadata and the pixel data for each field of view are read as expected if you open the data from Fiji, is that correct? If so, this would rule out an issue with the latest version of Bio-Formats at least.
On the OMERO side, the first question is what is the version of your OMERO.server? Also is there a representative sample of these datasets that you could share ideally publicly e.g. via Zenodo so that we could try and reproduce on our side?

For the second question in your post, a consideration is whether it makes sense to work against the primary data where each tile is stored as a field of view or whether the data should be transformed into a secondary representation where these tiles are stitched together into one (or multiple) whole slide image with pyramidal levels. I would expect this data structure to be much more amenable to the downstream analysis workflows e.g. in QuPath.

I have no knowledge of what Harmony offers in terms of settings or stitching solution. However, I expect several knowledgeable users and developers on this forum will be able to comment about their experience with similar workflows.

1 Like

Correct! And apologize for not noting the Omero version in my initial post:

OMERO Diagnostics (admin) 5.8.2

Commands:   java -version                  11.0.10   (/bin/java)
Commands:   python -V                      3.6.8     (/mnt/data/OMERO.venv/server_venv3/bin/python -- 2 others)
Commands:   icegridnode --version          3.6.5     (/bin/icegridnode)
Commands:   icegridadmin --version         3.6.5     (/bin/icegridadmin)
Commands:   psql --version                 11.11     (/bin/psql)
Commands:   openssl version                1.0.2     (/bin/openssl)

How can I actually see which bio-formats version my Omero installation is using? Only by reading the release notes or is there some system command available?

In addition I will create a representative dataset that I can share with you within the next week. The ones I have so far are way too big unfortunately. I’ll keep you updated!

Thanks for your effort!

1 Like

How can I actually see which bio-formats version my Omero installation is using? Only by reading the release notes or is there some system command available?

With omero-py >= 5.7.0 I would expect that OMERO diagnostics would display this information. Are there lines similar to

Jar:        lib/server/formats-api.jar     Bio-Formats API	

at the end of the output?

1 Like

Ah, haven’t noticed this additional output at the end yet! Here you go:

Jar:        lib/server/formats-api.jar     Bio-Formats API      6.5.1   7 July 2020     6f50e4d52c9d96112635fd8b2dde737f31041cf0
Jar:        lib/server/formats-bsd.jar     BSD Bio-Formats readers and writers  6.5.1   7 July 2020     6f50e4d52c9d96112635fd8b2dde737f31041cf0
Jar:        lib/server/formats-gpl.jar     Bio-Formats library  6.5.1   7 July 2020     6f50e4d52c9d96112635fd8b2dde737f31041cf0

As expected, it’s not the latest version. So maybe the issue within Omero showing one image for all fields might be solved with next omero release (incl. a newer bio-formats version). Nevertheless I will try to produce some example dataset for further tests and share it as soon as possible.

Thanks, Anna

1 Like

Thanks Anna,

the Bio-Formats version is as up-to-date as can be as there has been no OMERO.server release shipping a more recent Bio-Formats version. Briefly looking at the version history, I see no significant change to this reader that would explain the discrepancy.

We will wait for your representative dataset in order to conduct further tests on our systems.


Hi SĂ©bastien,

finally I produced a minimal dataset for testing and uploaded it to Zenodo. Unfortunately this minimal dataset works fine in Omero, at least in terms of showing every single image as distinct image in the bottom section. I’m really confused about this. Especially because I realized just this morning, that also for the latest plate imports Omero is actually showing the same image for all positions and fields:

So I feel a bit lost about this issue, since we have older plates in the system where the different positions and fields show the distinct images, as you would expect it.

I will delete one of those faulty plates from Omero and re-import it, to see if it was just some bad day of our Omero server, but if that doesn’t work, I don’t have any further ideas what to do in terms of debugging.

Any hints are much appreciated, since I would love to use omero.figure on those plate images :slight_smile:

Thanks, Anna

Hi Anna,

so trying to summarize the state of your system, the plates known to work are old plates imported into the system and the sample plate uploaded to Zenodo.

The plates failing to work (as in the pixel data is the same of all fields of view) are slide scans and recent HCS acquisitions.

Is that correct?

I tested the sample dataset you uploaded and I can confirm it reads without issue on our side as well. I would be very surprised if re-importing the incorrectly read plates fixed your issue. A few additional debugging thoughts:

  • is the bug showing up when accessing the images in the viewer i.e. the plane data is truly identical across fields of views or is the issue with the thumbnails only?
  • do you know whether the faulty plates were generated using a more recent version of the acquisition software/instrument that would explain the difference between old acquisitions and new ones?
  • have you tried re-importing one of the old plates working in your system to confirm the import behavior is deterministic and these plates are still working as expected?


Absolutely correct.

The bug appears everywhere. Also in Viewer, Omero.figure, etc.

That might be the case, but more apparent is the different Omero version, since the working imports are already 2 years old (we didn’t import many plates into Omero so far). Anyway, a different Harmony version or Omero version would not explain, why the yesterday created minimal dataset can be imported without any issues.

This is unfortunately not possible. I’m not the data owner and it’s not transparent where the original files are placed to re-upload them. It seems Omero is not supporting the download of a full plate, is it?

@petebankhead : I guess there is no possibility to use Qupath for the Operetta whole slide scans until the vendor software (Harmony) changes the export format or do you have any thoughts on this?

Thanks a lot,

Hi Anna, I’m afraid I’m not familiar with the format – have you tried it in QuPath, and if so what happened?

In the end, QuPath will need to use Bio-Formats to read any non-RGB whole slide images (a subset of RGB images can be read with OpenSlide).

So, Sébastien, this indeed worked. Same plate re-imported and all single images can be seen and loaded. So maybe just something with the post-processing did not work. I uploaded another whole slide scan and for this the post-processing haven’t finished after 3 days. Not sure if our omero server is just underscaled for such big datasets. I will keep on testing.

BR, Anna

1 Like

Thanks for the update, the fact a reimport was sufficient is a bit puzzling but at least for your users, this means the data should be usable.

For the plate hanging in the processing step, the usual candidates limiting import time are, min-max calculation and/or thumbnail generation (dependent of the number of images), pyramid generation (for large images) but 3 days feels wrong.

If you know the ID of the fileset, does omero fs importtime report anything useful ? Otherwise, I assume the server logs might indicate what is hanging/being stuck.