Re: [PHP-DEV] GD vs Imagick

This is only part of a thread. view whole thread
  100241
August 17, 2017 05:03 pierre.php@gmail.com (Pierre Joye)
hi Rasmus,

On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz <rasmus@mindplay.dk> 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
  100290
August 23, 2017 12:42 rasmus@mindplay.dk (Rasmus Schultz)
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 php@gmail.com> wrote:

> hi Rasmus, > > On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz <rasmus@mindplay.dk> > 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 >
  100291
August 23, 2017 13:58 thruska@cubiclesoft.com (Thomas Hruska)
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/
  100292
August 23, 2017 14:13 cmbecker69@gmx.de ("Christoph M. Becker")
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