-
Notifications
You must be signed in to change notification settings - Fork 1
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
Potential off-by-one when calculating resolution sizes #8
Comments
I feel like I must be missing something, but as far as I can tell there isn't way to get the XY size of each resolution without directly working with a I think ideally, the request for resolution information: qupath-extension-omero-web/src/main/java/qupath/lib/images/servers/omero/OmeroWebImageServer.java Line 283 in d2cf2c3
qupath-extension-omero-web/src/main/java/qupath/lib/images/servers/omero/OmeroWebImageServer.java Line 209 in d2cf2c3
qupath-extension-omero-web/src/main/java/qupath/lib/images/servers/omero/OmeroRequests.java Line 83 in d2cf2c3
would give us not just the zoom level scale factor, but the actual XY sizes since those are available from to include the resolution descriptions themselves in the returned JSON. Definitely would appreciate other opinions or better ideas though (@chris-allan / @sbesson). https://forum.image.sc/t/qupath-omero-weird-pyramid-levels/65484 is some prior investigation on this topic, but to be clear I strongly disagree with the suggestion that this is something to fix in Bio-Formats. |
Thanks @melissalinkert, yes looking at this earlier, the OMERO.web While having a simple scaling array makes sense from a viewer/zoom display perspective, I agree it is not sufficient to support scenarios like this one. Looking at the image.sc thread, it certainly like the QuPath / BioImageServer logic is internally working around this limitation as some formats are specially handled to account for the different of downsampling factors alongside X and Y - https://github.com/qupath/qupath/blob/17da581a49be1beb6af49a3cd15fa9c6f2527a95/qupath-extension-bioformats/src/main/java/qupath/lib/images/servers/bioformats/BioFormatsImageServer.java#L736-L745 I assume the problem is not limited to the micro-service though since the same resolution descriptors would be used when using the standard OMERO.web API? Do we know if this is failing in the same way for the synthetic image created above? |
Issue is definitely not limited to the microservices, and this extension currently requests zoom levels via I can view the imported image as expected without any errors in PathViewer and OMERO.web preview pane. |
My sense here is that the reason this isn't particularly problematic for the viewers currently is that they make their requests via
Combination of the two also an option since their not mutually exclusive. |
With this logging added:
I see this response from
Specifically, the zoom levels are:
and 3 tiles with a response code other than 200:
The actual exception that is thrown (server name replaced with
|
I feel like we've got something else odd going on here because the math to produce that scaling factor does not make sense:
|
As @sbesson and @melissalinkert reminded me, the For example:
If the scaling factor is different between X and Y this won't improve anything and if it's fractional it won't work at all. |
Generate artificial pyramid using https://github.com/ome/bioformats/blob/develop/components/formats-gpl/utils/WritePyramid.java and:
then import to an OMERO server (qupath-testing ID 2128 is an example). Attempting to load the imported image in QuPath will throw
FileNotFoundException
when attempting to load level 2, which is resolution 5 according to Bio-Formats indexing. The level dimensions in QuPath are calculated to be 721x1137, which means that it's trying to read one more pixel in Y than actually exists.Level dimensions are calculated according to the downsample factor reported by https://github.com/glencoesoftware/qupath-extension-omero-web/blob/main/src/main/java/qupath/lib/images/servers/omero/OmeroRequests.java#L83. The exact XY dimensions for each resolution level are not reported by that call. This is not simply a rounding issue, as the downsample factor times the largest resolution's SizeY is very slightly larger than 1137 (so
Math.floor(...)
wouldn't work). We'll need to get the exact XY dimensions of each resolution in some other way.The text was updated successfully, but these errors were encountered: