Slashdot Mirror
Bellard Creates New Image Format To Replace JPEG
An anonymous reader writes Fabrice Bellard (creator of FFMPEG, QEMU, JSLinux...) proposes a new image format that could replace JPEG : BPG. For the same quality, files are about half the size of their JPEG equivalents. He released libbpg (with source) as well as a JS decompressor, and set up a demo including the famous Lena image.
So I go to google to see this android studio 1.0 and my DL does not match the website DL sha-1 nor the filesize. Google says
android-studio-bundle-135.1629389.exe
(Recommended) 852499624 bytes 0c8a3b45385a698b43a47757fdd6a83ca837abd2
and I get
852,385,152 wrongsize_android-studio-bundle-135.1629389.exe
852,385,152 stillwrongsize_android-studio-bundle-135.1629389.exe
852,385,152 android-studio-bundle-135.1629389.exe
2f073a0bab9d644add78c45cc4e289b3e72bd647
Different browsers. Google signed this but did not sign the smaller (92 MB!) web installer for windows, so that's no good, either. C'mon!
one more format to explain to everyone, grandma and bosses, and argue and waste time about which format to use or support.
Why can't they just fix the damn JPEG and make it half the size instead??
And first comment maybe.
This will go over about as well.
...when even after 40 years it still flies to use a Playboy centerfold cropout as a standard test image in serious work :) And yes, the new format looks great.
GIFs and EPS files should be good enough for everyone!
Unlike JPEG, whose patent, if they exist, are too old and unenforced, HEVEC is riddled with new patents and all
associated problems.
Besides, file size for still images is not a big issue, even for embedded devices.
And how does it compare ti JPEG 2000 and JPEG XR? And all the other JPEG alternatives that have been trumpeted but never taken hold? And why should this succeed when those have failed?
1/2 the size of jpg for equivalent quality. I'm sold.
As soon as Photoshop and Firefox/Chrome start supporting it I can see widespread adoption.
The below site offers a better comparison interface than the Lena image link from the post. Drag your mouse across the image to see the effect:
http://xooyoozoo.github.io/yol...
Naming something "Better X" results in the names like "Better than Better than X", "Even Better X" or "Best X." Just. Stop.
"Better Portable Graphics" sounds completely unprofessional, so I don't think it will be taken seriously until he picks a new name.
I suggest "Bellard Portable Graphics" because it keeps the BPG initialism and tips the hat to its creator.
Are the possible patents protection mentioned on bellard.org a limit for potential native browser support?
From the web site "BPG natively supports 8 to 14 bits per channel," which is a huge advantage. 8 bits is more of a straight-jacket than people realise and this offers a more portable way for people to pass around high bit-depth issues than camera raw files (proprietary things inside) or TIFF (a complex container format prone to cross-platform issues and poor compression).
Note that, according to the BPG web site, "An alpha channel is supported" so BPG has transparency.
How are we going to pronounce this thing? "Bee-Peg" I suppose since "Bee-Pee-Gee" doesn't roll off the tongue.
Looks good.
Barney Stinson settled the pronunciation many years ago on How I Met Your Mother: it's "bee-peg". Although this format probably won't be used exclusively for pictures of boobs.
The main issue that is going to hold back adoption is the use of HEVC/H.265 as compression codec. While dedicated hardware is not needed to decompress the images in a timely manner, it also means that no licensing fees have been paid to the MPEG LA. Since the format is patent encumbered, I can't see this taking off unless the patent pool decides to give out a royalty free license for still images. Bellard himself assumes that most hardware will come with said codec licensed and built in but that does not include old hardware or even current hardware that is not being shipped with it. Barely anything ships with H.265 support other than the iPhone 6 and a couple of Mediatek SoCs.
I want this, but have a few random thoughts on this.
It appears that the Javascript decoder is emscripten based - this means it can still be optimized. BPG library works but I'd rather see native browser support for this, as it will make more efficient use of the processor (for slower systems or a poor raspberry pi, this matters).
TL;DR - I want this in my camera. I want support in my favourite image editor. I want native browser support. Once the whole chain is catered for, this has a chance.
Looking at the Lena comparison, there's really no difference in size between JPEG and BPG. Quality seems better at lower resolution though.
I don't think we should compare BPG with JPEG, since it is very outdated. I wonder how it stacks against WebP - does it also support animation? Better compression? Licenses? Faster encoding/decoding? Browser manufacturer support? I'm all for making web more optimal, because you can never have "fast-enough" bandwidth, especially on a mobile device in bad connection area, but lets compare similar things.
Doing some investigation, the claim that the BPG decoder is "small" might not be exactly true. The decoder, even minified, clocks in at 237 kB.
Although this is mitigated since the decoder could be cached in the browser cache, making it so that the decoder could be downloaded just once - at least just once per session. And once per web site, of course, because everyone is going to host their own copy of it. (I imagine at least... would same-origin policy be a problem if you tried to keep it somewhere central/standard?)
Anyone deploying this would be advised to consider if the space savings outweigh that initial cost in space. Then again, it all depends on what you want to acheive. What if you just have a huge archive of seldom-accessed images and want to save on disk space rather than on network bandwidth? Might make sense to store the images as BPG server-side and do decompression server-side if you can take the CPU hit.
Well, not exclusively. Not quite.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
So he's just slapped a wrapper around a patent-encumbered HEVC?
Yeah. No thanks.
Looks great. So does WebP. Unfortunately patents and licenses look to invade this one also making it doubtless unviable to some. Microsoft will complain because the decode/encode is optionally LGPL, and not include. Mozilla will probably have patent issues over the H.265 bits. Apple will simply ignore, for reasons of its own. Photoshop will not ship out of the box with support, requiring a third party plug in, and most other image editors will simply not support it.
One thing it does have over the others is creation by a slightly more neutral source. WebP seemed to be purely hampered by the "Google" tag. Microsoft's Jpeg enhancements by MS. Apple is now probably too scary and loosing the "cool" factor to change ecosystems (like it managed with streaming video).
I really hope some people get together and solve the political hurdles required to make this format a goer...
I was hoping for the complete Lena. When the image popped up, in the 1970s, sure that the larger parts of the image were cut off for indecency.
But in 2014, I think this is no topic any longer.
A new coding algorithm could as well have come with a new perspective on morals.
And given us something NSFW, to look at in the workplace!
Note that, according to the BPG web site, "An alpha channel is supported" so BPG has transparency.
Now, that should have been the headline instead of saving a few poxy KB.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Hans Reiser wouldn't have had to kill nina Reiser if it were.
Men could marry pretty young female children if it were
(allowed in the Old Testament (Deuteronomy 22 28-29))
Feminists would also probably be killed if it were.
The problem here is that H.265 and by extension BPG are heavily patent-encumbered. These are not just latent patents but patents that the H.265 contributors are using for a revenue stream.
Bellard suggests "just use the licensed hardware decoder you probably already have" but a) that doesn't make technical sense in lots of cases and b) most people don't, in fact, have such a thing currently and c) the encoding situation is even worse.
Were it a headline, it wouldn't distinguish it from WebP which got alpha channel in 2012, and is lossy format.
It is a glorified subset of HEVC (Main 4:4:4 16 Still Picture Profile, Level 8.5).
(And this is good, because HEVC has okayish hardware support.)
This guy always reminds me of Belloq from Raiders. Just a shade into the shadows from our heroes!
Why is there no mention of Portable Network Graphics in this discussion? .png has an alpha channel, has broad support, and uses *lossless* compression. What's not to like? It does not compress as tightly as highly compressed .jpg, but as several have pointed out, that's not as big an issue any more.
So am I missing something? Or is it just some kind of marketing thing that .png does not see much use?
Will
My main problem with the name is that every time I see "BPG" I just mentally autocorrect it to "BGP" and then end up somewhat confused.
24bit PNGs compress much worse. It really is an issue for the web, images form the majority of the payload for most websites, and whilst people on /. might be use to several Mb/s broadband the reality is many people don't have that. Even in the UK mobile speeds are very low outside of cities. And when you compare evena jpg at fairly high quality to a 24bit PNG there's no practical difference visually so there's just no reason to clog up the web with PNGs. Obviously I'm just referring to photos - PNGs are great for logos/icons/etc.
PNG is used extensively in Apple products. It's the standard format for non-compressed images in iOS apps, along with jpg for compressed images. Apple recommends using png for user interface elements, and jpg for pictures. Which makes sense, since jpg can compress a picture to 20% of the size with very few artifacts. Size does matter for mobile apps. And I wish people would realize that it matters for servers, too. Yes, available bandwidth is enormous these days. But if your server is serving pages that are twice the size and your audience is large, you're going to need a bigger server room and use considerably more energy. Servers are on their way to becoming the biggest power hogs on the planet. Smaller images mean less hard disks and less data pipes.
Say what you want about GIF, it is still alive. It still lives on
Will the BPG format be as versatile as GIF?
...demonstrate new format superior for compressing those images - news at 11!
Seriously, wtf has happened to geek thoroughness?
Why is there no mention of Portable Network Graphics in this discussion? .png has an alpha channel, has broad support, and uses *lossless* compression. What's not to like? It does not compress as tightly as highly compressed .jpg, but as several have pointed out, that's not as big an issue any more.
So am I missing something? Or is it just some kind of marketing thing that .png does not see much use?
Generally I use png when I need transparency on logos and the like, for everything else I use jpg. If this bpg is good and gets in I can use a single format, which would make things, oh I dunno, 5% easier. Arguably I could just use only png but for some reason I don't, too much converting I guess. Adding another format doesn't really do anything but it's a slow morning so might as well chime in.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Although the comparison pages posted in this thread (this is an awesome one https://xooyoozoo.github.io/yo... ) are fun and interesting, they compare the bit efficiency of the two algorithms. That is important yes. But that isn't how these formats are used: when bandwidth is an issue (and it is to web site authors, be they individuals or companies, no matter what anyone on this thread says to the contrary), compression is increased to the threshold of perceptibility, or a little beyond. That is, the provider will increase compression until artifacts are just barely noticeable.
So, the more pertinent question, in terms of image quality, is how the two algorithms compare for equal levels of error, both in number of bits, and also in subjective image quality.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Considering the number of images we push through the internet, a "retina"-resolution JPEG is still a factor of ten smaller than a PNG. Since many mobile plans have data caps, and many more are still forced to drop to EDGE speeds due to spotty coverage, it does play a role. Those that argue that image size does not play a role have not seen now average surfers have little to no tolerance for delays. Even speeding up the load time from three seconds to under a second is very important.
A PNG is still used a lot, though, due to its support of alpha channels. But that means they tend to be used where they can be cached. It has more or less replaced the venerable GIF for those areas where a SVG cannot (yet) be used. The old rule of thumb of choosing JPEG for photographic images and PNG for more solid colours still applies.
The really important thing is porn industry's support.
And here I thought I was the only one with that problem, fortunately the people at NOCs and Web designers/ content management people don't often interact so cases of confusion will be cept low.
Looks good. Better compression and better looks. ...
How performance intensive is the decompression/decoding? If that's in the green area, I see no reason not to adopt it.
Let's adopt it.
Would need some marketing though. Flashy logo and a pronounceable name. How about "Bepog"?
We suffer more in our imagination than in reality. - Seneca
In this industry, there's no such thing as a "replacement," it's "just another competing format." None of the old formats ever dies, all we ever get is more new formats, all of which need to be supported, ultimately making everything more complicated. I'm not saying we shouldn't advance... but the belief that some new format you create will replace something instead of muddying the existing pool of formats is laughable. related xdcd. (yes, I know it's "standards" and not "formats," but the result is the same)
Stupid sexy Flanders.
Hey look. The marketing guy showed up!
I guess FFMPEG ( eff eff emm peg ), and VLC (vee ell sea) have issues with their names, right?
Hard Drives these days are huge. When I had my first HD (40 MB, I forget the model), this would have been incredible. I remember, I was a 286 box and I felt so cool. I was stepping up from a Tandy 1000 Tl and from a Zenith "laptop" from that. Now I have some 6T in my rig and much more home server. 1/2 the size? Like I care.
Finally! someone in this thread that speaks some sense!
Side note: I am not interested in adopting anything that is powered by JS. This just seems absolutely lazy and retarded. (as is his JSlinux!)
Isn't there an algrithm to enlarge those? ;-)
The first question to come to my mind is who has the patents on this animal, and how long will it be before the lawsuits begin? They'll probably wait until the new format is firmly established on the Internet before springing the "gotcha" on folks.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
On my site (http://thedecibelkid.com) which is relatively image-heavy I like the idea of INCREASING the image quality while using the SAME bandwidth.
If you don't risk failure you don't risk success.
How are we going to pronounce this thing? "Bee-Peg" I suppose since "Bee-Pee-Gee" doesn't roll off the tongue.
;)
Oh come on, you literalist! You should clearly pronounce it with a soft "B".
Double the image quality for the same bandwidth. I want this format supported in all browsers yesterday already.
If you don't risk failure you don't risk success.
Hard drives are bigger. bandwidths are greater. What's the point of this other than doctoral research of some sort?
For a photograph, PNG isn't anywhere near the compression level of even a high quality JPEG.
The tiny 512x512 Lena image ends up at around 462kb as a PNG. To my eyes, I'd say that the BPG at around 15kb looks just as good.
30x size difference. Not even close.
.png has an alpha channel, has broad support, and uses *lossless* compression. What's not to like?
Lossless compression works terribly on photographic images, which limits the kind of images you can practically use with an alpha channel in web browsers today.
It's a soft G: "Bee-Pej".
-- Don't Tase me, bro!
...of the Internet, but OSPF has strong merits of its own.
WebP has lossy and lossless modes, just to clarify, and is actually a good candidate to replace JPEG, PNG and even GIF, as it also has animation.
PNG is quite old and tired at this point. Both BPG and other newly proposed formats such as WebP have lossless modes which easily beat PNG at compression.
How has parallelism been taken into consideration with this format? Original JPEG format has Huffman decoding bottleneck: it does not matter how fast the processing of decompressed bitstream is if the bitstream decompression is the limit. For example, the "world's fastest" JPEG decoder TurboJPEG can be beat by factor of 2-3x when restart interval markers are present in the data-stream. This allows a hack: scan for next RST marker and dispatch a new job for scheduler to decompress and post-process the packet. I don't know anyone else that has done this optimization to JPEG software decoder (the Mango JPEG decoder does this and is at least twice the speed TurboJPEG. :)
http://pastebin.com/BWVaYfZ8
(The magic is on line 153, it looks stupid, pointless and lame.. but the performance increase is incredible)
The point being that the format should mandate a mechanism for breaking the task into smaller chunks. Spatially partitioned image compression schemes are embarassingly parallelizable but only if the data layout allows it. Video streaming does not have this problem as the decoder can decompress multiple frames simultaneously as long as their start offset is known. This will scale well with number of cores and threads. Image is a wee-bit different problem since your thread-pool super threading engine will be sniffing after the single-thread bitstream decoder. JPEG files can at least be injected with RSTn markers for future performance increase.
I did read that this is computatively very expensive endeavour, so it would be really great news to hear that the decoder will not have any artificial limitations. Sure, restarting the bitstream will reduce compression efficiency but this would be something that can still be controlled by the encoder if the internal is configurable. If you want last 0.5-1% of compression: compress the whole image in single segment. If you are willing to trade 1% of compression to 4x better decoding rate, that choise could at least be made by the encoder and not enforced by the format itself.
This guy is a true genius. He has single-handedly now replaces the massive efforts of giants like Google and their, as of now obsolete, WebP format. In the visual comparisons, BPG trumps all the other formats hands down. This format WILL be adopted as a new standard.
A big problem with PNGs is that PNG editors don't try to make the smallest possible files.... you need tools like pngcrush for that.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I'll stick with PNG.... because it's fully supported and... Oh, wait. Nevermind.
Since Christians have largely abandoned the practice, whereas some Islamic countries still allow marriages of girls as young as 9
so is it impossible to extend png to include more aggressive (but still lossless) compression?
i'm getting tired of the tower of babel.
As far as I can tell, a JavaScript decoder relies on XMLHttpRequest, which works only if the page and image are served from the same origin. This means you can't hotlink BPG images from another server unless that server has whitelisted your server with CORS. Watch sites switch to BPG as an anti-hotlinking measure, and watch this end up chewing up CPU time especially on mobile devices by decoding images in JavaScript rather than native code.
What ELSE does this new format do? Provide a means to track people? Encode hostile code maybe?
Steganography will be easier to detect.
Why is a "new" image file format being compared to JPEG? Most web designers moved to PNG a decade ago, or more. The most prevelant use of JPEG is in consumer grade digital cameras, which frankly, is completely stupid on the manufacturers part as they are using an outdated and not-particularly-good image file format for pictures.
Where's PNG in the mix and why isn't it in the comparisons? PNG is also not patent encumbered at all, AFAIK. I record and create images in RAW or TIFF and then export to PNG for web and TIFF for print (no compression). The only time I use JPEG is if a client specifically requests it.
Think of the bigger picture. In the same way that jpeg influenced the creation of mpeg, it won't be long until a new video format gets released, allowing for the next wave of video media. From 4k video into current blu ray disks, to more streaming content at the same bandwidth.
Looking at the comparison pages the savings is in the terms of double (30) to at the most triple bytes (150) and not anywhere near 50%. Yes the quality is better which alone might be ample reason to switch once it's supported in every major browser and image editing software.
"GET / HTTP/1.0" 200 51230 "-" "Mozilla/4.0 (compatible; Setec Astronomy)"
It is technically possible but practically impossible, for two reasons: One, it is very hard to get even backwards-compatible extensions approved for addition to PNG. See the failure of APNG for an example. Two, such a change would not really be backwards-compatible, and the files would be named "png" but would not actually open in any current PNG reader. There would thus be very little advantage of adding this to PNG rather than creating a new format.
There is a reason why JPEG is blocky. The blocky nature of the encoding preserves details better.
BPG blurs everything heavily. Small details and fine textures literally disappear.(*)
JPEG is definitely outdated and web could gain from a worthy replacement. But BPG IMO doesn't appear to be "it".
(*) I wonder how JPEG would fare on the images, decoded from BPG. Since fine details are removed by BPG, the JPEG would be smaller too.
All hope abandon ye who enter here.
Well, within epsilon of exclusively..
do do do do do do do do do do do do... oh wait, wrong compression format.
Is BPG using some form of VQ (vector quantization)? What are the key tech improvements over JPEG?
About that "small" Javascript decoder. Did you look at it?
You call that "small" ?
The x86 assembly code is somewhat troublesome, also.
Need Mercedes parts ?
Thats because you ate a fuzzy fungus!
Seriously though, can i get some too?
looks like another way to sell you everything once again that you already have. I am on constant guard against that sort of thing. you can't have my Ampex 601, cold dead hands or not!
if this is supposed to be a new economy, how come they still want my old fashioned money?
don't bother with the lena comparison - look at the [lack of] artifacting in comparison to the other compressors
http://xooyoozoo.github.io/yolo-octo-bugfixes/
In the past I would have written this off as great but stands no chance of ever being used.
Then I looked at html code just a simple ..IMG SRC="...bpg".. thing and javascript include up at the top.
The one problem preventing new significantly better formats from catching on and being deployed in the field is now gone... I can imagine at some point browser vendors ending up adding native support just for the sake of saving a few CPU cycles.
But what is the Weissman score?
Twitter.com/TrentonHyatt
An excellent discussion and I learned a couple of things.
I will continue to use .png for archival needs where bandwidth issues do not apply, and I can avoid worrying about the copy-of-copy degradation of .jpg without the excessive size of .tiff or other lossless formats. I will convert to .jpg at as high compression as is workable when preparing images for the web.
This leads to another question, now that several persons who know something about this stuff are gathered together on this one thread:
Blender can work with images from a number of different sources and these can be stored within the .blend database. These might be reference images during modeling or textures used in the finished product. They are usualy the major contributor to the size of the .blend file. So, does anyone know whether there would be an advantage to using one image format over another when working with Blender?
Will
Is it any different/better than already existing PGF file format?
https://en.wikipedia.org/wiki/...
What takes a miracle is trying to convince someone like you to stop naysaying for 10 damned minutes and look at the world from a different perspective. Fat chance indeed.
When you can store hundreds and hundreds of GBs of data really cheaply, who cares about a slight saving in file size for their gentleman's fine art collection?
To have a right to do a thing is not at all the same as to be right in doing it
penis
There already is lossy compression in PNG: converting a photo to indexed mode.
Yet now Microsoft, king of MPAA panderers, even supports the MKV format in its products going forward (including Xbone and Windows 10) because piracy is so rampant that there's a huge demand for that format
Are you sure it wasn't to allow the use of WebM, which uses a profile of MKV as its container?
I wonder how much of Matplotlib's use of this portrait relates to Playboy's copyright in the pic of Lena. The US Government always puts its works made for hire, such as the Navy portrait of Rear Admiral Hopper, in the public domain.
This is huge and will take off because there are big companies that would save a lot of money by using it. For example, WordPress.com, which hosts billions of images, does pay for their bandwidth. They have a simple plugin that compresses all uploaded images. All they have to do is change their plugin to use BPG and suddenly the billions of blogs out there using smaller images? That is the majority of their image bandwidth. And it is cut in half.
Sure both storage and bandwidth seem bloated. But on a large scale, such as WordPress.com, this could mean hundreds of thousands, perhaps millions, of dollars in drive space and bandwidth savings each year.
Now, DeviantArt and other image gallery companies will see the same benefit.
Then this moves to WordPress.org and the other half the bloggers on the internet start using it too.
Now that WordPress uses that image type, every consumer who right-clicks and downloads those images now needs to be able to open BPG files.
When there is money to be made or saved, a technology will take off.