[ome-users] Pyramids, fast/slow rendering and image size

Martin Wlotzka martin.wlotzka at uni-heidelberg.de
Mon Jul 10 11:17:11 BST 2017


Dear All,

I'd like to post an observation I made with my OMERO installation
(config below) and I'd be happy to have your opinion/explanation:

"fast" case: .lif file, 6000 x 10000 x 1 x 1 x 3 uint16, has no pyramid
file, memo file exists
=> rendering/viewing < 6 sec, pyramid still not created

"slow" case: .lif file, 3600 x 4000 x 1 x 1 x 5 uint16, pyramid file
exists, has no memo file
=> rendering/viewing > 23 sec, pyramid not used (no reload/network
activity when zooming), memo file still not created

After deleting the pyramid file, also the "slow" case became "fast", and
the missing memo file was created, but no pyramid recreation happened.
This observation makes me wonder about pyramids and "big" images.

>From the supported formats list I read that the Leica .lif can't store
pyramids. However, the fact that pyramid files for .lif images exist on
my server confuses me. So, should I understand that
(a) OMERO cannot use pyramids at all for this format, or
(b) that only the format cannot store pyramids but OMERO can compute
them in accompanying files?

-> If (a), is the existence of pyramid files just a bug/relict from
previous OMERO/BioFormats versions (came from 5.2.8 through 5.3.1, 5.3.2
to 5.3.3)?
-> If (b), how could I trigger the pyramid computation (doesn't happen
when viewing the images, as described above)?

Up to what size are images in the scope of OMERO? From some email/forum
posts I thought that my two cases should not be a problem, right?
However, why is the default max_plane_height/width set to a small size
of 3192 pixels? Any idea what rendering time I can expect for the two
cases above?

Config: 5.3.3-ice36-b63 on Ubuntu 16.04, 8 x 2.6 GHz CPU, blitz &
pixeldata 10 GB, indexer & repo 5 GB, no memory issues.

Thank you,
Martin



More information about the ome-users mailing list