H.264 and VP8 for still image coding: WebP?(x264dev.multimedia.cx)
x264dev.multimedia.cx
H.264 and VP8 for still image coding: WebP?
http://x264dev.multimedia.cx/?p=541
3 comments
Wrong on just the alpha channel or all of it?
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 with Microsoft, Apple, and their hardware partners to look at next-generation technology they can put out, unencumbered by any patents and figure out a 3-year timetable after which they will have the format ready for use in cameras and phones. At the hardware level where the data is encoded off the CCD. Partnering with Flickr, Facebook, etc. they could make sure that these phones and cameras with next-gen encoders work out of the box, on the web.
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 with Microsoft, Apple, and their hardware partners to look at next-generation technology they can put out, unencumbered by any patents and figure out a 3-year timetable after which they will have the format ready for use in cameras and phones. At the hardware level where the data is encoded off the CCD. Partnering with Flickr, Facebook, etc. they could make sure that these phones and cameras with next-gen encoders work out of the box, on the web.
Cameras also take pictures with an order of magnitude more pixels and far more coefficients than are needed for web display. You can safely ignore the transcoding effects when you are also downsizing and "down-quality-ing".
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.
disclaimer: i work at G but not on this.
> 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.
Unfortunately, Google is alone on this one and will have to push webm and webp and any other open format on their own.
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.
Unfortunately, Google is alone on this one and will have to push webm and webp and any other open format on their own.
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.
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.
Some features of JPEG haven't been implemented due to patent concerns, but I think those have expired now.
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.
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.
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.
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.
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.
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.
Flickr, Picasa and such re-encodes the images to various sizes for display even if the untouched original is available. I believe that many phones offer to downsize before upload to save bandwidth in the other direction too.
[deleted]
The only time you see an original photo on Flickr is by going to choose size and selecting original. Everything else has been re-encoded.
I don't know... Judging from this article, I think these conclusions are premature: http://englishhard.com/2010/10/01/real-world-analysis-of-goo...
I am especially interested in the lack of banding vs. JPEG.
Now - next question: Can it support CMYK?
I am especially interested in the lack of banding vs. JPEG.
Now - next question: Can it support CMYK?
Wrong:
> We plan to add support for a transparency layer, also known as alpha channel in a future update.
from: http://googlecode.blogspot.com/2010/09/webp-new-image-format...