Issue 567 in webp: Outline of the text is not as sharp as the original even without compression

[rafae… via monorail]

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

New issue 567 by rafae...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567

What steps will reproduce the problem?
1.Take a PNG without loss quality with TEXT
2.Export with ANY application to webP (with no compression)

What is the expected output? What do you see instead?
Text outline should be as sharpness as PNG original

What version of the product are you using? On what operating system?
libwebp7 1.2.2-1.1 on openSUSE Tumbleweed

Please provide any additional information below.
I have tried exporting from different programmes with the same result. The outline of the black text is clearly always more blurred in the webP version, while in the PNG it is perfectly defined.
- GIMP
- Gwenview
- XNview
- Digikam

Attachments:
original.png 36.4 KB
converted.webp 22.7 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

[ygu… via monorail]

Comment #1 on issue 567 by ygu...@google.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c1

Thanks for your report.

I believe what you call "webP (with no compression)" is WebP lossy quality 100. Quality 100 is still lossy; you have to explicitly enable "lossless" to have exactly the same pixels as your input PNG. This is because internally, lossy WebP converts the pixels to an internal color space (called YUV). Lossless WebP keeps the RGB data.

Unfortunately lossy WebP only supports subsampled chroma samples internally; meaning sharp, colorful edges may "bleed" to neighboring areas.
libwebp has a feature called "Sharp YUV" to mitigate this issue, but it is not available on all editing software.

You can check https://squoosh.app/ that offers it. I attached a few examples with custom settings.

Attachments:
gimp_lossless.webp 29.3 KB
squoosh_lossless_effort9.webp 19.1 KB
squoosh_lossy_effort6_q90_sharpyuv.webp 16.2 KB

[rafae… via monorail]

Comment #2 on issue 567 by rafae...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c2

After reading your comment, I have checked that none of the programs I use (GIMP, Krita, Digikam) mentions in the advanced options the option "Sharp YUV", not even Krita, which is the one that shows more options (I attach a screenshot of the options in English). However, if I select the "Text" profile in Krita's simple export options, the result, although with some artifacts, shows the text much sharper than even the "Squoosh" export, but occupying only 7KiB!!! I don't know why the "Sharp YUV" option doesn't appear.

The lossless webP export with these applications is always almost identical in size to the original PNG. "squoosh.app" however, let play me with "Effort" and "Slight loss" getting a near identical to PNG version with only about 11KiB size, but changing slightly the background colour. So "Squoosh" did the best job.

Those options of Squoosh should be available in applications using libwebp to let user get a decent result.

Attachments:
Krita - advanced webP export options.webp 34.7 KB
Digikam - left orignal PNG , right Krita webP text profile.png 119 KB
convertido con Krita.webp 7.4 KB

[jz… via monorail]

Comment #3 on issue 567 by jz...@google.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c3

> Those options of Squoosh should be available in applications using libwebp to let user get a decent result.

That would be a decision for the application maintainers. We try to do our best with documentation and exposing the options in the tools we maintain. I think it would be good to file issues with those applications using this as a reference.

[rafae… via monorail]

Comment #4 on issue 567 by rafae...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c4

I'll open an issue to those applications, referencing this thread.

Thank you for your help and your good job developing and enhancing webP.

[jz… via monorail]

Updates:
Status: Done

Comment #5 on issue 567 by jz...@google.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c5

Thank you for the report and following up with those applications. It's difficult to track what is supported across so many.

I don't think there's anything to be done for libwebp, but if you run into any issues please feel free to file a new bug.

[jehan… via monorail]

Comment #6 on issue 567 by jehan...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c6

Hi! I know it's closed, but may I ask: is the "sharp yuv" option any relevant in the lossless WebP case?

From what I understand from above comment, it should not matter at all:

> I believe what you call "webP (with no compression)" is WebP lossy quality 100. Quality 100 is still lossy; you have to explicitly enable "lossless" to have exactly the same pixels as your input PNG. This is because internally, lossy WebP converts the pixels to an internal color space (called YUV). Lossless WebP keeps the RGB data.

And making a quick test in lossless with and without the option, the file size and pixel values are exactly the same, which seems normal (per definition of "lossless") and confirm the quote.

Yet in some random blog (https://www.ctrl.blog/entry/webp-sharp-yuv.html), someone is saying:

> The lossless WebP image file sizes was 0,3–0,1 % smaller with the sharp YUV option. This last one is quite surprising as it shouldn’t have any effect on the lossless encoding. There is a tiny positive file size reduction overall with the sharp YUV option but it’s insignificant.

It may be "insignificant", yet apparently there could still be a different (in specific cases?)?

For the record, I am asking because a contributor just implemented this option in GIMP but I have been wondering if we should make the option inactive when "lossless" is checked or if it can still make a different "somehow". Thanks! :-)

[ygu… via monorail]

Comment #7 on issue 567 by ygu...@google.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c7

> is the "sharp yuv" option any relevant in the lossless WebP case?

No. "Sharp yuv" is only relevant to the lossy WebP case which encodes YUV 4:2:0 samples internally (chroma subsampling), whereas the lossless WebP case encodes RGB samples internally (no subsampling).

You may reach to the blog author to get a reproducible example but I would expect there was some confusion somewhere.

[jehan… via monorail]

Comment #8 on issue 567 by jehan...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c8

Actually forget the question. I thought it would be much simpler to just grep libwebp repo, then it's pretty clear (only usage of `use_sharp_yuv` in the code):

------------------
if (!config->lossless) {
[…]
if (config->use_sharp_yuv || (config->preprocessing & 4)) {
if (!WebPPictureSharpARGBToYUVA(pic)) {
return 0;
}
------------------

So yeah the option is useless and not used at all in non-lossless case. Sorry for the noise!

[jehan… via monorail]

Comment #9 on issue 567 by jehan...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c9

> No. "Sharp yuv" is only relevant to the lossy WebP case which encodes YUV 4:2:0 samples internally (chroma subsampling), whereas the lossless WebP case encodes RGB samples internally (no subsampling).

Oh I hadn't seen your answer when I made my last one. Thanks for confirming in any case! :-)

Anyway I'll make the option inactive in GIMP when "lossless" is checked, then!

> You may reach to the blog author to get a reproducible example but I would expect there was some confusion somewhere.

I guess I'll just leave a comment (looks like we can leave unidentified comments) and point them here. Up to them to decide if they want to follow up with a reproduction case. ;-)

[ygu… via monorail]

Comment #10 on issue 567 by ygu...@google.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c10

> the option is useless and not used at all in non-lossless case

the option is useless and not used at all except* in non-lossless case

> I'll make the option inactive in GIMP when "lossless" is checked

Great, thank you.

> I guess I'll just leave a comment

Thanks!

[jehan… via monorail]

Comment #11 on issue 567 by jehan...@gmail.com: Outline of the text is not as sharp as the original even without compression
https://bugs.chromium.org/p/webp/issues/detail?id=567#c11

> the option is useless and not used at all except* in non-lossless case

Ahah yeah sure. Just wrote too quick. ;-)

Anyway I left a comment to this blog post (gone through moderation, we'll see if they ever see it).