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

[Martin Wlotzka]

Dear Josh,

thank you for the comments! I learned one thing which changed the
picture for me and raised a new issue.

First of all, I misunderstood the meaning of the configuration
omero.pixeldata.max_plane_height/width. I thought it sets the absolute
maximum possible image size which is importable, therefore I used a
value of 20K. But now I realize that it is just the size above which
pyramids are used. Maybe one could include a short hint on that in the
configuration glossary :-)

So the pyramids generally work as expected after I set a lower
max_plane_height/width. But at the same time, I encountered a new issue:

I use a lot the Leica .lif format. It works well with 8 bit color depth
both for pyramid-less rendering of small images, as well as with
pyramids for larger images. However, with 16 bit color depth only the
pyramid-less small images work, but the larger images with pyramids look
completely weird. .tif images work well in any size and color depth. So
I think it's really an issue with the .lif format.

Just to share some performance experience (keen to hear experience from
the community): I checked different tile sizes and measured roughly the
time [sec] from click-to-complete when zooming and adjusting channels in
the web image viewer.

                           tile_height/width = 128 | 256 | 512
----------------------------------------------------------------------
[ 5899 x 9898 x 1 x 1 x 3 x tif uint8 ]    5     3     2.5
[ 5892 x 6966 x 1 x 1 x 3 x tif uint8 ]    4.5  3     2.5
[ 3554 x 3002 x 1 x 1 x 3 x tif uint8 ]    6     3.5   2
[ 3554 x 3002 x 1 x 1 x 3 x tif uint16]   6     3.5   2.5
[ 3554 x 3002 x 1 x 1 x 3 x lif uint8 ]    5     3      2
[ 5883 x 4997 x 1 x 1 x 3 x lif uint8 ]    5     3      2.5

System: Ubuntu 16.04, 8 x 2.6 GHz, OMERO 5.3.3-ice36-b63, blitz &
pixeldata 5GB, indexer & repo 2.5 GB

Cheers,

Martin


On 11.07.2017 16:26, Josh Moore wrote:
> 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
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users