380 alphanumeric well images #71
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Automated Review URLs |
jo-mueller
reviewed
Jan 22, 2026
Co-authored-by: Johannes Soltwedel <38459088+jo-mueller@users.noreply.github.com>
imagejan
approved these changes
Jan 22, 2026
jo-mueller
approved these changes
Jan 23, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR suggests relaxing the allowed names of images in wells, following the discussion here: ome/ngff#380
While I understand restrictions on names for rows and columns of HCS plates, the images in HCS plates can be many things. I don't think it's reasonable to restrict it more than general Zarr node naming restrictions. As proposed by @d-v-b , this PR proposes following the Zarr spec recommendations for characters in node names.
I don't know what the rule on linking to other pages like the Zarr spec page is / should be, so we can also remove that link if needed.
@thewtex Could you also have a look at this and whether this would interfere with anything ngff-zarr related?
We already implemented this in ngio (we actually had always been using
_in path names and only noticed last fall that this clashes with the strict path definitions in HCS wells.cc @imagejan @lorenzocerrone