JPEG XL

I think they do the same for progressive JPEG 1. as far as I'm aware, the DC components of progressive JPEG actually look like perfect squares, and the decoders in browsers blur them of their own volition specifically to make progressive look nicer

Neither the jpeg 1 nor the jxl spec says anything about how you're supposed to render partial image data, only the final image is specified. So it's not in or out of spec to show low-res previews in a blurry way, in a blocky way, or using the fancy upsampler we use in libjxl.

if there ends up being a way to query the percentage of bytes loaded (maybe there already is, I'm not super familiar with the Web API), websites could potentially do it themselves with JS and CSS which in practice means no one will do it but I like that it gives you control

can you tell whether this one uses the default upsampler?

because it doens't look very blurry, but also I remember something along the lines of: LF blurring works on a 1:8 of the image, so it might not have the chance to blur those blocks that much given how big they are 🤔

that's just a result of raw unsqueeze transform and 8x NN upsampling for LF frame, nothing fancy. that one was decoded using jxl-oxide iirc

This looks like just unsqueezing with assumed zero residuals. The tendency term will cause it to look like that.

oh hmm. it might be good to replace that graphic with VarDCT progressive loading, people will definitely see those more (and is sort of expected to be used for a photographic image like this)

it's actually progressive VarDCT encoding, though LF frame uses Modular because squeeze transform is much better at creating lower resolution previews

ah, gotcha

so it uses squeeze until 1:8 then switches to DCT

https://github.com/libjxl/jxl-rs/issues/387

is there a benchmark how fast JPEG XL decoding speed is at different lvls of compression?

`benchmark_xl --input=blah.png --codec=jxl:d1,jxl:d2,jxl:d3 --decode_reps=30 --num_threads=0 --inner_threads=NB_THREADS`

These are the kind of numbers I get with 4 threads: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- jxl:d0.2 5242 3523753 5.3768204 11.758 133.465 0.74666458 90.75474509 50.15 0.20155062 1.083701491906 5.377 0 jxl:d0.5 5242 1986915 3.0317917 12.640 182.482 1.14921882 88.17999824 44.31 0.42358538 1.284222622528 3.484 0 jxl:d1 5242 1196239 1.8253159 11.615 163.103 1.72378463 83.06925731 40.91 0.69828552 1.274591623605 3.146 0 jxl:d2 5242 689070 1.0514374 10.365 199.808 2.75924460 73.21579877 37.37 1.11687348 1.174322525976 2.901 0 jxl:d3 5242 487047 0.7431747 9.850 211.756 3.72705648 64.65200124 35.56 1.45422875 1.080746076298 2.770 0 jxl:d4 5242 386094 0.5891327 8.837 133.573 5.33052577 57.45251261 34.37 1.74048901 1.025378975295 3.140 0 jxl:d6 5242 276871 0.4224716 10.431 142.772 6.08248985 45.78377116 32.84 2.20675997 0.932293458274 2.570 0 jxl:d8 5242 221731 0.3383347 10.444 144.541 7.63092791 37.06003665 31.78 2.65585771 0.898568704211 2.582 0 jxl:d12 5242 174917 0.2669022 9.157 367.764 27.60635948 -4.51364357 27.76 8.81798618 2.353539564305 7.368 0 Aggregate: 5242 609766 0.9304284 10.502 176.985 3.60911399 59.51716417 36.68 1.27187356 1.183387241367 3.469 0 ```

oh wow thank you!

perhaps more interesting is at different encoding efforts with roughly the same visual quality

And if you want to test against AVIF: `--codec custom:avif:avifenc:avifdec`