Benchmarking imagemagick vs. gd

Just a quick note. For a client project, I had to compare the performance of GD, ext/imagick and ext/magickwand for reading and merging two alpha-channel PNG24 images and writing them back to disk. Here’s the result (the absolute figures don’t mean anything):

gd wins slightly, and the two imagemagick extension show (unsurprisingly) the same performance. And if you merge more than 2 pictures together, gd’s lead increases.

Conclusion: We will stay with GD for that particular task.

The source for the benchmark script. If someone has improvement suggestions, I’m all ears .)

I was recently doing a project that needed lots of compositing and resizing of pngs with alpha channels. I originaly wrote it with GD but ended up rewriting it use ImageMagick (command line in this case) because GD just refuses to stop messing up more then single bit alpha.

It also has a penchant for segfaulting which is problematic.

Joshua Eichorn, why did I see any bug reports from you about ext/gd? Especially about the segfaults?

Alpha support is far to be perfect though, but once you know the limitation, it works fine.

I made similar observations when comparing the Image_Transform drivers, which is quite some time ago, though.

Try pnm* small programs. Very small, fast and don’t use memory like GD. You can do almost this some like in GD.

Example – resize image:
system(‘/usr/bin/djpeg “file.jpg” | /usr/bin/pnmscale -width 200 | /usr/bin/cjpeg -quality 70 -outfile “file2.jpg”‘);

andrzey: calling 3 programms (starting them et al.) on the command line is out of question here. I doubt, that it will perform very well, if you have many concurrent requests. But thanks for the hint anyway, maybe useful for another project

The problem with GD and segfaults is, I’m never able to, or I don’t have time to make a minimum test case, and I don’t have an environment setup to create core dumps (which is my bad buts its reality).

Also Alpha wise things just never worked how I expected. A good example image is:
The lenses of the glasses are partially transparent. I wasa working on a facial composite application so you take those glasses resize them and then composite them over say eyes.

I ended up building huge piped commands to send to imagemagick convert and composite, I never was able to get this working right. It seems like GD just refuses to read in Alpha channel information correctly.

I’m on php 4.3.10 or 4.3.11 so maybe it works differently in 5, but thats not much of an option for me.

Using your image and some various images here, it works well. I wonder if you set the alphablending mode before the copy? Not setting it ends with some ugly results without any kind of blended areas.

png just sucks because MSIE’s bad implementation of the alpha layers.

Joshua’s example shows why the png format is not acceptable, try to view it with a Gecko browser and MSIE and appreciate the differences :

I’ll stick on gif format and dhtml effects, leaving the high definition transparency work to more competent and (really) portable graphic effects such as flash or java.

hrhr, PNG sucks, because MS isn’t capable of implementing decent support for it? your worldview is somehow turned upside down…

“Joshua’s example shows why the png format is not acceptable, try to view it with a Gecko browser and MSIE and appreciate the differences :”

Read again his post, he said that GD was not able to manage alpha correctly.

Nice FUD try ;)

I was tried with nconvert, the shell command for xnview. Making a tested comparition vs imagemagick and other similar I think it’s the fast more.

nconvert -quiet -out jpeg -rexifthumb -ratio -resize 300 300 -q 50 -o originalfile.png -truecolors finishfile.jpg

The PNG bug in the GD library can be fixed by using:

imagesavealpha($image, true);

This benchmark gives us some info about the resulting file size, but does anyone have info about a comparison between gd and imagemagick for the toll it takes on the cpu and on available memory?