render_image_region renders cropped image

[Rylern]

Bug report

Describe the bug

When the Mimosa_TB_ferme_9_40x.JPG image is uploaded to an OMERO server, the request http://<omero-address>/webgateway/render_image_region/<image-id>/0/0/?tile=0,0,0,1600,1200 returns a cropped view of the original image (the image has a size of 1600 x 1200 pixels).

However, the request http://<omero-address>/webgateway/render_image/<image-id>/0/0/ returns a correct view of the image.

Original image:

Result of http://<omero-address>/webgateway/render_image_region/<image-id>/0/0/?tile=0,0,0,1600,1200:

To Reproduce

Steps to reproduce the behavior:

1. Upload the Mimosa_TB_ferme_9_40x.JPG image to an OMERO server.
2. Go to http://<omero-address>/webgateway/render_image_region/<image-id>/0/0/?tile=0,0,0,1600,1200
3. Compare with http://<omero-address>/webgateway/render_image/<image-id>/0/0/

Expected behavior

http://<omero-address>/webgateway/render_image_region/<image-id>/0/0/?tile=0,0,0,1600,1200 and http://<omero-address>/webgateway/render_image/<image-id>/0/0/ should give the same result.

Version:

• OMERO version: OMERO.web 5.27.2

[sbesson]

@Rylern thanks for opening this issue. At Glencoe Software, we independently came across this issue quite recently so this is a timely opportunity to provide a summary our findings and possible next steps.

The short version is that this is the expected behavior i.e. the webgateway rendering endpoint truncates tile requests exceeding a maximum length.

For the longer version, this feature originated in ome/openmicroscopy#5542 and released in OMERO 5.4.4. Similarly to the maximum plane width/height, this change introduced a property specifying a maximum tile length. The OMERO.web gateway was updated to read the value of this property, defaulting to 1024, and truncate the response for tile requests which dimensions exceed this cutoff. From an API perspective, the expectation is that the caller must be aware of the maximum tile length using IConfig.getConfigValue and make tile requests with appropriate widths/heights.

To help clients and reduce confusion, there are a few possible immediate todos to reduce the confusion:

• Add default value and documentation for omero.pixeldata.max_tile_length omero-model#110 properly declares the property with its default value server-side allowing clients other than the OMERO.web gateway to read the default value
• the maximum tile length property should be added to https://omero.readthedocs.io/en/stable/sysadmins/config.html
• the WebGateway documentation could be updated to document this tile length limitation and maybe more generally the signature of the render_image_region endpoint

/cc @will-moore @jburel

[Rylern]

Thanks @sbesson, knowing this maximum tile length of 1024 helped me find a quick fix for that in the OMERO QuPath extension.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/ndpis-dont-load-fully-in-omero-viewer-after-update-to-omero-server-5-6-14/109361/3

[sbesson]

See also https://forum.image.sc/t/ndpis-dont-load-fully-in-omero-viewer-after-update-to-omero-server-5-6-14/109361 for a separate report of this issue following the OMERO.server 5.6.14 upgrade and the change in the NDPI tile size which affects the legacy image viewer. I suspect the issue comes from https://github.com/ome/omero-web/blob/96d113830f31142cb272c5a486b048cd185c51bd/omeroweb/webgateway/static/webgateway/js/ome.viewport.js#L319C11-L320 and the fact the Bio-Formats tile width/height are used without boundary checks for the image region requests.