WebP vs HEVC

[Jonathan Ozik]

I was reading wikipedia at:
http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding 
and stumbled on a line:

For still images HEVC reduced the average bit rate by 

15.8% compared to H.264/MPEG-4 AVC,

22.6% compared to JPEG 2000,

30.0% compared to JPEG XR,

31.0% compared to WebP,

and 43.0% compared to JPEG

is there any plans for WebP to evolve info more efficient codec than HEVC?

or being more efficient than JPEG is all one can expect from WebP?

[oX Triangle]

adds follow facts..
the new jpeg-encode is 25x slower
the new jpeg-decode is 3x slower

and i think no hardware acceleration possible

webp has there mainpower in ranges of verylowbitrate

and possible hardware accelerations (VPx-Codecs)

and is not final ;-)

[oX Triangle]

oh sorry I thought you were talking about new mozjpeg2

[Jyrki Alakuijala]

WebP claimed to be only 8 % better than JPEG does not seem to match reality. When we measure it with a random sample of pictures taken from the internet we see closer to 30 % improvement in both lossy and lossless.

In one study they most likely resampled the Y-component to 512x512 internally before psychovisual metrics, leading to much worse results than one would get when doing the analysis without resampling. Perhaps the results of this study are repeated here.

On Fri, Jul 18, 2014 at 8:17 AM, oX Triangle <oxdos...@googlemail.com> wrote:

oh sorry I thought you were talking about new mozjpeg2

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Pascal Massimino]

Hi,

On Thu, Jul 17, 2014 at 7:57 AM, Jonathan Ozik <joz...@gmail.com> wrote:

I was reading wikipedia at:
http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding 
and stumbled on a line:

For still images HEVC reduced the average bit rate by 

15.8% compared to H.264/MPEG-4 AVC,

22.6% compared to JPEG 2000,

30.0% compared to JPEG XR,

31.0% compared to WebP,

and 43.0% compared to JPEG

is there any plans for WebP to evolve info more efficient codec than HEVC?

Pure efficiency is not the only dimension to image-on-the-web.

Features and overall complexity are another ones (think of battery life).

Along with other non-technical considerations.

 

or being more efficient than JPEG is all one can expect from WebP?

There's that, but not only. Other non-JPEG features are useful in reducing

bandwidth overall

 (see for instance numbers reported here http://chrome.blogspot.fr/2014/01/more-web-more-savings-with-chrome-for.html).

[Jonathan Ozik]

ok. would it make sense for me to petition Google (and/or WebP devs) to add a goal in WebP RoadMap to try and increase WebP codec efficiency to a point where it would rival or even outperform HEVC? (yes/no)

if so, *HOW* could I petition Google (and/or WebP devs) to add higher efficiency into RoadMap?

[Pascal Massimino]

Hi Jonathan,

On Fri, Jul 18, 2014 at 8:52 AM, Jonathan Ozik <joz...@gmail.com> wrote:

ok. would it make sense for me to petition Google (and/or WebP devs) to add a goal in WebP RoadMap to try and increase WebP codec efficiency to a point where it would rival or even outperform HEVC? (yes/no)

it's been stated several times that WebP will a-priori stick to VP8 for lossy compression for any foreseeable future.

One have consider the cost of introducing new versions and formats in a installed format, and the afferent cost of this disruption.

Going for alternate higher-efficiency formats is of course being researched (after all, VP8 already evolved into VP9),

but that is a parallel effort.

Note that if very-high efficiency is your interest, you can use HEVC format with a single keyframe and the <video> tag.

Also, there are interesting formats like https://sites.google.com/site/dlimagecomp/ if you are looking for a pure storage

solution.

if so, *HOW* could I petition Google (and/or WebP devs) to add higher efficiency into RoadMap?

--

[Brendan Bolles]

On Jul 19, 2014, at 2:36 AM, Pascal Massimino wrote:

> Also, there are interesting formats like https://sites.google.com/site/dlimagecomp/ if you are looking for a pure storage
> solution.

Interesting! Sounds like it's able to really crush files without losing quality at the expense of long encoding times, which is ideal for web when you encode once and then download many times (assuming decoding times are not also long).

Too bad it looks like there is no plan to release the code.


Brendan

[Jonathan Ozik]

Thank You for all Your answers and I apologize for becoming somewhat annoying with my VP9 obsession.

One more question: If You would have to make an educated guess on how much slower VP9-based-WebP-encoder be compared with VP8-based-WebP-encoder? If todays VP8-based-WebP-encoder takes 1-3 seconds to encode 1 image, how many seconds would You think it would take for VP9-based-WebP-encoder to encode the same image on the same PC?

[James Zern]

Hi,

On Wednesday, August 13, 2014 4:43:59 AM UTC-7, Jonathan Ozik wrote:

Thank You for all Your answers and I apologize for becoming somewhat annoying with my VP9 obsession.

One more question: If You would have to make an educated guess on how much slower VP9-based-WebP-encoder be compared with VP8-based-WebP-encoder? If todays VP8-based-WebP-encoder takes 1-3 seconds to encode 1 image, how many seconds would You think it would take for VP9-based-WebP-encoder to encode the same image on the same PC?

I haven't tried to match size/quality at all, but below are some quick notes about using vp9 via ffmpeg if someone wanted to do comparisons.

$ ffmpeg -y -i <image> -psnr -c:v libvpx-vp9 out.ivf/webm
-cpu-used 0..16 will affect speed, as will -deadline realtime
-b:v -qmin/-qmax will affect quality and output size; setting the latter two to 0 will do lossless.
-benchmark_all will give encode-only timings, but you'll need to sum
encode+flush unless you use '-lag-in-frames 0'.
-cpu-used 6 + realtime is a little less than 2x, but it drops off from

there pretty quickly.