6 ms·

Preemptive disclaimer: I don't want to belittle the work the authors did here in any way, and are actually excited especially about the reversible, lossless jpe

Preemptive disclaimer: I don't want to belittle the work the authors did here in any way, and are actually excited especially about the reversible, lossless jpeg<->brunsli coding and that google's buy in and network effects will most likely mean this comes to a viewer/editing software near you in the not so distant future (unlike lepton, which never got out of it's tiny niche). But seeing the 22% improvement figure reminded me that the typical JPEG file on the internet is rather unoptimized even on write-once-read-many services like imgur or i.reddit.com which transform files (stripping meta data etc) and do not preserve the original files. Just using the regular vanilla libjpeg encoder you can usually save 5%-10% just by lossless recoding of the coeffs and the better-yet-more-computionally-intense mozjpeg coder can even get you a bit further than that. Then again, the imgur single image view page (desktop) I just randomly opened by randomly clicking an item on their homepage transfers 2.9MiB of data with ads blocked (3.9MiB deflated), 385KiB of which was the actual image, and that image can be lossless recoded by mozjpeg to 361KiB (24KiB difference, a 6.2% reduction), so the 24KiB (0.8%) reduction out of 2.9MiB of cruft hardly matters to them I suppose and may be cheaper in bandwidth and storage cost to them than the compute cost (and humans writing and maintaining the code). Using brunsli, that same 385KiB imgur file went down to 307KiB so roughly a 20% reduction, but still only 2.6% reduction of that massive 2.9MiB the imgur site transferred in total.

Santosh83 7y ago
Yes not so useful for small images but when users view multi-megabyte images then I guess the savings will start to be significant even with the page overhead. Say a 4Mb image can be optimised to 2.5Mb then total download comes down from 6.9Mb to 5.4Mb which is not trivial, especially when the same page has multiple images (some people upload a gallery of images on sites like imgur) or when viewing lots of image URLs. Especially on a limited data plan these small savings will start adding up.
- rndgermandude 7y ago
  Yes, it would be a win for the users, especially on limited data plans. Though I wouldn't hold my breath for most sites to actually implement it; most sites do not mind serving megabytes of data for a single page view to users, incl megabytes of scripts, even to mobile users. 4MiB to 2.5MiB is out of range for brunsli, more like 3.2MiB if you're lucky. I also tried with a 54 MiB JPEG[1] just now. The brunsli coding is 49MiB so not even a 10% reduction on this particular file. And it took a wallclock time of 16 seconds on my last gen Intel. Decoding it back to JPEG took 11 seconds on the same box. [1] A picture of a wedding cake, taken with a NIKON D810, one of the largest JPEGs I had available. I was "exported" by Lightroom 9 it seems from a NEF/RAW source, and is full of meta data too, around 100KiB of it.
  - bscphil 7y ago
    > I also tried with a 54 MiB JPEG[1] just now. The brunsli coding is 49MiB so not even a 10% reduction on this particular file. What about JPEG XL? That's the primary usefulness of brunsli IMO, it's built into JPEG XL as one of the ways it achieves much better compression (comparable to, or possibly better than, AVIF).
    - rndgermandude 7y ago
      Just tried using their latest code. Same 54MiB JPEG yielded (with cjpexl -q x) 3.8 MiB (q=70) 13 MiB (q=90) ("visually lossless (side by side). Default for generic input.") 19 MiB (q=95) ("visually lossless (flicker-test).") 40 MiB (q=100) ("mathematically lossless. Default for already-lossy input (JPEG/GIF)") I'm guessing q=100 is essentially (mostly, minus rounding errors) lossless non-reversible brunsli JPEG-XL. To compare, webp (cwebp -q x, also operating on a q=0...100 scale) 9.9 MiB (q=70) 18 MiB (q=90) 23 MiB (q=95) 28 MiB (q=100) 65 MiB (z=6, medium lossless preset) I didn't do exact timings but JPEG XL was noticeably faster, then again they use multithreaded (using 4 threads here) AVX2 code, which cwebp does not (used the debian provided package for webp), so I wouldn't pay too much attention to this result. Keep in mind JPEG XL isn't finished, and that neither are their defaults and recommendations.
      - bscphil 7y ago
        That does sound very impressive. (Keep in mind, though, that there's no reason to think the q= settings give equivalent quality between JPEG XL and webp.) Also, your lossless encoding was only 40 MiB instead of 49 MiB for pure Brunsli, so presumably JPEG XL is capable of some stronger lossless compression.
        rndgermandude 7y ago
        Regarding brunsli vs JPEG XL "lossless": yes, JXL fared better there, but then again did not have the requirement of reproducing the bit-exact JPEG back on demand. So (as far as I understood) JPEG XL in q=100 will go back to the pixel data and run the the full JPEG XL coder on it (with no quantization to avoid loss), while JPEG XL in reversible "bg" mode[1]/brunsli will only decode back to the coeffs (so there is no loss at all) and then use their superior lossless (brunsli) coding to store these coeffs more efficiently along with some metadata to allow reconstructing the original file on demand. I could be wrong, I only skimmed the docs and code; when I was quite tired. [1] JXL has a "bg" mode too that is reversible to the original JPEGs, but that's currently not exposed by the cjpegxl tool. But I saw in in their benchmark tool, and there it produced essentially the same size files than plain brunsli tool did, probably because it's essentially just the brunsli tool.
zxcvbn4038 7y ago
I get what your saying but when your storing millions of images and transferring them frequently those small reductions in size are very significant when you get your storage and/or transit bill. A.lot of the fluff and filler you mentioned is cached, so your not bringing it down every request. Even if it wasn’t you can assume it’s deemed becc
- rndgermandude 7y ago
  You'd think so, but imgur for example is literally in the business of serving images to a lot of users (and some videos, too) and yet they did not even implement the vanilla libjpeg optimized coding it seems. And I am not just picking on imgur, they are just an example for today; other similar services didn't do much better last I checked, neither when it comes to serving optimized JPEGs nor overall page sizes either.
- IshKebab 7y ago
  I think that's his point - you can already reduce JPEG size a bit by using fancier libraries, but even huge sites like Imgur apparently don't bother.
  - jonsneyers 7y ago
    Maybe Imgur doesn't bother, I don't know. I work for Cloudinary, and we do bother. A lot.
- taneq 7y ago
  The small reductions in image size still pale into insignificance compared with the gains they'd get if they just cut 90% of the crud out of every imgur page load. In the past few years that site has become exponentially more bloated and resource intensive for zero apparent gain (to the users anyway).
hinkley 7y ago
I tried to order some takeout the other day and the place was busy so I got voicemail. The beginning was pretty solid, but as he went on you could tell that he was making it up as he went. By the end he was struggling to pull it out of a spiral and it sounded awkward. This lead to a conversation with my friend about how it was a recording, and I never needed to hear this cut of the message. You could do it over and over until you got it right and I would be none the wiser. But somehow when we record things we feel like it’s “out there” and we can’t take it back. Or, we make the reverse mistake and do things “live”, resulting in tremendous amounts of resources being spent to redo work that could have been one and done, or really only changes infrequently. In the analog world, or with software. In the middle on the software side are tools in the vein of continuous improvement. There’s that service that will file PRs to fix you dependencies. There should be linters and test fuzzers that do the same in the easy cases. We have tools to scan the assets we already have and try to precompress them better. New ones like this one arrive from time to time. But doing them prior to publication introduces friction and people push back. And once it ships to our servers we erroneously believe it’s too late to change them and I don’t know why. Are we stuck in the old headspace of shrinkwrapped software that you can’t change without enormous difficulty? Or is something else going on?
bscphil 7y ago
Imgur is even more awful on mobile, with its infinitely loading interface. I wrote about a dozen rules for uBlock that try to get rid of everything but the image on Imgur's mobile site, and this seems to help quite a lot. Tends to break the page and require retooling pretty often though.
JyrkiAlakuijala 7y ago
> still only 2.6% reduction of that massive 2.9MiB ... in total. This is unfair argument from my point of view. When we deployed a 30 % improvement for fonts (woff to woff2), people argued that fonts is just a small part of websites. When we deployed a 30 % improvement for PNG-like images in WebP lossless, people argued that they are only a small part of the traffic. When we deployed a 15-30 % improvement for CSS, JS and HTML with Brotli people argued that those are only a small part of the web. When we deploy improvements to video, people argue that 'yes it is a lot of data, but it is buffered so people are not waiting and they care less than for other types of data'. Let's review each technology within its scope.
Someone 7y ago
For a meaningful comparison, you have to divide ¿a large? part of that 3.9 MiB by the number of times it will get reloaded from cache. _If_ users, on average, look at lots of images, that divisor could be large.

Santosh83 7y ago

Yes not so useful for small images but when users view multi-megabyte images then I guess the savings will start to be significant even with the page overhead. Say a 4Mb image can be optimised to 2.5Mb then total download comes down from 6.9Mb to 5.4Mb which is not trivial, especially when the same page has multiple images (some people upload a gallery of images on sites like imgur) or when viewing lots of image URLs. Especially on a limited data plan these small savings will start adding up.

rndgermandude 7y ago
Yes, it would be a win for the users, especially on limited data plans. Though I wouldn't hold my breath for most sites to actually implement it; most sites do not mind serving megabytes of data for a single page view to users, incl megabytes of scripts, even to mobile users. 4MiB to 2.5MiB is out of range for brunsli, more like 3.2MiB if you're lucky. I also tried with a 54 MiB JPEG[1] just now. The brunsli coding is 49MiB so not even a 10% reduction on this particular file. And it took a wallclock time of 16 seconds on my last gen Intel. Decoding it back to JPEG took 11 seconds on the same box. [1] A picture of a wedding cake, taken with a NIKON D810, one of the largest JPEGs I had available. I was "exported" by Lightroom 9 it seems from a NEF/RAW source, and is full of meta data too, around 100KiB of it.
- bscphil 7y ago
  > I also tried with a 54 MiB JPEG[1] just now. The brunsli coding is 49MiB so not even a 10% reduction on this particular file. What about JPEG XL? That's the primary usefulness of brunsli IMO, it's built into JPEG XL as one of the ways it achieves much better compression (comparable to, or possibly better than, AVIF).
  - rndgermandude 7y ago
    Just tried using their latest code. Same 54MiB JPEG yielded (with cjpexl -q x) 3.8 MiB (q=70) 13 MiB (q=90) ("visually lossless (side by side). Default for generic input.") 19 MiB (q=95) ("visually lossless (flicker-test).") 40 MiB (q=100) ("mathematically lossless. Default for already-lossy input (JPEG/GIF)") I'm guessing q=100 is essentially (mostly, minus rounding errors) lossless non-reversible brunsli JPEG-XL. To compare, webp (cwebp -q x, also operating on a q=0...100 scale) 9.9 MiB (q=70) 18 MiB (q=90) 23 MiB (q=95) 28 MiB (q=100) 65 MiB (z=6, medium lossless preset) I didn't do exact timings but JPEG XL was noticeably faster, then again they use multithreaded (using 4 threads here) AVX2 code, which cwebp does not (used the debian provided package for webp), so I wouldn't pay too much attention to this result. Keep in mind JPEG XL isn't finished, and that neither are their defaults and recommendations.
    - bscphil 7y ago
      That does sound very impressive. (Keep in mind, though, that there's no reason to think the q= settings give equivalent quality between JPEG XL and webp.) Also, your lossless encoding was only 40 MiB instead of 49 MiB for pure Brunsli, so presumably JPEG XL is capable of some stronger lossless compression.
      - rndgermandude 7y ago
        Regarding brunsli vs JPEG XL "lossless": yes, JXL fared better there, but then again did not have the requirement of reproducing the bit-exact JPEG back on demand. So (as far as I understood) JPEG XL in q=100 will go back to the pixel data and run the the full JPEG XL coder on it (with no quantization to avoid loss), while JPEG XL in reversible "bg" mode[1]/brunsli will only decode back to the coeffs (so there is no loss at all) and then use their superior lossless (brunsli) coding to store these coeffs more efficiently along with some metadata to allow reconstructing the original file on demand. I could be wrong, I only skimmed the docs and code; when I was quite tired. [1] JXL has a "bg" mode too that is reversible to the original JPEGs, but that's currently not exposed by the cjpegxl tool. But I saw in in their benchmark tool, and there it produced essentially the same size files than plain brunsli tool did, probably because it's essentially just the brunsli tool.

zxcvbn4038 7y ago

I get what your saying but when your storing millions of images and transferring them frequently those small reductions in size are very significant when you get your storage and/or transit bill. A.lot of the fluff and filler you mentioned is cached, so your not bringing it down every request. Even if it wasn’t you can assume it’s deemed becc

rndgermandude 7y ago
You'd think so, but imgur for example is literally in the business of serving images to a lot of users (and some videos, too) and yet they did not even implement the vanilla libjpeg optimized coding it seems. And I am not just picking on imgur, they are just an example for today; other similar services didn't do much better last I checked, neither when it comes to serving optimized JPEGs nor overall page sizes either.
IshKebab 7y ago
I think that's his point - you can already reduce JPEG size a bit by using fancier libraries, but even huge sites like Imgur apparently don't bother.
- jonsneyers 7y ago
  Maybe Imgur doesn't bother, I don't know. I work for Cloudinary, and we do bother. A lot.
taneq 7y ago
The small reductions in image size still pale into insignificance compared with the gains they'd get if they just cut 90% of the crud out of every imgur page load. In the past few years that site has become exponentially more bloated and resource intensive for zero apparent gain (to the users anyway).

hinkley 7y ago

I tried to order some takeout the other day and the place was busy so I got voicemail. The beginning was pretty solid, but as he went on you could tell that he was making it up as he went. By the end he was struggling to pull it out of a spiral and it sounded awkward. This lead to a conversation with my friend about how it was a recording, and I never needed to hear this cut of the message. You could do it over and over until you got it right and I would be none the wiser. But somehow when we record things we feel like it’s “out there” and we can’t take it back. Or, we make the reverse mistake and do things “live”, resulting in tremendous amounts of resources being spent to redo work that could have been one and done, or really only changes infrequently. In the analog world, or with software. In the middle on the software side are tools in the vein of continuous improvement. There’s that service that will file PRs to fix you dependencies. There should be linters and test fuzzers that do the same in the easy cases. We have tools to scan the assets we already have and try to precompress them better. New ones like this one arrive from time to time. But doing them prior to publication introduces friction and people push back. And once it ships to our servers we erroneously believe it’s too late to change them and I don’t know why. Are we stuck in the old headspace of shrinkwrapped software that you can’t change without enormous difficulty? Or is something else going on?

bscphil 7y ago

Imgur is even more awful on mobile, with its infinitely loading interface. I wrote about a dozen rules for uBlock that try to get rid of everything but the image on Imgur's mobile site, and this seems to help quite a lot. Tends to break the page and require retooling pretty often though.

JyrkiAlakuijala 7y ago

> still only 2.6% reduction of that massive 2.9MiB ... in total. This is unfair argument from my point of view. When we deployed a 30 % improvement for fonts (woff to woff2), people argued that fonts is just a small part of websites. When we deployed a 30 % improvement for PNG-like images in WebP lossless, people argued that they are only a small part of the traffic. When we deployed a 15-30 % improvement for CSS, JS and HTML with Brotli people argued that those are only a small part of the web. When we deploy improvements to video, people argue that 'yes it is a lot of data, but it is buffered so people are not waiting and they care less than for other types of data'. Let's review each technology within its scope.

Someone 7y ago

For a meaningful comparison, you have to divide ¿a large? part of that 3.9 MiB by the number of times it will get reloaded from cache. _If_ users, on average, look at lots of images, that divisor could be large.