-
Notifications
You must be signed in to change notification settings - Fork 28
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
Apply inversion and quantization to proper channels #441
Conversation
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionality looks good to me, just some minor comments/questions
omeroweb/webgateway/views.py
Outdated
@@ -2269,7 +2297,7 @@ def getRenderingSettings(image): | |||
return rv | |||
|
|||
def applyRenderingSettings(image, rdef): | |||
invert_flags = _get_maps_enabled(rdef, "inverted", image.getSizeC()) | |||
invert_flags = _get_inverted_enabled(rdef, "inverted", image.getSizeC()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the second and third argument still needed?
omeroweb/webgateway/views.py
Outdated
map_json = r["maps"] | ||
# If coming from request string, need to load -> json | ||
if isinstance(map_json, (unicode, str)): | ||
map_json = json.loads(map_json) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In _get_inverted_enabled
json.loads
is wrapped in a try
block to catch JSON errors, should this also be wrapped and return false
on error?
Conflicting PR. Removed from build OMERO-python-superbuild-push#135. See the console output for more details.
--conflicts |
|
In the sample URLs from the description, first request has:
2nd one has:
Testing locally now, these give identical rendering settings (quantization is applied to 2nd channel which is also inverted)
However, this doesn't throw any errors as expected when
whereas if the maps is shorter than c:
both give:
|
…aps are provided than channels
Conflicting PR. Removed from build OMERO-python-superbuild-push#136. See the console output for more details.
--conflicts |
Conflicting PR. Removed from build OMERO-python-superbuild-push#1344. See the console output for more details.
--conflicts |
Retesting URLs above, e.g.
|
Conflicting PR. Removed from build OMERO-python-superbuild-push#137. See the console output for more details.
--conflicts |
Conflicting PR. Removed from build OMERO-python-superbuild-push#138. See the console output for more details.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inline with the testing of glencoesoftware/omero-ms-image-region#120 (which motivated this PR), tested a few endpoints with and without this PR (using current IDR as the reference point)
-
a single resolution multi-channel image -https://idr.openmicroscopy.org/webclient/img_detail/10501752/ with different query parameters:
?tile=0,0,0,464,494
default?m=c&c=1|0:10$00FF00,8|0:10$FF0000,13|0:10$0000FF,15|0:34.953$0000FF,26|0:10$FFFF00,30|0:10$00FFFF,34|0:10$FF00FF,41|0:10$FFFFFF&maps=[{},{},{},{},{},{},{},{"inverted":{"enabled":false},"quantization":{"family":"exponential","coefficient":2}}]&tile=0,0,0,464,494
?m=c&c=1|0:10$00FF00,8|0:10$FF0000,13|0:10$0000FF,15|0:34.953$0000FF,26|0:10$FFFF00,30|0:10$00FFFF,34|0:10$FF00FF,41|0:10$FFFFFF&maps=[{},{},{},{},{},{},{},{"inverted":{"enabled":false},"quantization":{"family":"polynomial","coefficient":2}}]&tile=0,0,0,464,494
?m=c&c=1|0:10$00FF00,8|0:10$FF0000,13|0:10$0000FF,15|0:34.953$0000FF,26|0:10$FFFF00,30|0:10$00FFFF,34|0:10$FF00FF,41|0:10$FFFFFF&maps=[{},{},{},{},{},{},{},{"inverted":{"enabled":false},"quantization":{"family":"logarithmic","coefficient":2}}]&tile=0,0,0,464,494
?m=c&c=1|0:10$00FF00,8|0:10$FF0000,13|0:10$0000FF,15|0:34.953$0000FF,26|0:10$FFFF00,30|0:10$00FFFF,34|0:10$FF00FF,41|0:10$FFFFFF&maps=[{},{},{},{},{},{},{},{"inverted":{"enabled":false},"quantization":{"family":"linear","coefficient":2}}]&tile=0,0,0,464,494
?m=c&c=1|0:10$00FF00,8|0:10$FF0000,13|0:10$0000FF,15|0:34.953$0000FF,26|0:10$FFFF00,30|0:10$00FFFF,34|0:10$FF00FF,41|0:10$FFFFFF&maps=[{},{"inverted":{"enabled":true}},{},{},{},{},{},{}]&tile=0,0,0,46
-
a multi-resolution image https://idr.openmicroscopy.org/webclient/img_detail/14000763/, with similar parameters as the one suggested in the description
/?m=c&z=1&t=1&format=jpeg&c=-1|C0:255$FF0000,2|C0:255$00FF00,3|C0:255$0000FF&tile=1,20,3,1024,1024&maps=[{},{"inverted":{"enabled":true},"quantization":{"family":"polynomial","coefficient":1.9}},{}]
?m=c&z=1&t=1&format=jpeg&c=2|C0:255$00FF00,3|C0:255$0000FF&tile=1,20,3,1024,1024&maps=[{"inverted":{"enabled":true},"quantization":{"family":"polynomial","coefficient":1.9}},{}]
Confirmed on current production IDR, the parameters are inconsistently interpreted and the rendered region differs from what is generated e.g. by adusting the rendering settings manually in the viewer. With this PR included, the behavior is working as expected.
The set of proposed changes make sense to me and ensure that the maps
parameters has the same dimensions as the c
parameters and that inversion/quantization values are assigned to the relevant channels.
More improvements/clarifications are being discussed in #443. Immediately, the PR fixes an outstanding issues and is ready for inclusion in the upcoming 5.18.0 release from my perspective.
Fixes #439. Refactors how inversions and quantizations are applied. In particular, pads out the quantizations so that if channels are missing from the
c
parameter, the corresponding channel hasNone
as its quantization. Also, if the number ofmaps
provided does not match the number of channels specified inc
, a 400 is returned with an error message.Testing
An IDR image is used here but any 3-channel image should work with the same query parameters. Similar to the issue, before the change the following URLs will yield different results, but with the change they should yield the same result:
https://idr.openmicroscopy.org/webgateway/render_image_region/14000763/0/0/?m=c&z=1&t=1&format=jpeg&c=-1|C0:255$FF0000,2|C0:255$00FF00,3|C0:255$0000FF&tile=1,2,3,1024,1024&maps=[{},{%22inverted%22:{%22enabled%22:true},%22quantization%22:{%22family%22:%22polynomial%22,%22coefficient%22:1.9}},{}]
https://idr.openmicroscopy.org/webgateway/render_image_region/14000763/0/0/?m=c&z=1&t=1&format=jpeg&c=2|C0:255$00FF00,3|C0:255$0000FF&tile=1,2,3,1024,1024&maps=[{%22inverted%22:{%22enabled%22:true},%22quantization%22:{%22family%22:%22polynomial%22,%22coefficient%22:1.9}},{}]