Open Microscopy Environment

I am new to omero, and currently testing import scenarios from various imaging systems.
I encountered several problems while importing files from Olympus CellR
(I am not sure whether this fits more Omero forum or this one...).
We are using Omero 5.2.7 and CellR version 3.2 Build 1700.

1. The first problem deals with the awkward tree structure after import from apl files.
Apparently, entries from the created fileset are named according to the following pattern:
database.apl [imageName]
The problem is that with this pattern it is very likely to get the whole list
of identical entries, because database.apl is constant for each import, and imageNames are by default just channel names (at least on our system), so they will be repeated many times. IMHO, it would be very helpful to have the "Experiment Name" included in the entry name, e.g. instead of the database name. Each acquisition in CellR results in a new experiment placed in the database, and this is the "Experiment Name" field that distinguishes each experiment/run. Currently, to avoid identical entries in Omero, an user would have to specifically name each image/image sequence in CellR, which would be a nightmare,
considering that each experiment might have many image sequences, and each database contains many experiments. Renaming "Experiment Name" to something meaningful is much simpler.
My current workaround is to import images after prior export to tiff files (the CellR database tree structure is preserved in windows explorer after export, and then it can be reconstructed during import to Omero by setting "1 Directories before File" in import options). But this approach does not preserve hyperstacks; all images in an image sequence become time points (I could not find a way in omero to (batch) re-set Z and T dimensions from a T sequence).

2. Second problem is related to [imageName],
which usually reflects "Channel name", as it is visible in CellR, but sometimes, for no apparent reason, becomes full windows path to tiff file.

3. Third problem is the lack of proper recognition of dimensions when importing from apl file.
When image sequences of Z-stack type are imported into Omero, they may be falsely recognized as time series, although original metadata clearly shows it was a Z-Stack.
Could not find a way in Omero to correct this kind of problem (swapping Z and T). Surprisingly, more complex data, containing both T and Z dimensions, or even T, Z and P (positions) dimensions are correctly recognized (positions are always split).

I would be very grateful for any help how to solve these issues. If the reported issues are indeed bugs, maybe it would be possible to correct them in future Bio-formats and Omero releases. I know that CellR is not developed anymore, but I guess it is still used by many labs.

Best,
Tomasz

Hi Tomasz,

Welcome to the OME community!

Someone with Bio-Formats expertise will likely respond at some point, but in the meantime it might be worth supplying them with a sample of an image you're having problems with, if that's possible, allowing them to attempt to reproduce the issue?

If the file is smaller than 2GB, you should be able to upload it directly to http://qa.openmicroscopy.org.uk/qa/upload/.

Best,

Kenny

Dear Kenny,
many thanks for your reply!
I've just uploaded two CellR databases to demonstrate the described problems
Best,
Tomasz

Hi Tomasz,

Thank you for uploading the fileset. I was able to do some initial testing and reproduce the various issues that you were reporting here.

1. I can see that the naming here might not be ideal, I will log a feature request to investigate the use of 'Experiment Name' as a potential alternative.

2. It appears that the metadata records for a few of those files are in a different layout than the parser is expecting and it is unable to locate the metadata correctly as such it is defaulting to using the file path instead. Do you know if the column layouts in the database are expected to differ for any of the files which are labelled with the full file path?

3. This also appears as though it is an issue with parsing the metadata incorrectly. I will have to spend some further time debugging to find out exactly. The reader should be fetching the Z dimensions from the column 'Z-Layers'. I will log a bug to further investigate this issue.

David Gault

Dear David,
Regarding #2: Yes, there may be something that appears to influence the parsing behaviour. In CellR, channels can be acquired either combined inside a so-called multi-color frame or without the multi-color frame. In the first case, single multi-channel image sequences are created, which facilitates image analysis in CellR (e.g. ratioing), but may create problems after export to tiff files and trying to open them in another software (w/o using Bio-Formats). In the second case, separate image sequences are created for each channel and saved under the same experiment. While I was testing import to omero, I created databases containing sequences both with and without multi-color frame. They were imported to omero as expected, i.e. multi-channel sequences were recognized as multi-channel (although channel names were not recognized properly, and just named 0, 1 etc.; but this is not a problem as it can be easily corrected in omero), and single channel sequences stayed as such. At first I noticed that multi-channel entries were named according to the pattern "database.apl [imageName]", and single channel entries were named after Windows path. But at another import, it was the opposite. Now it appears to me that parsing works fine for the first images of the same type to be imported, but if subsequent images have different "multi-color frame status" (or just different number of channels) they will be named after Windows path. I have to admit, users usually either use multi-color frame or not at all, so to have both types in one database will be rare, although still possible.
Best,
Tomasz

Hi Tomasz,

Thank you for the extra investigation, that sounds like it could be what is happening all right. Having that extra information will be a great help when it comes to improving the reader. Please do let us know if you find any other issues or inaccuracies so we can track any required bug fixes or improvements.

David