You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Construct Volume from loaders; load volume meta at loader creation - #499
This PR takes another step towards making Volume the primary client-facing interface for initiating volume data loads, rather than VolumeLoader, by altering the Volume constructor to require a VolumeLoader.
To enable this, all VolumeLoader methods that previously initiated a load of metadata rather than actual data are now synchronous. This has the effect of moving metadata loading to loader creation. Most loaders therefore now follow the OmeZarrLoader pattern of having a private constructor and an asyncstatic method that "opens" the loader. Once a loader is open, it must have all the data it needs to construct metadata objects immediately.
Solution
The loader interface change described above was pretty trivial on most VolumeLoader implementers, but two required more intensive changes:
OMEZarrLoader is responsible for computing the extent of a data request and picking a scale level. The metadata that this PR requires it to load in advance is more complex, and the code that loaded the relevant metadata was relatively entangled with the code that converted it into the required types.
WorkerLoader is a handle to a VolumeLoader running on a WebWorker, so everything it does involves message passing and is therefore async. This PR enables WorkerLoader to hold onto metadata on the main thread, so it can return results from metadata methods synchronously.
The reason will be displayed to describe this comment to others. Learn more.
The ultimate aim of this stack of PRs is to make this code, which initiates data loading, a call on volume with a simpler signature, rather than a call to loader. This PR doesn't get all the way there and in fact makes this procedure temporarily a bit more complicated; the next PR in this stack is set to clean it up.
The supplied loadSpec is no longer passed to volume construction. A non-default time or scale-level constraint is used by getDims above but discarded for the actual volume and data load, unlike the previous createVolume(loadSpec, ...) call. Pass it as the constructor's second argument.
Prevent mutation of cached transform translation
src/loaders/JsonImageInfoLoader.ts:74
jsonToImageInfo now runs against WorkerLoader's cached main-thread metadata, but tr aliases json.transform.translation and is rescaled in place. Creating another volume from the same loader and time point therefore rescales the translation shared by an already-created volume. Previously, worker responses isolated the returned arrays. Copy the translation before rescaling so conversion neither changes cached metadata nor shares this array between volumes.
The reason will be displayed to describe this comment to others. Learn more.
Remove?
This branch has not been deployed
No deployments
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
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.
Review time: medium-large (30-35min)
Problem
This PR takes another step towards making
Volumethe primary client-facing interface for initiating volume data loads, rather thanVolumeLoader, by altering theVolumeconstructor to require aVolumeLoader.To enable this, all
VolumeLoadermethods that previously initiated a load of metadata rather than actual data are now synchronous. This has the effect of moving metadata loading to loader creation. Most loaders therefore now follow theOmeZarrLoaderpattern of having a private constructor and anasyncstaticmethod that "opens" the loader. Once a loader is open, it must have all the data it needs to construct metadata objects immediately.Solution
The loader interface change described above was pretty trivial on most
VolumeLoaderimplementers, but two required more intensive changes:OMEZarrLoaderis responsible for computing the extent of a data request and picking a scale level. The metadata that this PR requires it to load in advance is more complex, and the code that loaded the relevant metadata was relatively entangled with the code that converted it into the required types.WorkerLoaderis a handle to aVolumeLoaderrunning on aWebWorker, so everything it does involves message passing and is thereforeasync. This PR enablesWorkerLoaderto hold onto metadata on the main thread, so it can return results from metadata methods synchronously.