Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new property descr., improve formulations #2256

Merged
merged 16 commits into from
Jun 30, 2022
Merged
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions omero/sysadmins/limitations.rst
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,7 @@ images if it doesn't already exist in the file. The threshold size is configurab
default. However, this process can be very resource-intensive, depending on the size of the
image as well as the image format and any data compression used, for example see
`PixelData threads and pyramid generation issues <https://forum.image.sc/t/pixeldata-threads-and-pyramid-generation-issues/49794>`_.
Further, OMERO never generates pyramids for floating-point or double pixel data types. Working with large floating-point pixel data type images without pre-generated pyramids in OMERO can cause problems (see below).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "Working with large floating-point images..." is an acceptable abbreviation? Or even "large floating-point pixel type images" is slightly less verbose


The OMERO pyramid generation process should be considered as deprecated and instead it is recommended
that users avoid these issues by converting
Expand All @@ -64,12 +65,12 @@ files before importing into OMERO. A number of suitable tools are available such
`aicsimageio <https://github.com/AllenCellModeling/aicsimageio>`_,
`libvips <https://github.com/libvips/libvips>`_ and `QuPath <https://qupath.github.io/>`_.

Large images with floating-point pixel data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Large images with floating-point or double pixel data types
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

:model_doc:`Pyramids <omero-pyramid/>` of image tiles are currently not
generated for images with floating-point pixel data, meaning the imported
image will be scrambled if it is over the size threshold mentioned above.
generated for images with floating-point or double pixel data types, meaning the viewing of the imported
images will be compromised if it is over the size threshold mentioned above.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main caveat with the usage of compromised is that it might be understood with other implications esp. in terms of security.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pyramids of sub-resolution image tiles are not generated for images with floating point pixels. However, in some cases, these images can be viewed in OMERO clients at full resolution (if the images are not too large).

This behaviour is configured by omero.pixeldata.max_plane_float_override. By default this is True; OMERO overrides the requirement for floating-point images above the max_plane size to have pyramids, which allows them to be treated as regular images and possibly viewed in the clients.

However, this also allows OMERO to attempt the calculation of min/max pixel intensity for these images (normally disabled for large images because it is resource intensive to read every pixel value).

When the property omero.pixeldata.max_plane_float_override is set to False on your server, OMERO will not attempt to treat large floating-point images as if they are smaller images, so any large images without pre-generated pyramids will not be viewable. However, this will protect the server from expensive attempts to calculate min/max pixel values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can replace the last paragraph below

This primarily affects the following file formats:

* :bf_v_doc:`Gatan DM3 <formats/gatan-digital-micrograph.html>`
Expand All @@ -79,6 +80,14 @@ This primarily affects the following file formats:
This issue can be avoided by pre-generating pyramidal OME-TIFF images as
sbesson marked this conversation as resolved.
Show resolved Hide resolved
described above.

Requests sent from the clients to the OMERO.server when displaying large images
with floating-point pixel data type which have no pre-generated pyramids
can cause limitation or even a complete loss of service, necessitating a server restart.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where limitations == performance issues?

These requests are generated any time when for example a user in OMERO.web
changes rendering settings on such image. Set the property
:property:`omero.pixeldata.max_plane_float_override` to ``false`` on your server to prevent these problems.


.. _ngff_limitations:

Import of OME-NGFF
Expand Down