Don't sleep on JPEG XL. It's used under the hood within DNG files (at least, it's an option, Adobe DNG Converter can leverage it, including by the CLI), DxO PureRAW leverages it in the latest versions. Apple Photos can view them, and I think it's been the compression methodology used inside their ProRAW DNGs for a while (which probably by default makes it one of the worlds most popular image compressors for RAW files). I've had a lot of success using it for various things. Had some issues surrounding metadata but that may be user error on my part.
Worth highlighting the QOI Image format (qoiformat.org) showing that you can also get significant image compression benefits with a simple 1-page specification [1]:
> 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.
The opposite should also be possible with the ultimate formula a giant lookup table with all the images preloaded.
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.
> Now that WebP is widely supported by browsers and operating systems, there's really no downside to using it. It's much more flexible than JPEG or PNG and offers better compression than both of them.
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.
I recently built a small image optimizer for macOS since ImageOptim is mostly abandonware now. Specifically for folks who dislike complex build tools for this job https://shiboru.com
Most comprehensive write up of JPEG et al. I have ever come across.
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.
Don't sleep on JPEG XL. It's used under the hood within DNG files (at least, it's an option, Adobe DNG Converter can leverage it, including by the CLI), DxO PureRAW leverages it in the latest versions. Apple Photos can view them, and I think it's been the compression methodology used inside their ProRAW DNGs for a while (which probably by default makes it one of the worlds most popular image compressors for RAW files). I've had a lot of success using it for various things. Had some issues surrounding metadata but that may be user error on my part.
JPEG XL aka .jxl is now supported by Firefox 152 and Chrome since 145 (behind a flag though on both).
JXL is the best image format we have - supports lossy and lossless compression, HDR, and much more!
https://jpegxl.info/
Worth highlighting the QOI Image format (qoiformat.org) showing that you can also get significant image compression benefits with a simple 1-page specification [1]:
> 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.
[1] https://qoiformat.org/qoi-specification.pdf
The opposite should also be possible with the ultimate formula a giant lookup table with all the images preloaded.
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.
> Now that WebP is widely supported by browsers and operating systems, there's really no downside to using it. It's much more flexible than JPEG or PNG and offers better compression than both of them.
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.
TIL that AVIF has been supported across all browsers since January 2024. Definitely looks like something I can start using.
> I'd probably skip WebP, and go straight to AVIF now.
That is my assessment as well. The compression ratios with AVIF are ridiculous compared to older formats.
I love image and video compression. For fun, I made my own and managed to squeeze an image of myself into byte level file sizes.
It's amazing to me how we much we can fill in the blanks to make something recognizable with such little data.
holy smokes this whole website is beautiful and so well done.
I recently built a small image optimizer for macOS since ImageOptim is mostly abandonware now. Specifically for folks who dislike complex build tools for this job https://shiboru.com
ImageOptim seems mostly done though. What more does it need to do compared to what it claims to do?
Most comprehensive write up of JPEG et al. I have ever come across.
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.