Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 and VP8 for still image coding: WebP?

x264dev.multimedia.cx

Post reply on HN
Print view View original

11–18 of 18 posts

Re: H.264 and VP8 for still image coding: WebP?

#11

Post by FooBarWidget »

sprout wrote: post #6
andrewf wrote: post #4

Earlier quoted context omitted.

I don't think most pictures on the Internet come from a camera verbatim. If you look at something like cnn.com or arstechnica.com - most images on that page have been scaled, cropped, composited with other images and finally re-encoded.

Where are most pictures on the Internet? I would guess Facebook and Flickr, uploaded by users who haven't the skill or the time to bother touching up the pictures they took today.

Why would anybody care about the format that Facebook users use? I see way more value in reencoding company website images in WebP so that things load faster at the same quality. This is especially useful if your visitors are fairly technical, i.e. when you are a systems software vendor or when you're a tech blogger: even if WebP is only supported by Chrome and Firefox, it means half of your audience can enjoy the faster loading times. With HTTP content negotiation you can gracefully fallback to JPG. WebP does not need the support of Facebook users to become valuable.

Re: H.264 and VP8 for still image coding: WebP?

#12

Post by spot »

sprout wrote: post #2

Even if all the vendors in a position to do so put in support for WebP today, it would be pretty much a decade before it got any serious use. Most Cameras take pictures as jpegs, and re-encoding jpegs in another lossy format is a losing proposition. So anything released today is of necessity in it for the long haul. That said, maybe releasing a spec today from one player isn't the way to go. Google should be talking…

Google's servers can identify when the client can handle this format and give those users a better experience (faster download). So it will be saving money for G while at the same time either driving wider adoption of Chrome, or spreading the format to other browsers. Sounds like a good move to me.

disclaimer: i work at G but not on this.

Re: H.264 and VP8 for still image coding: WebP?

#13

Post by CWuestefeld »

andrewf wrote: post #4
sprout wrote: post #2

Even if all the vendors in a position to do so put in support for WebP today, it would be pretty much a decade before it got any serious use. Most Cameras take pictures as jpegs, and re-encoding jpegs in another lossy format is a losing proposition. So anything released today is of necessity in it for the long haul. That said, maybe releasing a spec today from one player isn't the way to go. Google should be talking…

I don't think most pictures on the Internet come from a camera verbatim. If you look at something like cnn.com or arstechnica.com - most images on that page have been scaled, cropped, composited with other images and finally re-encoded.

For professional stuff, definitely.

But there's a movement afoot to build greater image-processing power into cameras, doing all of those operations right there on the device.

Personally, I'd never do that. I shoot RAW, and then handle on my desktop -- and calibrated monitor -- all of the adjustments. If nothing else, no matter how good the camera's CPU, the awful display on the back of the camera makes serious work impossible. It just can't be big enough if it's on the back of a convenient camera, and it won't be calibrated.

But for your average person taking photos of the kids at their soccer game, they don't care about any of that. The camera makers do a pretty good job of fine-tuning the heuristics (white balance, color adjustment, sharpening, etc.) so that the JPEG the camera produces is usually quite good, even if it's not excellent.

These people will be the ones driving a new "broadcast" image format. For quality stuff, the enthusiasts and pros have DNG and TIFF.

Re: H.264 and VP8 for still image coding: WebP?

#14

Post by werftgh »

patrickaljord wrote: post #7
sprout wrote: post #2

Even if all the vendors in a position to do so put in support for WebP today, it would be pretty much a decade before it got any serious use. Most Cameras take pictures as jpegs, and re-encoding jpegs in another lossy format is a losing proposition. So anything released today is of necessity in it for the long haul. That said, maybe releasing a spec today from one player isn't the way to go. Google should be talking…

> Google should be talking with Microsoft, Apple, and their hardware partners to look at next-generation technology they can put out, unencumbered by any patents But Apple and Microsoft are not interested by formats unencumbered by patents. Google, xiph and the fsf have been pushing for such formats for decades and Apple and Microsoft have been doing the contrary, pushing hard for their patents encumbered wm9 and AAC…

Might not be possible, it's not the format or algorithm thats patented - in many cases it's the concept. A patent on compressing an image by only storing some spatial frequencies gets you however you code the DCT.

Re: H.264 and VP8 for still image coding: WebP?

#15

Post by tvon »

patrickaljord wrote: post #5

> it doesn’t even support all of JPEG’s features, let alone many of the much-wanted features JPEG was missing (alpha channel support, lossless support). It only supports 4:2:0 chroma subsampling, while JPEG can handle 4:2:2 and 4:4:4. Google doesn’t seem interested in adding any of these features either. Wrong: > We plan to add support for a transparency layer, also known as alpha channel in a future update. from: ht…

Wrong on just the alpha channel or all of it?

Re: H.264 and VP8 for still image coding: WebP?

#17

Post by astrange »

patrickaljord wrote: post #7
sprout wrote: post #2

Even if all the vendors in a position to do so put in support for WebP today, it would be pretty much a decade before it got any serious use. Most Cameras take pictures as jpegs, and re-encoding jpegs in another lossy format is a losing proposition. So anything released today is of necessity in it for the long haul. That said, maybe releasing a spec today from one player isn't the way to go. Google should be talking…

> Google should be talking with Microsoft, Apple, and their hardware partners to look at next-generation technology they can put out, unencumbered by any patents But Apple and Microsoft are not interested by formats unencumbered by patents. Google, xiph and the fsf have been pushing for such formats for decades and Apple and Microsoft have been doing the contrary, pushing hard for their patents encumbered wm9 and AAC…

JPEG is an open format already, so that alone as an argument for replacing it doesn't really make sense.

Some features of JPEG haven't been implemented due to patent concerns, but I think those have expired now.

Re: H.264 and VP8 for still image coding: WebP?

#18

Post by sprout »

FooBarWidget wrote: post #11
sprout wrote: post #6

Earlier quoted context omitted.

Where are most pictures on the Internet? I would guess Facebook and Flickr, uploaded by users who haven't the skill or the time to bother touching up the pictures they took today.

Why would anybody care about the format that Facebook users use? I see way more value in reencoding company website images in WebP so that things load faster at the same quality. This is especially useful if your visitors are fairly technical, i.e. when you are a systems software vendor or when you're a tech blogger: even if WebP is only supported by Chrome and Firefox, it means half of your audience can enjoy the fa…

Facebook users, myself included, care a good deal.

Facebook's introduction of 2000px wide images (close to the output of most consumer cameras) makes this all the more important. If Facebook's letting people upload directly from their cameras to the site with no scaling, the format the camera uses is a big deal.

Also, Facebook is a very large portion of photos shared over the web.

Post reply on HN