Imagemagick compress jpg7/3/2023 ![]() ![]() Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. The "good" JPGs on server 1 were produced by Lightroom with setting 70 and therefore match the pattern.) (The Photoshop value 70 seems to correspond to 65 in Lightroom, a bit more than 80 in Affinity Photo and something around 90 in Pixelmator Pro. In Photoshop, a quality setting of 70 (of 100) and better leads to fairly or even much smaller WebPs, while the saving decreases with lower quality until there happens a turnaround to even bigger WebPs, approximately at 60. Meanwhile I did a bit more testing and found a clear correlation to the JPG compression rate. You'll be surprised at the tradeoffs between image quality and filesize you can achieve. squoosh.app has a nice interface for WebP options – open a test image, select WebP in the compress menu and play around with the settings a bit. There's also a range of other options to tweak to get optimal results, so maybe play with that a bit before you give up on WebP altogether. WebP can encode lossless images, maybe the 'bad' server is doing that? Or if you're doing lossy compression, maybe you just need to set the WebP encoding to a lower quality level – WebP lossy encoding also has a quality setting between 1 and 100, same as JPG. This one only talks about JPG, but you can use a element with two elements, one for WebP and one for JPEG.Īnother thing to consider if you're seeing wildly different results on two different servers, maybe those just use different settings. See my tutorial on using responsive images in ProcessWire for details. In fact, you'll want to generate multiple variants in different resolutions for different screen sizes. You want to upload high-quality JPGs (Quality setting of 90~100) and then generate compressed variants in JPG / WebP based on the source image. That said, uploading pre-compressed JPGs and then converting them to WebP is not a good idea. Re-encoding an already heavily compressed image will always result in a garbled image and larger filesize, regardless of format. ![]() So there’s a good chance that I will join your Besides filesize, how does the visual quality of both images compare? Do the WebP images look better, worse or the same as the JPEG files? If you have a slightly larger filesize for a much better image, that might still be a good trade-off. Measured in figures you might have better image quality, but I doubt that the difference will be recognized by the average user. To achieve a noteworthy saving in the WebPs, you have to produce unreasonably big JPGs first, but the resulting WebP will be bigger than your more realistic old-school JPG before. The "good" JPGs on server 1 were produced by Lightroom with setting 70 and therefore match the pattern.)Īll things considered, the advantage of this "next-gen format" is hard to detect. Is there any influence on the WebP conversion I might have Thanks for your feedback, glad to know I’m not alone. So I’d consider the WebP use on server 1 as clearly progressive, while server 2 essentially limits itself to fill up the webspace with bigger images that will never appear on a display. The JPG quality on server 1 is about the same (regardless the 41 lousy ones), the only difference is their smaller size of 900 x 600 px with an average file size of 150 kB. ![]() The source JPG’s size is around 1.200 x 800 pixel with a moderate compression rate and file sizes ranging between 100 and 500 kB with an average of 250 kB. Server 1 seems to confirm this assumption (the JPGs with bigger WebPs here are highly compressed 3rd party images) while server 2 ist acting completely strange. WebP smaller than JPG: 89 (on average less than 10 %)Īs far as I know, the quality of the source JPG has an impact on the WebP: highly compressed JPGs may lead to hardly smaller or even bigger WebPs, while the savings with high quality JPGs tend to be more spectacular. WebP bigger than JPG: 773 (on average 30–40 %) WebP smaller than JPG: 285 (on average 30–40 %) WebP bigger than JPG: 41 (on average more than 40 %) While integrating the WebP functionality was no problem at all, I’m massively confused by the results: one server works as expected, the other one does the sheer opposite. Both servers run on identical system configurations and PW versions (3.0.184). I’ve recently set up 2 PW installations for using WebP images (following this explanations, strategy 3). ![]()
0 Comments
Leave a Reply. |