Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

ImageMagick as GD replacement.


Go to End


3 Posts   3194 Views

Avatar
mateusz

Google Summer of Code Hacker, 27 Posts

8 June 2007 at 10:58am

Edited: 08/06/2007 10:58am

In my proposal I suggested creating ImageMagick class for editing photos as faster than GD class. I had experience with ImageMagick and I was pretty sure that difference between GD and ImageMagick is huge.
Surprisingly I did some investigation and it turned out that difference is not so big.

Performance data:

GD Rotate: 3.3215408325195
GD Resize: 8.8823390007019
GD Crop: 3.3448140621185

Imagemagick Rotate: 7.4195408821106
Imagemagick Resize: 7.741574048996
Imagemagick Crop: 2.1027619838715

Each operation(rotate, resize, crop) was executed 100 times.

So now I’m not sure it’s essential to create that class. Bigger performance difference could be encountered with image effects because ImageMagick has some of them built-in whereas in GD I will have to do it in PHP, but image effects is a minor functionality.

Avatar
Ingo

Forum Moderator, 801 Posts

10 June 2007 at 1:54pm

it has to be an optional thing, so we don't need to adjust the installation requirements. imagemagick definetly produces higher quality results, so it's a good idea. typo3 had a lot of problems with changing APIs in imagemagick (the typo3 founder, kasper skarhoj, left a message in the installation-script expressing how he regretted switching to imagemagick *gg*). there's a fork called "graphicsmagick" which has a more stable API, so i'd opt for this (or a way to plugin different graphics processors, with graphicsmagick as default, and fallback to GD). see http://www.linux.com/article.pl?sid=06/12/22/169248 for more info.

Avatar
Sam

Administrator, 690 Posts

10 June 2007 at 3:52pm

I agree that it is optional / lower priority. The real benefits of ImageMagick, IMO, are support for more file types and more transformation operations.

My advice would be to use the same kind of API as SilverStripe's GD class - perhaps refactor it so that there's a static method that returns either a GD object or an ImageMagick object, that each inherit from the same base class or implement the same interface.

If you were to go down this path, I would suggest adding additional methods for the conversion of files from one format to another. So that you could upload a TIFF or BMP and insert it into your webpage, provided that you had imagemagick installed.

Of course, there are risks in creating widely divergent functionality depending on whether you had an extension file installed - you could get situations where either the imagemagick enabled or the imagemagick disabled versions had bugs that the other didn't, or that people were uncertain about what functionality they would get in a SilverStripe CMS. I think that, if a site were to benefit from Imagemagick, you would want to indicate this to the user.

For example, if a user uploaded a BMP or TIFF (or EPS, etc etc) file, you would have a message saying "If you want to insert this image in your web-page, please install imagemack. read more"