confine projection #305

will-moore · 2020-02-17T12:58:28Z

This ports the same logic to the iviewer to restrict the size of projections.

To test:

import an image where Z * X * Y * C * bits-per-pixel is > 1024 * 1024 * 256.
Z projection should be disabled.

will-moore · 2020-02-17T15:19:45Z

That second commit handles the scenario at ome/omero-web#115 (comment) where we enable/disable projection when user turns channels on/off.
The decision for old viewer was to simply use the total number of channels when deciding whether to disable projection (see discussion at that link). The above commit adds quite a lot of code to maintain and test, to handle the case of "image with a large number of channels is above the projection limit but we want to allow projection when a small number of channels are enabled". So we should probably keep things simple and revert that to same behaviour as old viewer)?

pwalczysko · 2020-02-18T15:57:58Z

The above commit adds quite a lot of code to maintain and test, to handle the case of "image with a large number of channels is above the projection limit but we want to allow projection when a small number of channels are enabled". So we should probably keep things simple and revert that to same behaviour as old viewer)?

Yes, I think so. Keep simple

pwalczysko · 2020-02-18T16:04:43Z

Interesting side-question: Multi-t and multi-z images. Atm, I am gettting a multi-t projections when I have multi-t images with (orginally) multi-z. See for example user-3 https://merge-ci.openmicroscopy.org/web/webclient/?show=image-100718

pwalczysko · 2020-02-18T17:15:08Z

Yes, the behaviour here is as expected. See the under-size-limit images from previous comment and a over-limit-image-when-all-channels-on in https://merge-ci.openmicroscopy.org/web/webclient/?show=image-100727

But I guess it would be better to not to introduce complex logic with "when channels on..." etc.

jburel · 2020-02-18T17:17:39Z

I think it is better to stick to sizeC instead of active channels.
This could potentially annoy user but it is easier to understand when the functionality is on/off

This reverts commit 5abeecd. As discussed in ome#305 don't try to dynamically disable projection on channel toggle

pwalczysko · 2020-02-20T10:00:51Z

All looks good. Checked iviewer, and also "old" viewer with images from https://merge-ci.openmicroscopy.org/web/webclient/?show=project-15107

Ready to merge fmpov

jburel · 2020-02-20T10:12:47Z

src/controls/dimension-slider.js

@@ -517,7 +517,13 @@ export default class DimensionSlider {
     */
    getZProjectionDisabled(handle, forwards) {
        let dims = this.image_config.image_info.dimensions;
-        return (handle !== null && forwards || (dims.max_x * dims.max_y) > UNTILED_RETRIEVAL_LIMIT);
+        let tiled = (dims.max_x * dims.max_y) > UNTILED_RETRIEVAL_LIMIT;
+        let bytes_per_pixel = Math.ceil(Math.log2(this.image_config.image_info.range[1]) / 8.0);


you may want to add a TODO and create an issue so we can use the omero-model property when available ome/omero-model#47

Ah interesting, so: see if someone set a value explicitly for iviewer, then check the server default, then use a client fallback?

Currently we don't have the config available from the server.
When that is available, we could teach iviewer to use that as a default value, but if it is set in iviewer itself then use that. That could allow iviewer to be more restrictive than the server (but not less restrictive since the server would enforce it's own limit).

will-moore · 2020-02-20T10:13:41Z

Maybe we should make this configurable within iviewer itself while we wait for configuration to be available on the server. I'd hate for someone to upgrade and then be blocked from viewing images that they have previously viewed OK.

jburel · 2020-02-20T10:15:28Z

That will be certainly a good option

jburel · 2020-02-24T10:27:52Z

plugin/omero_iviewer/iviewer_settings.py

+         1024 * 1024 * 256,
+         int,
+         ("Maximum bytes of raw pixel data allowed for Z-projection. "
+          "Above this threshold, Z-projection is disabled")],


Maybe indicate that this value will be ignored if the limit is greater that the one set server-side.
Server side is work-in-progress but when it is in-place that will be the rule.

Seems wrong for the documentation to describe future functionality.
Since I'll need to open a PR to update the functionality, I can change the description at the time to match (depending on what we end up with).

we can review the wording later on when we implement the size limit from server
My point is that if people start setting a high limit, this will be ignored later on and will default to the server one. This might come at a surprise for that.

will-moore added 2 commits February 17, 2020 12:55

Limit projection to stack size of 256 * 1024 * 1024

0db7e5e

Update projection-enabled when channels turn on/off

5abeecd

will-moore changed the title ~~Limit projection to stack size of 256 * 1024 * 1024~~ confine projection Feb 17, 2020

will-moore added 2 commits February 19, 2020 23:11

Revert "Update projection-enabled when channels turn on/off"

105a242

This reverts commit 5abeecd. As discussed in ome#305 don't try to dynamically disable projection on channel toggle

Use sizeC instead of active channels for proj disable

2c3e68b

jburel reviewed Feb 20, 2020

View reviewed changes

will-moore added 2 commits February 20, 2020 11:02

Add MAX_PROJECTION_BYTES config to iviewer

205c3ea

Add settings info to README

0322a13

jburel reviewed Feb 24, 2020

View reviewed changes

jburel merged commit 70dbfc9 into ome:master Feb 27, 2020

will-moore mentioned this pull request Aug 19, 2020

Projections and tiled images threshold #341

Closed

This was referenced Mar 6, 2024

confine Z-projections ome/omero-figure#546

Closed

Max projection limits ome/omero-figure#440

Closed

sbesson mentioned this pull request Jul 15, 2024

Max projection bytes ome/omero-figure#560

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

confine projection #305

confine projection #305

will-moore commented Feb 17, 2020

will-moore commented Feb 17, 2020

pwalczysko commented Feb 18, 2020

pwalczysko commented Feb 18, 2020

pwalczysko commented Feb 18, 2020

jburel commented Feb 18, 2020

pwalczysko commented Feb 20, 2020

jburel Feb 20, 2020

joshmoore Feb 21, 2020 •

edited

Loading

will-moore Feb 21, 2020

will-moore commented Feb 20, 2020

jburel commented Feb 20, 2020

jburel Feb 24, 2020

will-moore Feb 24, 2020

jburel Feb 27, 2020

confine projection #305

confine projection #305

Conversation

will-moore commented Feb 17, 2020

will-moore commented Feb 17, 2020

pwalczysko commented Feb 18, 2020

pwalczysko commented Feb 18, 2020

pwalczysko commented Feb 18, 2020

jburel commented Feb 18, 2020

pwalczysko commented Feb 20, 2020

jburel Feb 20, 2020

Choose a reason for hiding this comment

joshmoore Feb 21, 2020 • edited Loading

Choose a reason for hiding this comment

will-moore Feb 21, 2020

Choose a reason for hiding this comment

will-moore commented Feb 20, 2020

jburel commented Feb 20, 2020

jburel Feb 24, 2020

Choose a reason for hiding this comment

will-moore Feb 24, 2020

Choose a reason for hiding this comment

jburel Feb 27, 2020

Choose a reason for hiding this comment

joshmoore Feb 21, 2020 •

edited

Loading