Image Compression
makingsoftware.com
makingsoftware.com
> 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.
I interpret this to mean that the checksum is the compressed file?
Surely you'd need to compute checksums for all possible images to confirm that the checksums are unique.
You're calculating a perfect hash for an input that could be anything. That isn't going to be short or easy to confirm.
And then you've got the question of if it's worth it. Yes the hash could represent an image of random noise at the same size as a blank black image. But it's going to be larger than today's technology for representing that black image.
So for a lot of images it isn't worth it. I would guess(?) the average photo is a lot closer to ordered than unordered, so it isn't going to work there either.
The checksum is the compressed file but you need to split the problem and forEach structure it in such a way that one can dial into it. You need to be able to compare the current result with the previous one in a linear way. It needs to fulfill all preconceived ideas of what an image should look like.
I think the joke is pretty good.
JXL is the best image format we have - supports lossy and lossless compression, HDR, and much more!
I’ve given up trying to use JXL in the Apple ecosystems for exchanging HDR images for this reason.
DNG is more a container in which you can store lots of different think and not only RAW images.
For example PureRaw output Linear DNG that is not a RAW anymore. In the same way ProRaw is not a RAW image dispite it's name. But yes PureRaw and some ProRaw are compressed internally with jxl.
You can get way better perceptual compression at much much tinier sizes though. This is where a lot of user studies and research could play out.
If you've read that article out, you might want to take a look at alternative approaches to compressing images with similar principles.
https://github.com/guilt/MLL is a recent reimplementation of an old idea; If you quantize out the image blocks you could emit them in vector coordinates and have perceptually similar results at a fraction of the size with very decent signal preservation.
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.
That is my assessment as well. The compression ratios with AVIF are ridiculous compared to older formats.
So I still end up using .jpg quite often, or .webp as a good middle ground
The default speed in libavif (-s 6 in avifenc) is fast enough, and it has been used by big CDNs to encode AVIFs for years. You can make the encoder as fast or slow as you'd like, depending on your compute/compression efficiency trade-off requirements.
Right; the issue is compatibility. But that doesn't get solved if we collectively stick to the past and only use old formats like gif and jpeg. Compatibility gets fixed by using a format, and then complaining to software developers when their software isn't compatible with our workflows. Eventually compatibility improves, and we get our cake and eat it too. Better storage and bandwidth use. And compatibility across all our software.
It just takes time.
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.
That is a very odd thing to say in a post that also mentions WebP. I would say that of all the commonly supported lossy image codecs released since 1992, JPEG takes the least advantage of human perception quirks.
It's amazing to me how we much we can fill in the blanks to make something recognizable with such little data.