79 ms·

Image Compression

228 points by vinhnx 4mo ago

filup 4mo ago
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.
Theodores 4mo ago
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.
thm 4mo ago
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 https://shiboru.com
- Y-bar 4mo ago
  ImageOptim seems mostly done though. What more does it need to do compared to what it claims to do?
mythz 4mo ago
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 https://qoiformat.org/qoi-specification.pdf
- econ 4mo ago
  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.
  - lukevp 4mo ago
    blur hash is an algorithm for a low res representation of an image for placeholder purposes, it's pretty nice. https://blurha.sh https://blurha.sh
  - benj111 4mo ago
    >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 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.
    - econ 4mo ago
      Please do read this as satire... 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.
mrngld 4mo ago
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.
- yboris 4mo ago
  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/ https://jpegxl.info/
  - jiggawatts 4mo ago
    The format supports HDR, but most apps using it don’t. I’ve given up trying to use JXL in the Apple ecosystems for exchanging HDR images for this reason.
    - encrypted_bird 4mo ago
      Speaking out of genuine curiosity here, but what kinds of photos are you taking that require HDR?
- Narew 4mo ago
  Disclaimer : I worked at DxO. 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.
- thinkingQueen 4mo ago
  Those are good venues to sneak JPEG XL into the mainstream. It would be a pity if it became another JPEG 2000. On the other hand, JPEG 2000 was probably just too advanced and computationally complex to be widely adopted at the time. Sometimes I look back at it and, after all the extensions and revisions, it feels like it has everything—but it’s still a niche codec. A cautionary tale, and a pattern that tends to repeat itself with codecs...
CodesInChaos 4mo ago
> 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.
- AndrewStephens 4mo ago
  > 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.
  - conradkay 4mo ago
    It's great but you definitely pay for it. Encoding can be really slow, and to a lesser extent decoding as well. So I still end up using .jpg quite often, or .webp as a good middle ground
    - CodesInChaos 4mo ago
      [dead]
    - juliobbv 4mo ago
      You can adjust how much "effort" the avif encoder puts on images. 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.
- pseudosavant 4mo ago
  TIL that AVIF has been supported across all browsers since January 2024. Definitely looks like something I can start using.
- Self-Perfection 4mo ago
  In lossless mode WebP is superior to AVIF.
polalavik 4mo ago
holy smokes this whole website is beautiful and so well done.
stevefan1999 4mo ago
I still remember the multimedia course...DCT, JPEG and all the compression algorithms like Huffman coding and Arithmetic coding...
sudo_cowsay 4mo ago
shouldn't people have learned this in high school cs?
- encrypted_bird 4mo ago
  That assumes everyone's high school had a CS class. Mine certainly didn't.
mistercow 4mo ago
> More so than any other image format, JPEG takes advantage of the quirks of human perception to throw away information while largely preserving quality. 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.
- casey2 4mo ago
  webp doesn't preserve quality it actively makes the web and images shittier.
  - mistercow 4mo ago
    WebP generally preserves higher visual quality at the same compression ratios as JPEG. You can make bad looking images with either codec by demanding smaller file sizes, but all else equal, WebP usually looks better.
01010101000 4mo ago
Render graphics in X11 or Wayland. Lossless FLAC, which is in 44.1 kHz.

228 points by vinhnx 4mo ago

filup 4mo ago

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.

Theodores 4mo ago

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.

thm 4mo ago

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 https://shiboru.com

Y-bar 4mo ago
ImageOptim seems mostly done though. What more does it need to do compared to what it claims to do?

mythz 4mo ago

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 https://qoiformat.org/qoi-specification.pdf

econ 4mo ago
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.
- lukevp 4mo ago
  blur hash is an algorithm for a low res representation of an image for placeholder purposes, it's pretty nice. https://blurha.sh https://blurha.sh
- benj111 4mo ago
  >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 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.
  - econ 4mo ago
    Please do read this as satire... 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.

mrngld 4mo ago

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.

yboris 4mo ago
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/ https://jpegxl.info/
- jiggawatts 4mo ago
  The format supports HDR, but most apps using it don’t. I’ve given up trying to use JXL in the Apple ecosystems for exchanging HDR images for this reason.
  - encrypted_bird 4mo ago
    Speaking out of genuine curiosity here, but what kinds of photos are you taking that require HDR?
Narew 4mo ago
Disclaimer : I worked at DxO. 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.
thinkingQueen 4mo ago
Those are good venues to sneak JPEG XL into the mainstream. It would be a pity if it became another JPEG 2000. On the other hand, JPEG 2000 was probably just too advanced and computationally complex to be widely adopted at the time. Sometimes I look back at it and, after all the extensions and revisions, it feels like it has everything—but it’s still a niche codec. A cautionary tale, and a pattern that tends to repeat itself with codecs...

CodesInChaos 4mo ago

> 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.

AndrewStephens 4mo ago
> 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.
- conradkay 4mo ago
  It's great but you definitely pay for it. Encoding can be really slow, and to a lesser extent decoding as well. So I still end up using .jpg quite often, or .webp as a good middle ground
  - CodesInChaos 4mo ago
    [dead]
  - juliobbv 4mo ago
    You can adjust how much "effort" the avif encoder puts on images. 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.
pseudosavant 4mo ago
TIL that AVIF has been supported across all browsers since January 2024. Definitely looks like something I can start using.
Self-Perfection 4mo ago
In lossless mode WebP is superior to AVIF.

polalavik 4mo ago

holy smokes this whole website is beautiful and so well done.

stevefan1999 4mo ago

I still remember the multimedia course...DCT, JPEG and all the compression algorithms like Huffman coding and Arithmetic coding...

sudo_cowsay 4mo ago

shouldn't people have learned this in high school cs?

encrypted_bird 4mo ago
That assumes everyone's high school had a CS class. Mine certainly didn't.

mistercow 4mo ago

> More so than any other image format, JPEG takes advantage of the quirks of human perception to throw away information while largely preserving quality. 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.

casey2 4mo ago
webp doesn't preserve quality it actively makes the web and images shittier.
- mistercow 4mo ago
  WebP generally preserves higher visual quality at the same compression ratios as JPEG. You can make bad looking images with either codec by demanding smaller file sizes, but all else equal, WebP usually looks better.

01010101000 4mo ago

Render graphics in X11 or Wayland. Lossless FLAC, which is in 44.1 kHz.