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.
This will go over about as well.
Because the new half-the-size JPEG files wouldn't work with old JPEG editors/viewers.
...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.
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!)
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.
Are the possible patents protection mentioned on bellard.org a limit for potential native browser support?
Bandwidth still matters for mobile, so smaller images of the same quality are quite welcome on mobile sites and apps.
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.
Yesterday it worked; today it is not working; Windows is like that...
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).
JPEGs do support alpha channels, browsers just might not render them properly, but same goes with JPEGs with CMYK colorspace.
- Raynet --> .
I can see how explaining a file format would be a problem for you.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
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.
Would you be happy if this exact same thing were somehow called JPEG? That's essentially what you're asking. "Fixing" JPEG doesn't magically make it work everywhere just because it has that name.
It trades JPEG's pixelation for removal of details/changing colours/etc.
That is how lossy compression works. JPEG also removes details and changes colors
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.
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.
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'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.
Irony: Agile development has too much intertia to be abandoned now.
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!
...because jpegs are so huge to begin with :|
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
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.
I have always been under the impression that Jpg's and other graphic formats are already compressed (i don'thing BPM's are), and will sometimes grow larger if compressed again. Try this with a batch of Jpg or another graphic's format, it will be larger than the batch total. Sometimes by just a little; sometimes by a great deal.
Can't argue though as BPG seems to compress,while I figure with just more loss of the data you can see anyhow - JPG's line when it first came out.
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.
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.
In a crowded place, bandwidth is very much an issue - as radio is a shared medium.
But generally speaking, bandwidth matters more for the mobile operators than it matters for you. They are the ones who have to do expensive upgrades when they face network congestion.
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!
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 nice additional features, like efficient lossless compression modes, transparency and HDR. That's huge - it's not just competing with JPG, it's also competing with *PNG*, and it's *way* smaller than PNG.
There's also specialty apps. Think, for example, something like Google Earth which is constantly downloading vast amounts of texture data. Waiting for that data (as well as the height data) is why you have to wait for Google Earth when you move to a new location. The more high-detail texturemapped objects (like buildings) that get added, the more important good compression is going to be.
There's tons of other reasons, but the basic point is, if it truly is "generally agreed as significantly better", and becomes a standard implemented by browsers and major graphics tools, it will get adopted. Maybe not instantly, but it definitely will happen.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
To me, just looking at the Lena image before looking at the comparisons, my immediate thought was "this has been photoshoped to death" - sure it looks better than JPEG but it still looks like crap. The real issue is that for the future size will not matter but other issues will be more important. I'd rather see "4D" support (Lytro camera by Ren Ng) than any improvement on low end graphics.
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 will use it. There's even a "legacy mode" javascript decoder for good measure for people who don't have support.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
"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"
WTF? So many stupid, conflicting statements in one paragraph... you moron.
So, you're saying that "with todays (sic) website-bloat and bandwidth", packing your images "even smaller" isn't "likely to fly". WTF? Why WOULDN'T it be "likely to fly", when it solves both of the problems you mention at the start of the sentence?
"it's not immediately clear to me that this is in any way better than just using higher quality/size JPEG"
WTF? So it isn't better than using a "higher size" (LOL) JPEG? So, using a smaller BPG file, half the size of the equivalent JPEG, is not a good thing?
Christ. I give up.
JPEG is (barring the possibility of some lossless mode that looks very little like JPEG except for a few metadata fields; but is technically part of the spec, not sure if we have one of those) indeed compressed; but it's lossy compression and lossy compression is an area where there is actually a reasonable amount of ongoing development.
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.
Sometimes you can 'fix' a format (maybe I'm just dating myself; but MP3s made impressive strides in apparent quality at a given bitrate in the years after their introduction); but you run into a major constraint:
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, adoption will likely be easy; but if decoder behavior prevents you from doing what you want to make some improvement or other, sometimes you just need a new format.
With 'mobile' there are really two considerations: One is the fact that 'mobile' (even if the fault is, in fact, with shitty backhaul) is going to be fairly slow in emerging markets. Two, relevant even in wealthy developed nations without asshole oligopoly telcos, is the fact that mobile devices are brutally power constrained, and RF chatter isn't exactly cheap in energy terms. The faster you get the data you need and shut down, or move to a slower, lower power mode, the radios, the happier your battery will be.
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.
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.
Remember that in many emerging markets, Blackberry is the way most of the population access the web.
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.
Well, the JS decoder doesn't actually work at least on the original iPad though.
It's kind of pointless and not really an option if you don't get significantly above 90% support with the JS decoder.
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 graphic with highly visible artifacts like that. The important point to take from this is that for the same image quality, you'll get images that look far less compressed. Alternatively, for the SAME bandwidth, you can get images that have much less visible artifacts. This format also supports high bit depths as well as transparency, so it's very much at home in the high-end side of graphics as well.
Irony: Agile development has too much intertia to be abandoned now.
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.
I'd still rather Lytro support.
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.
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?
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?
Irony: Agile development has too much intertia to be abandoned now.
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.
You thought you were getting first post because Slashdot's comment system is all screwed up these days. I often (say, a few times a week) find articles showing up with no comments, yet the front page comment counter shows many.
This place has gone to the dogs.
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?
This format will, unfortunately, probably get little traction for one reason. JPG is here and it's "good enough".
Nope -- that's not the reason. The reason is "JPEG is here and everyone archives their photos as JPEG, with no uncompressed original, particularly given that most consumer digital cameras use JPEG as their native format."
The problem for the near future is that untold petabytes of data out there exist that cannot benefit from this new format.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
A) What useful, practical, mass-market purpose is there for light-field photography?
B) Have you seen a light-field camera with any sort of decent resolution?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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? ;-)
I had similar thoughts.
It looked to me like running the resulting jpeg raw data through a DCT and low pass filtering the larger "block" layers might produce a similar image. I'm sure If I have nothing better to do some day I'll give it a try (i.e. I hope someone else tries it).
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)
a) An obvious one, CAPTCHA.
b) by the time support for it comes around there will be decent resolutions. They're at 4 megapixels with their 2nd gen camera which is sufficient for a lot of web graphics uses. I'm sure they'll hit 8-12 by gen 3.
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.
The JPEG originals from the camera are generally far too large for reasonable web use anyway. Nearly all photos you see on the web will have been downscaled and recompressed since they left the camera.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Another great implementation for this will be images stored on smartphones. I know plenty of people who don't want to use iCloud (for good reason) that often have their phones filled quickly with music and photos. If you could halve the size of an image, you could greatly expand the usage of small hard drives on phones. Add to that the benefit of being able to send smaller images over your cell data plan and it feels like a natural fit.
"There are lies, there are damn lies, and there are statistics"
A) It's not that obvious. Care to explain how that would work? A2) That's not interesting to the end-user.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
...because jpegs are so huge to begin with :|
The BBC news site gets 40 million unique users per week and their homepage contains around 400k worth of JPEGs.
If BPG reduces the size of those images by 100k and If each of those users loads the homepage just once, that would save them 570 gigs of bandwidth per week.
Not to mention the saving for users with bandwidth caps on their connection...
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 agree with you about MP3/Ogg - but the Javascript decoder (used for example in http://bellard.org/bpg/gallery...) could make all the difference.
Basically it means that the server admin can reap the benefits (bandwidth) while the user has to handle the legacy conversion (Javascript runs on the user's machine). Therefore there is practically no downside for those who decide what is on a webpage.
And once this format is even just semi-widespread, browsers will start to support it too - and then it's a standard.
I'll stick with PNG.... because it's fully supported and... Oh, wait. Nevermind.
Exactly. And because a Javascript implementation is available it works right now on every browser.
Since Christians have largely abandoned the practice, whereas some Islamic countries still allow marriages of girls as young as 9
More importantly though, you have a user with a device that will lose a chunk of its battery power for all the time that the LTE radio is turned on ;)
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.
Yeah and if everyone gave me a penny I'd be mega rich. Just because adding them up a shitload of times and multiplying them millions makes a shitload of space doesn't negate the point that a jpg generally isn't a big file. Especially when optimised for web.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
A) It's not that obvious. Care to explain how that would work?
A2) That's not interesting to the end-user.
a) It is obvious. 3D is computationally expensive compared to 2D. An image a real person can manipulate to reveal the characters is easy for a person (given simple controls) and hard for a computer.
a2) You asked for useful, practical, mass-market - not interesting to the end user. For the latter, I can think of a million interesting uses for adding simple/quick depth to a web page without going full blown 3D/video/flash. From design tools to menus to smooth slideshow containers as a single object.
...and the downscaled, recompressed version will probably be the only version kept in the archive.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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.
PNG is lossless and supports images with more bits per channel. Plus it has extensions to support animation.
But it does negate the suggestion that we shouldn't replace JPEGs with something smaller just because JPEGs are already "small"...
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..
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?
Faster! Faster! Faster would be better!
Yes, the hard part is getting adoption. Just look how far Google's WebP image format has gotten. Or not gotten. (I'm not talking about their WebM video format which has also not gotten a lot of traction). Looks like they unveiled it in 2010 or before, but nobody has used it as far as I can see.
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?
Compression works best with repeating patterns. Lossy compression introduces noise, compressing noisy data is harder, so lossily compressing lossy compressed data is bad.
The past is like a foreign country, and often, a foreign country is like the past.
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?
It's too bad, because we really could have used this years ago while we were still on dialup
Ahh, the days of dialup. Getting Rick-rolled by goatse images while waiting for the JPG to "progressively" load, when expecting a pretty lady.
We should replace jpgs with these bpgs because they offer transparency too. Save messing with png or gif or whatever and just have one filetype that does everything. The actual size is moot it most cases when we're talking KB in relation to GB.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Alpha channel is big advantage (worth it in its own IMHO), but even a small size decrease adds up to a lot of bandwidth for high traffic sites, especially any with a lot of image content.
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.
Add to that, it's relatively easy to wrap your images in a noscript tag referencing a JPG version, so for the cost of storing two versions of the image on the server, you get to save money on bandwidth for anyone whose client can support it and not degrade the user experience for people who can't.
I am TheRaven on Soylent News
The formal limit is 0. I can return nothing for all your stuff encoded to nothing, and there you have it - very lossily compressed.
Exactly correct answer. Merge JPEG-BPG-> JPG
NEXT.
Big ups to the above comment. I am sure most of Slashdot knows this, but a lot of indie games apper to be using .ogg for sound files. Couldn't you listen to the entire Hotline Miami soundtrack using the .ogg files in the game's installation folder?
But what is the Weissman score?
Twitter.com/TrentonHyatt
45GiB per month? Around here typical packages for mobile broadband top out at about 5gigs. You can get ones that have more, but they'll typically throttle it at some point.
What's more, the actual cellphone coverage for the data they do provide tends to suck. If you happen to live someplace that's relatively flat and easy to provide service to, it might be easier to provide such bandwidth, but that's not universally true. Then there's parts of the world where 2G is still more or less what people have available to them.
Dude, are you just boasting about your internet speeds?
First of all, I'm not even going to bother to read all of your post, those numbers mean nothing, because not everyone lives in the same place as you.
And I'm not even talking about emerging markets, even in western countries many still don't have affordable fast mobile internet.
PNG is lossless, it is not much more than the original image passed through zlib, you might want to clean your eyes.
You are either a visionaire or a shill.
For me this seems as interesting as "3D" cinema.
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
i don't understand how this could translate to fewer servers. Your storage infrastructure would shrink, though.
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.
The problem with CMYK JPEG is that there are two competing standards: one with K=255 being full black, and one with K=0 being full black.
If you have to send more data (bigger files), you need more servers. A single server can only handle a certain maximum amount of data transfer, right? I thought that was pretty obvious, but maybe I'm missing something?
My bad - I meant to say BNG, not PNG in the first paragraph.
Irony: Agile development has too much intertia to be abandoned now.
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.
first off, nobody added a bunch of shit up and second, nobody multiplied anything by millions.
your a fucktard making shit up. faggot.
In reality you'd still have seen images compressed to hell, like Facebook does today. They would have just done it with fewer bytes.
Not really. Neither the JPEG compression standard nor the usual JFIF container format support tansparency: http://www.faqs.org/faqs/jpeg-faq/part1/section-12.html
There is a way to add an alpha channel, but it's a hack. That's the reason browsers don't support it.
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.