search

hms-dbmi / viv

Library for multiscale visualization of high-resolution multiplexed bioimaging data on the web. Directly renders Zarr and OME-TIFF.
http://avivator.gehlenborglab.org
MIT License
283 stars 46 forks source link

Future code-splitting for image decoders #279

Closed manzt closed 11 months ago

manzt commented 4 years ago

An issue I see going forward is that the bulk of the JS bundles for consumers using Viv are primarily image codecs that might not used.

Both geotiff.js and zarr.js are currently configured in a way that prevents code-splitting. This is being addressed in zarr.js (https://github.com/gzuidhof/zarr.js/pull/63), and I've also opened in issue in geotiff (https://github.com/geotiffjs/geotiff.js/issues/172).

While it would be great to add more codecs to support more images, each additional codec has the cost of forcing all end-users to download a larger bundle up-front. Ideally, applications using Viv and not Viv (the library itself) should determine how these codecs are loaded.

For something like Avivator, we don't know what people will try, so having a flexible way to dynamically load modules would be ideal. For other applications, where developers know types of images before-hand bundles with only necessary codecs can be constructed.

manzt commented 4 years ago

I'm not sure if there is any action item here currently, but I wanted to highlight a concern with the cost of features we intend to add to Viv.

For instance, adding better LZW support (#277) meant editing the Viv source in a way that effects all downstream users. If we think about a more flexible design for image codecs in Viv (like a configurable dynamic registry), perhaps there is a way that Avivator (a library consumer) could have made these changes without effecting the Viv source.