Re: GD vs Imagick

This is only part of a thread. view whole thread
August 15, 2017 13:26 ("Christoph M. Becker")
On 15.08.2017 at 12:52, Rasmus Schultz wrote:

> The following GD issue is all-too common: > > > > 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 <>. 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 <>) – 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 account – so there's some bond. -- Christoph M. Becker