Support » Plugin: Warp iMagick – Compress Sharpen Optimize Image Convert WebP Resize Upload » A Few Questions…
Hi, I’m trying Warp Imagick to see if it can replace our existing image conversion solution with better results. I do have a few questions, and hope it’s OK to ask here. Didn’t see a way to direct email.
Our case may be a bit different than most as we’re trying to keep quality on resized thumbnails as high as possible for a portfolio site that shows are images very large. So quality is a bit more important than max size reduction for us. We have about 8 thumbnail sizes that are generated from each high-quality original to fill our responsive images srcset.
1) It appears that the color profiles are being stripped from the images (both JPG & WebP), even if I choose ‘Do Not Strip At All’ from “Strip meta data’ setting. I tried settings different Color Spaces, but same result. How do we get it to retain embedded color profiles (ours will usually be standard sRGB IEC61966-2.1)?
2) Is there any way to invoke ImageMagick’s sharpen settings for resized images? By default, resized images are horribly soft. So we’ve had to rely on an ancient sharpening plugin that hasn’t been updated in 4-5 years. Would love to have an all-in-one solution.
3) What exactly does ‘WebP Compression Quality for JPEG images’ do? Does that just determine whether WebP uses the quality setting in the WebP box vs. what’s in the JPEG box?
4) Are WebP thumbnail images all generated from the original uploaded full-size JPG image? That would be ideal, as I believe our existing solution converts the already resized JPGs to WebP, so double compression (not good).
5) Is there any way to go beyond the imposed quality limits for special-case situations like ours? Our images unfortunately are photos/mock-ups of our projects (brochures, catalogs, etc), so they have large areas of solid color, small type, and photographic images all in one image. So compression artifacts become much more noticeable.
6) If this just isn’t the right solution for our needs (quality), do you know of any other suggestions?
Not sure if you’re the team behind the video on Squoosh, but I found that very informative and interesting! Seems like some of those concepts would be good to have as an option from within WP, so not sure if that is your purpose with this plugin.
THANKS FOR ANY HELP HERE!!!
1) Depends on few things
– If you look for profiles in the webp enabled browser, and .htaccess redirects jpeg to webp, all images will acctualy be webp (no metadata). Regardless of image extension (.jpg vs jpg.webp)
– If image is converted to sRGB from other colorspace, ‘icc’ profile should be removed from thumbnails, if not already
– Another plugin may set ‘image_strip_meta’ filter to true/false.
– If original image does not contain icc profile, ‘Do Not Strip At All’ can’t help.
Warp-iMagick doesn’t add icc profile to images converted to sRGB.
Warp-iMagick only removes icc profiles when instructed to do so, or icc profile has to be removed due conversion from another colorspace to sRGB.
AFAIK, sRGB images on the web do not need icc profile at all,
JPEG images without icc profiles are by default considered as having sRGB icc profile.
2) Yes. Sharpening may be be implemented in some future version.
4) No. That is not currently implemented because iMagick in most OS distributions I tested, is not, by default, compiled with WebP libraries. PHP-GD is used to convert from JPEG file to WebP file.
5) Configure Warp-iMagick to highest compression quality (85%). Next version may allow up to 95-100%.
6) There are plenty of image plugins on WP repository. I can’t know them all and all of your needs.
Tip: In Debian 10/PHP7.4.9, imagemagick-core is linked to libjpeg-turbo library. File compression using libjpeg-turbo is almost as good as WebP.
4) Warp-iMagic converts JPEG to WebP in same way as ‘cwebp’ program does, file to file, “so double compression (not good)”.
Hi, thanks for the quick & thorough responses! Much appreciated. I just had a couple follow-up notes.
1) So sorry, it did appear that the sharpening plugin we were using was using the GD library, and therefor stripping the profiles. I tried a different sharpening plugin, that uses ImageMagick and has parameters that can be adjusted, and it does appear to retain the ICC profiles, at least on the JPEGs. I’m testing in Adobe Bridge, which shows the proper profiles now for all of the JPEGs. But it still shows the WebP versions as ‘Untagged’. Not sure if Bridge just doesn’t really understand WebP images (there are no thumbnail previews), or if the WebP’s truly don’t have profiles.
– Do you happen to know a better method to verify WebP profiles, and ‘should’ they retain the profiles if the JPEGs have them?
2) Would love to see the option for sharpening here. It could be off by default (to save space), but nice for some to have the option if they need it. And it could be as simple as some basic defaults that are toggled on/off, or a couple choices (like heavy, mild, off).
4) Ah, thanks. That’s too bad. It would probably produce much better images if the higher quality WebP compression was used alone, rather than on the thumbnails that already have all the poorer JPEG compression artifacts added. Might defeat a lot of the benefits of WebP compression quality. With so many browsers now supporting WebP, those images would probably be seen by the vast majority of visitors over the fallback JPEGs. Even when trying to make pretty ‘high-quality’ images, the WebPs are still a fair amount smaller than the JPEGs.
We have a dedicated server that runs CloudLinux. We just had the support team add PHP 7.4.x to use as an option, and that’s what I’m using on the site I’m running these tests on. We had them install ImageMagick and the Imagick module, but don’t know anything about how it was compiled. Not sure if there are ‘defaults’. All I can tell is that its using ImageMagick v.6.9.10-68 Q16, and Imagick module v.3.4.4.
Thanks again for the support and a very nice plugin!
1) Colorspaces and ICC profiles are not the same thing.
ICC profiles are another standard, kind of “bridge for colors” when converting colors to another colorspace or to device (screen/printer). AFAIK, browsers do not need ICC profiles (or they have them internally built in) for internet standard sRGB colorspace. So, sRGB JPEG metadata may be completely removed.
WebP format does support (EXIF) metadata (including ICC) but I’m not aware of PHP tool/library that is able to write metadata into WebP. Anyways that would be beyond the intended scope of this plugin.
2) Currently I have another priorities to develop, but this may be eventually implemented.
4) In Warp iMagick, WebP files are generated from thumbnails and from original (quality) upload.
4) If you follow (Debian 10) package dependencies,
at the end you will find libjpeg-turbo:
4) ANOTHER TIP
Once you have libjpeg-turbo installed, you may replace it with MozJpeg (https://mozjpeg.com/). With MozJpeg installed, maybe you do not need WebP at all?
Thanks again for the support and a very nice plugin!
You are welcome to write a 5 stars review here. 🙂
Hi, thanks for the updates here! I have updated Warp Imagick and re-activated it to do some testing with the additional options you’ve added. The added sharpening, especially with the option to adjust, is VERY welcomed and could eliminate our dependency on a different plugin just for that feature. And not sure if the Color Sampling adjustments were in there before, but another welcome option to gain better quality for users like us!
So I’ve ran tests on a few sample images we use and comparing with the current optimization and sharpening plugins we use. After checking the results, which look very promising, I just have a couple follow-up questions if that’s OK.
7) Is your sharpening using a default ‘0’ for the threshold value? Our other plugin allows adjusting that (along with sigma and a couple other things), but not sure it’s mandatory. Just wondering so I know if I’m comparing apples-to-apples.
4) What does Warp use for WebP conversions? Is it a local install of cwebp, or does/can it use the WebP features of Imagick if it is compiled with it? And is it still converted after Imagick resizes the original and adds it’s own compression?
4b) Could it be possible (with a function or in a future release) to apply the option of using ‘sharp-YUV’ in the conversions of WebPs? I know cwebp, and even Imagick (if compiled with WebP) ‘can’ support it (see: https://titanwolf.org/Network/Articles/Article?AID=65aba585-2bd1-4977-8798-7db7502a7b1c#gsc.tab=0).
In our testing, we were surprised to see how much of a difference changing the chroma subsampling from 4:2:0 to 4:4:4 made, especially on certain types of images. Globally, the files were just cleaner, color edges a bit sharper. But on one ‘stress-test’ image we use that is of a package design with a vibrant red solid background with black, yellow, and white reversed type over it, the difference in quality is MASSIVE! I had to go back and check the settings and images to make sure I didn’t open the wrong image. And this image is also the one that shows the most degradation on the WebP versions. If it didn’t have a photo of the package contents (mixed nuts) in it, we might go PNG.
So we’re really wondering if the main issues we’re seeing with WebPs (besides them re-optimizing the already downsampled JPGs) is the known issues they have with fine details and certain vibrant colors. This is what ‘sharp-YUV’ is supposed to help, though not sure it will be as significant as going from 4:2:0 to 4:4:4 on JPGs. We just really want to see if this could make WebPs the optimal size AND quality option.
4c) Regarding the use of libjpeg-turbo / Mozjpeg, does this work to better the compression quality and results of the resizing Imagick does? Does Imagick need to be compiled to support it?
We’ve spent the last couple weeks working with our server IT staff to get the install of Imagick on PHP 7.4 compiled with WebP support, but its looking like on our server (cPanel; CentOS/CloudLinux), trying to get anything other than the default packages installed & working is just not possible and causes errors. So we are ‘stuck’ with either Imagick 3.4.4 running ImageMagick 6.9.10-68 Q16 with NO WEBP support, or a CloudLinux ‘alt’ PHP version which has ImageMagick 7.0.10-10 Q16 and DOES support WebP. The latter is what I was using in today’s tests.
Thanks again! Sorry for the long post. My head has been swimming in all the technical details of image conversions & techniques possible with WordPress the last few weeks…
7) No thresholds here. When 0, radius is automatically set
4) I answered that question earlier in this thread.
Generated WebP files are created by PHP-GD function:
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.
Using libjpeg-turbo or MozJpeg over standard libjpeg, doesn’t change image quality.
Libjpeg-turbo may execute faster using CPU features or same time to better reduce file size for same image/compression quality.
MozJpeg may reduce file size further but at the cost of execution time.
Hi, thanks for the quick responses! Much appreciated.
4) Sorry, you did say that above, my apologies. And this makes sense now, too, as to why the WebPs don’t have meta data (including ICC profiles), as GD doesn’t support that. And it also doesn’t look like the imagewebp that GD uses for creating WebPs supports the ‘sharp-YUV’ option, at least not from that PHP info page. That’s too bad…
And since it appears imagewebp/GD doesn’t support lossless encoding, how does Warp handle PNGs? We have a small portion of our images that are optimized as PNGs (things ilke logos, etc.). If Warp would convert these using standard lossy WebP conversion, I suppose we’d have to disable WebP when uploading PNGs. In checking some older files, it looks like WebP versions of PNGs are just a few KB smaller, with zero difference to image.
7) Thanks fo the clarification. It looks like the other sharpening plugin we were using uses UnsharpMask, which has a few additional options.
Having a hard time finding pros/cons to each method. And if Warp is doing the sharpening BEFORE the image is compressed with Imagick, where our plugin is after (I’m not sure how to figure this out for sure), that would be a big advantage either way as it wouldn’t be sharpening all of the Imagick jpg artifacts & noise.
4C) I’ll have to look more into how libjpeg-turbo and/or Mozjpeg could/would work in this workflow. I believe the other optimization plugin we’ve been using does use Mozjpeg, but just applies it to the already resized/optimized/saved Imagick thumbnails. So it’s just re-compressing the already compressed thumbnail files, resulting in no quality gains, just a tiny bit of additional filesize reduction.
I guess I’m realizing just how it seems that WordPress appears to be ‘hard-wired’ in using Imagick or GD to do the initial resizing & compressing of all images. This means anything else just happens in addition to this, and nothing would be able to actually ‘improve’ quality once the compression and image degradation has taken place. But I may be wrong here, still learning…
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.
Hi, thanks for the added clarity here. Sorry for all the questions, just really trying to understand the possibilities and limitations of WordPress/PHP/Imagick/CloudLinux/etc. to get the best possible quality images without them being MASSIVE in filesize. And I know our emphasis on quality may not be as important to most.
It does appear that CloudLinux on our server is using libjpeg-turbo. So we’ll investigate the links you sent to see if we can drop Mozjpeg in without causing everything to go haywire (which happened when trying to recompile Imagick with WebP support).
I think Warps’ workflow of sharpening images after resizing and before compressing is ideal for quality. So will probably produce the best quality JPEGs. And the option for adjusting Color Sampling Factor seems to help a fair amount as well. We’ll start there.
And if the final saved thumbnails are then sent to GD to produce the WebP versions, maybe we’ll just alter turning WebP support on for images that do well with WebP (typical photographs) and turn off for those that don’t (images with small vibrant-colored details, more ‘graphical’ images). We do like the fairly significant reduction in filesize that WebP offers, but at its default it just destroys the quality of very certain types of images.
Couple last questions if that’s OK:
– Is your Color Sampling Factor just adjusting the Imagick Sampling Factors (https://www.php.net/manual/en/imagick.setsamplingfactors.php)?
– What does ‘Compression Type’ alter, and what would be the differences between Imagick & WordPress defaults there?
Thanks again! A ‘hybrid’ approach may be what we’re needing to use to get around limitations of the different processes involved.
- The topic ‘A Few Questions…’ is closed to new replies.