Bug: Save settings on Image with 60 channels

[will-moore]

The issue of long query strings in the rendering URL was fixed in https://github.com/ome/omero-iviewer/pull/201 but the same changes were not applied to the Saving URL where rendering settings are also passed in JSON encoded in the URL.

This means that saving of rendering settings fails on images with large numbers of channels as reported at https://forum.image.sc/t/omero-iviewer-doesnt-save-rendering-settings-in-image-w-many-channels/37484

[imagesc-bot]

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

https://forum.image.sc/t/omero-iviewer-doesnt-save-rendering-settings-in-image-w-many-channels/37484/2

[will-moore]

This is getting kinda messy. I'm wondering if @chris-allan has any thoughts on this?

The problem is that rendering settings encoded as JSON can get very long for images with many channels. e.g. for a single-channel:

maps=[{"inverted":{"enabled":true},"quantization":{"family":"exponential","coefficient":0.2}}]

so with 60 channels we exceed the query length limit in nginx. This was addressed in #201 for render_image query strings by only including rendering settings that were different from the saved settings in iviewer. However, if the state of 'saved settings' in iviewer is different from the actual saved settings on the server (e.g. saved by iviewer in another tab) then we can get the unexpected rendering of image. If you don't specify ALL the settings in the query string, you can get various different renderings of the image for the same URL, depending on the currently saved settings. This also makes any nginx caching of the image invalid for a given URL.

The previous issue #201 was fixed in the OpenLayers part of the iviewer, that kept track of the last saved settings and uses the difference between current and saved settings to generate the rendering query string.

To fix this same bug for saving, I need to duplicate that logic in the model/aurelia part of the app. However, before doing that I wondered if we might consider a more concise way of encoding the rendering settings in the query string, which would also fix the other issues above.

Any thoughts on this? cc @jburel

[atarkowska]

Hello, I think I faced the same problem with image with 35 channels. THat feature works in old viewer and preview but not in iviewer. Any chance that is a temporary issues?

[will-moore]

Hi Ola, can you check the dev-tools to see what response you're getting when you try to save the settings? I wouldn't have thought that 35 channels is too many. If the error response suggests that the query string is too long (414 response), can you check how long it is and whether it exceeds the nginx config http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers (I think the default is 4096 characters). Thanks, Will.

[atarkowska]

Hi @will-moore, appology for a slow followup. adjusting nginx config doesn't change anything, I am getting Status 400 Bad Request

Request Line is too large (4447 > 4094) 

[atarkowska]

I think the error seems to come from a Gunicorn backend, not from Nginx. I fixed that using omero.web.wsgi_args to change it's limit by passing the parameter --limit-request-line https://docs.gunicorn.org/en/latest/settings.html?highlight=limit_request_line#limit-request-line

Hope that helps