9 ms·

BPG Image Comparison

357 points by rayshan 12y ago

ogig 12y ago
Compare original vs BPG in the soccer picture, then look at the green strip on the shirt of the red team player and slide over it. It's magical how perfectly the compresion make the red dots disappear.
- viraptor 12y ago
  Another great one is the Irish Mannequinn. I thought BPG blows up the edges, because every other format smoothed them out. But no, when you compare to the original, all the interesting edges (hair, hanging fabric, top of the lips) should be very visible. I really like the results!
  - k__ 12y ago
    Yes, it seems like BPG is smarter in finding interesting parts of the image.
- lucio 12y ago
  JP2K-Medium seems to preserve a resemblance of the dots
  - lstamour 12y ago
    Yep, I really liked the look/size tradeoff of JPEG 2000. It's too bad it hasn't caught on, particularly for cameras as an alternative to JPEG.
- hellgas00 12y ago
  If you look at the Air Force Academy Chapel, the horizontal window bracing are almost completely eliminated when comparing BPG and the Original.
- ot 12y ago
  That looks like an aggressive chroma subsampling/quantization. Image encoders must allocate the bitrate among the channels, luma (Y), and chroma (Cb, Cr). Most of the time it is better to allocate most of the bitrate to the luma, because that's what the eye is most sensitive to. However it can create artifacts like this.
- Alphasite_ 12y ago
  The issue I had was with how the cheeks lost their colour, when compared with JPEG.
Scaevolus 12y ago
previously: https://news.ycombinator.com/item?id=8735572 https://news.ycombinator.com/item?id=8735572 BPG context: https://news.ycombinator.com/item?id=8704629 https://news.ycombinator.com/item?id=8704629
corysama 12y ago
If an American company incorporated Bellard's reference decoder into a commercial product that is distributed in binary form to clients, would that company need to license the HVEC patents to avoid being sued by an HVEC patent holder?
- pdq 12y ago
  Almost certainly yes, you would need to license the many patents covered in H.265 and H.264. However if you look at the history of JPEG and MP3, which were also encumbered with patents, the public domain basically won due to the sheer number of violations being too large to take down or even force licensing. It will be interesting to see if any product (ie browser) actually puts any of these algorithms in their codebase.
- masklinn 12y ago
  Yes. Part of the idea seems to mostly be that if you have HVEC support via the OS or licensing, you get BGP support without any additional legal hassles.
bhouston 12y ago
Seems to give screwed up results for the BPG in Google Chrome Dev: Version 41.0.2243.0 dev-m (64-bit) But works in my copy of Firefox.
- azakai 12y ago
  Same results here too - corrupted in Chrome 41, works ok in Firefox. Filed a bug: https://code.google.com/p/chromium/issues/detail?id=442599 https://code.google.com/p/chromium/issues/detail?id=442599
  - lstamour 12y ago
    And as reported in the above bug, fixed 5 days ago. We're living in the almost bleeding edge here ;-) https://code.google.com/p/chromium/issues/detail?id=439743 https://code.google.com/p/chromium/issues/detail?id=439743
PythonicAlpha 12y ago
Fruits: Mozjpg medium is still worse as BPG and is nearly double the size, it leaves a lot artifacts in the cloudy areas. Found it very convincing. I think the results depend a little on the kind of input, but some of the pictures where rather convincing. WebP seems to do better than jpeg.
- kevingadd 12y ago
  A key observation is that WebP biases towards smoothness (which certainly produces pleasing images!) at the cost of sacrificing detail. mozjpeg produces images with numerous macroblocking artifacts (ick) that seem to preserve more of the original image detail, from the cases I looked at.
codexon 12y ago
I think the big question is whether people can put BPG pictures online without getting sued. edit Why am I being downvoted for saying this? Do the people downvoting me realize that BPG is using HEVC which is patented by many entities?
- georgemcbay 12y ago
  Not sure what the score looks like for your post, but this is certainly the big question for me too considering that one of the primary factors in the terrible stagnation of widely used media formats (which has consequences as terrible as people commonly and unironically using GIFs -- fuckin GIFS!!!! to share "videos") has been serious patent concerns associated with most new contenders.
- wtallis 12y ago
  How could distribution of the encoded images be infringing a patent? It's the distribution and possibly use of the encoders and decoders that would be within the scope of patent law, not the output itself. The encoded image isn't the invention. If I own a patented 3d printer, would you be worried that those patents could restrict my ability to distribute the objects printed by it? The javascript decoder would certainly be covered by the patents as much as any other decoder, so it doesn't solve the patent-related barriers to adoption even if it takes care of the practical issues with using the format.
  - codexon 12y ago
    Err, because MPEG-LA and the other patent holders that didn't join knows that Fabrice Bellard didn't license the patent from them, so you used an unlicensed encoder. If you stick that poly-fill on your website they can also sue you for distributing the decoder to everyone that downloaded the javascript file.
    - reubenmorais 12y ago
      IANAL, and this might be a simple case of letter vs. spirit, but my understanding was that shipping the decoder's source is allowed, so with a JS implementation you're theoretically safe. This was one of the arguments around Broadway, the JS H.264 decoder.
chipsy 12y ago
The "Production" picture [0] is quite challenging for all encoders. The original has fine details like text that are smoothed out of existence even in the "Large" profiles - though to its credit BPG preserves more of it than the others. (Also, relative to other high-detail pictures this one has an unusually low filesize.) [0] http://xooyoozoo.github.io/yolo-octo-bugfixes/#production&bpg=l&png=s http://xooyoozoo.github.io/yolo-octo-bugfixes/#production&bp...
skrowl 12y ago
Yay! Another new image thing for 1 browser to support and the rest to need polyfills for!
- callahad 12y ago
  Check the discussion from 11 days ago. I think your concerns are misplaced. BPG ships a polyfill... and it works. That's what you're seeing live on the parent page. Previous discussion: https://news.ycombinator.com/item?id=8704629 https://news.ycombinator.com/item?id=8704629
randerson 12y ago
Subjectively, the best overall trade-off between quality and file size seems to be BPG Large. Great comparison.
tambourine_man 12y ago
Jaws dropped. Maybe having the option of adding 1-2% of luminance noise after decompression to disguise the plastic feel would make it look even better. It would look a bit different every time you load the image, though. I would love to be able to use this today.
- anyfoo 12y ago
  Must not necessarily look different: use a PRNG with a fixed seed, possibly as part of the image itself. Since there's nothing cryptorelevant here, the PRNG can be a simple one and its exact parameters specified as part of the standard.
- mark-r 12y ago
  I find BPG isn't nearly as plastic as WebP in this comparison.
- Scaevolus 12y ago
  The x265 encoder might not have Psy-RDO enabled --http://x264dev.multimedia.cx/archives/37 http://x264dev.multimedia.cx/archives/37 It penalizes "loss of detail" like that, biasing towards (inaccurate) noise over (accurate on average) absolute pixel values (PSNR).
simonsarris 12y ago
When I clicked it I thought this was supposed to be a test damning BPG somehow, but I get the impression from other comments that I am NOT supposed to see this: http://i.imgur.com/XDXOB2w.jpg http://i.imgur.com/XDXOB2w.jpg All the other image formats work fine. Any idea why? Windows Chrome 41.0.2243.0 dev-m (64-bit)
- lstamour 12y ago
  I see it too. Identical version: 41.0.2243.0 dev-m (64-bit) and also on Windows. I see it here as well: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html which explains "The BPG images are decoded in your browser with a small Javascript decoder." You can find more on the format at: http://bellard.org/bpg/ http://bellard.org/bpg/ Someone filed a bug today: https://code.google.com/p/chromium/issues/detail?id=442599 https://code.google.com/p/chromium/issues/detail?id=442599 Fixed in Canary 5 days ago: https://code.google.com/p/chromium/issues/detail?id=439743 https://code.google.com/p/chromium/issues/detail?id=439743
  - swasheck 12y ago
    OT ... but I find Canary to be much more usable and stable than Dev.
- akx 12y ago
  I get the same bug, and I find it pretty attractive, really, from a glitch art standpoint... Too bad it's apparently already fixed in Chrome :)
nl 12y ago
I wasn't aware, but BPG is a Fabrice Bellard[1] project. Bellard is possibly the best example I'm aware of the 100x programmer. [1] http://blog.smartbear.com/careers/fabrice-bellard-portrait-of-a-super-productive-programmer/ http://blog.smartbear.com/careers/fabrice-bellard-portrait-o... [2] A subset of things he started: LZEXE, FFMpeg, QEMU. He's also held the record for the calculation of the largest known prime and the most digits of Pi, wrote the first x86 emulator in JS that could boot Linux, won the International Obfuscated C Contest, etc etc.
- sillysaurus3 12y ago
  I'm concerned that highlighting his accomplishments every time one of his projects comes up gives the wrong impression to the newer programmers reading the site, or even to experienced programmers. You, reader, can be a Bellard. There's nothing "special" about what Bellard has done, in the sense of it being beyond your abilities. You just have to believe in yourself, along with having a willingness to work hard most days. But working hard is easy when you find an interesting problem. Bellard is able to do so much because knowledge is like compound interest: The more you know, the more you can learn. Bellard has been saving up for a long time. Competition is sometimes motivational, and if you insist on looking at it like a competition, then realize that every day Bellard devotes to relaxation is a day you can catch up to where he's at. Competition is what motivated me, when I first started. And once you realize there's nothing magical about what they know, you realize you can sprint very hard towards where they're at, which is exciting. But once you start down that path, competitive spirit tends to transcend into something else entirely. You stop comparing yourself to others. You focus on putting one foot in front of the other, taking the next logical step towards your goal. Repeat for N days, and suddenly people are highlighting the projects you've done. But what's your goal? Well, that's up to you. So pursue your interests! You can do it.
  - WildUtah 12y ago
    I agree. The classic talk on this subject is Richard Hamming's "You and Your Research." [0] I think there may be video online. [0] http://www.cs.virginia.edu/~robins/YouAndYourResearch.html http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
tedd4u 12y ago
It's interesting to see the comparison at a fixed output size. It would also be interesting to see a comparison at a) fixed encoding time, b) fixed decoding time.
pdkl95 12y ago
Very nice compression! As others have mentioned, BPG seems to be a bit better at picking which details to save. It's an improvement over mozjpg - even at "tiny" size, the usual (and annoying) "JPEG/MPEG-style block noise" seems to be eliminated. (no offense intended to mozjpeg, which is working from an old spec) -- Speaking of image formats, it might be nice to have a new format where the container is designed to only allow a minimum of features. Something like a file with only [MagicNum, xsize, ysize, xdpi, ydpi, gamma, <compressed pixels>, CRC32]. The idea is that it should NOT support "metadata" like comments or EXIF. As we've seen, there is a problem with getting most people to understand that they should probably strip EXIF/etc before uploading, and having a format where we could say "only upload .foo pictures" instead of "run $tool to strip EXIF". A browser plugin could even auto-convert every image while uploading. Unfortunately, it would face the same problem as any new image format: nobody wants to use a new format until it is already popular.
steadicat 12y ago
BPG does a much better job at smaller sizes: its artifacts are way less jarring than JPEG’s (they just look like smudges). However, to my eye, Large is the only acceptable quality level on these examples, and at Large the difference between JPEG and BPG looks almost imperceptible. Considering the cost of polyfilling, I would stick with JPEG.
- sigmar 12y ago
  I have to strongly disagree. For several of the images there are artifacts and noise in the large JPEG that looked much better in a medium BPG (which are about 60% the size of the JPEG). Also, saying "Large is the only acceptable quality level," means that you are only considering only a very narrow use-case
- jacobolus 12y ago
  > However, to my eye, Large is the only acceptable quality level on these examples, and at Large the difference between JPEG and BPG looks almost imperceptible. I feel we must be looking at different examples, or must have very different definitions of “imperceptible”. I find that there is a very substantial difference in high frequency detail between mozjpeg and BPG in nearly all of these examples at the 'large' size, as well as many images where mozjpeg produces highly objectionable artifacts even at the 'large' size and BPG does not. Speaking for myself, I would prefer to use a higher quality setting than any of the ones demonstrated even with BPG for most of my personal purposes. For my typical use cases, the 'large' BPG versions of most of these images are at the edge of acceptable quality, and every one of the other compressed versions falls far short of acceptable.† Many other people have use cases where precise image replication isn’t as important though, and at every size BPG seems like a dramatic step up over the competition. One thing I hope gets worked out before this goes mainstream is color management / color profile support. In Safari on my Mac there are several images where the rendered BPG image is obviously not correctly applying the image’s color profile. † Kakadu’s JPEG2000 encoder and WebP at that 'large' size also seem noticeably better than mozjpeg, but they still seem to wipe more high frequency detail and produce more artifacts – especially edge artifacts – than BPG. On some images packed with very high contrast fine detail (e.g. Vallée de Colca), WebP performance and BPG performance seems pretty similar and a bit better than Kakadu; in general compression is hard in these cases so the “large” size ends up being pretty large.
rasz_pl 12y ago
opera 15: [16/12/2014 06:25:05] JavaScript - http://xooyoozoo.github.io/yolo-octo-bugfixes/ http://xooyoozoo.github.io/yolo-octo-bugfixes/ Inline script thread Uncaught exception: TypeError: Cannot convert 'file' to object Error thrown at line 5, column 4 in <anonymous function>() in http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2.js http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2...: for (i = 0; i < file.length; i++) called from line 1, column 0 in http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2.js http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2...: (function() {
frontsideair 12y ago
Maybe Bellard is reading these comments. I made a very unpopular remark about his use of Lena.jpg and while I believe it's mostly coincidence, he used an imageset without Lena.jpg. If you're reading, Bellard, hi!
- akie 12y ago
  Ignore the haters - I read your comment and upvoted it. It is everyday sexism and role-confirming behavior, and it is off-putting to women and making them feel unwelcome. But I think people are not aware of it and mean no harm, which is why it's good you pointed it out. I do think some people can only relate to the argument when you propose to replace Lena with a seductively pretty half-naked (gay?) man, though.
  - Houshalter 12y ago
    Some people use the Fabio test image: http://4.bp.blogspot.com/-jUHXZ0jW4Lc/T1t3W0ex2BI/AAAAAAAAFeY/7TY0cTty1og/s400/Fabio.jpg http://4.bp.blogspot.com/-jUHXZ0jW4Lc/T1t3W0ex2BI/AAAAAAAAFe... I don't see the problem with using either one and think the controversy is ridiculous.
  - polshaw 12y ago
    More relevantly, it is a good test image. It's a woman with a bare shoulder! Nobody would have a problem with it if it were an attractive man in that image instead (sexuality irrelevant).
    - akie 12y ago
      Ok, so would you be comfortable if this http://imgur.com/coB85tW http://imgur.com/coB85tW was the standard test image then?
      - polshaw 12y ago
        Yes. Although there is a lot more going on in the original that justifies its use as a test image; varying levels of subtlety of detail (the two parts of the top of the hat, DoF, and especially the feathers or whatever you call it) as well as the human in it. original being referenced: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html
citrin_ru 12y ago
Is anybody has comparison of original image and one decoded from BPG with highlighted difference? E. g. using Imagemagick's compare command. It is interesting in which areas BPG differ from original.
mda 12y ago
Do you think the difference (especially for medium and large versions) is worth using a patent encumbered format?
jmspring 12y ago
This conversation showed up a couple of weeks ago... Any new "image compression format" isn't going to gain widespread traction unless is can displace JPEG in terms of hardware support and ubiquity in cameras. I was part of the JPEG-2000 support. The company I was with at the time had technology around how blocks were encoded (it gave up block independence at the benefit of 20+% encoding efficiency -- downside would be an intermediary step to reconstruct the JPEG steam). None of those solutions took off. Explain to me how beyond a hobbyist market BPG will make a splash?
- jacobolus 12y ago
  It’ll make a splash if (0) the legal issues are sufficiently sorted out so that adopters don’t feel threatened using the format (1) the polyfill works everywhere, as it seems to, without too substantial a slowdown, (2) it saves enough bandwidth that major websites start sending BPG instead of JPG to at least some web clients, (3) one or more major browsers decide to build in native support, and maybe an extra boost (4) it manages to support use cases that other formats don’t handle well (e.g. photographic/naturalistic images with full alpha channel) and carves out a niche as the main format for those particular types of images. I can imagine Safari and IE building support for this format entirely as a counter to Google’s WebP, since they already need support for HEVC as a matter of course. Many current websites send very heavily compressed JPEG images to save bandwidth, and just live with the big hit to image quality. If they had a similar-filesize alternative that they could use for some or all clients that didn’t degrade image quality, and still was guaranteed to work smoothly, it’s plausible they might adopt it.
  - jmspring 12y ago
    Who is going to re-encode their images en masse? Content companies? Photo sites?
    - jacobolus 12y ago
      It doesn’t need to be done by anyone en masse. It can easily be phased in gradually.
Kiro 12y ago
I want to see a comparison with a normal JPG picture.
- tempestn 12y ago
  You can compare between JPG and BPG by choosing "Mozjpeg" on one side and "BPG-x265" on the other. There are many pictures to choose from. Or did I misunderstand your question?
chernoby 12y ago
bpg is definitely better for tiny pictures
comex 12y ago
Note that the decoder is 68K compressed. That's not much, and of course can be cached, but considering that the improvement (from WebP, anyway) seems to be most notable for the <50K images, it may not be terribly practical... Considering that the page says it's based on a Daala comparison page, it would be interesting to stick a Daala snapshot in the mix for comparison using the same images (reencoding to PNG like it does for WebP, I'm not suggesting porting Daala to emscripten). A quick browse of the original page shows Daala sometimes beating x265, sometimes losing to it, but I guess both x265 and the Daala {encoder, codec} may have been improved in the last six months.
wolf550e 12y ago
Why does the comparison use x265 instead of the reference HEVC encoder? Fabrice Bellard recommends that as it produces better quality encodes at the expense of CPU time. I'm interested in seeing the result of using 4:4:4 with BPG. If you have the originals to compress, of course (meaning, the original is not chroma subsampled).
- xooyoozoo 12y ago
  He either made his judgement based on non-obvious criteria or, more likely, looked at x265 at the "wrong" moment. Right before libbpg was announced, x265 had several commits fixing large 10bit and 422/444 bugs. As far as intra-prediction goes, x265 should be better than the HM by at least a few percents MSE-wise and around 10% SSIM-wise[0]. [0] https://github.com/strukturag/libde265/wiki/Intra-Prediction-Mode-Algorithm https://github.com/strukturag/libde265/wiki/Intra-Prediction...
  - wolf550e 12y ago
    Integration with that library would be great too. Thanks for the link!
koliber 12y ago
I just wanted to point out, that BGP in "tiny" mode changes the image quality in a way that is strangely reminiscent of film. A lot of details get blurred out, but in a pleasant way.
deleted 12y ago
[deleted]
z-e-r-o 12y ago
It's interesting how bad mozjpeg looks compared to classic jpeg compression tools like jpegoptim, given how many blogs have been writing about Mozilla creating the "ultimate" jpeg encoder. Comparing it with jpegoptim reveals that at the small-medium-large sizes mozjpeg produces a result with more visual artefacts. wget http://xooyoozoo.github.io/yolo-octo-bugfixes/comparisonfiles/Original/Ricardo_Quaresma-L-,_Pablo_Zabaleta-R-Portugal_vs._Argentina,_9th_February_2011.png -O src.png convert src.png -quality 100 -sampling-factor 1x1 full.jpg jpegoptim -s full.jpg -S85 --stdout > s85.jpg jpegoptim -s full.jpg -S50 --stdout > s50.jpg jpegoptim -s full.jpg -S30 --stdout > s30.jpg jpegoptim -s full.jpg -S18 --stdout > s18.jpg
- sp332 12y ago
  How are the file sizes?
  - z-e-r-o 12y ago
    Exactly 18-30-50-85 kB if you use the -S syntax.
    - sp332 12y ago
      Whoops, I assumed that was an arbitrary "quailty" setting. Thanks
- deleted 12y ago
  [deleted]
turbolent 12y ago
Impressive. What are the differences for decoding/load time? Especially on mobile devices this is a big deciding factor.
Zardoz84 12y ago
I would love see how does with scanned documents for preservation ... for example : - http://www.digibis.com/digibib-demo/i18n/catalogo_imagenes/grupo.cmd?path=1000009&interno=S&presentacion=pagina&posicion=1 http://www.digibis.com/digibib-demo/i18n/catalogo_imagenes/g... - http://www.digibis.com/digibib-demo/cartografia/es/catalogo_imagenes/grupo.cmd?texto_busqueda=&path=1000114&interno=S&presentacion=pagina&posicion=1 http://www.digibis.com/digibib-demo/cartografia/es/catalogo_...
kmfrk 12y ago
Makes me happy that the JS method used doesn't require me to do the same <picture> <source> and provide multiple formats to support older browsers.
deleted 12y ago
[deleted]

357 points by rayshan 12y ago

ogig 12y ago

Compare original vs BPG in the soccer picture, then look at the green strip on the shirt of the red team player and slide over it. It's magical how perfectly the compresion make the red dots disappear.

viraptor 12y ago
Another great one is the Irish Mannequinn. I thought BPG blows up the edges, because every other format smoothed them out. But no, when you compare to the original, all the interesting edges (hair, hanging fabric, top of the lips) should be very visible. I really like the results!
- k__ 12y ago
  Yes, it seems like BPG is smarter in finding interesting parts of the image.
lucio 12y ago
JP2K-Medium seems to preserve a resemblance of the dots
- lstamour 12y ago
  Yep, I really liked the look/size tradeoff of JPEG 2000. It's too bad it hasn't caught on, particularly for cameras as an alternative to JPEG.
hellgas00 12y ago
If you look at the Air Force Academy Chapel, the horizontal window bracing are almost completely eliminated when comparing BPG and the Original.
ot 12y ago
That looks like an aggressive chroma subsampling/quantization. Image encoders must allocate the bitrate among the channels, luma (Y), and chroma (Cb, Cr). Most of the time it is better to allocate most of the bitrate to the luma, because that's what the eye is most sensitive to. However it can create artifacts like this.
Alphasite_ 12y ago
The issue I had was with how the cheeks lost their colour, when compared with JPEG.

Scaevolus 12y ago

previously: https://news.ycombinator.com/item?id=8735572 https://news.ycombinator.com/item?id=8735572 BPG context: https://news.ycombinator.com/item?id=8704629 https://news.ycombinator.com/item?id=8704629

corysama 12y ago

If an American company incorporated Bellard's reference decoder into a commercial product that is distributed in binary form to clients, would that company need to license the HVEC patents to avoid being sued by an HVEC patent holder?

pdq 12y ago
Almost certainly yes, you would need to license the many patents covered in H.265 and H.264. However if you look at the history of JPEG and MP3, which were also encumbered with patents, the public domain basically won due to the sheer number of violations being too large to take down or even force licensing. It will be interesting to see if any product (ie browser) actually puts any of these algorithms in their codebase.
masklinn 12y ago
Yes. Part of the idea seems to mostly be that if you have HVEC support via the OS or licensing, you get BGP support without any additional legal hassles.

bhouston 12y ago

Seems to give screwed up results for the BPG in Google Chrome Dev: Version 41.0.2243.0 dev-m (64-bit) But works in my copy of Firefox.

azakai 12y ago
Same results here too - corrupted in Chrome 41, works ok in Firefox. Filed a bug: https://code.google.com/p/chromium/issues/detail?id=442599 https://code.google.com/p/chromium/issues/detail?id=442599
- lstamour 12y ago
  And as reported in the above bug, fixed 5 days ago. We're living in the almost bleeding edge here ;-) https://code.google.com/p/chromium/issues/detail?id=439743 https://code.google.com/p/chromium/issues/detail?id=439743

PythonicAlpha 12y ago

Fruits: Mozjpg medium is still worse as BPG and is nearly double the size, it leaves a lot artifacts in the cloudy areas. Found it very convincing. I think the results depend a little on the kind of input, but some of the pictures where rather convincing. WebP seems to do better than jpeg.

kevingadd 12y ago
A key observation is that WebP biases towards smoothness (which certainly produces pleasing images!) at the cost of sacrificing detail. mozjpeg produces images with numerous macroblocking artifacts (ick) that seem to preserve more of the original image detail, from the cases I looked at.

codexon 12y ago

I think the big question is whether people can put BPG pictures online without getting sued. edit Why am I being downvoted for saying this? Do the people downvoting me realize that BPG is using HEVC which is patented by many entities?

georgemcbay 12y ago
Not sure what the score looks like for your post, but this is certainly the big question for me too considering that one of the primary factors in the terrible stagnation of widely used media formats (which has consequences as terrible as people commonly and unironically using GIFs -- fuckin GIFS!!!! to share "videos") has been serious patent concerns associated with most new contenders.
wtallis 12y ago
How could distribution of the encoded images be infringing a patent? It's the distribution and possibly use of the encoders and decoders that would be within the scope of patent law, not the output itself. The encoded image isn't the invention. If I own a patented 3d printer, would you be worried that those patents could restrict my ability to distribute the objects printed by it? The javascript decoder would certainly be covered by the patents as much as any other decoder, so it doesn't solve the patent-related barriers to adoption even if it takes care of the practical issues with using the format.
- codexon 12y ago
  Err, because MPEG-LA and the other patent holders that didn't join knows that Fabrice Bellard didn't license the patent from them, so you used an unlicensed encoder. If you stick that poly-fill on your website they can also sue you for distributing the decoder to everyone that downloaded the javascript file.
  - reubenmorais 12y ago
    IANAL, and this might be a simple case of letter vs. spirit, but my understanding was that shipping the decoder's source is allowed, so with a JS implementation you're theoretically safe. This was one of the arguments around Broadway, the JS H.264 decoder.

chipsy 12y ago

The "Production" picture [0] is quite challenging for all encoders. The original has fine details like text that are smoothed out of existence even in the "Large" profiles - though to its credit BPG preserves more of it than the others. (Also, relative to other high-detail pictures this one has an unusually low filesize.) [0] http://xooyoozoo.github.io/yolo-octo-bugfixes/#production&bpg=l&png=s http://xooyoozoo.github.io/yolo-octo-bugfixes/#production&bp...

skrowl 12y ago

Yay! Another new image thing for 1 browser to support and the rest to need polyfills for!

callahad 12y ago
Check the discussion from 11 days ago. I think your concerns are misplaced. BPG ships a polyfill... and it works. That's what you're seeing live on the parent page. Previous discussion: https://news.ycombinator.com/item?id=8704629 https://news.ycombinator.com/item?id=8704629

randerson 12y ago

Subjectively, the best overall trade-off between quality and file size seems to be BPG Large. Great comparison.

tambourine_man 12y ago

Jaws dropped. Maybe having the option of adding 1-2% of luminance noise after decompression to disguise the plastic feel would make it look even better. It would look a bit different every time you load the image, though. I would love to be able to use this today.

anyfoo 12y ago
Must not necessarily look different: use a PRNG with a fixed seed, possibly as part of the image itself. Since there's nothing cryptorelevant here, the PRNG can be a simple one and its exact parameters specified as part of the standard.
mark-r 12y ago
I find BPG isn't nearly as plastic as WebP in this comparison.
Scaevolus 12y ago
The x265 encoder might not have Psy-RDO enabled --http://x264dev.multimedia.cx/archives/37 http://x264dev.multimedia.cx/archives/37 It penalizes "loss of detail" like that, biasing towards (inaccurate) noise over (accurate on average) absolute pixel values (PSNR).

simonsarris 12y ago

When I clicked it I thought this was supposed to be a test damning BPG somehow, but I get the impression from other comments that I am NOT supposed to see this: http://i.imgur.com/XDXOB2w.jpg http://i.imgur.com/XDXOB2w.jpg All the other image formats work fine. Any idea why? Windows Chrome 41.0.2243.0 dev-m (64-bit)

lstamour 12y ago
I see it too. Identical version: 41.0.2243.0 dev-m (64-bit) and also on Windows. I see it here as well: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html which explains "The BPG images are decoded in your browser with a small Javascript decoder." You can find more on the format at: http://bellard.org/bpg/ http://bellard.org/bpg/ Someone filed a bug today: https://code.google.com/p/chromium/issues/detail?id=442599 https://code.google.com/p/chromium/issues/detail?id=442599 Fixed in Canary 5 days ago: https://code.google.com/p/chromium/issues/detail?id=439743 https://code.google.com/p/chromium/issues/detail?id=439743
- swasheck 12y ago
  OT ... but I find Canary to be much more usable and stable than Dev.
akx 12y ago
I get the same bug, and I find it pretty attractive, really, from a glitch art standpoint... Too bad it's apparently already fixed in Chrome :)

nl 12y ago

I wasn't aware, but BPG is a Fabrice Bellard[1] project. Bellard is possibly the best example I'm aware of the 100x programmer. [1] http://blog.smartbear.com/careers/fabrice-bellard-portrait-of-a-super-productive-programmer/ http://blog.smartbear.com/careers/fabrice-bellard-portrait-o... [2] A subset of things he started: LZEXE, FFMpeg, QEMU. He's also held the record for the calculation of the largest known prime and the most digits of Pi, wrote the first x86 emulator in JS that could boot Linux, won the International Obfuscated C Contest, etc etc.

sillysaurus3 12y ago
I'm concerned that highlighting his accomplishments every time one of his projects comes up gives the wrong impression to the newer programmers reading the site, or even to experienced programmers. You, reader, can be a Bellard. There's nothing "special" about what Bellard has done, in the sense of it being beyond your abilities. You just have to believe in yourself, along with having a willingness to work hard most days. But working hard is easy when you find an interesting problem. Bellard is able to do so much because knowledge is like compound interest: The more you know, the more you can learn. Bellard has been saving up for a long time. Competition is sometimes motivational, and if you insist on looking at it like a competition, then realize that every day Bellard devotes to relaxation is a day you can catch up to where he's at. Competition is what motivated me, when I first started. And once you realize there's nothing magical about what they know, you realize you can sprint very hard towards where they're at, which is exciting. But once you start down that path, competitive spirit tends to transcend into something else entirely. You stop comparing yourself to others. You focus on putting one foot in front of the other, taking the next logical step towards your goal. Repeat for N days, and suddenly people are highlighting the projects you've done. But what's your goal? Well, that's up to you. So pursue your interests! You can do it.
- WildUtah 12y ago
  I agree. The classic talk on this subject is Richard Hamming's "You and Your Research." [0] I think there may be video online. [0] http://www.cs.virginia.edu/~robins/YouAndYourResearch.html http://www.cs.virginia.edu/~robins/YouAndYourResearch.html

tedd4u 12y ago

It's interesting to see the comparison at a fixed output size. It would also be interesting to see a comparison at a) fixed encoding time, b) fixed decoding time.

pdkl95 12y ago

Very nice compression! As others have mentioned, BPG seems to be a bit better at picking which details to save. It's an improvement over mozjpg - even at "tiny" size, the usual (and annoying) "JPEG/MPEG-style block noise" seems to be eliminated. (no offense intended to mozjpeg, which is working from an old spec) -- Speaking of image formats, it might be nice to have a new format where the container is designed to only allow a minimum of features. Something like a file with only [MagicNum, xsize, ysize, xdpi, ydpi, gamma, <compressed pixels>, CRC32]. The idea is that it should NOT support "metadata" like comments or EXIF. As we've seen, there is a problem with getting most people to understand that they should probably strip EXIF/etc before uploading, and having a format where we could say "only upload .foo pictures" instead of "run $tool to strip EXIF". A browser plugin could even auto-convert every image while uploading. Unfortunately, it would face the same problem as any new image format: nobody wants to use a new format until it is already popular.

steadicat 12y ago

BPG does a much better job at smaller sizes: its artifacts are way less jarring than JPEG’s (they just look like smudges). However, to my eye, Large is the only acceptable quality level on these examples, and at Large the difference between JPEG and BPG looks almost imperceptible. Considering the cost of polyfilling, I would stick with JPEG.

sigmar 12y ago
I have to strongly disagree. For several of the images there are artifacts and noise in the large JPEG that looked much better in a medium BPG (which are about 60% the size of the JPEG). Also, saying "Large is the only acceptable quality level," means that you are only considering only a very narrow use-case
jacobolus 12y ago
> However, to my eye, Large is the only acceptable quality level on these examples, and at Large the difference between JPEG and BPG looks almost imperceptible. I feel we must be looking at different examples, or must have very different definitions of “imperceptible”. I find that there is a very substantial difference in high frequency detail between mozjpeg and BPG in nearly all of these examples at the 'large' size, as well as many images where mozjpeg produces highly objectionable artifacts even at the 'large' size and BPG does not. Speaking for myself, I would prefer to use a higher quality setting than any of the ones demonstrated even with BPG for most of my personal purposes. For my typical use cases, the 'large' BPG versions of most of these images are at the edge of acceptable quality, and every one of the other compressed versions falls far short of acceptable.† Many other people have use cases where precise image replication isn’t as important though, and at every size BPG seems like a dramatic step up over the competition. One thing I hope gets worked out before this goes mainstream is color management / color profile support. In Safari on my Mac there are several images where the rendered BPG image is obviously not correctly applying the image’s color profile. † Kakadu’s JPEG2000 encoder and WebP at that 'large' size also seem noticeably better than mozjpeg, but they still seem to wipe more high frequency detail and produce more artifacts – especially edge artifacts – than BPG. On some images packed with very high contrast fine detail (e.g. Vallée de Colca), WebP performance and BPG performance seems pretty similar and a bit better than Kakadu; in general compression is hard in these cases so the “large” size ends up being pretty large.

rasz_pl 12y ago

opera 15: [16/12/2014 06:25:05] JavaScript - http://xooyoozoo.github.io/yolo-octo-bugfixes/ http://xooyoozoo.github.io/yolo-octo-bugfixes/ Inline script thread Uncaught exception: TypeError: Cannot convert 'file' to object Error thrown at line 5, column 4 in <anonymous function>() in http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2.js http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2...: for (i = 0; i < file.length; i++) called from line 1, column 0 in http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2.js http://xooyoozoo.github.io/yolo-octo-bugfixes/js/splitimage2...: (function() {

frontsideair 12y ago

Maybe Bellard is reading these comments. I made a very unpopular remark about his use of Lena.jpg and while I believe it's mostly coincidence, he used an imageset without Lena.jpg. If you're reading, Bellard, hi!

akie 12y ago
Ignore the haters - I read your comment and upvoted it. It is everyday sexism and role-confirming behavior, and it is off-putting to women and making them feel unwelcome. But I think people are not aware of it and mean no harm, which is why it's good you pointed it out. I do think some people can only relate to the argument when you propose to replace Lena with a seductively pretty half-naked (gay?) man, though.
- Houshalter 12y ago
  Some people use the Fabio test image: http://4.bp.blogspot.com/-jUHXZ0jW4Lc/T1t3W0ex2BI/AAAAAAAAFeY/7TY0cTty1og/s400/Fabio.jpg http://4.bp.blogspot.com/-jUHXZ0jW4Lc/T1t3W0ex2BI/AAAAAAAAFe... I don't see the problem with using either one and think the controversy is ridiculous.
- polshaw 12y ago
  More relevantly, it is a good test image. It's a woman with a bare shoulder! Nobody would have a problem with it if it were an attractive man in that image instead (sexuality irrelevant).
  - akie 12y ago
    Ok, so would you be comfortable if this http://imgur.com/coB85tW http://imgur.com/coB85tW was the standard test image then?
    - polshaw 12y ago
      Yes. Although there is a lot more going on in the original that justifies its use as a test image; varying levels of subtlety of detail (the two parts of the top of the hat, DoF, and especially the feathers or whatever you call it) as well as the human in it. original being referenced: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html

citrin_ru 12y ago

Is anybody has comparison of original image and one decoded from BPG with highlighted difference? E. g. using Imagemagick's compare command. It is interesting in which areas BPG differ from original.

mda 12y ago

Do you think the difference (especially for medium and large versions) is worth using a patent encumbered format?

jmspring 12y ago

This conversation showed up a couple of weeks ago... Any new "image compression format" isn't going to gain widespread traction unless is can displace JPEG in terms of hardware support and ubiquity in cameras. I was part of the JPEG-2000 support. The company I was with at the time had technology around how blocks were encoded (it gave up block independence at the benefit of 20+% encoding efficiency -- downside would be an intermediary step to reconstruct the JPEG steam). None of those solutions took off. Explain to me how beyond a hobbyist market BPG will make a splash?

jacobolus 12y ago
It’ll make a splash if (0) the legal issues are sufficiently sorted out so that adopters don’t feel threatened using the format (1) the polyfill works everywhere, as it seems to, without too substantial a slowdown, (2) it saves enough bandwidth that major websites start sending BPG instead of JPG to at least some web clients, (3) one or more major browsers decide to build in native support, and maybe an extra boost (4) it manages to support use cases that other formats don’t handle well (e.g. photographic/naturalistic images with full alpha channel) and carves out a niche as the main format for those particular types of images. I can imagine Safari and IE building support for this format entirely as a counter to Google’s WebP, since they already need support for HEVC as a matter of course. Many current websites send very heavily compressed JPEG images to save bandwidth, and just live with the big hit to image quality. If they had a similar-filesize alternative that they could use for some or all clients that didn’t degrade image quality, and still was guaranteed to work smoothly, it’s plausible they might adopt it.
- jmspring 12y ago
  Who is going to re-encode their images en masse? Content companies? Photo sites?
  - jacobolus 12y ago
    It doesn’t need to be done by anyone en masse. It can easily be phased in gradually.

Kiro 12y ago

I want to see a comparison with a normal JPG picture.

tempestn 12y ago
You can compare between JPG and BPG by choosing "Mozjpeg" on one side and "BPG-x265" on the other. There are many pictures to choose from. Or did I misunderstand your question?

chernoby 12y ago

bpg is definitely better for tiny pictures

comex 12y ago

Note that the decoder is 68K compressed. That's not much, and of course can be cached, but considering that the improvement (from WebP, anyway) seems to be most notable for the <50K images, it may not be terribly practical... Considering that the page says it's based on a Daala comparison page, it would be interesting to stick a Daala snapshot in the mix for comparison using the same images (reencoding to PNG like it does for WebP, I'm not suggesting porting Daala to emscripten). A quick browse of the original page shows Daala sometimes beating x265, sometimes losing to it, but I guess both x265 and the Daala {encoder, codec} may have been improved in the last six months.

wolf550e 12y ago

Why does the comparison use x265 instead of the reference HEVC encoder? Fabrice Bellard recommends that as it produces better quality encodes at the expense of CPU time. I'm interested in seeing the result of using 4:4:4 with BPG. If you have the originals to compress, of course (meaning, the original is not chroma subsampled).

xooyoozoo 12y ago
He either made his judgement based on non-obvious criteria or, more likely, looked at x265 at the "wrong" moment. Right before libbpg was announced, x265 had several commits fixing large 10bit and 422/444 bugs. As far as intra-prediction goes, x265 should be better than the HM by at least a few percents MSE-wise and around 10% SSIM-wise[0]. [0] https://github.com/strukturag/libde265/wiki/Intra-Prediction-Mode-Algorithm https://github.com/strukturag/libde265/wiki/Intra-Prediction...
- wolf550e 12y ago
  Integration with that library would be great too. Thanks for the link!

koliber 12y ago

I just wanted to point out, that BGP in "tiny" mode changes the image quality in a way that is strangely reminiscent of film. A lot of details get blurred out, but in a pleasant way.

deleted 12y ago

[deleted]

z-e-r-o 12y ago

It's interesting how bad mozjpeg looks compared to classic jpeg compression tools like jpegoptim, given how many blogs have been writing about Mozilla creating the "ultimate" jpeg encoder. Comparing it with jpegoptim reveals that at the small-medium-large sizes mozjpeg produces a result with more visual artefacts. wget http://xooyoozoo.github.io/yolo-octo-bugfixes/comparisonfiles/Original/Ricardo_Quaresma-L-,_Pablo_Zabaleta-R-Portugal_vs._Argentina,_9th_February_2011.png -O src.png convert src.png -quality 100 -sampling-factor 1x1 full.jpg jpegoptim -s full.jpg -S85 --stdout > s85.jpg jpegoptim -s full.jpg -S50 --stdout > s50.jpg jpegoptim -s full.jpg -S30 --stdout > s30.jpg jpegoptim -s full.jpg -S18 --stdout > s18.jpg

sp332 12y ago
How are the file sizes?
- z-e-r-o 12y ago
  Exactly 18-30-50-85 kB if you use the -S syntax.
  - sp332 12y ago
    Whoops, I assumed that was an arbitrary "quailty" setting. Thanks
deleted 12y ago
[deleted]

turbolent 12y ago

Impressive. What are the differences for decoding/load time? Especially on mobile devices this is a big deciding factor.

Zardoz84 12y ago

I would love see how does with scanned documents for preservation ... for example : - http://www.digibis.com/digibib-demo/i18n/catalogo_imagenes/grupo.cmd?path=1000009&interno=S&presentacion=pagina&posicion=1 http://www.digibis.com/digibib-demo/i18n/catalogo_imagenes/g... - http://www.digibis.com/digibib-demo/cartografia/es/catalogo_imagenes/grupo.cmd?texto_busqueda=&path=1000114&interno=S&presentacion=pagina&posicion=1 http://www.digibis.com/digibib-demo/cartografia/es/catalogo_...

kmfrk 12y ago

Makes me happy that the JS method used doesn't require me to do the same <picture> <source> and provide multiple formats to support older browsers.

deleted 12y ago

[deleted]