Skip to content
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

Plate export improvements #31

Open
dominikl opened this issue Oct 21, 2020 · 0 comments
Open

Plate export improvements #31

dominikl opened this issue Oct 21, 2020 · 0 comments

Comments

@dominikl
Copy link
Member

dominikl commented Oct 21, 2020

Comments from now closed PR #28

@joshmoore
Feedback from ome/ome-zarr-py#56 :
The contents of the Field_* folder should probably be multiscales. That adds yet another layer to this already pretty deep hierarchy, but it will mean we can always assume a pyramid.
Several of the string elements in the path aren't readably computable at the moment (see https://github.com/ome/ome-zarr-py/pull/56/files#diff-b50d9715cc6e4017cfc055fd0ed73ecb5d9158e17f4d58ca5b3ba08b89c46657R354-R358) Ideas on this front are:
- encode the naming scheme for row and column
- encode an array of these values rather than the row/column size
- encode the paths to the individual images
is probably the easiest for the moment. 3. is more verbose but is probably my long-term preference.

@sbesson
"The contents of the Field_* folder should probably be multiscales. That adds yet another layer to this already pretty deep hierarchy, but it will mean we can always assume a pyramid."
Also assuming multiscales gets increasingly used for thumbnailing, big 👍 for having this a MUST rather than a SHOULD in the spec from my side.

This was referenced Oct 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@dominikl and others