WebP should go to VP9

[oX Triangle]

here is a new study

http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/

and my opinion ist - webp should open the VP9-Frame

[24lev...@gmail.com]

Probably impossible at this state.

If they changed it, it will break all compatibility as VP9 and VP8 aren´t the same thing.

However, they can make a "next version", something like, WebP9, or something like that.
But they will probably have to remake much research and programming, and it may not be worth it.

However, i am hoping for it, as anything that lowers size or increases quality is good:)

[oX Triangle]

webp use the RIFF-container

and the main-frame is the VP8-Frame (its an i-Frame known from video-codec)
if we ALLOW the VP9 (or another Frames...) the reading application think its an empty image

or u can use a VP8-Thumb and an added VP9-Frame

but the biggest question ist... not the technic is problem - the patent/license situation is the question

[24lev...@gmail.com]

But it won´t work in the end.

If i give you an VP9 version of Webp, you won´t be able to see it, perhaps in some hacked way, but not on the original decoder.

But of course, you can keep 2 images, 1 vp8 and 1 vp9, and use vp9 if the decoder supports it, however that just makes the size bigger  for little reason.

And patent issue, yeah it´s always that. Google often handles that good though, even though their effort for making it open source often goes to waste as it somehow become patented some way or another.
At least that happened with VP8 somehow i think.

[oX Triangle]

which format have no evolution?
TIFF started as RAW added later the ZIP-compression
and some years later the JPEG-Compression

PDF has serveral versions added more and more different algorithms

like bmp, like iw44 (wavelet), like jpeg, like jpeg2000 and bitonal JB2 (include seperation of image)

i think webp is now on v0.3 and it should be possible to add VP9/VPX and other features

[24lev...@gmail.com]

Not saying it won´t have it added.

Though Evolution in these cases are rather, "added functions".

I don´t think the original Tiff Decoder will work with ZIP Compression, with that you need tha newer Tiff standard.

It´s those things that make things complicated.

It´s easy to improve a codec as long as they follow the specifications, but move out of the boundaries, and a new standard must be made.

Though i am absolutely hoping for VP9, by no way am i trying to deny it will come, i want it to come to improve webp.

I like webp Lossless, Lossy however... i have problems with colors not showing correctly, i am guessing the YUV is to blame for that however, so it can´t compare to Jpeg even though the overal quality is better.
But that isn´t something that can´t be fixed, especially if they update with VP9 then they can add more functions like YV24, RGB lossy or whatever.

I truly wished it was more speed to this though, as Jpeg has been around for like 20 years, and is till pretty much the overall best format for images.

But Google has a good way to trying to break into stuff when they set their mind to it.

Btw, do you know if HEVC will make some "webp" thing?
Would be awesome if there was competition like in the video codec branches.

[kinchu...@gmail.com]

I agree that these formats have undergone long-term evolutions.

However, their evolution paths somehow allow them to add features that would break backward-readability. Here are the reasons:

Consider the audience and circulation of these files.

 1. A turn-key software system that stores images in this format, but is able to import/export any other image formats.

     This means nobody would need to be concerned about the internal file format used within this system.

    (Early stage of TIFF.)

 2. A business user sends a business document to another user in a different company, having already confirmed that the recipient can handle this format.

    (The early use of PDF for printing, and TIFF)

 3. A company or individual has to make a document available on the web for public download. It is not known whether the audience can handle this format or not.

    This situation always require the lowest denominator of technology. In particular:

 3.1  If a reader can be downloaded, a link is provided. This is the situation for PDF which lasted from mid-1990s to mid-2000s.

       (Remember small-town citizens complaining they couldn't open government website documents?)

 3.2  If a file format supports multiple "versions", the lowest version is used when the audience is general public.

       Basically, TIFF wasn't even an acceptable choice for the public web. For PDF, only PDF1.4 can be used.

Because WebP is designed to hit the third goal (general web use), it has to provide backward-compatibility for a while until every web browser vendor is committed to adding continuous support for the newer versions of WebP.

Just my two cents. Thanks,

Ryan Wong

[Jonathan Ozik]

If I had a vote, I would vote for braking the webp into 2 versions:
1. long-term compatibility (the stable version we already have today).
2. maximum efficiency (the alpha/beta version. VP9 and other future high efficiency technologies).

why do we need two versions? well, webp is slow on popularity gain, because it's not impressive enough the way it is today. why it isn't impressive enough? because the webp developers want to maintain long-term compatibility. it's a paradox. we cant have popularity without sacrificing compatibility. now lets think how it would be with two versions: the next time Mozilla would make a study, they would have to test the maximum efficiency version and would show it to be at least as good as VP9 so we win and gain popularity. Web-developers? Well, those who want to reach the widest audience would use the present day long-term compatibility version for making webp files, and those web-developers who want to show the radical power of webp would use maximum efficiency version for not-so-wide audience.

I myself need a maximum efficiency webp version to compress ~50 GB archive of JPEGs with as close to zero quality loss as possible, yet I found that recompressing JPEG->JPEG at q50 is almost as good as JPEG->WebP at q77 and that is sad.

please, please consider reaching maximum efficiency sooner rather than later.

[diana.v...@gmail.com]

more than a year has passed since the first suggestion(s) to make vp9 based webp mod. how much have been accomplished to reach vp9 level quality encoder?