It's amazing to me how we much we can fill in the blanks to make something recognizable with such little data.
I think the MozJPEG compression optimisations deserves a mention, as does where we started, with RLE encoding for printer things.
Also important for my personal understanding of JPEG is the context: slow CPUs and analogue screens. OG JPEG was optimised for this, MozJPEG changed the look up tables and the ubiquitous 'turbo' JPEG library to use a few more CPU cycles and save a few more bytes, whilst fixing the banding that was actually okay in the analogue days of old CRT monitors.
Bookmarked the article for re-reading.
I'd probably skip WebP, and go straight to AVIF at this point. I believe all modern browsers support it, and it compresses better than WebP.
> QOI is fast. It losslessly compresses images to a similar size of PNG, while offering 20x-50x faster encoding and 3x-4x faster decoding.
> QOI is simple. The reference en-/decoder fits in about 300 lines of C. The file format specification is a single page PDF.
Could ofc also make decompression by trying a million things.
To exist the compressed file only needs a formula to validate the result. Like it being a type 42 image with this checksum. It might take a quantum computer to confirm existence.
I had a fun idea to skip pixels and rows and make a tiny image at the beginning of the file followed by almost identical images with different offset.
Like progressive jpeg the entire image is visible almost instantly.
They could for practical purposes be seperate files too.
For mobile devices you only need the first n images for higher resolution and/or larger displays you keep loading until the resolution is acceptable or the tiles run out.
It would be wonderful for thumbnails. Display say 32x32, pre-load 256x256 and continue loading when clicked.
That is my assessment as well. The compression ratios with AVIF are ridiculous compared to older formats.
JXL is the best image format we have - supports lossy and lossless compression, HDR, and much more!