wip new lazy to_multiscale() for labels #1068
Draft
+199
−52
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.
Closes #1069
This PR (still work-in-progress) aims at implementing a function to generate a pyramidal image given a dask array, by relying on
ome-zarrinternal APIs and by extending functionalities currently not available viaome_zarr.scale.Scaler. Such a function is also provided by themultiscale-spatial-imagepackage, but as explained in the linked issue we hit a performance roadblock.ome-zarr-pydoes not support downscaling of thezdimension, nor downscaling via scale factors specified per dimension (both cases are supported bymultiscale-spatial-image); these cases will be covered by this PR. The implementation could also live inome-zarr-py(CC @will-moore @joshmoore @jo-mueller), I'd be happy if someone later can pick up the code so I can remove it fromspatialdataand use it from upstream.Side technical note:
spatialdatausesxarray_coarsen(frommultiscale-spatial-image) for images, (which is fully lazy), anditk_nearest(frommultiscale-spatial-image) for labels (which is not lazy and therefore problematic). Since downscaling for images doesn't give problems, we could use the old implementation, but I'm reimplementing it withome-zarr-pyAPIs anyway. So far it seems that both implementations lead to identical results.