The big story here is this introduces a new image file format without requiring you to upgrade a browser or download a plugin. Those aren't PNGs of representative images you're looking at - that's BPG decoding happening in your browser.
So we don't like HVEC due to patent worries? Fine, we can swap in another format and use the same technique.
We don't have an I-frame format for Daala that's finalized yet? Fine, we can use work-in-progress. The format does not need to be finalized. If you update it, you rebuild your images and bundle a new JavaScript decoder.
The ability to ship media along with a sandboxed, runnable decoder is awesome, and I'm surprised it hasn't caught on until now. I remember Google a while back implemented their own "video" codec in JavaScript using JPEGs and primitive inter-frame processing, exactly because there wasn't a universal video codec format they could use.
Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? If it downloads them itself, then any parallel fetching by browsers will stop working. And if they are decoded by javascript, they will take (very slightly) longer, and both the encoded and decoded images need to be held in memory both in javascript, and the browser. Are they decoded to .bmp, .jpg, .png? Can CSS reference them without javascript changing the styles? Can they be cached locally if downloaded directly?
If you needed this for any page that loaded lots of images, all of the above would significantly increase page-load time, and memory usage. Especially on a mobile browser, it would use more resources (hence more battery), than otherwise. So personally I wouldn't like to see this be the future. Maybe just as a fall back, but detection for that might be a little hard.
If you want Designers to start using this, then we need a photoshop plugin, an illustrator plugin, a Sketch plugin, a pixelmator plugin. Make it easier for us to export images as a .BGP. If the images are truly smaller without affecting the current user experience of users using mostly modern web browsers, then we're more likely to pick up on using this.
Isn't there hardware support for JPEG decoding on most mobile devices?
If so, I imagine it couldn't compete performance and battery life wise.
I remember Mozilla did a software video decoder once in JavaScript.
I was ready to pass by this post with a yawn until I saw where it was coming from: Fabrice Bellard. He's no doubt an absolute freakin' genius. And if anybody knows about image conversion, it's him.
Even the things he does just for fun are impressive. Have you ever booted up Linux inside your browser? http://bellard.org/jslinux/
EDIT: I didn't expect this comment to be so popular and feel like I've hijacked the thread a little - sorry. Feel free to continue at https://news.ycombinator.com/item?id=8706850
I would much rather someone revived the Fractal Image format, which is now out of patent. It's very expensive to encode, but that's nowhere near as big a problem as it used to be. It's very fast to decode, very small, and the files are resolution independent: http://en.wikipedia.org/wiki/Fractal_compression
I was blown away when I encountered it at PC Magazine in the 90s and it seems like it would be very responsive to the needs of today's web.
I'd like to see a modern implementation and some unbiased testing done before I got too excited. From what I could tell, the tech got more hype than was justified by its ability to perform, and I suspect the fact that it still isn't in much use may have more to do with difficult being better at anything in particular than a current existing solution rather than a lack of people interested in it.
(And note my phrasing of "got more hype than was justified by its ability to perform"... it isn't that it has no ability, just that it got more hype than it should have. Same thing happened to "wavelets". Yes, I know about JPEG2000... again, the point isn't that they are "bad" or "can't work" but that they got more hype than their real performance justified.)
After making a few needed tweaks to get libbpg to compile on Mac OS X, I used the compiled bpgenc binary to convert a test PNG to BPG format. I also converted the PNG to a JPEG for comparison purposes. You can see the results here:
Looking at the Lena pictures demo, the extremely low file size comparison at the top shows just how good .bpg is in that use case. That could make for some much lighter websites when used for less important items like image thumbnails on shopping sites, for example.
When the file size gets larger at the end, it looks like there might be a little loss of detail. Ideally I'd like to compare them by switching back and forth using the original image and the .bpg as Photoshop layers...
I notice the container has no ICC profile support. Trivial do add as an extension tag, but should definitely be in the first spec IMO. And if I read this correctly, extension tags are hardcoded as numbers, rather than using a tag name. I don't think that's a good idea.
The BPG spec says, "Arbitrary meta data (such as EXIF) are supported." This isn't good enough. Modern formats need to specify how ICC profile format information is to be embedded, under what circumstances, and smaller space alternatives (similar to DCF and EXIF color space tags). Otherwise this is like JFIF, where it's the ICC spec and not the JFIF spec that describes how ICC profiles are to be embedded. To replace JPEG and PNG, the BPG spec needs to define such things itself rather than deferring the work to others or making it optional. Image color space data isn't optional if high quality is to be taken seriously, and for that matter the encoding of copyright and image provenance information needs to be defined in the spec also.
Is there a situation where 14-bit sRGB isn't enough? There are a lot of weird color matching issues on the web caused by inconsistent application of ICC profiles to PNG images by different browsers / platforms.
No doubt Fabrice is very smart. I read about his 4G base station the other day. I'd love to be a fly on the wall while he codes and thinks out these projects.
His accomplishments are impressive: QEMU, FFMPEG, TCC, JSLinux, the list goes on
I have been wishing there was a JPEG equivalent with an alpha channel for like forever. That allows better compositing to arbitrary background images or patterns. Now the question is how long before browsers might support it natively.
Its purpose is to replace the JPEG image format when quality or file size is an issue.
Some of the HEVC algorithms may be protected by patents in some countries
There have been some patent disputes over JPEG, but I don't think replacing it with another possibly patented format is a good idea, even if it's technically superior in some ways.
Why not use Daala to start from? The overlapping transform probably help especially for still images, and the patent situation is probably at least better.
This definitely looks like it compares favourably against both JPEG and PNG. The test doesn't directly compare against JPEG-2000, JPEG XR or WebP, but the results are more convincing than any examples I've seen for any other formats, and the Mozilla study showed HEVC's format did best on quality metrics.
I hope browser vendors take note. The patent issues are concerning, but if that can be worked around and a new spec designed, then we might just actually have a new image format for the web which really is better than what we've already got.
I'm not qualified to comment on BPG, but this is the first I've heard of Mr. Bellard. I enjoy reading works from minds of this caliber. He seems to be a model citizen for the programming community. Are there others I should know about like Fabrice?
So can anyone talk about the patent issues? I hear there are multiple holders of HVEC patents and they are willing to use them. So if you use this library, wouldn't you be liable?
I'd really like to know that. Because I'd really like to use this.
I've tried it with a picture of mine. The encoding process was painfully slow, but I guess that does not concern the end-user much. The file size went from 1.2M in jepg to 164K in bpg, and the decoding was fairly fast. After turning the image back into PNG the quality seemed OK but that's tough to assess objectively.
The coolest thing is this javascript program that can decode and display the pictures on-the-fly.
Definitely an image format that could save storage space and bandwith, IMHO.
I wouldn't be in such a hurry - right now x265 (as far as I know the best HEVC encoder) still loses to x264 in terms of practical use (you only really get better results by using bitrates so low that the end product will look terrible anyway, and x265 loses hard to x264 quality-wise when encoding at similar bitrate and speed). Considering that x264 is backed by about a decade's worth of development, this isn't that surprising.
There are still patent issues, and you still need to obtain a license to use the software. You will never see this image format integrated into any other open source projects, like Firefox, for this reason.
1. Why a Subset of HEVC Still Picture Profile? Why not just a use HEVC Picture instead?
2. Since JS sources are readable and being interpreted by VM ( Free Speech ), patents issues should not be a problem?
3. I am assuming the quality of BGP still has Lots and Lots improvement to be made? Since all H.265 encoder hasn't had the time to be tuned. ( Compared to x264 )
I guess the JS is just for proof of concept until support is shipped with browsers etc, but it isn't rendering properly in the stock Android browser (4.2.2).
It gets to Lena's head in the first image, then becomes brigtly multi-coloured, though it looks like the difference between colours right... as if maybe an int overflow in the browser's JS implementation?
That's far from indistinguishable to me. It's actually quite obvious that the BPG is blurring detail at that compression ratio.
Edit: it's particularly noticeable in the wood grain patterns. Also, there's a soft grey dot to the left of the top of the lamp, 100px or so, that's entirely missing in the BPG. There are loads more examples...
Edit again: the color saturation of the rug is pretty washed-out as well.
I would guess, that decoding speed can become an issue for websites, where many images are already in the cache but are re-displayed rather often...
I write this, because I am building such an application and for now it has many PNGs ... and yes, using a format like BPG would be fine, because I use the PNGs only because of transparency ... but when redisplay is done via a Java Script, I doubt that I could have the same speed. Loading is not so much a limiting factor, since after some time, all relevant PNGs are already in the browser cache.
Can anybody say something to this topic?
Of course, it would be great to have this integrated into the mayor browsers soon ...
[+] [-] pslam|11 years ago|reply
So we don't like HVEC due to patent worries? Fine, we can swap in another format and use the same technique.
We don't have an I-frame format for Daala that's finalized yet? Fine, we can use work-in-progress. The format does not need to be finalized. If you update it, you rebuild your images and bundle a new JavaScript decoder.
The ability to ship media along with a sandboxed, runnable decoder is awesome, and I'm surprised it hasn't caught on until now. I remember Google a while back implemented their own "video" codec in JavaScript using JPEGs and primitive inter-frame processing, exactly because there wasn't a universal video codec format they could use.
[+] [-] keeperofdakeys|11 years ago|reply
If you needed this for any page that loaded lots of images, all of the above would significantly increase page-load time, and memory usage. Especially on a mobile browser, it would use more resources (hence more battery), than otherwise. So personally I wouldn't like to see this be the future. Maybe just as a fall back, but detection for that might be a little hard.
[+] [-] wmf|11 years ago|reply
[+] [-] akshatpradhan|11 years ago|reply
[+] [-] tambourine_man|11 years ago|reply
Still, it is quite amazing.
[+] [-] sillysaurus3|11 years ago|reply
If only the rightclick menu could be customized by JS. Adding only a limited number of entries to the menu seems like it'd be okay.
[+] [-] billyhoffman|11 years ago|reply
Google Animated doodle with JPEG and opacity
http://zoompf.com/blog/2012/04/how-do-google-animated-doodle...
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] mark-r|11 years ago|reply
Even the things he does just for fun are impressive. Have you ever booted up Linux inside your browser? http://bellard.org/jslinux/
[+] [-] pervycreeper|11 years ago|reply
Would this have been less interesting or valuable if it hadn't been made by a hacker celebrity?
[+] [-] higherpurpose|11 years ago|reply
> Based on a subset of the HEVC open video compression standard.
So BPG is patent-encumbered, right?
[+] [-] jokoon|11 years ago|reply
[+] [-] tambourine_man|11 years ago|reply
Having alpha channel support, 14 bits and better compression would be lovely.
[+] [-] simonebrunozzi|11 years ago|reply
[+] [-] joubert|11 years ago|reply
[+] [-] anigbrowl|11 years ago|reply
I would much rather someone revived the Fractal Image format, which is now out of patent. It's very expensive to encode, but that's nowhere near as big a problem as it used to be. It's very fast to decode, very small, and the files are resolution independent: http://en.wikipedia.org/wiki/Fractal_compression
I was blown away when I encountered it at PC Magazine in the 90s and it seems like it would be very responsive to the needs of today's web.
[+] [-] jerf|11 years ago|reply
(And note my phrasing of "got more hype than was justified by its ability to perform"... it isn't that it has no ability, just that it got more hype than it should have. Same thing happened to "wavelets". Yes, I know about JPEG2000... again, the point isn't that they are "bad" or "can't work" but that they got more hype than their real performance justified.)
[+] [-] kibwen|11 years ago|reply
[+] [-] TD-Linux|11 years ago|reply
Unfortunately I can't find a free PDF at the moment.
[+] [-] tachyonbeam|11 years ago|reply
http://pointersgonewild.com/2014/01/02/tile-based-image-comp...
[+] [-] bane|11 years ago|reply
They have a 6-minute figure on their page. I wonder what modern hardware could do with it? Anybody care to give it a whirl?
[+] [-] spot|11 years ago|reply
[+] [-] lbotos|11 years ago|reply
[+] [-] justinmayer|11 years ago|reply
http://justinmayer.com/bpg-test/
Size of PNG before conversion: 186K
Size after conversion to JPEG: 52K
Size after conversion to BPG: 9K
I took the liberty of submitting a Homebrew formula, so hopefully this will soon be a quick "brew install libbpg" away. (^_^)
https://github.com/Homebrew/homebrew/pull/34722
[+] [-] ChrisGranger|11 years ago|reply
When the file size gets larger at the end, it looks like there might be a little loss of detail. Ideally I'd like to compare them by switching back and forth using the original image and the .bpg as Photoshop layers...
[+] [-] pdknsk|11 years ago|reply
[+] [-] cmurf|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
[+] [-] justinmayer|11 years ago|reply
[+] [-] panic|11 years ago|reply
[+] [-] jason_slack|11 years ago|reply
His accomplishments are impressive: QEMU, FFMPEG, TCC, JSLinux, the list goes on
[+] [-] ChuckMcM|11 years ago|reply
I have been wishing there was a JPEG equivalent with an alpha channel for like forever. That allows better compositing to arbitrary background images or patterns. Now the question is how long before browsers might support it natively.
[+] [-] jason_slack|11 years ago|reply
Does anyone know if he has a day job or does he just lock himself away and work on these interesting projects?
[+] [-] paraboul|11 years ago|reply
[+] [-] userbinator|11 years ago|reply
Some of the HEVC algorithms may be protected by patents in some countries
There have been some patent disputes over JPEG, but I don't think replacing it with another possibly patented format is a good idea, even if it's technically superior in some ways.
[+] [-] 1ris|11 years ago|reply
[+] [-] AshleysBrain|11 years ago|reply
I hope browser vendors take note. The patent issues are concerning, but if that can be worked around and a new spec designed, then we might just actually have a new image format for the web which really is better than what we've already got.
[+] [-] tericho|11 years ago|reply
[+] [-] GhotiFish|11 years ago|reply
I'd really like to know that. Because I'd really like to use this.
[+] [-] grondilu|11 years ago|reply
The coolest thing is this javascript program that can decode and display the pictures on-the-fly.
Definitely an image format that could save storage space and bandwith, IMHO.
[+] [-] sp332|11 years ago|reply
[+] [-] WhitneyLand|11 years ago|reply
[+] [-] Daiz|11 years ago|reply
[+] [-] TD-Linux|11 years ago|reply
[+] [-] cjensen|11 years ago|reply
[1] http://x265.org
[+] [-] ksec|11 years ago|reply
1. Why a Subset of HEVC Still Picture Profile? Why not just a use HEVC Picture instead?
2. Since JS sources are readable and being interpreted by VM ( Free Speech ), patents issues should not be a problem?
3. I am assuming the quality of BGP still has Lots and Lots improvement to be made? Since all H.265 encoder hasn't had the time to be tuned. ( Compared to x264 )
[+] [-] hyp0|11 years ago|reply
It gets to Lena's head in the first image, then becomes brigtly multi-coloured, though it looks like the difference between colours right... as if maybe an int overflow in the browser's JS implementation?
[+] [-] asah|11 years ago|reply
186,967 ==> 29,872 and indistinguishable, 6.25:1
(and pls tell me if it breaks on your browser - I want to push this live!!!)
adam
[+] [-] ChrisGranger|11 years ago|reply
Edit: it's particularly noticeable in the wood grain patterns. Also, there's a soft grey dot to the left of the top of the lamp, 100px or so, that's entirely missing in the BPG. There are loads more examples...
Edit again: the color saturation of the rug is pretty washed-out as well.
[+] [-] PythonicAlpha|11 years ago|reply
I write this, because I am building such an application and for now it has many PNGs ... and yes, using a format like BPG would be fine, because I use the PNGs only because of transparency ... but when redisplay is done via a Java Script, I doubt that I could have the same speed. Loading is not so much a limiting factor, since after some time, all relevant PNGs are already in the browser cache.
Can anybody say something to this topic?
Of course, it would be great to have this integrated into the mayor browsers soon ...