Extend application context to include pixels service.

[mtbc]

This PR extends the minimal microservice to bring up just enough of the OMERO server to enable the pixels service and to use it to report image dimensionality at http://localhost:8080/image?id=1234 for image ID 1234.

[will-moore]

I don't know if we've discussed URLs yet, but if the image ID is essential (not optional) I would expect it to be in the form http://localhost:8080/image/1234/ instead of using the query string. The main exception is if you want to allow multiple IDs http://localhost:8080/image?id=1234&id=56?

[mtbc]

:+1: This is just about showing the image information is available at all, the URL-form stuff will get a bunch of fiddling anyway when expanding to match what Xpublish does.

[manics]

@will-moore The URLs are being defined in https://github.com/ome/omero-ms-zarr/blob/master/swagger.yaml

Published as http://petstore.swagger.io/?url=https://raw.githubusercontent.com/ome/omero-ms-zarr/master/swagger.yaml

[manics]

We might also need to discuss how the response of Xpublish differs from e.g. retrieving raw Zarr chunks over http (if it does at all) since this would affect how easily clients can load a Zarr from this service.

[will-moore]

xpublish provides additional REST endpoints that wont be available from serving 'raw' zarr files https://xpublish.readthedocs.io/en/latest/tutorial.html#rest-api Also, I found that you need to your zarr files to have NO groups if you want to consume with e.g. http://guido.io/zarr.js whereas xpublish/xarray does have groups, so the structure of the zarr file itself can be important.

[joshmoore]

xpublish provides additional REST endpoints

Interesting. Some of those may be worth thinking about. Using fsspec.implementations.http.HTTPFileSystem to play around with "raw" zarr, these are other "official" zarr API calls:

"GET / HTTP/1.1" 200 -
"GET /.zgroup HTTP/1.1" 200 -
"GET /test/ HTTP/1.1" 200 -
"GET /test/.zarray HTTP/1.1" 200 -
"GET /test/0.0 HTTP/1.1" 200 -
"HEAD /.zgroup HTTP/1.1" 200 -
"HEAD /test/ HTTP/1.1" 200 -
"HEAD /test/.zarray HTTP/1.1" 200 -
"GET /.zarray HTTP/1.1" 404 -       # Not an array so 404
"GET /test/.zgroup HTTP/1.1" 404 -  # Not a group so 404
"GET /test/.zattrs HTTP/1.1" 404 -  # No attributes were saved

So:

• file listings of groups
• group metadata
• array metadata
• attributes for groups and arrays
• chunks

so the structure of the zarr file itself can be important.

I think in the case of a library expecting just an array and no groups you'd need to pass a sub-path which is itself still a valid zarr.

[mtbc]

Still trying to find a good explanation of how the combined metadata is formed and this PR doesn't really seem the place for broader discussion but: without groups, how were you thinking of handling subresolutions?

[joshmoore]

Certainly with groups. From https://github.com/zarr-developers/zarr-specs/issues/50 metadata of the form:

{
  “multiscale”: {
    “version” : “0.1”,
    “series” : [
      [
          {"path": "base"},
          {"path": "0"},
          {"path": "1"},
          {"path": "2"},
          {"path": "3"},
          {"path": "4"}
      ]
     // See the detailed example below for optional metadata
  }
}

[joshmoore]

Merging to add some simple Python tests. Note: in my omero-ms-zarr directory I now have a FullText directory. I'll see if it re-appears but it likely points to some misconfiguration.

[mtbc]

in my omero-ms-zarr directory I now have a FullText directory

Me too, for now I'm considering it a feature. :smiley: