Max projection bytes

[will-moore]

Fixes #440.

This protects users from requesting Z-projections exceeding the MAX_PROJECTION_BYTES limit of 1024 * 1024 * 256 bytes or a value configured on the server omero.pixeldata.max_projection_bytes. We always take into account the number of active channels rather than total channel count.

When a user enables Z-projection on an image, we test whether the full Z-range projection (with current channels enabled) exceeds the MAX_PROJECTION_BYTES. If so, the maximum number of Z-planes that can be projected is shown in red (tooltip includes the MAX_PROJECTION_BYTES limit). This limit will change when channels are turned on/off.

If a user exceeds the Z-projection limit using the Z-range sliders, we show a warning message instead of the Z-projected image.

To test: (I have already created https://merge-ci.openmicroscopy.org/web/figure/file/3901 as follows):

• BEFORE this PR is merged, find/create one or more images that are bigger than 1024 * 1024 * 256 bytes. Might be easiest to create fake images. E.g. I tested with testProjection&sizeX=1952&sizeY=1952&sizeZ=73&sizeC=4&pixelType=int16.fake based on https://forum.image.sc/t/z-projections-disabled/95042 and testProjection&sizeX=1024&sizeY=1024&sizeZ=50&sizeC=4&pixelType=int8.fake which falls under the limit when a single channel is enabled.

• Save a Figure that includes these images with Z-projection exceeding the limit.

  • WITH this PR: Open your existing OMERO.figure and check in the Info panel that correct pixelsType is shown (this data isn't included in existing figures but is loaded on the fly when you open an older figure).
  • Add these to a figure - they should also show the correct pixelsType in Info panel.
  • Enable Z-projection for large and small images. Only those that can exceed the max projected bytes (with the current channels enabled) will show the red Max N with a tooltip to show the meaning.
  • Drag the Z-range sliders - when you choose a range that exceeds the limit in red, you should see the placeholder warning shown instead of requesting the server to project the image:

[sbesson]

From a preliminary round of testing, this functionality seems to work as intended and prevents projections in the app when the selected Z-range exceeds the threshold configured server-side. One thing I noticed though is that the projection still happens when running the figure export script. I assume the script must also be updated accordingly but this raises the question of what the behavior should be when a figure has been saved with a Z-range exceeding the max projection limit threshold.

[will-moore]

@sbesson in 447144c I've updated the figure export script to respect the MAX_PROJECTION_BYTES limit. If that limit is exceeded then we render a black image (similar to screenshots above but without the warnings).

I think this is reasonable behaviour both for pre-existing figures saved with the Z-projection that exceeds the limit, as well as for newly created figures. In both cases the user will see that the limit has been exceeded in the browser as above before trying to run the export script.

[will-moore]

@sbesson Why should the sizeZ influence the ability to perform small Z-range projections? For example, if I can do Z-projection with a Z-range of 5 on an image of sizeZ: 10, why wouldn't I be allowed to do the same Z-range projection (same number of bytes) on an image with sizeZ: 100?

As I understood, the unconditional disabling of Z-projection in iviewer and webgateway viewer was due to this being simpler to implement (e.g. we don't base this on active channels but on sizeC since it's easier). I'm not sure if this is what you mean by "the current semantics of the server projection service"?

The default behaviour in OMERO.figure when you turn on Z-projection is to start with a small Z-range since this is often what users want and it is less work for the server. It would be nice to preserve this functionality when it is operating below the MAX_PROJECTED_BYTES.

[will-moore]

When combined with #563 this PR causes an error because re_path is no-longer imported.

09:32:53   File "/home/omero/workspace/OMERO-web/.venv3/lib64/python3.9/site-packages/omero_figure/urls.py", line 36, in <module>
09:32:53     re_path(r'^max_projection_range_exceeded/'
09:32:53 NameError: name 're_path' is not defined

We will try to get that PR merged first - excluding this one for now... (editing description)

[sbesson]

@will-moore what's the status of this PR? Is it ready for another round of testing?

[sbesson]

With the last commits, using the example figure linked from the description

For images whose Z-stack exceeds the projection limit, the tooltip of the projection icon correctly indicates Z-projection exceeds MAX_PROJECTION_BYTES: <value> but cliking on it gives the broken image icon. In addition, reloading figures displays the spinning icon for images meeting this condition. I assume this is not the expected behavior and these should be replaced by the placeholder black plane ?

[will-moore]

@sbesson Thanks, yes I realised that I used urls.path for a url that contained regex. Fixed now.

[will-moore]

Testing the upgrade by temp excluding this from merge-ci...

Created pre-update figure. Removed exclude flag...

[will-moore]

Using the same images as @sbesson above, I created a figure on merge-ci without this PR and turned-ON Z-projection for all images, then saved the figure. After updating the build to include this PR, I opened the saved figure. Initially 4 of them were "projection disabled" since we assume dtype is float while the dtype was loaded. Once dtypes are loaded (couple of seconds), only 2 of the images were "projection disabled":

Once this figure was saved and re-loaded, the 2 images were immediately "projection disabled".

LGTM 👍

[will-moore]

This is now released in OMERO.figure 7.1.0