Removed url property from LoadSpec in favor of passing URLs into IVolumeLoader constructors
Replace test viewer's outdated time series playback with newer API
Allow JsonImageInfoLoader to accept an array of URLs to support JSON time series in the new API
Add caching to OMEZarrLoader (but no other loaders so far)
Made the API changes described in the list at the bottom of this comment
Strap in, this one got away from me a bit.
The original intent of this PR was to address a comment in #134: now that loaders are stateful and Volumes may submit load requests to them at will, it makes sense to remove the url property from LoadSpec and set it in loader constructors instead.
I made this change, but this presented a problem for the example viewer. It used its own ad hoc time series playback mechanism, where a collection of JSON atlas volumes are treated as frames of a single time series. (Ideally I would have removed this when I added first class support for time series in #104, but I didn't have a means to also support JSON time series then.) All these volumes were previously loaded by the same JsonImageInfoLoader, but under this new stateful loader paradigm each frame would have required a new loader. In order to avoid this awkward situation, I replaced the old time series mechanism with the current setTime API, and supported the JSON time series by allowing JsonImageInfoLoader to accept an array of URLs representing time series frames. This has the added bonus of enabling new region-aware loading features in zarr time series, since the old mechanism would throw out and recreate volumes.
In order to preserve as much of the original behavior of the time series JSON as possible, my original intent was to also add cache support in this PR (partially addressing #126). I began this process with OMEZarrLoader, but found that JsonImageInfoLoader would have required more intensive changes, since its data arrives in atlased batches of (up to) four channels and is never converted to a cache-compatible format in the loader. So only zarrs get cached for now, but this at least demonstrates the API I want to extend to the other loaders and allows us to try out cache performance in the test viewer. (Note though: JSON time series frames are no longer prefetched!)
I also made the following stray API tweaks:
Removed the url parameter from the PerChannelCallback type. All callbacks passed to loaders ignored this parameter, both in the test viewer and in website-3d-cell-viewer.
setTime accepts an optional PerChannelCallback like a loader method call would.
Volumes now properly mark themselves as "unloaded" when loading new data
TL;DR:
urlproperty fromLoadSpecin favor of passing URLs intoIVolumeLoaderconstructorsJsonImageInfoLoaderto accept an array of URLs to support JSON time series in the new APIOMEZarrLoader(but no other loaders so far)Strap in, this one got away from me a bit.
The original intent of this PR was to address a comment in #134: now that loaders are stateful and
Volumes may submit load requests to them at will, it makes sense to remove theurlproperty fromLoadSpecand set it in loader constructors instead.I made this change, but this presented a problem for the example viewer. It used its own ad hoc time series playback mechanism, where a collection of JSON atlas volumes are treated as frames of a single time series. (Ideally I would have removed this when I added first class support for time series in #104, but I didn't have a means to also support JSON time series then.) All these volumes were previously loaded by the same
JsonImageInfoLoader, but under this new stateful loader paradigm each frame would have required a new loader. In order to avoid this awkward situation, I replaced the old time series mechanism with the currentsetTimeAPI, and supported the JSON time series by allowingJsonImageInfoLoaderto accept an array of URLs representing time series frames. This has the added bonus of enabling new region-aware loading features in zarr time series, since the old mechanism would throw out and recreate volumes.In order to preserve as much of the original behavior of the time series JSON as possible, my original intent was to also add cache support in this PR (partially addressing #126). I began this process with
OMEZarrLoader, but found thatJsonImageInfoLoaderwould have required more intensive changes, since its data arrives in atlased batches of (up to) four channels and is never converted to a cache-compatible format in the loader. So only zarrs get cached for now, but this at least demonstrates the API I want to extend to the other loaders and allows us to try out cache performance in the test viewer. (Note though: JSON time series frames are no longer prefetched!)I also made the following stray API tweaks:
urlparameter from thePerChannelCallbacktype. All callbacks passed to loaders ignored this parameter, both in the test viewer and in website-3d-cell-viewer.setTimeaccepts an optionalPerChannelCallbacklike a loader method call would.CachedVolume->CacheStorefor clarity