Jump to content

PW 3.0.132 – Core updates


ryan
 Share

Recommended Posts

@ryan thank you very much for all the additions you implemented in such a short time on top of my github pullrequest. It seems that there currently nothing is left in regard of webp support in ProcessWire. But I already have one or two points for future updates to the image rendering engines, that should be implemented when all browsers will support webp and we don't need fallback jpegs or pngs anymore. ?

  • Like 12
Link to comment
Share on other sites

  • 2 weeks later...

Hello,

since the upgrade to PW 3.0.132, I have noticed some artefacts in the generated images:

weissenrieder_architekten.0x260.png.1e5a5e14fa32fdc38b84bcfb61b83940.png

Before the upgrade:

weissenrieder_architekten.0x260-1.png.a381b0abb3582e39d52cb2680dbe7eb0.png

I have the ImageSizerEngineIMagick installed and use PHP 7.2.14 with Imagick 3.4.4. I think this issue is specific to Imagick. If I uninstall ImageSizerEngineIMagick I don't have artefacts.

Has anyone else noticed such issue or is it maybe just my local installation?

Regards, Andreas

  • Like 2
Link to comment
Share on other sites

Hi @AndZyk

I can confirm this. If I upload a PNG saved by Photoshop then all is good but if I upload a PNG optimized with ImageOptim then transparency is removed and some sort of inverted version of the image is generated. It does look like it is a ProcessWire 3.0.132 issue indeed.

It would be great to fix it ASAP as it is a real pita....

Edited by szabesz
missing words added
  • Like 2
Link to comment
Share on other sites

Hmmm, upon further inspections, I'm no longer so sure that it is a ProcessWire issue because the clone of the site in question in my local dev environment (MAMP Pro) can generate proper PNGs, while the one in production cannot. But still, it started happening after some ProcessWire upgrades.

  • Like 1
Link to comment
Share on other sites

Ok, it could also be my local MAMP server setup. Because I have recently installed Imagick with Pecl and use this instead the build-in Imagick of MAMP. But switching didn't change anything and I think I have experienced this issue on our webhoster as well. Let's wait if someone else experienced this. ?

  • Like 2
Link to comment
Share on other sites

Ah, @ryan has added support for PNG8 to the Imagick engine, what wasn't before.
He also asked me why this wasn't added and I was unsure if I simply forgot to add it. But now when I see this, I think I had tested it and removed it from the Imagick supported filetypes / subtypes, so that this images always were rendered by GD! until before the last Update.

https://github.com/processwire/processwire/pull/141#issuecomment-495983196

So it seems it should be rolled back again, at least for PNG8.

EDIT: I couldn't remember as it is (how many?) years ago as the Image Engine System was introduced. And yep, it would have been better to add some comments. ;-)

Edited by horst
  • Like 3
Link to comment
Share on other sites

1 hour ago, szabesz said:

Hi @AndZyk

I can confirm this. If I upload a PNG saved by Photoshop then all is good but if I upload a PNG optimized with ImageOptim then transparency is removed and some sort of inverted version of the image is generated. It does look like it is a ProcessWire 3.0.132 issue indeed.

 

Besides the broken Imagesupport for PNG8 I want to say:

"Uploading ImageOptim optimized images are ONLY for output use as is(!), NOT for serving as master image from what one should generate new variations. ? "

Everytime when I read something like this, my photographer heart hurts and somewhere a kitten dies, I believe.  ??  ? 

Link to comment
Share on other sites

5 minutes ago, horst said:

at least for PNG8.

I see! Yes, those PNGs are indeed PNG8 in my case.

  • Tracy on MAMP Pro reports :IMAGICK SETTINGS Version: 6.9.6
  • Whereas in production: IMAGICK SETTINGS Version: 6.7.8

It seems like it is a bug in older verions of Imagick which are still quite common, I guess.

  • Like 1
Link to comment
Share on other sites

Just now, szabesz said:

It seems like it is a bug in older verions of Imagick which are still quite common, I guess.

Yep, and I / we don't like version hunting for all the format issues in Imagick or GD. ?

  • Like 1
Link to comment
Share on other sites

7 minutes ago, horst said:

Everytime when I read something like this, my photographer heart hurts and somewhere a kitten dies, I believe.

? I know the theory, however, saving space can be important on some servers. Also, in this particular case form a 3000x3000 PNG8 a 1000x1000 JPG is generated, and I do not think anyone can tell what the source was just by looking at it.

Edited by szabesz
typo
  • Like 1
Link to comment
Share on other sites

Hohoho, a 3000 x 3000 PNG, for what do you need this? You generate a 1000 x 1000 variation?

If you use photoshop jpeg quality 12 you also has lossless master images.

My favor would be to have LZW-Tiffs as master, = Lossless compression and a format that cannot wrongly used for web output. ?

  • Like 1
Link to comment
Share on other sites

6 minutes ago, horst said:

Hohoho, a 3000 x 3000 PNG, for what do you need this?

I do not need it ? but my client does so I had to find a way not to upload the "same" image twice, once for the client and once for the site. The client also needs those PNGs to be as small as possible, so that is where crushing them comes into play.

Anyway, if you could revert the change, that would be great for the time being. Maybe a note in the source code about the issue could help to decide when to add it again to the supported filetypes is feasible. (A few years from now on, maybe?)

  • Like 1
Link to comment
Share on other sites

From @ryan's comment in the blog post https://processwire.com/blog/posts/webp-images-in-pw/:

"By the way, if for some reason the webp results in a larger image (which is very rare), calling the $image->webp->url will return the smaller (non-webp) image."

Very excited to see webp support in PW core then followed all the instructions. Couldn't get it working, or so I thought. Seems I did.

OK, I take the craftsman's approach when adding images:

  1. Photoshop image as needed then reduce the image size to close to the max dimensions I need
  2. Export for Web Legacy - jpeg high @ 60% quality
  3. Drop exported jpeg into the lovely TinyBeest app https://www.tinybeest.com/ (Mac only)
  4. Upload TinyBeest-optimised image to PW, often output with MarkupSrcSet  https://modules.processwire.com/modules/markup-src-set/ template code

Every time I used $image->webp->url I got a jpg file with great quality. Only got webp when I uploaded the original image, often MB's huge.

Bit frustrating that my images still get scored down on Google Page Speed Insights for not being webp - but then they'd be bigger and take longer to download ?

  • Like 1
Link to comment
Share on other sites

4 hours ago, psy said:

Bit frustrating that my images still get scored down on Google Page Speed Insights for not being webp - but then they'd be bigger and take longer to download 

@psy You can set webpQuality to lower values what will result in smaller filesizes. 

Examples: 

 

 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...