Issue 536 in webp: PNG > WEBP lossless convertion not lossless

[necro… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 536 by necro...@gmail.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536

What steps will reproduce the problem?
1. Convert attached file with "cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless sample.png -o sample.webp"

What is the expected output? What do you see instead?
reduced number of colors

What version of the product are you using? On what operating system?
1.2.1rc2 win10x64 20h2

Please provide any additional information below.

Attachments:
sample.png 501 KB

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[jz… via monorail]

Comment #1 on issue 536 by jz...@google.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536#c1

Thanks for the report. Can you attach sample.webp as well? By default even with -lossless some hidden pixels (due to alpha) may be modified to improve the compression [1]. You can use -exact to make the image completely lossless.

How are you checking the number of colors or is the webp visibly different from the original? On windows the code will use a native Windows Imaging Component (WIC) decoder so the result can vary based on what's installed. You can compare the result using the '-no-wic' binaries.

[1] https://developers.google.com/speed/webp/docs/cwebp#options

[necro… via monorail]

Comment #2 on issue 536 by necro...@gmail.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536#c2

So why not to rename -lossless to -nearlossless and the whole point of webp breaks when you use exact - cause filesize becomes bigger than original

[jz… via monorail]

Comment #3 on issue 536 by jz...@google.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536#c3

> So why not to rename -lossless to -nearlossless

-near_lossless is a separate feature which will cause visual differences to the original. With -lossless (but not -exact) the image will be visually lossless.

> ... and the whole point of webp breaks when you use exact - cause filesize becomes bigger than original

On linux I get the same result with and without -exact (cwebp -lossless ...), so it would be good if you can try the -nowic versions to see if you see any difference in behavior.

size in bytes:
628889 sample.png
408810 sample-exact.webp
408810 sample.webp

md5sum:
8cc5cdc8e8eb95e16ebcee32e13751a5 sample.png
3bf4ffec93cc1e9e621fd571084bade4 sample-exact.webp
3bf4ffec93cc1e9e621fd571084bade4 sample.webp

[jz… via monorail]

Comment #4 on issue 536 by jz...@google.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536#c4

On a base install of Windows 10 1909 18363.1874 I get the same results with WIC and -nowic as well as -exact. In my case the default Windows PNG decoder is being used according to WIC Explorer [1].

[1] https://docs.microsoft.com/en-us/windows/win32/wic/-wic-samples

[rafae… via monorail]

Comment #6 on issue 536 by rafae...@gmail.com: PNG > WEBP lossless convertion not lossless
https://bugs.chromium.org/p/webp/issues/detail?id=536#c6

I discovered this thread just after I opened mine, but the conclusion is the same https://bugs.chromium.org/p/webp/issues/detail?id=567

I was trying to impose the use of webP on our corporate site, but unfortunately I have to admit that webP doesn't do "magic" and preserves the sharpness and colours of the original image. In my case, as in this thread, it is clear that the outline of the texts in general is not as well defined as in the original, and even the red colour of the background changes slightly. I don't have particularly good eyesight, but I notice the difference!!! The truth is that I was hoping that at least when exporting to webP without compression, the result would be the same as the PNG .... but it is not like that.

Translated with www.DeepL.com/Translator (free version)