Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] GD vs Imagick

Posted by Rasmus Schultz 
Rasmus Schultz
[PHP-DEV] GD vs Imagick
August 15, 2017 01:00PM
The following GD issue is all-too common:

https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images

Basically anyone who's ever accepted uploaded images and resized or
converted them, has bumped into this.

Only Imagick makes it possible to work around this issue, it's not possible
with GD, at all - and the internal behavior of GD is arguably "wrong", as
the visible output of simply opening and saving a JPEG image with GD is
mangled with washed-out colors.

I am starting to wonder why GD is the default in PHP?

It's a pretty outdated library with a clunky API - we have Imagick with a
much more concise API and a ton more useful features.

Why is the less-capable image library the default on the PHP platform? Why
not Imagick?
Kalle Sommer Nielsen
Re: [PHP-DEV] GD vs Imagick
August 15, 2017 01:20PM
2017-08-15 12:52 GMT+02:00 Rasmus Schultz <[email protected]
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans
Re: [PHP-DEV] GD vs Imagick
August 15, 2017 01:30PM
On Tue, 15 Aug 2017, Rasmus Schultz wrote:

> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.
>
> I am starting to wonder why GD is the default in PHP?

The GD library is bundled with PHP, and hence easy to always made
available. Imagick is an external library, so we can't have this on by
default.

> Why is the less-capable image library the default on the PHP platform?
> Why not Imagick?

I wouldn't say any is the default though...

cheers,
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dan Ackroyd
Re: [PHP-DEV] GD vs Imagick
August 15, 2017 03:10PM
On 15 August 2017 at 12:11, Kalle Sommer Nielsen <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: GD vs Imagick
August 15, 2017 03:30PM
On 15.08.2017 at 12:52, Rasmus Schultz wrote:

> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.

Indeed, GD completely ignores and forgets color profile information when
loading an image, and thus doesn't write it back on saving. See
https://github.com/libgd/libgd/issues/136.

However, as workaround it would be possible to read the color profile by
other means and to re-apply it after the image has been saved.

For simple JPEG to JPEG resizing lossless JPEG transformations would be
even more suitable (see https://github.com/libgd/libgd/issues/343) – I
don't know whether this is already supported by Imagick or Gmagick.

> I am starting to wonder why GD is the default in PHP?
>
> It's a pretty outdated library with a clunky API - we have Imagick with a
> much more concise API and a ton more useful features.
>
> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?

This is most likely for historic reasons. In the years libgd was
basically unmaintained, PHP developed the bundled libgd further, and
most of that was later back-ported to libgd. Furthermore most current
maintainers of libgd are also guys with a php.net account – so there's
some bond.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
S.A.N
Re: [PHP-DEV] GD vs Imagick
August 16, 2017 02:50PM
2017-08-15 13:52 GMT+03:00 Rasmus Schultz <[email protected]>:
> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.
>
> I am starting to wonder why GD is the default in PHP?
>
> It's a pretty outdated library with a clunky API - we have Imagick with a
> much more concise API and a ton more useful features.
>
> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?

Imagick - unsafe, slow and requires many external dependencies.

Now there are much better modules:
Vips - safe, much faster (7x) requires little dependency.
http://pecl.php.net/package/vips

It's better to spend your time on Vips , instead of having an Imagick
Thank.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Remi Collet
Re: [PHP-DEV] GD vs Imagick
August 16, 2017 04:20PM
Le 15/08/2017 à 12:52, Rasmus Schultz a écrit :
> I am starting to wonder why GD is the default in PHP?

Don't really know, perhaps because the first one ?

But we have various alternatives:
- imagick
- gmagick
- vips
(perhaps others)

And ImageMagick is really an ugly upstream

- most common commit message is "..." [1]

- unstable API
(imagick extension even check that build version === runtime versions)

- soname bump in patch version (yes, really, when 4th digit change)

- lack of CI
(else I don't understand how they can release with broken tests [2])

And about extensions:

- imagick conflicts with gmagick (as GraphicMagick is a fork of
ImageMagick, you cannot load both in the same process), so having
imagick the default one will kill gmagick.



[1] https://github.com/ImageMagick/ImageMagick/commits/master
[2]
https://github.com/ImageMagick/ImageMagick/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aclosed%20author%3Aremicollet%20
Pierre Joye
Re: [PHP-DEV] GD vs Imagick
August 17, 2017 07:10AM
hi Rasmus,

On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz <[email protected]> wrote:
> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.
>
> I am starting to wonder why GD is the default in PHP?
>
> It's a pretty outdated library with a clunky API - we have Imagick with a
> much more concise API and a ton more useful features.

I disagree here, as old functions are old fashioned, new ones are easy
to understand and to use. Not OO, but that's a little details (contrib
welcome). And I disagree with outdated as well. It is focused on
easiness and most common usages. More features make it depending on
the requests or available time to actually add them. Performance wise
it is also similar to similar actions.

> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?

Imagick is good, but it is a huge library, by its size, features, code
base (external) and complexity. I would never ever recommend to have
it bundled or even less by default.

In any cases, both libraries (or the bindings) welcome contributors,
you are more than welcome too :)

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Schultz
Re: [PHP-DEV] GD vs Imagick
August 23, 2017 02:50PM
Thank you all for considering the subject and contributing your thoughts.

I understand why Imagick is not attractive as a standard module (even
according to the maintainer) since we can't feasible bundle all it's
dependencies, so I suppose that's a no-go.

The libvips module does in deed look interesting. I suppose this would have
all the same problems though? Lots of dependencies.

So GD wins perhaps mostly because it's small and has fewer dependencies.

Color profiles in my experience are pretty common though - and currently
(silently) leads to mangled images with GD.

I've seen a work-around, as somebody mentioned, which involves parsing the
binary contents of JPEG files, extracting the color profile and injecting
it into a JPEG file after GD has saved it - this is (A) horrible in terms
of memory and CPU usage, and (B) not what most users are going to want in
the first place; you most likely want color profiles moved, which is better
in terms of browser compatibility and performance when delivering images
over the web. So this is not a good work-around.

I wanted to contribute to Intervention Image - a library that abstracts GD
and Imagick behind a common API, but it turns out, this can't be
implemented with GD in PHP, except of course resorting to approaches like
pixel-by-pixel manipulation, for which PHP is totally unsuitable.

Ideally, I think that GD should be fixed, since it's the default (by which
I mean, it's the only option on a standard PHP install) so that libraries
like Intervention Image can deliver predictable results.

I'm not a C developer though, so I can't help with that.


On Thu, Aug 17, 2017 at 7:03 AM, Pierre Joye <[email protected]> wrote:

> hi Rasmus,
>
> On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz <[email protected]>
> wrote:
> > The following GD issue is all-too common:
> >
> > https://stackoverflow.com/questions/5773032/how-to-stop-
> gd2-from-washing-away-the-colors-upon-resizing-images
> >
> > Basically anyone who's ever accepted uploaded images and resized or
> > converted them, has bumped into this.
> >
> > Only Imagick makes it possible to work around this issue, it's not
> possible
> > with GD, at all - and the internal behavior of GD is arguably "wrong", as
> > the visible output of simply opening and saving a JPEG image with GD is
> > mangled with washed-out colors.
> >
> > I am starting to wonder why GD is the default in PHP?
> >
> > It's a pretty outdated library with a clunky API - we have Imagick with a
> > much more concise API and a ton more useful features.
>
> I disagree here, as old functions are old fashioned, new ones are easy
> to understand and to use. Not OO, but that's a little details (contrib
> welcome). And I disagree with outdated as well. It is focused on
> easiness and most common usages. More features make it depending on
> the requests or available time to actually add them. Performance wise
> it is also similar to similar actions.
>
> > Why is the less-capable image library the default on the PHP platform?
> Why
> > not Imagick?
>
> Imagick is good, but it is a huge library, by its size, features, code
> base (external) and complexity. I would never ever recommend to have
> it bundled or even less by default.
>
> In any cases, both libraries (or the bindings) welcome contributors,
> you are more than welcome too :)
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
Thomas Hruska
Re: [PHP-DEV] GD vs Imagick
August 23, 2017 04:00PM
On 8/23/2017 5:42 AM, Rasmus Schultz wrote:
> I'm not a C developer though, so I can't help with that.

The world's core software runs on C. PHP is also written in C. You
can't develop extensions for PHP unless you know C. Developing userland
applications in PHP is a lot easier when you know how to deep dive into
PHP's source code because you can know precisely what each option will
do even if the public documentation is a bit sparse in places. Those
are several reasons to start learning C even if you don't use it in your
day-to-day development efforts. A whole world of possibilities opens up
when you learn C and you'll be a more well-rounded software developer too.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] GD vs Imagick
August 23, 2017 04:20PM
On 23.08.2017 at 14:42, Rasmus Schultz wrote:

> The libvips module does in deed look interesting. I suppose this would have
> all the same problems though? Lots of dependencies.
>
> So GD wins perhaps mostly because it's small and has fewer dependencies.

I'm not sure about that. If GD is to be built with the full feature
set, it needs libgpng, libjpeg, libwebp, libxpm, libtiff, libfreetype
and libfontconfig. Basically, only the GIF and BMP stuff are
implemented by libgd itself.

> Ideally, I think that GD should be fixed, since it's the default (by which
> I mean, it's the only option on a standard PHP install) so that libraries
> like Intervention Image can deliver predictable results.

I don't think that anybody disagrees with this, but it's simply a matter
of man power. Also note, that storing the color profiles when reading
an image would cause an ABI break, so that can't happen in 2.2.x, but
would have to wait for 2.3, which might be far away.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrea Faulds
[PHP-DEV] Re: GD vs Imagick
August 31, 2017 02:50AM
Hi,

Rasmus Schultz wrote:
> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.
>
> I am starting to wonder why GD is the default in PHP?
>
> It's a pretty outdated library with a clunky API - we have Imagick with a
> much more concise API and a ton more useful features.
>
> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?
>

Imagick is, as others have pointed out, huge and internally messy. GD is
at least smaller. There's also a benefit to having just the one
extension for image handling by default, it prevents fragmentation.

For all its problems, I feel we are better off trying to improve GD than
we are trying to tame the monster that is Imagick and bundling it.

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] GD vs Imagick
August 31, 2017 03:40AM
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
Rasmus Schultz
Re: [PHP-DEV] GD vs Imagick
September 08, 2017 11:40AM
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 <[email protected]> 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
>
>
Sorry, only registered users may post in this forum.

Click here to login