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

[Sebastien Besson (Staff)]

Hi Martin
> On 19 Jul 2017, at 09:37, Martin Wlotzka <martin.wlotzka at uni-heidelberg.de> wrote:
>
> 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 :-)

We can definitely see where the historical name of these properties can
lead to confusion. We will look into adding some documentation for
OMERO 5.4.0 clarifying their intent. Thanks for raising the issue.

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

If pyramid generation problems only happen for large 16-bit Leica LIF images,
this might suggest a format-specific issue. Would it be possible to upload
a sample file at http://qa.openmicroscopy.org.uk/qa/upload/?

> 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

Best,
Sebastien
>
> 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
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users


The University of Dundee is a registered Scottish Charity, No: SC015096