OMERO Bioformats support of Abberior MSR excl. channels

[Sethur]

Hi,

I wanted to put this into a separate thread since it might go unnoticed otherwise and definitely needs fixing. After trying out the included support for the new Abberior Imspector MSR format, I realized that channels are currently unsupported, i.e. channel images from the same measurement will not be grouped in OMERO as they get with the other formats. This makes it hard to identify images that belong to the same measurement. Is there a ticket for this, yet?

Cheers,

Tristan

[mlinkert]

Hi Tristan,

See reply to the previous thread: viewtopic.php?f=13&t=7698&start=10#p15628

We don't have a ticket for this yet, as we really do need files that exhibit the problem along with a description and/or screenshots of the expected behavior. As noted in the other thread, we don't have other software that can read .msr files, so it's very important to have a description what the correct acquisition metadata should be - otherwise we're forced to guess, which as you've seen can lead to problems.

We'll certainly open a ticket as soon as we have an example of this problem that includes the number of expected channels. If the files that you've uploaded already demonstrate this problem, then please just let us know what the correct channel count should be.

Regards,
-Melissa

[Sethur]

Hi Melissa,

sorry I didn't see your response in the other thread, forgot to turn the page. I uploaded another sample file "Abberior_Instruments_Imspector_STED_Example.msr" that illustrates both issues:

Opening it in ImageJ with Bioformats 5.1.0 lists 5 series, where there should have been exactly 2:

- Series 1 and Series 2 should be two channels in one image.
- Series 3 is a single channel overview image.
- Series 4 and 5 should not be there at all (not sure what they represent).

I have a suspicion regarding Series 4 and 5: In Impector, one can add line profile plots to a measurement (i.e. a series). They will appear as a graph window next to the respective channel window and they are definitely saved somewhere in the metadata. The file I uploaded does not contain any visible graph windows any more, but I cannot exclude that the user did this during her work and then closed those windows and saved the file.

The best way to tackle this would probably be to put you in contact with the lead developers of Abberior Instruments. Since they told me that they already gave out the relevant information of their new MSR format to the Bioformats group and are strongly in favor of a proper Bioformats MSR support, they will hopefully gladly share the necessary missing specs. I will write you an PM with their email addresses.

Cheers,

Tristan

[mlinkert]

Hi Tristan,

Thank you very much for uploading another file. There is now a ticket:

https://trac.openmicroscopy.org/ome/ticket/12841

and as usual, you have been CC'd.

Regards,
-Melissa

[Sethur]

Hi Melissa,

I had an interersting dicussion with the lead programmer from Abberior Instruments about the MSR-format and support for OMERO, particularly about the multiple-channel-issue. Apparently, due to historical reasons regarding the workflow with Imspector, including this is not as straightforward as I had thought. This is partly due to the powerful features that Imspector offers and partly because the labeling of the data is currently not particularly helpful for grouping data into measurements and channels (if I understood that correctly).

One issue is that users can currently create new data/images by combining arbitrary images from other measurements (in the same raw data file), i.e. they could add set 1/time t/depth Z/channel 2 to set 3/time t'/depth Z'/channel 4 and things like that. I'm not sure if Imspector even saves these linked images as raw numbers or if it just saves the relationship. To resolve this, I would currently suggest either ignore those linked images (in case it's just a relationship) or always put those them into a separate set (in case the raw data is saved).

Another thing that came up during the discussion was the fact that users are very dependent on having ROI metadata preserved when their images are imported into OMERO. I am not sure if you are currently planning any ROI import for any of the formats that Bioformats supports, but if you do, this would be a very important feature for STED users that work with AI (and possibly also Leica) instruments.

To elaborate on this: A STED workflow usually consists of:
1) Creating a confocal "overview" image to find an interesting part of your sample.
2) Identifying a mostly very small region of interest inside that initial overview image and re-scan the selected area with the STED laser enabled (which will usually lead to strong bleaching and only work once). Typically, this second measurement will also include (in a separate channel) a purely confocal "comparison" image to check whether the STED image is super-resolving. This confocal overview image is scanned in a separate channel (i.e. the detector is read out twice for every pixel), and should be treated as belonging to the STED image (which is currently not the case).
The problem is, that users currently have trouble finding out which ROIs (of the overview image) they actually scanned to create the STED image. This is currently not just a problem of importing the respective ROI metadata of the overview images into OMERO (although the metadata should be present if the user did not overwrite the ROI before saving the .msr-file), but also a problem of Imspector itself, since there is no ImageJ-like ROI-Manager and no way of displaying your last selected ROI once it disappeared.

I will discuss these issues with AI again, today, and if you are at the users' meeting in Paris next month we could have a chat about this.

Best,

Tristan

[mlinkert]

Hi Tristan,

OK, I think that makes sense. We don't currently have a way to model the STED/ROI workflow described, but if the file you've uploaded shows this workflow then we should be able to use it as a basis for updating the model.

I will be at the users' meeting in a couple of weeks, so we can certainly have a discussion about this then.

Regards,
-Melissa