Re: [PHP-DEV] GD vs Imagick

This is only part of a thread. view whole thread
  100215
August 15, 2017 11:11 kalle@php.net (Kalle Sommer Nielsen)
2017-08-15 12:52 GMT+02:00 Rasmus Schultz <rasmus@mindplay.dk
> Why is the less-capable image library the default on the PHP platform? Why > not Imagick?
Most likely because no one have come fourth and attempted to push it into core and have been willing to do all the work required for it. As for GD, I would argue and say that for the average developer needing image functionality, it fits the needs, the API is clunky yes and I have been wanting to redesign at least the PHP binding for quite some time, but that is a huge task, for a marginally small gain imo. If you are willing to do the work, and work together with the maintainer of Imagick, then I don't see any showstoppers for why it can't be included in the php-src through an RFC much like Sodium recently was added to 7.2 -- regards, Kalle Sommer Nielsen kalle@php.net
  100217
August 15, 2017 13:04 danack@basereality.com (Dan Ackroyd)
On 15 August 2017 at 12:11, Kalle Sommer Nielsen <kalle@php.net> wrote:
> the maintainer of Imagick,
Hey, that's me!
> and work together with the maintainer of Imagick,
Actually, it would be lovely if anyone contributed to Imagick. I've been the maintainer of the extension for a little over three years and have spent a significant amount of time: * increasing the test coverage. * working with the ImageMagick guys upstream to fix memory access issues. * porting the extension to PHP 7. * extending the extension to compile against both ImageMagick 6 and 7. * adding to the documentation in the PHP manual * creating a site that has working examples http://phpimagick.com/ In that time, other than minor bug fixes there have been almost no contributions from other people.
> then I don't see any showstoppers for why it
There are some serious downsides to shipping Imagick with PHP. 1. Imagick is a thin wrapper around the ImageMagick library, as opposed to full-fledeged api to an external service, like PDO is. This means Imagick is only guaranteed to work with the version of ImageMagick it was compiled against. This is also true of GD, but we ship the GD library as part of PHP src. We would need to either also ship the ImageMagick source with PHP, or people would need to recompile PHP whenever they upgraded the ImageMagick library. Either of those choices would more exciting than hoped for. 2. Releasing Imagick with PHP means that the release cycles would need to be sync'ed. This has proven to be inconvenient in the past when an extension has wanted to change the api, but was forced to wait due to needed to wait for the next minor/major version of PHP. 3. There are significant chunks of work that ought to be done for a version 4 of Imagick, that probably ought to be done before thinking about bringing it in as a core extension. The two main things that spring to mind are: i) The code that allows iterating over Imagick objects that contain multiple images is just bogus, and doesn't do what anyone would expect it to do. Just removing the iterating, and making people explicitly access images inside an Imagick object, is probably the right thing to do, but obviously a major breaking change. https://github.com/mkoppanen/imagick/issues/122 ii) A significant amount of functionality was added to ImageMagick 7. Exposing this functionality through Imagick is going to take quite a bit of work, and may result in some breaking changes. There are probably other issues, but those are the big ones I can think of right now. To summarise, even if it is a good idea to ship Imagick as a core extension, it will take a significant portion of time to make it happen. Some what ironically _I have never used Imagick in production_, so I've been maintaining a reasonably large code base for no personal benefit, other than the 'glory' of being an open source maintainer*. I've already been thinking of ways to remedy that, but that is a discussion for another day. While I'm working a full time job, I wouldn't be able to commit to spending anything close to the amount of time required to do this. No-one else has touched the source code in multiple years, and aren't up-to-speed with what is happening in the ImageMagick 6 -> 7 migration, so the first steps to even consider moving Imagick to be a core extension would either be: i) Someone else step up and start helping with maintaining Imagick and then in a few months have them look at the work required. ii) Finding a company/someone to hire me for the multiple months required to get Imagick into a position where it would be conceivable to ship it as a core extension. cheers Dan Ack * my landlord does not accept 'open source glory' in lieu of rent payment. Also, a related tweet - https://twitter.com/MrDanack/status/895797231923671040
  100331
August 31, 2017 01:30 kris.craig@gmail.com (Kris Craig)
2. Releasing Imagick with PHP means that the release cycles would need

to be sync'ed. This has proven to be inconvenient in the past when an
extension has wanted to change the api, but was forced to wait due to
needed to wait for the next minor/major version of PHP.


Why would they need to be synced?  When PHP releases a new version, can't
we just bundle the latest Imagick build and plug into that?

Sure, having them in sync would yield certain benefits, but none of them
appear to be deal-breakers to me.  Or am I just missing something?

--Kris
  100464
September 8, 2017 09:34 rasmus@mindplay.dk (Rasmus Schultz)
Yeah, I keep thinking about this.

I'm not sure there's a really good reason why PHP shouldn't come with
best-in-class image support, if it's available - which it sounds like it
is; libvips looks more modern, lower memory and CPU overhead, better
overall really, and appears to be stable and up-to-date?

Yeah, it has dependencies. Doesn't everything? Does it matter, as long as
they're bundled?


On Thu, Aug 31, 2017 at 3:30 AM, Kris Craig craig@gmail.com> wrote:

> 2. Releasing Imagick with PHP means that the release cycles would need > > to be sync'ed. This has proven to be inconvenient in the past when an > extension has wanted to change the api, but was forced to wait due to > needed to wait for the next minor/major version of PHP. > > > Why would they need to be synced? When PHP releases a new version, can't > we just bundle the latest Imagick build and plug into that? > > Sure, having them in sync would yield certain benefits, but none of them > appear to be deal-breakers to me. Or am I just missing something? > > --Kris > >
  100930
October 24, 2017 11:02 danack@basereality.com (Dan Ackroyd)
On 31 August 2017 at 02:30, Kris Craig craig@gmail.com> wrote:

> Why would they need to be synced?
Currently Imagick can have a single branch. Commits to that branch are made and then for the next release, we can determine if it needs to be a major minor or patch release based on the changes. People are then free to upgrade to the next version of Imagick at their own leisure. Or not if they don't feel like it. If it was shipped as part of PHP it would need to have: One branch for each version of PHP supported. Which for now is 5.6, 7.0, 7.1, 7.2 and 7.next Each commit to Imagick would need to be evaluated for whether it should be brought to those branches. Additionally we would probably need to have an additional branch for BC breaking stuff to do in, to await PHP 8. Not only would this be a maintenance burden for the developers, it would also be an arse for end-users. "Oh, you want to upgrade to PHP 7.3? Then you also need to upgrade Imagick, even though you'd prefer to keep to the current version, as it works fine for you." "Oh, you want the new version of Imagick that has a BC breaking change in it? Well sorry, you'll need to wait for PHP 8 for that." cheers Dan
  100931
October 24, 2017 11:18 danack@basereality.com (Dan Ackroyd)
On 15 August 2017 at 14:04, Dan Ackroyd <danack@basereality.com> wrote:

> Actually, it would be lovely if anyone contributed to Imagick.
So far, no volunteers. :-p As well as the documentation that are open, this bug: https://bugs.php.net/bug.php?id=73840 Is one that doesn't require any knowledge of ImageMagick....it's a purely PHP problem. cheers Dan