Bellard Creates New Image Format To Replace JPEG 377
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.
Ok, looks good (Score:3, Informative)
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.
Re: (Score:2)
Well, by virtue of the in-browser javascript decoder, at least that end is handled already - it "just works" in chromium at least. Between that and alpha support, this looks like it has everything that's been needed from a lossy image format for a long time now.
Re: (Score:2)
As soon as Photoshop and Firefox/Chrome start supporting it I can see widespread adoption.
Just like JPEG-2000 and WebP which have support in Chrome and Photoshop? What about the fact that all iPods and phone support AAC compression for music?
No it takes miracles for people to abandon what they know in favour of something technically superior.
Or The Reverse (Score:3)
Double the image quality for the same bandwidth. I want this format supported in all browsers yesterday already.
Re: (Score:2)
Why are you surprised that a 5.8 thousand byte image has more artifacts than a 2 million(ish) byte image?
Better comparison site (Score:5, Informative)
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... [github.io]
Re: (Score:3)
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... [github.io]
Interesting, thanks for the link -- I must say, I see pretty much no visual difference at all between BPG and the WebP format on those sample pics, at identical file size.
Re: (Score:3, Informative)
Look at the blue sky in the Moscow pic. It is VERY wavy in JPEG, smooth in BPG
Re:Better comparison site (Score:4, Interesting)
Look harder especially around areas of high detail. JPEG had problems with gradients, WebP doesn't, so in this example picture the difference between JPEG and any other format are quite severe which may have lead to you missing the obvious, such as the guywires holding up the crosses which are in some cases completely obliterated in the WebP format.
Otherwise the detail is similar however WebP introduces significant artefacts around the detail whereas BPG appears to draw it more smoothly.
Re: (Score:3)
Try the "Pont de Quebec at Night" image making sure "Mozjpeg" is on the left and BPG-x265 on the right.
Then hover your mouse cursor over the image. Everything to the left of the cursor is JPEG, and everything to the right BPG.
Tell me you then can't see a difference.
Re: (Score:2)
BPG natively supports 8 to 14 bits per channel (Score:5, Interesting)
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).
Re: (Score:2)
As a photographer, this is a big issue for me.
Re: (Score:2)
I'm not so sure. High bit depths are valuable in production - when you wouldn't want to use lossy compression at all, and big files are not great problem. Size matters for distribution of the finished image, and there's little point in more than eight bits per channel there - many monitors can't even display that many, and few people have the visual acuity to care.
Re: (Score:2)
Yes, no maybe. It depends on what you lose in compression. JPEG is a great example. In product if you value your ability to work with detail and alter colours, well JPEG completely obliterates dark shades and the blue channel. Once you save something as a JPEG your chance to boost the shadows without introducing horrendous visual artefacts are decimated.
On the other hand I have a 36mpxl camera. I have no problem with compression introducing visual smearing in the images if it retains the colour definition a
Re: (Score:3)
Higher encoded bit depths can actually lower file size at a given quality or increase quality at a given filesize regardless if you are outputting at a lower depth.
http://x264.nl/x264/10bit_02-a... [x264.nl]
TLDR: Even though the dit depth is higher, it allows for more of the junk information to be thrown out while keeping more of the important data.
Blocking and banding are very problematic in JPEG and the easiest way to fix it is to just raise the bit depth which is probably why they added 12bit to JPEG 9.1 earlier t
HEVC/H.265 (Score:2)
vs WebP (Score:5, Insightful)
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.
Re: (Score:2)
WebP is only very marginally better than JPEG, see the linked compression studies in the original article.
Re: (Score:2)
Looked and I conclude you either need a new monitor or a new perscription. The difference between BPG and WebP is marginal with the winner being BPG. But the difference between either to JPEG is chalk and cheese.
Re: (Score:2)
I was talking about the comprehensive study with state of the art JPEG free encoders, not the visual comparison of 3 or so images that's made to make BPG look good.
Drat! (Score:2, Interesting)
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!
Massively patent-encumbered (Score:5, Informative)
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.
It's not a "replacement." (Score:4, Insightful)
What about Patents? (Score:3)
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.
Too much smoothing (Score:4, Interesting)
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.
tl;dr -- anyone with a technical overview? (Score:3)
Re:Great... (Score:5, Insightful)
Because the new half-the-size JPEG files wouldn't work with old JPEG editors/viewers.
Re: (Score:2, Informative)
There's more than one way to compress images though, some vastly different to others. BPM is working on the original image and compressing better than JPEG. As for whether that loses more data, that's not a given - it is possible for a different algorithm to compress to less data than JPEG but retain more information.
Re:Great... (Score:5, Informative)
This isn't to say that lossless compression is a trivial problem, or that there have been absolutely no improvements; but the 'by definition, it isn't lossless unless applying the decompression operation to the result of the compression operation produces something identical to the input' criterion makes it much easier to let the mathematicians and computer scientists work out the limits of the possible.
With lossy compression, there aren't any formal limits, which leaves the field much more open to solutions that rely on following the strong and weak points of human perception(visual in this case, auditory in other cases, visual/motion related in others), which leads to much greater complexity and diversity.
Re:Great... (Score:4, Interesting)
It's worth noting the demo page is using JavaScript decoder to display the images; so it seems more than feasible to transition to the new format by first just having JavaScript decoder do the displaying on image-intensive sites. Still, I have to agree that especially with todays website-bloat and bandwidth "Another new format to pack your images even smaller!" isn't likely to fly. If the headline was much better quality, maybe, but it's not immediately clear to me that this is in any way better than just using higher quality/size JPEG. (Although as hinted, image-intensive sites who pay for their own bandwidth surely disagree!)
Re:Great... (Score:5, Insightful)
Given that the developing world is likely to get online via wireless solutions, bandwidth is going to matter for a lot of people for a long time to come.
Re:Great... (Score:5, Insightful)
With mains power it matters less (electricity isn't free; but a few extra dollars a month is far less annoying than having your battery keel over dead at a bad time); but barring exciting breakthroughs in battery chemistry or design, basically all the savings are going to have to come from the device side.
Re:Great... (Score:5, Funny)
Remember that in many emerging markets, Blackberry is the way most of the population access the web.
Cool. A time traveler. What year are you from?
Re:Great... (Score:5, Insightful)
You and your friends who can get decent bandwidth, can afford decent smartphones and who can afford to just throw down an additional 2 euro a month for said bandwidth are, you may be surprised to hear, not representative of everyone. For example, the average internet connection speed in Algeria is about 0.94Mb/s. I'm pretty sure most people there are also not wandering around with the latest LTE enabled phone either.
Re: (Score:3, Insightful)
If you're running a server for a big company (say, Google or FaceBook) and every image is only half as big, that means a huge reduction in the number of servers you need, power consumption, etc. Less congestion on the internet, more responsive servers, less wasted energy, etc...
I imagine you also have a car that guzzles up twice as much gas as other cars, but who cares since you can afford it?
Re: (Score:2)
I have to agree, even as a big fan of smaller. BPG arguably does create better images at small sizes but it's not much better than JPEG. It trades JPEG's pixelation for removal of details/changing colours/etc.
Re:Great... (Score:5, Interesting)
I'm not sure how you can argue that after looking at the pictures in the link. It's clearly superior to JPG, because *everyone* can see the JPG artifacts. You only tend to notice the artifacts with BPG if you're comparing to a high quality picture or the original, or else looking really hard. It seems similar in principle to good audio compression that saves space by removing details the human ear is unlikely to miss.
It's too bad, because we really could have used this years ago while we were still on dialup - it would have saved us from seeing many beautiful images compressed all to hell. Yes, bandwidth matters to some degree nowadays, but not nearly as much as it used to. This format will, unfortunately, probably get little traction for one reason. JPG is here and it's "good enough". Audiophiles chafe at MP3 as well. Technically speaking, Ogg Vorbis was a superior format in nearly every way, but it's widely ignored in favor of MP3, which is "good enough". There's a small movement with FLAC and hi resolution sound, but most people can't hear or don't care about the difference. It will probably be the same for this.
Who knows... maybe I'll be proven wrong. It would help if the browser makers actually got behind it early and supported it fully - PNG suffered poor adoption because IE lagged so far behind with support for many years. Adobe, Corel, and other makers of image software will also need to offer native support as well. A format is worthless unless people are actually using it.
Re: (Score:2)
There's ample path to adoption. If it becomes a standard, browsers will implement it and major graphics tools will support its creation. Wherein major content providers who still have large bandwidth bills will use it to reduce their bandwidth requirements. The wider the adoption, the more the usage. We've seen new video formats effectively obliterate older, ubiquitous formats a number of times. We're overdue for the equivalent with still images. There's also the issue that it offers developers a number of
Re:Great... (Score:5, Interesting)
I'm a videogame programmer, and Ogg Vorbis is actually a very popular format for game audio. It's not only license free, but it supports multichannel audio and seamless sample-accurate looping, which standard MP3 can't do. It was great for videogame companies, but did little to really promote the file format itself. So, sure, the fact that we have usable reference libraries means anyone can add support to their products, but I don't think that makes much of a difference, unfortunately.
Don't get me wrong - I think it's a great format (obviously technically superior) and would love to see it succeed. You say that if the format "becomes a standard implemented by browsers and major graphics tools, it will get adopted". Well, sure, but that's sort of the hard part, right?
Re: (Score:2)
Don't think of it as "low end" graphics. The smallest pictures are demonstrating the worst artifacting possible in order to demonstrate the compression techniques being used. In the case of JPG, we can see the block-based artifacts very clearly. In PNG's case, you can see that the compression works differently, by reducing details and colors where it can, creating a "photoshopped" effect, as you put it.
Just like you never really see a JPG image compressed that badly, you'll probably also never see a BNG
Re: (Score:2)
I'd still rather Lytro support.
Re: (Score:3)
Re: (Score:2)
If the headline was much better quality, maybe, but it's not immediately clear to me that this is in any way better than just using higher quality/size JPEG.
I agree, half the size is for most people irrelevant. The article mentions the quality improvement you wanted but did not make it in the summery. Upto 14bits per channel could be a major plus when implemented natively in a DLSR.
Even then it first need to be widely supported before it is used by many, it needs to be used by many before it will be widely supported.
Re: (Score:2)
If the bar it's competing against for "widely supported" is raw camera image formats, then that's a pretty low bar to meet. Don't forget that it also has transparency, so it's also competing with (and crushing) PNG, as well as effective lossless compression.
I can really envision this taking off, if it gets adopted as a standard and browsers give it that starting "push". If browsers support it, photoshop and other major tools will as well, and content providers who pay out the nose for bandwidth absolutely w
Re: (Score:2)
Why can't they just fix the damn JPEG and make it half the size instead??
It would not be compatible with existing software. Furthermore, poor compression is only one problem with JPEG. Another is the lack or transparency. JPEGs are always 100% opaque.
Re:Great... (Score:4, Informative)
JPEGs do support alpha channels, browsers just might not render them properly, but same goes with JPEGs with CMYK colorspace.
Transparency is supported. Pronounciation? (Score:5, Informative)
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.
Re:Transparency is supported. Pronounciation? (Score:4, Funny)
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.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:3)
Oh come on, you literalist! You should clearly pronounce it with a soft "B".
Re: (Score:3)
It's a soft G: "Bee-Pej".
Re: (Score:2)
I can see how explaining a file format would be a problem for you.
Re: (Score:2)
Re: (Score:2)
If a spec-compliant; but not otherwise updated, decoder chokes on your 'improvement', you don't really have an improvement, you have a new format derived from the old format. If there is room to improve the encoder, while still producing something that existing decoders consider valid, great, ado
Re: (Score:3)
While I'm generally also skeptical, when JPEG2000 was released, decoding images in JavaScript wasn't an option. As such, there's not really any barrier for individual websites to switch, if they're heavily image-driven.
A bigger roadblock might be that these days, bandwidth (and storage) is cheap, and so savings in image size are less relevant than they used to be.
Re:JPEG2000 replaced JPEG (Score:4, Insightful)
Same-origin policy is a nightmare for use with CDNs. I really wanted to use WebP for image handling for the application I'm working on, but Firefox adamantly refuses to merge a patch adding WebP support, and the JavaScript shim can only access the images if they're pulled of the same host. Images loaded from a CDN aren't accessible to the JS decoder.
Re: (Score:2, Informative)
If you have the ability to change the server configuration, wouldn't CORS work? "Access-Control-Allow-Origin: *"
Re:JPEG2000 replaced JPEG (Score:4, Informative)
Boosting the signal, for those who don't read ACs:
CORS (Cross-Origin Resource Sharing) is explicitly intended to support things like CDNs. It lets you make cross-domain XHRs (and access the responses), so the JavaScript-based decoder will work perfectly. It adds minimal additional bandwidth requirement over a standard cross-domain GET (one short extra header on request, a couple on response), is supported on all mainstream browsers, and is much more secure that stupid hacks like JSON-P (though that would work here too, if for some reason you wanted to live in last decade's terrible work-arounds for same-origin policy).
http://en.wikipedia.org/wiki/C... [wikipedia.org]
Re: (Score:2, Insightful)
What in the world are you talking about? I have an application that's focused on processing and displaying user images. Are you seriously claiming that it would be better practice for me to deal with reinventing the storage wheel instead of saving everything to S3 and serving it from there?
Re: (Score:2)
Re: (Score:2, Offtopic)
Do you know what a CDN is?
I'm guessing the GP is talking about things like Cloudflare, MaxCDN, Azure CDN and Cloudftront.
There are very few people who'd be able to replicate such a network on their own. In fact, neither do those CDN companies.
Also, the statement "If one can't do the work on their own, they probably shouldn't be in the IT field at all" is blatently stupid, unless ofcourse you mold your own CPU's from raw sand.
Re: (Score:2)
Not everywhere and for everyone. A while back a lot of people used AVI files for their just about all of their video needs, and it did the job fine as pretty much all modern codecs work with it.
But in the third world people like to pirate a lot more, and contrary to popular belief, pirate release groups (collectively referred to as "the scene") love quality, and are rather OCD about making sure their releases are not only high quality, but the best quality they can be. Crap releases like divx and burned sub
Re: (Score:2)
and don't forget http://xkcd.com/927/ [xkcd.com]
Re: (Score:3)
A bigger roadblock might be that these days, bandwidth (and storage) is cheap, and so savings in image size are less relevant than they used to be.
Bandwidth isn't cheap on mobile data networks. On the other hand, requiring phones to execute battery sapping image decompression in Javascript is hardly a great idea either.
Re: (Score:3)
For a free format without any sponsors(either altruistic or, as with WebM, probably doing it as a tactical move to improve their negotiating position if the MPEG LA ever decided to shake down youtube for more than token fees for H264), it doesn't take a terribly plausible patent claim to be plausible enough that it'll be hard to find somebody to go slug it out in court.
As much as certain formats are...getting
Re:JPEG2000 replaced JPEG (Score:5, Informative)
You don't have to wait for someone to pop out of the woodworks. BPG is nothing but a still frame of HEVC video which is patented up the ass. Bellard and other open source video authors are accustomed to ignoring the patent situation because they don't really have a choice if you want to be interoperable, but that isn't an excuse for creating patent problems in a field where there are already widespread royalty free standards (JPEG, PNG).
Re: (Score:3)
The one interesting quirk about being directly based on a video codec, though, is that a variety of devices (eg. SoCs with fixed function decode blocks, computers with OS vendors that pay the appropriate tithes, etc.) might be 'automatically' licensed for the special-case use of treating a single HEVC frame as a still image by virtue of being suitably licensed for HEVC playback. It'd be amusing to see whether that argument is accepted, or whether 'single frame pl
Re: (Score:2)
Re: (Score:2)
Yeah, and PNG for GIF.
PNG gets used though.
Re:JPEG2000 replaced JPEG (Score:5, Insightful)
DJVU was another contender but it just happened to be tagged on to a PDF-like docuemnt format and not widely known as just an image format.
Finally, anything that was not (properly) supported by Internet Explorer ten years ago was a dead duck. And Microsoft and Apple actively snub any open format if they can get away with (like Vorbis, WebM etc).
Re:Patents (Score:4, Interesting)
From Wikipedia
[24] http://www.mpegla.com/main/pro... [mpegla.com] (PDF)
Re: (Score:3)
So what constitutes a "product" when it comes to software? Say Mozilla implement this new format for Firefox, does that mean Mozilla have to pay $0.20 to MPEG LA every time someone downloads a copy of Firefox?
The demo website linked in the story sent a BPG decoder implemented Javascript to our browsers. So does that mean Bellard owe MPEG LA a metric shit-ton of money now?
Re:Patents (Score:4, Informative)
Yes and yes, respectively. Though for the latter they probably won't bother.
This is just a terrible idea.
Re:This really is a man's world... (Score:4, Interesting)
Except that this test image has just a face and part of a shoulder, without any naughty bits. Not even erotic at all.
It's a good test image because it catches both distortions of detail and color damage to areas with a gentle gradient.
Re: (Score:2)
It's a good test image because it catches both distortions of detail and color damage to areas with a gentle gradient.
There must be better ones. It's washed out with hardly any green or blue.
Re:This really is a man's world... (Score:5, Funny)
Re: (Score:3)
If they have to be told what the image is from to get upset, to paraphrase Steve Jobs, they're getting offended wrong. The image as it is now does not objectify women any more than images that run in modern newspapers. Once it's been cropped to this level, it's literally lost all value that made it sexist to start with. If you can tell them instead it's from some old ladies fashion magazine and they're suddenly okay with it, I'd have to say you proved my point.
Re: (Score:2)
Re: (Score:2)
Forgive my ignorance, but how is this image sexist and/or how is it's source (Playboy?) sexist?
In order for something to be sexist doesn't it in some way have to discriminate between sexes?
Re: (Score:2)
Here is a less cropped version of Lena (prepare to be offended!)
http://jquery-custom-scrollbar... [rocketmind.pl]
Re: (Score:3)
Um... would you like a beer, perchance?
Re: (Score:2, Interesting)
It really is political correctness gone off the deep end when anyone even *cares* that the standard Lena image is cropped from Playboy or that it depicts a female. Who cares! It's an image. The standard argument is that it's "sexualized" and thus offends the sensitivities of some feminists. I call bullshit.
First of all, nobody uses this because it's sexualized; much better free porn is widely available to anyone on the Internet anyways. People use it because it was once used historically for image comp
Re: (Score:2)
"There's like, a whole bare shoulder in that photo. If that's going to offend you"
You have some weird conceptions, as though the reason people have a problem with the choice is because they're offended by the image of skin. A lot of the same voices opposing the use of images that objectify women are supporters of, for example, stopping the banning of images of breastfeeding and the like. It's not nakedness that's the problem. It's making half of the human race into objects seen as worth nothing more than se
Re: (Score:3)
I was pleased to see that Matplotlib switch to Grace Hopper as their test image. http://matplotlib.org/examples... [matplotlib.org]
Re: (Score:3)
Because JPEG 2000, JPEG XR, WebP and others don't work in browsers without specifically added support, BGP does (via javascript).
Re: (Score:3)
While my inclination is towards BPG, the argument could be made that it would be superior to implement a javascript decoder for those other file formats, if they provided better quality at lower file sizes...
Re:Compare to... (Score:5, Informative)
JPEG2000 in Javascript [github.com]
WebP in Javascript [appspot.com]
Another WebP in Javascript [appspot.com]
Re: (Score:2)
Because JPEG 2000, JPEG XR, WebP and others don't work in browsers without specifically added support, BGP does (via javascript).
Is there something about those formats that prevents someone from writing a Javascript-based visualizer? It's helpful that it's available, but frankly, it seems like an interim step to help in promoting the format - allowing people to see it on the web it it's native format instead of converted to a lossless PNG.
It does look like a great format, but until it's adopted as a web standard, all the browsers support it, and the major image editors can export it, it will remain among the many technically superio
Re: (Score:3)
I realize that this is Slashdot and we have a great tradition of not RTFA, but given that this is about an image format you could at least go LATFP (Look At The Fucking Pictures). It's also an impressive display of how well image deciding using JavaScript works (but then, this is the guy who wrote an entire x86 emulator capable of running Linux using JS, and even made it work on IE; I have no doubt as to the man's skill in that realm).
Link for image format and quality comparisons: http://xooyoozoo.github.io [github.io]
Re:Compare to... (Score:4, Funny)
Because it has a catchier name.
I mean, "JPEG 2000"? Seriously? That is -so- 20th century.
Re: (Score:3)
Because it has never been done before? http://bstring.sourceforge.net... [sourceforge.net]
Re:Simply impressive (Score:4, Insightful)
Not so much a "limit" as much as a complete showstopper.
Re: (Score:2)
I'm guessing that once the thing gets popular your browser will have built-in decoding capabilities, written and optimized in something more advanced than JS.
Re: (Score:2)
Don't forget that when the code gets transmitted, it can be compressed down to 71 kb.
Re: (Score:3)
Servers always work to reduce bandwidth usage. Bandwidth is expensive when you're talking thousands of users.
Smaller images means faster transfer and faster load times, especially for mobile.
Just look at all the efforts put into bundling/compression/etc. Some companies go as far as reducing all their CSS class names to 3 or less characters. These have different purposes though not always directly related to bandwidth reduction. Bundling is more about reducing the number of HTTP requests than reducing ba