[DRAFT] progressive decode

[dholth]

WIP fix #1373

TODO

• User interface to choose how much data to send to decoder.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jakearchibald]

It seems reasonable for this to be a JXL-only feature to begin with. Ideally it'd be something that worked across all codecs, where you're given a single <input type="range"> where the left side is zero bytes, and the right is the number of bytes in the larger of the two output images, but that's a much harder problem to solve.

[dholth]

It's far enough along to display partially decoded images and get an idea of how they work in jpegxl, but the partial decoding is just attached to the percent on-change function and is not well integrated with the post-compression decoding system. It looks like the browser's built-in decode doesn't display partial images at all, e.g. for JPEG or for Firefox Nightly's built-in jpeg-xl; the wasm encoder should always be used even if the browser supports that codec.

The images I've been testing seem to display after a minimum of 20-40% or the first 100-200kB of image data is available. First you will see a lower resolution version of the whole image. Then higher resolution blocks are filled in from left-to-right, top-to-bottom, and the effect is subtle. Squoosh app doesn't expose the compressor's block order parameters like "spiral out from the center or from a point of interest". Some level of progressive loading works even when progressive is not checked. Progressive images often compress better than non-progressive. Interesting experiment over all.