Legacy ImageMagick Discussions Archive

No. I tried setting it to 1 and also to 0, just to be sure. It seems that any call to an OpenMP routine makes the program crash, even if it's just querying the number of OpenMP threads, or if there aren't any OpenMP threads.

I have the exact same problem on the Mac.
ImageMagick 6.6.1-5 2010-11-15 Q16
Has this been resolved or addressed by any chance?
Thanks.
Pat.

You can always build ImageMagick without OpenMP support. However, try the latest release of ImageMagick and it may work properly with OpenMP enabled. Download and build from source, or try Mac Ports.

The last time I checked, the MacPorts version of ImageMagick didn't have a built-in option for disabling OpenMP. You have to modify the portfile. See http://www.ctcms.nist.gov/oof/oof2/install.html#osx for the instructions that we give our users.

-- Steve

I'm affected by this problem on OS X too, calling ImageMagick (via MagickWand) from a Python / Apache / mod_wsgi web app, which doesn't seem like an unusual setup to me.

Image processing works OK in single-thread / multi-process mode, but there is a crash in MagickReadImageBlob() as soon as 2 or more threads of execution are defined in Apache, even if only one HTTP request is being made. After finding this posting (thanks Google) and re-compiling with --disable-openmp everything then works fine with multiple threads.

Given that ImageMagick claims to be a thread-safe library, it's a little frustrating to have spent several hours discovering that I need to re-compile it with a special flag in order to call it from a thread!

If there's no quick fix for this in the pipeline (quite understandable if there isn't), I would suggest that a few lines are added to the "Install-mac.txt" file in the source code distribution, just to explain the problem and the workaround. It seems to me this is a very significant issue on the Mac platform.

Matt

(edited to fix formatting)

magick wrote: OpenMP is enabled at the scanline level. Each algorithm is divided into scanline chunks that are passed to however many processors are available on your system. It can speed up algorithms significantly for dual and quad core processor technology. One of our systems has 20 processors and ImageMagick is blazingly fast even for huge images (100000x100000). There are hundreds of internal algorithms that work in this fashion, farming out an image into chunks of scanlines for processing in parallel.

I had a different problem with openMP in libmagick on Linux (openSUSE-11.4) - when using the perl Image::Magick bindings in our CGI to convert 800x600 .ppm files to JPEG, it used 400% CPU on a 16-core machine for 2fps.
This went down to 9% after I added in the CGI:
BEGIN { $ENV{MAGICK_THREAD_LIMIT}=1; }
use Image::Magick;

Also the thumbnail creating CGI became a lot faster (1-2 secs instead of 8 for 55 thumbnails) with above addition - it probably has a lot of parallelism from apache already.
So overall, two or more threads are slower than one in these cases.

bmwiedemann wrote:

magick wrote: OpenMP is enabled at the scanline level. Each algorithm is divided into scanline chunks that are passed to however many processors are available on your system. It can speed up algorithms significantly for dual and quad core processor technology. One of our systems has 20 processors and ImageMagick is blazingly fast even for huge images (100000x100000). There are hundreds of internal algorithms that work in this fashion, farming out an image into chunks of scanlines for processing in parallel.

I had a different problem with openMP in libmagick on Linux (openSUSE-11.4) - when using the perl Image::Magick bindings in our CGI to convert 800x600 .ppm files to JPEG, it used 400% CPU on a 16-core machine for 2fps.
This went down to 9% after I added in the CGI:
BEGIN { $ENV{MAGICK_THREAD_LIMIT}=1; }
use Image::Magick;

Also the thumbnail creating CGI became a lot faster (1-2 secs instead of 8 for 55 thumbnails) with above addition - it probably has a lot of parallelism from apache already.
So overall, two or more threads are slower than one in these cases.

Did you solve it?if yest type how pls

The solution is included in my text that you quoted. I exported the environment var
MAGICK_THREAD_LIMIT=1
to avoid the huge overhead of parallelization