10 ms·

You can see how unbelievably better this is than JPG (at almost any file size) here: http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&jpg=t&bpg=t htt

You can see how unbelievably better this is than JPG (at almost any file size) here: http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&jpg=t&bpg=t http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&j... Or here: https://bellard.org/bpg/lena.html https://bellard.org/bpg/lena.html The difference between webp from the first link is actually quite small (http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&webp=t&bpg=t http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&w...). Additionally you can find the Javascript decoder here: https://github.com/xingmarc/bpg-decoder https://github.com/xingmarc/bpg-decoder It's 215k of Javascript though so isn't really that practical in most cases and I'd worry about how it was affecting battery life. It'd be very interesting to do some tests and see.

nolok 7y ago
In that link bpg tiny is insanely better at under 25kB than jpeg medium at 42kB. Looks really like this would be great for all the very small pictures and icons on the web.
ape4 7y ago
If I was making a graphics format I'd have one bit in the header for: is_lena. Then I could have very small Lena images /joke
- kevin_thibedeau 7y ago
  Original Lena or the remastered scan?
enriquto 7y ago
This comparison is a bit unfair to JPG. There are many JPG decompression algorithms. The "simplest" one consists in reconstructing the image from the given quantized DCT coefficients. But this is not the only one. Modern decompression methods (such as the one implemented by BPG) find the cleanest possible image that would get compressed to the given JPG file. These decompression algorithms eliminate most blocking artifacts on uniform regions, and that would be a fairer comparison. Nonetheless, the BPG format is a super-incredible hack.
- 0-_-0 7y ago
  That would make a lot of sense for JPEG, I wonder why such deblocking decoders aren't widespread. I've been planning to write an adversarial neural network based JPEG decoder that would find the most realistic possible image that would get compressed to the given JPEG... I would love to have such a decoder integrated into browsers!
  - tambourine_man 7y ago
    Decompression speed is extremely important. How fast would such a implementation be?
    - komali2 7y ago
      Sounds like the exercise would be more for the sake of it rather than trying to develop some widespread new decompression method.
    - 0-_-0 7y ago
      It would be multipass, so it would render ever increasing quality reconstructions, limited by a configurable limit, so that you can limit power consumption on mobile devices.
  - enriquto 7y ago
    > I wonder why such deblocking decoders aren't widespread. There are many, but mostly focused on output quality, and slow, and written in matlab using fancy tools. If somebody submits a simple patch (written in pure C without dependences) to the jpeg reference distribution, and the code is very fast and good enough, it will most surely become mainstream. The thing is, that the people who know enough math to create a good jpeg decompressor do not tend to be well-versed nor interested in C programming.
    - 52-6F-62 7y ago
      I haven't worked with matlab—nor is my math up to that kind of snuff by a long shot— but how hard would it be for an experienced programmer to port it over effectively?
ksec 7y ago
Just a reminder all these comparison were made with very old version of x265. And while x265 as an encoder is quite good, it certainly isn't as mature as x264. There are certainly much better commercial HEVC encoder out there.
- ComputerGuru 7y ago
  > There are certainly much better commercial HEVC encoder out there. The x265 team has repeatedly attempted to refute this claim, but it’s a lot of throwing numbers and lots of mud back and forth between the different implementors. Do you have anything solid to back that statement?
  - ksec 7y ago
    Beamr 5 would be one. [1] But my x265 experience is with pre 2.8. Not sure how much improvement there is in 3.0 and 3.1. My point is not that x265 isn't "good" in absolute terms, it just isn't x264 level insanely good. In AVC era, x264 was absolutely amazing in the details. And just to point out, comparing encoder is hard and depends a lot on materials and target bitrate. [1] https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Owners-Are-Killing-the-Golden-Goose-Over-Royalties-131923.aspx https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Ow...
    - ComputerGuru 7y ago
      Yeah, that’s actually the one I was referring to. The rebuttal to it left me unsure: http://x265.org/beamr-hevc-encoder-comparison/ http://x265.org/beamr-hevc-encoder-comparison/ (it is also from a while ago, before 3.x I believe)
ajross 7y ago
> unbelievably better I don't know that this qualifies as unbelievable. This is just good marketing and spin. The image in that link is exploiting the fact that modern codecs specify upsampling filters, so the HEVC half looks smoothly varying while JPEG can, per spec, only look pixelated when blown up like that. There's absolutely no reason that thing couldn't have shown you a jpeg image rendered with bilinear filtering, which of course is what you'll see if you put that JPEG on a texture and scale it up using the GPU. But it didn't, because it wanted to convince you how much "unbelievably" better HEVC is. Meh. I mean, to be clear: HEVC is absolutely better, to the tune of almost a factor of two in byte size for the same subjective quality. Just not like this. If you've got a site where still images are a significant fraction of your bandwidth budget (and your bandwidth budget is a significant fraction of your budget budget) then this could help you. In practice... static content bandwidth is mostly a solved problem and no one cares, which is why we aren't using BPG.
- deleted 7y ago
  [deleted]
- kevin_thibedeau 7y ago
  Fine detail is still better preserved where JPEG blows it away on low Q settings. A filter can't reconstruct that information.
  - ajross 7y ago
    Probably, but that effect is subtle and not the "OMG THIS IS PIXELATED" nonsense the linked page is showing. I'm not saying BPG isn't better, I'm saying that link is ridiculous and doesn't capture the much more modest gains that it actually offers.
- PaulHoule 7y ago
  A few times I have looked at the possibility of switching from JPEG to another format for photo web sites and every time I have I've come to the conclusion that you can't really win. There are three benefits that one could get from reducing the file size: 1. Reduced storage cost 2. Reduced bandwidth cost 3. Better user experience In my models, storage cost matters a lot. You can't come out ahead here, however, if you still have to keep JPEG copies of all the images. Benefits in terms of 2 are real. Benefits in terms of 3 are hard to realize. Part of it is that adding any more parts to the system will cause problems for somebody somewhere. For instance, you can decompress a new image format with a Javascript polyfill, but is download+decompress really going to be faster for all users? Another problem is that much of the source material is already overcompressed JPEG so simply recompressing it with another format doesn't lead to a really improved experience. When I've done my own trials, and when I've looked closely at other people's trials, I don't see a revolutionary improvement. A scenario that I am interested in now is making desktop backgrounds from (often overcompressed) photos I find on the web. In these cases, JPEG artifacts look like hell when images are blown up, particularly when images have the sharp-cornered bokeh that you get when people take pictures with the kit lens. In that case I can accept a slow and expensive process to blow the image up and make a PNG, something like https://www.mathworks.com/help/images/jpeg-image-deblocking-using-deep-learning.html https://www.mathworks.com/help/images/jpeg-image-deblocking-... or https://github.com/nagadomi/waifu2x https://github.com/nagadomi/waifu2x The other approach I imagine is some kind of maximum entropy approach that minimizes the blocking artifacts.
walrus01 7y ago
That US air force base chapel is in Horizon Zero Dawn!
pornel 7y ago
Codecs with built-in blurring always totally crush in "Tiny" demos. However, these are only good for demos where viewers care about not seeing artifacts, rather than appreciating the content. For realistic scenarios, you can't use compression that makes faces look airbrushed, makes wood and hair look like a plastic imitation, etc. If your designers/marketers/photographers care about "grain" in photos, they'll hate you for applying benchmark-winning aggressive smoothing and deringing. Note that when you switch the benchmark file size to "Medium", the difference is not that big. On "Large" all codecs, except some pathological cases, are nearly identical. And that makes JPEG stay, despite all newer codecs being "unbelievably" better. Everything newer than JPEG can smooth out blocking artifacts, but quality levels useful for still images don't exhibit blocking in the first place.

nolok 7y ago

In that link bpg tiny is insanely better at under 25kB than jpeg medium at 42kB. Looks really like this would be great for all the very small pictures and icons on the web.

ape4 7y ago

If I was making a graphics format I'd have one bit in the header for: is_lena. Then I could have very small Lena images /joke

kevin_thibedeau 7y ago
Original Lena or the remastered scan?

enriquto 7y ago

This comparison is a bit unfair to JPG. There are many JPG decompression algorithms. The "simplest" one consists in reconstructing the image from the given quantized DCT coefficients. But this is not the only one. Modern decompression methods (such as the one implemented by BPG) find the cleanest possible image that would get compressed to the given JPG file. These decompression algorithms eliminate most blocking artifacts on uniform regions, and that would be a fairer comparison. Nonetheless, the BPG format is a super-incredible hack.

0-_-0 7y ago
That would make a lot of sense for JPEG, I wonder why such deblocking decoders aren't widespread. I've been planning to write an adversarial neural network based JPEG decoder that would find the most realistic possible image that would get compressed to the given JPEG... I would love to have such a decoder integrated into browsers!
- tambourine_man 7y ago
  Decompression speed is extremely important. How fast would such a implementation be?
  - komali2 7y ago
    Sounds like the exercise would be more for the sake of it rather than trying to develop some widespread new decompression method.
  - 0-_-0 7y ago
    It would be multipass, so it would render ever increasing quality reconstructions, limited by a configurable limit, so that you can limit power consumption on mobile devices.
- enriquto 7y ago
  > I wonder why such deblocking decoders aren't widespread. There are many, but mostly focused on output quality, and slow, and written in matlab using fancy tools. If somebody submits a simple patch (written in pure C without dependences) to the jpeg reference distribution, and the code is very fast and good enough, it will most surely become mainstream. The thing is, that the people who know enough math to create a good jpeg decompressor do not tend to be well-versed nor interested in C programming.
  - 52-6F-62 7y ago
    I haven't worked with matlab—nor is my math up to that kind of snuff by a long shot— but how hard would it be for an experienced programmer to port it over effectively?

ksec 7y ago

Just a reminder all these comparison were made with very old version of x265. And while x265 as an encoder is quite good, it certainly isn't as mature as x264. There are certainly much better commercial HEVC encoder out there.

ComputerGuru 7y ago
> There are certainly much better commercial HEVC encoder out there. The x265 team has repeatedly attempted to refute this claim, but it’s a lot of throwing numbers and lots of mud back and forth between the different implementors. Do you have anything solid to back that statement?
- ksec 7y ago
  Beamr 5 would be one. [1] But my x265 experience is with pre 2.8. Not sure how much improvement there is in 3.0 and 3.1. My point is not that x265 isn't "good" in absolute terms, it just isn't x264 level insanely good. In AVC era, x264 was absolutely amazing in the details. And just to point out, comparing encoder is hard and depends a lot on materials and target bitrate. [1] https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Owners-Are-Killing-the-Golden-Goose-Over-Royalties-131923.aspx https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Ow...
  - ComputerGuru 7y ago
    Yeah, that’s actually the one I was referring to. The rebuttal to it left me unsure: http://x265.org/beamr-hevc-encoder-comparison/ http://x265.org/beamr-hevc-encoder-comparison/ (it is also from a while ago, before 3.x I believe)

ajross 7y ago

> unbelievably better I don't know that this qualifies as unbelievable. This is just good marketing and spin. The image in that link is exploiting the fact that modern codecs specify upsampling filters, so the HEVC half looks smoothly varying while JPEG can, per spec, only look pixelated when blown up like that. There's absolutely no reason that thing couldn't have shown you a jpeg image rendered with bilinear filtering, which of course is what you'll see if you put that JPEG on a texture and scale it up using the GPU. But it didn't, because it wanted to convince you how much "unbelievably" better HEVC is. Meh. I mean, to be clear: HEVC is absolutely better, to the tune of almost a factor of two in byte size for the same subjective quality. Just not like this. If you've got a site where still images are a significant fraction of your bandwidth budget (and your bandwidth budget is a significant fraction of your budget budget) then this could help you. In practice... static content bandwidth is mostly a solved problem and no one cares, which is why we aren't using BPG.

deleted 7y ago
[deleted]
kevin_thibedeau 7y ago
Fine detail is still better preserved where JPEG blows it away on low Q settings. A filter can't reconstruct that information.
- ajross 7y ago
  Probably, but that effect is subtle and not the "OMG THIS IS PIXELATED" nonsense the linked page is showing. I'm not saying BPG isn't better, I'm saying that link is ridiculous and doesn't capture the much more modest gains that it actually offers.
PaulHoule 7y ago
A few times I have looked at the possibility of switching from JPEG to another format for photo web sites and every time I have I've come to the conclusion that you can't really win. There are three benefits that one could get from reducing the file size: 1. Reduced storage cost 2. Reduced bandwidth cost 3. Better user experience In my models, storage cost matters a lot. You can't come out ahead here, however, if you still have to keep JPEG copies of all the images. Benefits in terms of 2 are real. Benefits in terms of 3 are hard to realize. Part of it is that adding any more parts to the system will cause problems for somebody somewhere. For instance, you can decompress a new image format with a Javascript polyfill, but is download+decompress really going to be faster for all users? Another problem is that much of the source material is already overcompressed JPEG so simply recompressing it with another format doesn't lead to a really improved experience. When I've done my own trials, and when I've looked closely at other people's trials, I don't see a revolutionary improvement. A scenario that I am interested in now is making desktop backgrounds from (often overcompressed) photos I find on the web. In these cases, JPEG artifacts look like hell when images are blown up, particularly when images have the sharp-cornered bokeh that you get when people take pictures with the kit lens. In that case I can accept a slow and expensive process to blow the image up and make a PNG, something like https://www.mathworks.com/help/images/jpeg-image-deblocking-using-deep-learning.html https://www.mathworks.com/help/images/jpeg-image-deblocking-... or https://github.com/nagadomi/waifu2x https://github.com/nagadomi/waifu2x The other approach I imagine is some kind of maximum entropy approach that minimizes the blocking artifacts.

walrus01 7y ago

That US air force base chapel is in Horizon Zero Dawn!

pornel 7y ago

Codecs with built-in blurring always totally crush in "Tiny" demos. However, these are only good for demos where viewers care about not seeing artifacts, rather than appreciating the content. For realistic scenarios, you can't use compression that makes faces look airbrushed, makes wood and hair look like a plastic imitation, etc. If your designers/marketers/photographers care about "grain" in photos, they'll hate you for applying benchmark-winning aggressive smoothing and deringing. Note that when you switch the benchmark file size to "Medium", the difference is not that big. On "Large" all codecs, except some pathological cases, are nearly identical. And that makes JPEG stay, despite all newer codecs being "unbelievably" better. Everything newer than JPEG can smooth out blocking artifacts, but quality levels useful for still images don't exhibit blocking in the first place.