Open Microscopy Environment

Hi team,

For our slide scan images (from Zeiss Axioscan in CZI format) of tissue micro-arrays (TMAs), we tend to get many scenes (>100) which are currently numbered in such a way that they appear out of sequence in the viewers:


Could the scene numbering scheme be changed so they appear in correct sequence? That is useful/important for visual inspection and critical for automatic annotation routines such as populate_metadata.

Thanks,
- Damir

Dear Damir,

I think that a change such as this should rectify the ordering: https://github.com/rleigh-codelibre/bio ... 6d98789f14 (note: untested)

Do you have a sample image you could upload which has a large number of scenes, for testing the change? I'm searching through our collection but I haven't found a suitable image yet.

Thanks,
Roger

Dear Roger,

Thanks for proposing a fix so quickly. It looks like that should do the job. The image files I have with many scenes are all extremely large (80-90 GB) so difficult to get to you so I'll try to generate a smaller one when I have time on the instrument next week.

Cheers,
- Damir

Thank you. I'm still searching our existing collection; if I find a suitable image in the interim I'll let you know.

Hi Roger,

I collected a couple czi files that have 100+ scenes in them to illustrate the issue and test your fix. Unfortunately, they are still a bit large at 2.3GB and 3.2GB so too large for the QA upload site. Could you provide an alternative upload location?

Another reason to upload these is to illustrate a different issue I have with these CZI files. They import fine into OMERO 5.3.5 but then they have 2 failure modes when trying to display them.
1) image "2017_10_13__4052-1_online_jpegXR.czi" was acquired on a Zeiss Axioscan using online stitching. It shows what appears to be fine thumbnails but refuses to display the image per thumbnail for any of the scenes while the overview image and slide label image are fine.
2) image "2017_10_13__4052-1_offline_fuse_jpegXR.czi" was acquired using offline stitching and fusing. After import it needs to build pyramids for all the scenes which takes a bit. But then the thumbnails and images appear to have their pixel values strangely distorted as if they are all overflown.

The images are from a bead slide so nothing exciting to show, just some bright spots on black background.
This issue only appears to occur for images with many scenes but I'm not sure what the scene count cutoff is.

Thanks for any pointers.
Cheers,
- Damir

Quick follow-up:
I did generate jpeg-xr lossy compressed versions of the 2 image files which I have uploaded that to the QA system. They show the same issues as the larger files so no need for alternatives upload instructions.

Also forgot to mention that all of these images can be read fine into Fiji (BF 5.7.1) so this is not likely a proper BioFormats issue.

Thanks,
- Damir

Dear Damir,

Thank you for the files. I've opened a PR here: https://github.com/openmicroscopy/bioformats/pull/2979

However there is some question regarding the stability of the metadata. Do you have any thoughts regarding this?

Thanks,
Roger

Hi Roger,

Thanks for getting the numbering fix in. That will be very helpful for me.

I was trying to follow your discussion with Sebastien about "stability of the metadata" but am not sure I completely understand.

When you imported into OMERO the files I uploaded, did you see the 2 failure modes I mentioned in my message? As I mentioned, BioFormats (and all its tools) don't have any issue but importing these 2 files gives the 2 different unwanted outcomes on my installation.

Cheers,
- Damir

Dear Damir,

I have been able to reproduce the issue you mentioned with 5.4.0 and I've created this ticket: https://trello.com/c/ZMZP2rVv/91-render ... ne-bug-czi

Bio-Formats is reading the CZI file correctly, so I think it's not a problem with the pixel data. I suspect that the OMERO rendering engine is doing something odd with this file, but I'm not yet sure why it's misbehaving because the two files look very similar in terms of channel colours, bit depth etc.

Regards,
Roger

Hi Roger,

Happy New Year to you and the team.

On the issue in this thread where the pixel values are all messed up, I have another file of a different type and much simpler that exhibits the same behaviour. It's the tiff file I uploaded to the QA system under id: 18868.
Maybe that will help figure out what is happening. It appears to have some connection to the need to create a pyramid. The file itself is fine when I read it into Fiji.

Cheers,
- Damir