Re: GD vs Imagick

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