[drupal-devel] [task] Core image handling

Bèr Kessels drupal-devel at drupal.org
Mon Jan 31 14:46:00 UTC 2005

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     normal
 Assigned to:  walkah
 Reported by:  walkah
 Updated by:   Bèr Kessels
 Status:       patch

But other than that, great work, a big +1 from me to go into core.

Bèr Kessels

Previous comments:

January 28, 2005 - 21:31 : walkah

Attachment: http://drupal.org/files/issues/image_0.inc (7.44 KB)

Due to popular demand - attached here is an image.inc for inclusion (in
includes/), that will offer some basic image detection and manipulation
functionality to drupal's core.
currently image.inc is responsible for managing image 'toolkits' -
these are either PHP modules (e.g. GD) or external programs (e.g.
imagemagick) that handle the actual manipulation of images. also
included is the default "GD" toolkit (that supports both GD1 or GD2,
depending on which is installed). PHP comes bundled with gd as of
version 4.3 - therefore this is a reasonable default. However, other
toolkits will follow (I presume) - they can be installed in includes/
(as image.$toolkit.inc).
There are 5 main functions that modules may now utilize to handle
* image_get_info() - this function checks a file - if it exists and is
a valid image file , it will return an array containing things like the
pixel dimensions of the image, plus the 'type' and common extension.
* image_scale - resizes a given image to fit within a given width /
height dimensions, while maintaining aspect ratio (not distorting the
image). - this function can be used to generate thumbnails, or ensure a
maximum resolution, etc.
* image_resize - similar to image_scale (but will not respect aspect
ratio - may well distort the image).
* image_rotate - rotate an image by X degrees
* image_crop - crops an image to a given rectangle (defined as top-left
x/y coordinates plus a width & height of the rectangle).
In a follow up I will post a patch that does the following:
* adds some default settings to admin/settings :
  * toolkit selection (and possibly configuration)
  * default thumbnail dimensions (WxH) - to be used as a system-wide
  * maximum dimensions (WxH ) - to be used as a system-wide default
* changes the user picture handling to silently resize uploaded
pictures to fit within the specified dimensions (rather than throwing
* uses image_get_info() to verify logo uploads in admin/theme
* patches upload.module to respect maximum dimensions for uploaded
Contribution modules  will now be able to rely on these base
manipulation functions to offer additional functionality (such as image
nodes, photo galleries, advanced image manipulation, etc)


January 28, 2005 - 21:50 : walkah

Attachment: http://drupal.org/files/issues/image-core.patch (7.22 KB)

and the patch (as mentioned above).


January 29, 2005 - 01:41 : rkendall

Thanks for that, I think I could find that useful.
Not meaning to criticize your very nice looking work, but I don't quite
get the use of the /ext/ info in image_get_info() , it just seems to be
duplicating information from the /type/ info.
Thanks again,


January 29, 2005 - 13:13 : walkah

'type' - is used primarily by the gd functions, which open image files
using createFromPng / createFromJPEG / etc... and they use 'JPEG' not
'ext' - is the common file extension - i.e. 'JPG' not 'JPEG'.
i agree, kind of a shame, but mostly harmless (imo)


January 30, 2005 - 19:07 : Dries

Please rename 'ext' to 'extension' and document the difference between
'type' and 'extension'.  It is confusing at best.
Personally, I prefer to use 'resolution' instead of 'res', and
'destination' instead of 'dest'.
The punctuation in the PHPdoc code seems random: some sentences end
with a point, others do not.
Some code seems to wrap but that might be due to the fact that the
image.inc file has been uploaded with the wrong MIME-type.
Otherwise this patch looks good, but I haven't really tested it yet.


January 31, 2005 - 15:44 : Bèr Kessels

Is there a good reason for introducing YAPS (yet another plugin system)
and not using tour well tested, optimised and wellknown .module system
for the toolkits?
Is there really a differerence in performance and complexity between:
image.$toolkit.inc and
If not, please (with sugar on top and such), we should not make
more/new plugin systems.

View: http://drupal.org/node/16358
Edit: http://drupal.org/project/comments/add/16358

More information about the drupal-devel mailing list