Comments on: Why we use GraphicsMagick

By: CBCのBlog » 再跟 Flickr 学习网站运维经验

CBCのBlog » 再跟 Flickr 学习网站运维经验 — Fri, 11 Dec 2009 05:39:17 +0000

[...] 在 2004 年的时候，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。 [...]

By: 再跟 Flickr 学习网站运维经验

再跟 Flickr 学习网站运维经验 — Wed, 02 Dec 2009 07:23:51 +0000

By: Anton

Anton — Wed, 03 Jun 2009 23:27:18 +0000

Cool!

By: Bob Friesenhahn

Bob Friesenhahn — Wed, 24 Dec 2008 01:09:38 +0000

Ja Hui,

What versions of IM and GM are you using? Also, are they built to support OpenMP? It seems that many/most people using GM are using a very antique version released back in 2004. A huge amount of work has been done since that time.

See http://www.graphicsmagick.org/OpenMP.html to see what kind of speedups we are seeing with OpenMP.

Bob

By: Ja Hui

Ja Hui — Sun, 07 Dec 2008 22:37:56 +0000

We’re running on a Pentium 3.0GHZ and the timing results were pretty close in most cases where GM was slightly faster for about half the operations and IM was slightly faster for the remaining half. We looped the PerlMagick Sharpen(’5×2′) method on a large image 20 times and the average ImageMagick time was 16.9 seconds with 22.1 for GraphicsMagick. For Implode(0.3), GraphicsMagick was slightly faster at 12.4 seconds with ImageMagick coming in at 15 seconds.

By: Bob Friesenhahn

Bob Friesenhahn — Sun, 16 Nov 2008 23:34:32 +0000

As a followup to the first and last posts, the GraphicsMagick benchmark report URL is now http://www.graphicsmagick.org/benchmarks.html. Since my last post, GraphicsMagick 1.3 has been released and the command-line performance just blows latest ImageMagick out of the water (sorry Chris! . The typical speed boost is perhaps 2X to 3X but in one case we observed at 272X speed difference.

When ImageMagick is executed by hand from the command line it does not feel so bad, but if you run it repeatedly in a script, it runs quite poorly.

We will soon be releasing GraphicsMagick 1.3.1 which further boosts the dramatic speed advantage that GraphicsMagick has over ImageMagick.

Bob

By: Bob Friesenhahn

Bob Friesenhahn — Mon, 27 Oct 2008 19:57:50 +0000

Hi, this is a response to Chris Madison’s post. I am the principle maintainer of GraphicsMagick. The benchmark was correct for the ImageMagick release which was benchmarked but ImageMagick has changed its syntax since then. The benchmark has since been updated to use the new ImageMagick syntax. Subsequent testing shows that ImageMagick has responded to these benchmark results by eliminating many of the performance issues uncovered by the benchmark.

It is true that ImageMagick has been releasing OpenMP features earlier than GraphicsMagick but this is because of the difference in development model. When GM 1.3 is released, most algorithms will be OpenMP accelerated, well tuned, and tested with several different OpenMP-capable compilers on a wide variety of platforms. Only a few algorithms remain to be re-implemented.

The link to the ImageMagick usage page is appreciated, but the implication is that GraphicsMagick does not support most of those features. In fact, GraphicsMagick does support most of the features described.

By: allspaw

allspaw — Sun, 14 Sep 2008 22:08:59 +0000

Thanks for the info, Chris. We don’t use any other features other than identify and convert, so the extra features aren’t much of a motivator for us.

We’ll be sure to try and test the new version of ImageMagick.

By: Chris Madison

Chris Madison — Sun, 14 Sep 2008 21:11:42 +0000

We ran the benchmarks against a modern version of ImageMagick (6.4.3) and got dramatically different results. In most cases the run times are similar. We did notice the benchmark script forces ImageMagick to cache the pixels to disk with these lines:

MAGICK_MAP_LIMIT=4000
MAGICK_MEMORY_LIMIT=4000
MAGICK_AREA_LIMIT=200000
export MAGICK_MAP_LIMIT MAGICK_MEMORY_LIMIT MAGICK_AREA_LIMIT

With GraphicsMagick working in memory and ImageMagick on disk we would expect a significant slowdown with ImageMagick. Instead comment out the export statement to get a proper comparison or correct the values (use 4000mb instead of 4000).

ImageMagick in some cases runs a bit slower than GraphicsMagick mainly because it supports additional features such as full alpha support, most algorithms permit channel selection (i.e. blur only red channel), support for CMYKA images, and ImageMagick is thread-safe whereas GraphicsMagick is not.

The GM developers are working on getting OpenMP into GM but OpenMP support has been included in ImageMagick for some time now.

Finally, ImageMagick supports hundreds of features that GraphicsMagick does not. See http://www.imagemagick.org/Usage for details.