ddur

4) The GD/imagewebp does compress PNG in the lossy way to WebP as it should be, because that is purpose of WebP images. Why would you want lossless webp compression from lossless PNG? That can’t save much of file size, if any.

It seems to me that you don’t need/want WebP at all.

‘sharp-YUV’ is irrelevant here because ImageMagick is not used for WebP because ImageMagick is by default compiled/packaged without libwebp. No plugin should or will expect from users to be able to compile ImageMagtick with libwebp.

Function GD/imagewebp doesn’t have that option. I don’t see it as “bad”, just as reality of modules/libraries available to PHP.

You maybe want to contact and influence authors/contributors of libgd, PHP-GD, ImageMagick, PHP-Imagick, libwebp and their respective package maintainers for most common Linux distributions.

WebP is optional. Just disable WebP and you will be perfectly fine with JPEG/PNG image quality & colors.

7) Warp iMagick is doing the sharpening (AFTER resize and) BEFORE the image is compressed.

Warp iMagick plugin is not for everyone. Plugin is for users that don’t want external services and users that are not allowed (or have no ability or no intention) to install, compile and/or execute binaries on the hosting server.

https://wordpress.org/plugins/tags/webp/
https://wordpress.org/plugins/search/webp/

Depends. If you have cPanel you will find it somewhere there.

https://support.cpanel.net/hc/en-us/articles/360051565714-How-do-I-verify-an-Apache-module-is-enabled-for-my-server-

Else ask your hosting provider, he would know what is going on. So far, from 1000+ installs, only one user had reported such a problem.

.htaccess itself may not be enough, configured/used Apache modules must be enabled. Maybe you have Nginx server? Maybe you use CDN that is caching first response?

7) No thresholds here. When 0, radius is automatically set
https://www.php.net/manual/en/imagick.sharpenimage

https://phpimagick.com/Imagick/sharpenImage?imagePath=Lorikeet&radius=0&sigma=1&channel=134217727

4) I answered that question earlier in this thread.

Generated WebP files are created by PHP-GD function:
https://www.php.net/manual/en/function.imagewebp.php

4b) Plugin doesn’t use ImageMagick to create WebP. See 4).

If some image requires exceptional settings, you can regenerate that image & thumbnails with changed setting and then return settings back to your chosen defaults. Use https://wordpress.org/plugins/regenerate-thumbnails/

4c) As far as I remember, ImageMagick is dynamically linked to libjpeg-turbo and doesn’t require recompile to use MozJpeg. Open & read links about MozJpeg, given in earlier messages.

Compiling ImageMagick with WebP library won’t change anything, because plugin use standard ImageMagick install and doesn’t use/require ImageMagick to generate WebP files at all.

@mcidesarrollo

1) Does force-convert-colorspace works for your unusual images now?

2) Until resize is re-implemented, you may use another plugin:

https://wordpress.org/plugins/resize-image-after-upload/

I tried it now.
Looks like it works fine.

@mcidesarrollo

BTW, there is a new test option to force colorspace conversion when original colorspace is undefined, but ImageMagick maybe uses ICC profile instead?

Please let me know if that works for your images.

@mcidesarrollo

Yes, it is removed because it is not reversible on regenerate. There were to many options to handle on regenerate, which in some cases may create a mess in thumbnails.

You may still enable Big Image Size Threshold.

Since that resize is not reversible like Big Image Size Threshold (which tries to preserve an original unmodified), resize option is planned to be moved/implemented on upload event and to be executed only once, without further complications when regenerating thumbnails.

https://www.geckoandfly.com/7987/how-to-change-exif-data-date-and-camera-properties-with-free-editor/

https://stackoverflow.com/questions/5384962/writing-exif-data-in-php