Future code-splitting for image decoders

[manzt]

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]

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.