Some users really need a way to access raw pixels, e.g. see https://forum.image.sc/t/omero-extension-in-qupath-working-with-raw-pixel-data-fluorescent-images/52649/2
Although OME-Zarr is likely to be the preferred way to do this in the longer term (#4), @melvingelbard and I weren't able to figure out a straightforward way to do this in the short term when we tried some months ago.
The Gateway class could help, but my hesitation was always the number of dependencies required. However I finally understand that this can be addressed in a relatively straightforward way by requiring the user to install the OMERO fat jar (or ImageJ plugin) as if it's a QuPath extension.
If that's done, then this QuPath extension could discover the Gateway class by reflection and access raw pixels that way.
It should be achievable without bloating this extension or introducing any new required dependencies: if the Gateway is missing we'll simply fall back to using the web API (and being restricted to JPEG-compressed rendered images). We'll also continue to use the web API to browse the server data.
With this approach, we could retain a single OmeroImageServer implementation that delegates pixel access to a helper class. Three could exist:
- Web API (no extra dependencies, but limited to 8-bit and generally RGB... with lossy compression)
- Gateway (only if available - not included by default)
- Zarr (in the future)
I spent about a week exploring this with some moderate success, but haven't pushed the code yet as it created a bit of a refactoring mess - and might very well have broken some things that previously worked.
The main problem is handling authentication reliably. Ideally I'd like to do this once using the current web/json API approach, but I haven't figured out how to get a session ID that can then be used with JoinSessionCredentials.
Anyhow, I'm creating this issue as a reminder and place to potentially discuss the approach.
@lacan @romainGuiet (sorry if I've missed anyone else who cares about this!)
Some users really need a way to access raw pixels, e.g. see https://forum.image.sc/t/omero-extension-in-qupath-working-with-raw-pixel-data-fluorescent-images/52649/2
Although OME-Zarr is likely to be the preferred way to do this in the longer term (#4), @melvingelbard and I weren't able to figure out a straightforward way to do this in the short term when we tried some months ago.
The
Gatewayclass could help, but my hesitation was always the number of dependencies required. However I finally understand that this can be addressed in a relatively straightforward way by requiring the user to install the OMERO fat jar (or ImageJ plugin) as if it's a QuPath extension.If that's done, then this QuPath extension could discover the
Gatewayclass by reflection and access raw pixels that way.It should be achievable without bloating this extension or introducing any new required dependencies: if the
Gatewayis missing we'll simply fall back to using the web API (and being restricted to JPEG-compressed rendered images). We'll also continue to use the web API to browse the server data.With this approach, we could retain a single
OmeroImageServerimplementation that delegates pixel access to a helper class. Three could exist:I spent about a week exploring this with some moderate success, but haven't pushed the code yet as it created a bit of a refactoring mess - and might very well have broken some things that previously worked.
The main problem is handling authentication reliably. Ideally I'd like to do this once using the current web/json API approach, but I haven't figured out how to get a session ID that can then be used with
JoinSessionCredentials.Anyhow, I'm creating this issue as a reminder and place to potentially discuss the approach.
@lacan @romainGuiet (sorry if I've missed anyone else who cares about this!)