WebP support

[MaxSt]

New image format from Google:

http://code.google.com/speed/webp/gallery.html

The format Is very young, so no image viewers support it, but... it's a good opportunity for XnView to be the first! Please, add WebP support!

[xnview]

Yes, i've seen it

[Drahken]

I think webp is a bad idea. There are already several JPG replacement formats floating around (jpeg 2000, hdphoto/jpeg-xr for example), and none are getting very widespread support yet (jp2k's the best supported, but it's been around for many years now & seems likely to die a quiet death). Adding yet another one at this point will only muddy the waters & make it so that none of them get widespread support. Additionally, the size improvements aren't very significant over JPEG, and webp is apparently limited to the lowest quality chroma subsampling (meaning all webp pics will look as bad as the worst jpeg pics). High quality subsampling (ie, no subsampling) has a massive effect on quality while only impacting filesize slightly, throwing that away in webp is indescribably stupid.

It would probably be best for xnview to support webp since ones of xnview's best features is the fact that it can read nearly any image format, but I hope the webp format itself dies off quickly.

[MaxSt]

Adding yet another one at this point will only muddy the waters & make it so that none of them get widespread support.

Trying new things is always good. Look at video codecs, how many new ones we saw since DivX 3 days? Probably hundreds. They compete, they learn from each other, some die, but top codecs right now are much much better than DivX 3.

Two jpeg alternatives in 20 years is not enough. Let google try. Let hipix try.
If they'll fail, others will learn from it.

webp is apparently limited to the lowest quality chroma subsampling

It's not just subsampling in encoder, but decoder have to upscale it correctly. Right now their decoder is absolute crap. Instead of interpolating chrome samples, it just doubles them. I send them some horribly pixelated examples, and they promised to fix it:

http://code.google.com/p/webp/issues/detail?id=14

I hope the webp format itself dies off quickly.

I hope WebP can and will be improved. They are not experts in image compression, but they could learn.

[DOS386]

I think webp is a bad idea. There are already several JPG replacement formats floating around (jpeg 2000, hdphoto/jpeg-xr for example), and none are getting very widespread support yet (jp2k's the best supported, but it's been around for many years now & seems likely to die a quiet death).

JPEG-2000 is proprietary (RTFL) so it's useless. Similar applies to other competitors: proprietary or too slow, useless.

Adding yet another one at this point will only muddy the waters & make it so that none of them get widespread support. Additionally, the size improvements aren't very significant over JPEG

Good point.

Trying new things is always good.

Not always. New things are only good if they are significantly superior to old stuff and don't have critical regressions (JPEG-2000 has a critical regression in license/legal area).

Look at video codecs, how many new ones we saw since DivX 3 days? Probably hundreds.

99.9% of them are useless

They compete, they learn from each other, some die, but top codecs right now are much much better than DivX 3.

Just the competition is far away from fair

BTW, there is a need for a JPEG replacement, for following reasons:

- Lossless JPEG "recompression" exists (JPEG must be bad if this really works ...)
- JPEG spec is bad (too complicated, only a subset is used)

http://code.google.com/speed/webp/faq.html
http://code.google.com/speed/webp/docs/ ... ainer.html

Also, this WebP is based on VP8 video codec (good) but the RIFF is a very bad idea. I haven't really evaluated the thing yet.

What I primarily want to see about WebP (or any other JPEG replacement or some other new thing) one day is a high quality specification.

[MaxSt]

Not always. New things are only good if they are significantly superior to old stuff and don't have critical regressions

Always. Not-superior ones could serve as a learning experience for others. I consider it good too.

[rabbat]

MaxST,
check out the nightly build of Chromium and the updated lib-webp-decode

http://code.google.com/p/webp/issues/detail?id=14
has been addressed

[budz45]

Another sample gallery;
http://code.google.com/speed/webp/gallery1.html

---------------------

Right,

It would be good if WebP and WebM as now added to the XnView 'Formats' website page
http://xnview.com/en/formats.html

[DOS386]

would be good if WebP and WebM as now added to the XnView 'Formats' website page http://xnview.com/en/formats.html

WebP is already there (but fails to mention that only by plugin, and how far this includes the later lossless and transy flavor, or not).

WebM is a video format and NC/XN doesn't support it.

[eL_PuSHeR]

I downloaded a precompiled win32 version yesterday. It includes the lossless format to transform from and to PNG. The lossless format has a webpll extension and cannot be opened yet.

Lossy compression can be opened normally under XnView (using 1.98.6), but when invoking file properties it shows compression: none.

It should say compression: webp lossy.

png2webpll is also SLOW AS HELL (but Google already stated that at this moment).

It packs files tighter than PNG though. It would be real cool if XnView would support this lossless flavour although I find rather idiotic to use a separate file extension for it.

[Drahken]

Have you tried renaming the file to a webp extension & see if xnview can open it?

[eL_PuSHeR]

Yes I did.

Headers are completely different

Start of WEBP Lossy header:

RIFF:ø WEBPVP8

Start of WEBPLL Lossless header:

È8’Øæ
A(

They are completely different formats (Google already stated that too).

[DOS386]

I downloaded some binaries from "Nov 17" ... authors don't offer a single lossless file themselves!!! (there are a few lossy ones, finally). I started it ... no result ... either it hangs or it's too slow (PNGOUT was done after few s with same image). OK, got a result, only with -c 0 2x bigger then PNG ... and at least 10x slower than PNGOUT, messages are strange, what's the default value of "c" ??? Where is TFM ? Where is the spec ? File begins with $42 $15 $DC $A8 ... it's a completely different format. Why don't they put "WebP" in there (with some non-printable char's like PNG did) ?

[eL_PuSHeR]

No. It's not hanging. It's just pretty slow. Try with a small PNG file first (maybe less than 50KB in size).

[Froggy01]

I just want to make a small remark about WebP format support in XnView:

In the formats documentation page, it is not metionned that a plugin is required to read WebP images...
There should be a blue image like this

Not sure if this topic is appropriate, but I found no one more relevant...