fix: detect voxel-cell convention from OME-Zarr LOD translation pattern#664
Merged
Conversation
Collaborator
Author
|
Here is a demonstration where the effect when zooming is quite jarring: on
|
|
🎉 This PR is included in version 0.21.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
Multiscale pyramids may use one of two conventions for the origin of each LOD: the corner or the center of the first voxel. To correct for this offset, a zarr will include a half-voxel-per-LOD translation pattern ("voxel-center" convention
trans_k = trans_{k-1} + 0.5 * (scale_k - scale_{k-1})) or with constant translations across LODs ("voxel-corner" convention). Both are valid; the choice is set by the dataset author, but not declared anywhere explicitly.Without normalization, downstream code (chunk visibility, rendering placement) gets the wrong extent for one or the other convention. We see both conventions in our sample data.
This fix detects the convention per-axis in
inferSourceDimensionMapby checking whether each LOD's translation delta matches the half-voxel prediction. For center-convention dimensions, we shift translations by-0.5 * scaleper-axis per-LOD. After this,chunk.offset = trans + chunkIdx * chunkSize * scaleis always the voxel-cell corner, and the rest of our code can use[offset, offset + shape * scale]without regard for the source data convention.See here the before/after of the "marmoset neurons" dataset. Note the offset in the corner, resolved by this PR (all corners look good after this change). The effect can be severe in 3D datasets with many levels (e.g. the exaSPIM dataset added in #662).
This effect can be especially jarring in 3D data where the "fallback" chunks show a very different slice compared to the current LOD.
Related Issue
Closes #369
Tests & Checks
Tested four datasets: zebrahub, ca wave dynamics, marmoset neurons, and exaSPIM