GD vs ImageMagick?
Moderator: General Moderators
GD vs ImageMagick?
Ok guys, I want to setup a site in which users can upload their screenshots of games and the server would do all the image resizing, sounds easy enough. Well I am using image magick and well it gets the job done but...yeh it's slow and when multiple people use it, my server (athlon 1900+ 512 MB) gets raped I wanted to know if GD was faster at resizing images or if there is any other 3rd party image rendering software that is quick
-
pootergeist
- Forum Contributor
- Posts: 273
- Joined: Thu Feb 27, 2003 7:22 am
- Location: UK
GD +
endorsed by the great Rasmus (all hail) himself and bundled with PHP from 4.3 onwards so widely available - functions that just plug straight into php scripts, so you can write your own manipulations very very easily. lots of potential and gets better every build. Really excels when using its own proprietary image format (.gd2) for basing manipulations from = much faster than compiling from png/jpg/bmp etc.
GD -
doesn't support .gif due to unisys patenting the LZW compression algorythm. often misused by stupid scripters trying to do too much every page load and, as such, often disabled by disgruntled server admins when there babies resources get hogged. (note : that is due to BAD coding practice rather than GD).
ImageMagick +
supports .gif apparently - dunno if that's really a plus though as people will keep using them and they won't die quickly like they should. quite a few easy pre-compiled manipulations available.
ImageMagick -
normally run through command line calls ( exec() or system() ) so must have that allowable - not bundled with php so must be compiled as an external module. Have never seen anyone manage anything with imagemagick that I cannot easily surpass by using GD2+ (and I have seen a fair few tricks)
Gimp +
script-fu - probably the most powerful image scripting language available anywhere (other than SVG which is more about interactive dynamics and not therefore server usable). envied by photoshop and PSP simply because of that language. absolutely loads of free open-sourced script-fus available from sites dealing in *nix based imagery. gimp is the best image editor available for *nix based systems and has all the support that open-source artisty types can give. I think my next step forward will be through gimp and script-fu
Gimp -
you might need a super duper admin and tutor to get anywhere with using script-fu on the backend processes.
----------------------------------------------
all in all, I reccommend GD if you have a version beyond 2 - can surely kick imagemagick to bits. If you ever need a demo, just find something someone did in imagemagick and I'll write a scriptlet to beat that with GD.
If you have GD2+ and want a proportional resizing thumbnail class with options for bevel, drop shadow, greyscale, overlay, frame, motion blur, ellipse etc - check the one I wrote at http://www.phpclasses.org/browse.html/package/1007.html - unfortunately the online demo is ummm, offline at the most (pesky host)
endorsed by the great Rasmus (all hail) himself and bundled with PHP from 4.3 onwards so widely available - functions that just plug straight into php scripts, so you can write your own manipulations very very easily. lots of potential and gets better every build. Really excels when using its own proprietary image format (.gd2) for basing manipulations from = much faster than compiling from png/jpg/bmp etc.
GD -
doesn't support .gif due to unisys patenting the LZW compression algorythm. often misused by stupid scripters trying to do too much every page load and, as such, often disabled by disgruntled server admins when there babies resources get hogged. (note : that is due to BAD coding practice rather than GD).
ImageMagick +
supports .gif apparently - dunno if that's really a plus though as people will keep using them and they won't die quickly like they should. quite a few easy pre-compiled manipulations available.
ImageMagick -
normally run through command line calls ( exec() or system() ) so must have that allowable - not bundled with php so must be compiled as an external module. Have never seen anyone manage anything with imagemagick that I cannot easily surpass by using GD2+ (and I have seen a fair few tricks)
Gimp +
script-fu - probably the most powerful image scripting language available anywhere (other than SVG which is more about interactive dynamics and not therefore server usable). envied by photoshop and PSP simply because of that language. absolutely loads of free open-sourced script-fus available from sites dealing in *nix based imagery. gimp is the best image editor available for *nix based systems and has all the support that open-source artisty types can give. I think my next step forward will be through gimp and script-fu
Gimp -
you might need a super duper admin and tutor to get anywhere with using script-fu on the backend processes.
----------------------------------------------
all in all, I reccommend GD if you have a version beyond 2 - can surely kick imagemagick to bits. If you ever need a demo, just find something someone did in imagemagick and I'll write a scriptlet to beat that with GD.
If you have GD2+ and want a proportional resizing thumbnail class with options for bevel, drop shadow, greyscale, overlay, frame, motion blur, ellipse etc - check the one I wrote at http://www.phpclasses.org/browse.html/package/1007.html - unfortunately the online demo is ummm, offline at the most (pesky host)
perhaps you want to put the resizing of images in another process, so to speak.
take the uploaded images, put them in a directory somewhere.
then have a cron script or similar that examines your upload directory and uses some command line tool, or a php script to do the work sequentially instead of all at once at peak times. you could even nice'ify it if your on linux.
the cron time could be releativly short ( say about 1 min ) so images could be processed without the user growing old and dying ( depends on how bad the situation is ... )
also, are you cacheing your images?
take the uploaded images, put them in a directory somewhere.
then have a cron script or similar that examines your upload directory and uses some command line tool, or a php script to do the work sequentially instead of all at once at peak times. you could even nice'ify it if your on linux.
the cron time could be releativly short ( say about 1 min ) so images could be processed without the user growing old and dying ( depends on how bad the situation is ... )
also, are you cacheing your images?
d1223m wrote:perhaps you want to put the resizing of images in another process, so to speak.
take the uploaded images, put them in a directory somewhere.
then have a cron script or similar that examines your upload directory and uses some command line tool, or a php script to do the work sequentially instead of all at once at peak times. you could even nice'ify it if your on linux.
the cron time could be releativly short ( say about 1 min ) so images could be processed without the user growing old and dying ( depends on how bad the situation is ... )
also, are you cacheing your images?
That's what I am doing now
-
pootergeist
- Forum Contributor
- Posts: 273
- Joined: Thu Feb 27, 2003 7:22 am
- Location: UK
I'd advise against cron for process intense stuff - unless you run a daemon program and individualize the tasks.
When someone uploads an image, they expect to wait between maybe a second and a couple of minutes (dependent on filesize and connection speed)
... therefore, doing the image processing during the move_uploaded_file process is quite sensible. The surfer doesn't notice (as a couple hundredth of seconds is negligible compared to a few secs uploading) and the server spreads the tasks adequatedly so as not to bog itself down.
The way I tend to do it is to upload, type/size/dimension test, move image to new folder/name then call a zero browser output script to create the thumbnail with a similar naming protocol to the newly named uploaded image. You could call an <img src thumbnailer and display it easily if you wanted.
When someone uploads an image, they expect to wait between maybe a second and a couple of minutes (dependent on filesize and connection speed)
... therefore, doing the image processing during the move_uploaded_file process is quite sensible. The surfer doesn't notice (as a couple hundredth of seconds is negligible compared to a few secs uploading) and the server spreads the tasks adequatedly so as not to bog itself down.
The way I tend to do it is to upload, type/size/dimension test, move image to new folder/name then call a zero browser output script to create the thumbnail with a similar naming protocol to the newly named uploaded image. You could call an <img src thumbnailer and display it easily if you wanted.