0.71 WebP lossless still bugged

[fireattack]

Windows x64 zip

See: http://newsgroup.xnview.com/viewtopic.php?f=62&t=30793

I chose lossless, but the result is still a lossy file.

[xnview]

you have not the same as cwebp?? Could you send me orignal file, and saved file, please

[foxyshadis]

Are you sure the loss isn't introduced in converting from RGB to YUV and back? Some colors can be badly affected by that, especially in very light and dark regions. I don't think XnView uses RGB in WebP at all, so it's only lossless after the conversion to YUV.

[fireattack]

you have not the same as cwebp?? Could you send me orignal file, and saved file, please

I use the following command: cwebp -lossless original.png -o output.webp

For xnview I use:



The results and original:

https://www.dropbox.com/sh/poqmnuh6nb94 ... jYPDa?dl=0

[fireattack]

Are you sure the loss isn't introduced in converting from RGB to YUV and back? Some colors can be badly affected by that, especially in very light and dark regions. I don't think XnView uses RGB in WebP at all, so it's only lossless after the conversion to YUV.

Hmm, I'm not sure I get your point. AFAIK what you are talking is about lossy webP, not lossless one.

[xnview]

i've checked the file, and it's lossless but i don't understand why output size is different...

[fireattack]

i've checked the file, and it's lossless but i don't understand why output size is different...

OMG, it's not, I don't even know how you can tell it is lossless, compare by naked eyes?

Just convert it back to png or bmp by xnview, and then subtract it from the original png by Photoshop or GIMP. The difference is small (apparently, since it's high quality compression) but it's not zero. The difference between original and cwebp produced webp IS zero (a.k.a. all black). I just added these files (difference PSD, and png versions converted from the webps) to the dropbox folder above.

For the lazy, here is the the difference after enhancement:

[furmanda]

Hello, I registered to report this exact same thing.

The files encoded with webp lossless also do not match their original for me. To determine that, I used the "search for similar files" tool, which shows crc of the images.

If I save the image with XnView MP (version 0.72, Windows 8.1 64, both x64 and 32-bit builds are affected), the crc won't match and similarity 99 is reported.
Image encoded with cwebp.exe from Google will have matching crc to the original (in my case, I used png) and similarity 100.

Also XnViewMP produces image with smaller filesize, too, which is probably caused by the same bug/glitch leading to non-losslessness. If I had to guess, maybe a non-lossless color conversion was used and rounding errors happened, or post/pre-processing was not disabled? But I'd expect the library to use the correct algo automatically, when lossless mode is enabled...

[fireattack]

Hello, I registered to report this exact same thing.

The files encoded with webp lossless also do not match their original for me. To determine that, I used the "search for similar files" tool, which shows crc of the images.

If I save the image with XnView MP (version 0.72, Windows 8.1 64, both x64 and 32-bit builds are affected), the crc won't match and similarity 99 is reported.
Image encoded with cwebp.exe from Google will have matching crc to the original (in my case, I used png) and similarity 100.

Also XnViewMP produces image with smaller filesize, too, which is probably caused by the same bug/glitch leading to non-losslessness. If I had to guess, maybe a non-lossless color conversion was used and rounding errors happened, or post/pre-processing was not disabled? But I'd expect the library to use the correct algo automatically, when lossless mode is enabled...

The smaller size is simply because it's actually lossy.

Since XnView is using Google's offical libary, I guess there are two ways to have this bug:
1. Xnview uses wrong parameters when delivering them form GUI to lib;
2. Google's lib is inborn bugged .

[xnview]

ok, i found the problem

[furmanda]

That's great! Thanks for looking into it

[xnview]

See Issue 563 for current status and details.

[furmanda]

I tried with the 0.75 beta build linked in announcement post.

It seems that lossless webp still gives different CRCs than the input, so there must still be some rounding issue or something like that. At least that happens when I use the "find similar pictures" feature to check it, I didn't know what other tool to check to see if the decoded data match completely.

Trying with this picture (but also others): http://blogs.nvidia.com/wp-content/uplo ... bundle.png

The comparator tool shows different CRCs for the original PNG and a lossless webp. When I take the webp and resave it as PNG, the resulting file has the same CRC as the webp input.

For this image, I am getting these crc values:

original:
1555617423

webp:
1038750730

webp resaved as PNG:
1038750730

original resaved as PNG:
1555617423

In compression settings, I have "lossless" ticked on and "compression method" set to 6, for webp.

If I use cwebp.exe from Google (cwebp.exe -lossless -m 6 bundle.png -o bundle_cwebp.webp), Xnview reports the same crc as with the original png file (1555617423).
(Edit: the file from cwebp also has 2 kb higher filesize.)

[xnview]

I tried with the 0.75 beta build linked in announcement post.

It seems that lossless webp still gives different CRCs than the input, so there must still be some rounding issue or something like that. At least that happens when I use the "find similar pictures" feature to check it, I didn't know what other tool to check to see if the decoded data match completely.

was fixed in 0.72, no????

[furmanda]

With 0.72 it was happening too, that was where I was reporting it first in december earlier in this thread. The tracker says you fixed it in 0.75, but in the 0.75 beta build it seems to be still present (or maybe the commit was not pulled in into that build or something...).