Remove image toolkits from core

If we retool it so that the toolkit functionality uses more of Drupal's module abilities, I think it'd be both more compact in core and the toolkits would see more use. One of the reasons that this was hardly missed is that it's an unusual API and very very few people even knew this existed.

I think image toolkit abstraction would be important when the custom modules dealing with image modification (like thumbnailing, resizing, resampling, ...) would actually use the toolkit. But I dont think they do, or do they? When they do, the option would possibly gain more popularity when there were built-in choices, e.g. when drupal would ship with an implementation for at least imagemagick and gd. I think especially when it comes to bulk modification imagemagick (or e.g. imlib) is quite a lot faster than GD.

I think it would be good to flush out some core image manipulation capabilities too. But is it even doable?

I know it's tough since there's no real image manip support in PHP (I don't consider the GD wrappers "real" PHP :)

It seems that the only way to create "drupal native" image support would be to bundle some lightweight graphics lib (like we do with jquery). But I don't think such a lib exists, let alone one that would withstand all the protests from core developers :) jquery is the only one i'm aware of (other than GD) and it's not all that light (or free).

But dang, it would be nice. And you know developers would eat that up and start generating lots of cool image related modules.

Im not talking about shipping image manipulation libraries, thats what php extensions are for. You have proper extensions in PECL, e.g. imlib2 (http://pecl.php.net/package/imlib2), FreeImage (http://pecl.php.net/package/FreeImage) and imagick (http://pecl.php.net/package/imagick). What I had in mind is writing wrappers for them so you can set in one instance which toolkit is going to be used. Same thing we do for databases just for image manipulation. Other fancy stuff should be in contributed modules.

I disagree that they're cruft. I think the lack of visibility simply means that the GD default works for pretty much everyone. Further, lots of folks still use the imagemagick toolkit because the lone setting (binary location) works on most systems. What I think needs to happen is that more toolkits should be made available. I agree, Earl, that making them module might make them more accessible. I'd be happy to put in some work on this for 6.

Dries, how does that sound to you?

My only concern is "module" is starting to mean lots of things... image toolkit, cck field... etc. And my initial reasoning for not making toolkits modules was because of their required nature. i.e. unlike most drupal modules, you *have* to implement certain things for a toolkit to work (whereas module hooks are optional overrides). This same scenario has cropped up in the filesystem work as well (Dopry calls them "drivers").

subscribing... i'm all for moving the toolkits into modules. then you get the benefits of the update status and installation requirements.

This is much bigger than a task (defined at http://drupal.org/node/1333).

CHANGELOG.txt (D7):

Image toolkits are now provided by modules (rather than requiring a manual file copy to the includes directory).