Supporting compression for `writeArrayBuffer` (JPG, LZW, Deflate etc)

[jo-chemla]

Would it be possible to enable compression support for writeArrayBuffer when encoding a data array into image?

UTIF.js advertises supporting compression JPG, LZW, Deflate among others but only for decoding.

complete list advertised in readme - see mapping: 1,3,4,5,6,7,8,32773,32809

Tracker for compression support in utif-js here photopea/UTIF.js#121. Note if pako library exists within the window scope, it gets used, which results in deflate encoding support, but external reference is probably not the best practice.

Edit: it might also be best to implement compression encoding for geotiffwriter independently of how utifjs handles it, since it does not seem to be on their roadmap as of now.

[oshawa-connection]

Hi @jo-chemla Do you know if anyone has started working on this? IMO the best approach would be to create a new, higher level alternative to writeArrayBuffer; in #515 users have to calculate tileoffsets and stripoffsets themselves which I would like to calculate automatically. This would go hand in hand with the new compression functionality, so it might be good to tackle them both at the same time.

What do you think?

I'm happy to work on this. A first stab might be to just support Deflate to start with, them move on to other more complicated encoders.

[jo-chemla]

Hi @oshawa-connection I don't know of anyone who started working on this - but I'm more of a user of geotiffjs, not a team member, just did one minor PR. It does seem to make sense to dedicate a higher-level api for both compression and your offsets computations.

Edit: Note the new kid in town from @kylebarron at devseed, deck.gl-raster own @developmentseed/geotiff does wrap @cogeotiff/core and hence supports compression methods Deflate, LERC, LERC+Deflate, LERC+ZSTD, LZW, JPEG (browser-only), WebP (browser-only), ZSTD. They are dynamically loading decompressors as needed, since not bundled to avoid inflating the bundle size.