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

[Josh Moore]

On Mon, Jul 10, 2017 at 12:17 PM, Martin Wlotzka
<martin.wlotzka at uni-heidelberg.de> wrote:
> Dear All,

Hi Martin,


> 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

I don't know of a case where it should be possible to view a file
without a memo file being created. Do the "Memoizer" lines in your
Blitz-0.log show anything relevant while looking at either of the
images?

Are these files in some way special, or do all files of this type in
these size ranges produce the same behavior?


> 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?

(b); For any file larger than the (configurable) 3000x3000 whose
format cannot store its own pyramid will have a pyramid generated for
it. And until that pyramid is generated, the image should not be
viewable (as for memo 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)?

It always should be triggered by double-clicking on the image, unless
something is going wrong. That should be minimally visible in the
logs.


> 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?

Correct. For "big" images, yours are rather small.


> However, why is the default max_plane_height/width set to a small size
> of 3192 pixels?

This was of course a compromise as big image support was being added.
Do you have any data to suggest a better setting?


> 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.

I don't off-hand.
~Josh.


> Thank you,
> Martin