ImageMagick 6.4.8 running too slower

[sabater_wb]

I had ImageMagick 6.4.3 installed in a server, and it was working very good.

Now, I have another server with best processor and more RAM, and ImageMagick 6.4.8.

The problem is that it is running too slow and eating a lot of processor power. Nobody from the support team know how to solve the problem.

I think that uninstalling the current version and installing the old version can solve the problem.

How can I remove imagemagick 6.4.8 ?

[magick]

We addressed a number of performance issues in the latest releases of ImageMagick. If you can, try the latest ImageMagick release, 6.5.1-3.

ImageMagick 6.4.8 includes support for OpenMP. Under most OS's, OpenMP scales linearly with each additional core. However we have found a few OS's where ImageMagick dogs with OpenMP support. Try building ImageMagick without OpenMP support. Add --disable-openmp to the configure script command line and rebuild / reinstall ImageMagick.

[sabater_wb]

I noticed that my current OS is Centos 5.3 32bits. My server has a Intel(R) Xeon(R) CPU E5430 with 8 cores 2.66GHz

My old server was CENTOS 4.7 x86_64

Do you know if maybe this the problem?

[magick]

Curiously enough the one problem we had with OpenMP was under CentOS 5.3 but only on a certain host. ImageMagick slowed down by an order of magnitude and the problem is currently being investigated. The same tests work fine under CentOS 5.2 and with CentOS 5.3 on certain processors. We have an 8 core Redhat 5.3. Enterprise box and ImageMagick is lightning fast because the algorithms run in parallel on each of the 8 processors. To determine if you have a bottleneck on your system, compile / install ImageMagick with --disable-openmp on your configure script command line. Verify OpenMP is not enabled with this command:

• convert --version

and ensure OpenMP does not appear in the output. Now get your baseline timing:

• cd ImageMagick-6.5.1-3
  cd PerlMagick
  make test

note the time the script runs. Now rebuild / reinstall ImageMagick without the --disable-openmp option on your configure script command line. Verify OpenMP is enabled with the convert command and ensure OpenMP does appear in the output and get your PerlMagick timing again. How do these times differ? If the OpenMP release of ImageMagick is much slower than the baseline you may have the same problem we run into with OpenMP under certain configurations with CentOS 5.3. You can try one last test. Set the thread limit and run the PerlMagick tests again:

• cd ImageMagick-6.5.1-3
  cd PerlMagick
  export MAGICK_THREAD_LIMIT=1
  make test

We would be most grateful if you can post the results of your timing test here. We will use it to help track down the bug in CentOS 5.3 gcc and the gomp library.

Thanks

[sabater_wb]

I ran make test using ImageMagick 6.5.1-3

The result was:

Files=18, Tests=325, 7 wallclock secs ( 0.13 usr 0.03 sys + 32.66 cusr 1.27 csys = 34.09 CPU)
Result: PASS

After this, I removed ImageMagick 6.5.1-3 and installed ImageMagick 6.4.3 with --disable-openmp on your configure script command line

after the installation tha make test was:

Files=18, Tests=325, 4 wallclock secs ( 0.11 usr 0.02 sys + 3.25 cusr 0.51 csys = 3.89 CPU)
Result: PASS

So, I think it is a pretty good result.

[magick]

Can you post the command line you are using or outline which image processing task you are performing with ImageMagick? We'll look at the specific algorithms and look for possible performance bottleneck. Thanks.

[sabater_wb]

I run commands like:
exec("convert $foto -unsharp 0x1 -crop ".$minwidth."x".$minheight."+".$posxim1."+".$posyim1." -matte -virtual-pixel transparent -distort Perspective \"0,0,1,-1 0,289,0,289 364,0,248,79 364,289,248,277\" $foto");

and like:

exec("convert ".$foto." -font Arial -pointsize 12 -draw \"gravity southwest fill black text 10,4 'Scrapee.net' fill white text 11,5 'Scrapee.net'\" -compose Screen \( -clone 0 glitterizer/".$glitter."/image001.gif -composite \) \( -clone 0 glitterizer/".$glitter."/image002.gif -composite \) -delete 0 -set delay 30 -layers Optimize ".$foto2."");

[fmw42]

NOTE: -distort perspective was changed in two ways at about IM version 6.3.5.9 and 6.3.6.0

First the order of control points was changes.

Second and most important to speed, the default sampling method was changed to EWA (area resampling). This will cause some slowdown. You can go back to the older method using -interpolate bilinear and get faster processing, but more aliasing.

From the changelog:

2007-09-29 6.3.6-0 Anthony <anthony@griffith...>
...
Changed order for coordinate arguments in -distort (for later leastsq multiple coordinate distortion function fitting)

2007-09-12 6.3.5-9 Anthony <anthony@griffith...>
Major Addition, Area Resampling Functions, (scaled interpolation) for pixel lookup in Distortion functions. This improves the look in areas of minification enormousally, especially in situations of infinite tiling and horizon views. All virtual pixel methods have been handled to minimise computation time involved with area resampling. To use the new function distortions need to be able to determine scaling vectors (distortion function derivitives) for correct working. All -distort methods, except Arc, uses scaled area resampling.
Improvements to perspective distort method, to include the correct differentation between the 'ground' on which the image lies, and the 'sky', the color of which can be set using the -mattecolor setting (as the distortion invalid pixel color). Background color is retains for surrounding ground areas. The horizon is also correct anti-aliased and transparent colors are also allowed, allowing you to add backdrops of gradients and patterns.

Never mind, I thought you were using an older version of -distort perspective. Sorry

[nhcoding]

I'm using v6.6.5-10 on CentOS5.5. I too experienced very slow PerlMagick runtimes. I rebuilt with --disable-openmp and reran my tests. The speed up was orders of magnitude faster. A section of code that did a series of Annotate and Draw commands that was taking 27s is now taking 20ms. I thought the program was broken when I saw the 20ms timing output. I was pleasantly surprised to find the code works perfectly.

The specs on our server are:
+ Dell T710
+ 32GB (8x4GB) RAM
+ Xeon E5530 2.4Ghz, 8M Cache (4 cores) x 2
+ Testing with no CPU load

[magick]

We've seen this problem and it has something to do with CentOS and OpenMP. We have access to at least 30 different CentOS machines. On all but one OpenMP accelerates ImageMagick significantly. However, on one it slows it down to a crawl. We fixed the problem by adding

• <policy domain="resource" name="thread" value="2"/>

to policy.xml on this one system.