"sharp_yuv"-option

[HDDen]

What about passing "sharp_yuv"-argument to cwebp? It increases result's webp quality, especially on contrast red-blue patterns. Details, for example, is here https://www.ctrl.blog/entry/webp-sharp-yuv.html

[HDDen]

Found solution in the documentation

$options = array(
    'converter-options' => [
        'cwebp' => [
            'command-line-options' => '-sharp_yuv',
        ],
    ],
);
Stack::convert($source, $destination, $options, $logger=null);

Maybe add similar option to imagickbinary? To be able to set additional parameters, e.g. "-define webp:use-sharp-yuv=1"

[rosell-dk]

It seems to be an overlooked option, which deserves to be promoted in webp-convert, by implementing it as a separate option. Will do!

[rosell-dk]

Which default do you think would be appropriate?
When converting pngs to lossy (ie with encoding:auto), I think "on" would be appropriate.
How about jpegs?

[rosell-dk]

Setting default to "off" would be sensible in the sense that it doesn't change the current behavior. But on the other hand, it is a weak argument if "on" generally provides better visual quality. Before deciding, it should be tested how much longer conversion takes with this setting. We don't want big images to take forever to convert.

[rosell-dk]

I implemented the option for cwebp and imagemagick. It is called "sharp-yuv" (note the dash rather than underscore). I will see if it can be implemented in more converters before I close the issue

[rosell-dk]

ffmpeg and vips does not currently support the sharp_yuv option, which means I'm done

[rosell-dk]

Actually, I just discovered that vips does support use_sharp_yuv. It just called it something else! ("smart-subsample"). This means I must deprecate that special option for vips and use "sharp-yuv" instead

Bwt: Found out by looking in the Vips sourcecode: https://github.com/libvips/libvips/blob/master/libvips/foreign/vips2webp.c

[rosell-dk]

Created a new issue for it: #280

[HDDen]

Which default do you think would be appropriate?
When converting pngs to lossy (ie with encoding:auto), I think "on" would be appropriate.
How about jpegs?

Hello! I think, jpeg's also need "on" by default. Potentially, in autogeneration-mode (on demand, for example) this give higher picture quality at the cost of an insignificant increase in bytes. Me using sharp_yuv with %86-quallity, and result is great (better is avif only).

[HDDen]

But, by several hostings installed cwebp 0.3.0, which haven't "-sharp_yuv" command. This may cause error during converting with "on"-option by default.
Especcially this problem go with VPS on CentOS, because installing libwebptools from repo's installs old versions of packets.

[rosell-dk]

Good thing you discovered this before it was published :)

The solution is to only pass the option to versions of cwebp that supports it.
This kind of functionality is already in our library (in Cwebp.php).

We must now examine which versions of cwebp that supports the option.
We should also examine what happens when trying to set this option in Imagick, etc, when using an old version of libwebp

[rosell-dk]

It seems that the sharp_yuv option it was added in cwebp 0.6.0-rc2:
webmproject/libwebp@4689ce16

[rosell-dk]

Yes, cwebp 0.5.0 fails with the following error (when called with the option):
Error! Unknown option '-sharp_yuv'

[rosell-dk]

Fixed for cwebp.
@HDDen: Can you check what happens when the option is passed to imagickbinary on your VPS with the old libraries on it?
(-define webp:use-sharp-yuv=1)

[rosell-dk]

Reopened, because it must be checked for imagickbinary with old libraries installed

[HDDen]

@HDDen: Can you check what happens when the option is passed to imagickbinary on your VPS with the old libraries on it?
(-define webp:use-sharp-yuv=1)

Hello! Tested on ImageMagick 6.9.10-68 Q16 x86_64 2021-02-24 with CentOS Linux release 7.9.2009 (Core)

Launched two command, and visually result haven't differences (in my opinion, webp:use-sharp-yuv=1 isn't working on this version, but I cannot verify it exactly, because generally using cwebp and haven't any test VPS).

convert /var/test.png -quality 86 /var/test.png_magick-regular.webp
convert /var/test.png -quality 86 -define webp:use-sharp-yuv=1 /var/test.png_magick-sharp.webp

Also processed test picture with cwebp, using these commands (to compare sharp_yuv between imagemagick and cwebp):

cwebp -q 86 /var/test.png -o /var/test.png_regular.webp
cwebp -q 86 -sharp_yuv /var/test.png -o /var/test.png_sharp.webp

Result :

Result images also available here

[rosell-dk]

Ok, as expected. Thanks for testing!

ImageMagick, GraphicsMagick and their extensions generally ignore unknown options - at least on newer libraries. Just wanted to be completely sure that the old libraries didn't abort when called with unknown options.

[rosell-dk]

@HDDen: Just want to let you know that I just released 2.6.0, so the sharp-yuv option is available now