Legacy ImageMagick Discussions Archive

I've been seeing a 14x increase in the time it takes to write a GIF file starting in late 6.4.0 and now in 6.4.1. I'm running ImageMagick on 32-bit Ubuntu running in a VMWare Fusion virtual machine on an Intel iMac, OS X 10.5.2. My test input image is http://home.nc.rr.com/foxhunter/test.miff. Please let me know if you need any more information.

Code: Select all

tim@linux:~/RMagick/projects/RMagick/doc/ex$ identify test.miff
test.miff MIFF 200x200+0+0 DirectClass 16-bit 235kb 0.000u 0:01

Using 6.3.9, I timed converting the test image to GIF, and then again to PNG to give some context.

Code: Select all

tim@linux:~/RMagick/projects/RMagick/doc/ex$ convert -version
Version: ImageMagick 6.3.9 03/23/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.gif

real    0m2.799s
user    0m2.628s
sys     0m0.128s
tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.png

real    0m0.049s
user    0m0.024s
sys     0m0.024s

Here's the same conversions using 6.4.0-11. Nothing changes except the version of ImageMagick. ~40 seconds seems excessive for a 200x200 image:

Code: Select all

tim@linux:~/RMagick/projects/RMagick/doc/ex$ convert -version
Version: ImageMagick 6.4.0 04/27/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.gif

real    0m39.869s
user    0m39.430s
sys     0m0.040s
tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.png

real    0m0.082s
user    0m0.032s
sys     0m0.016s

And, for one more data point, the same conversions using 6.0.0.

Code: Select all

tim@linux:~/RMagick/projects/RMagick/doc/ex$ convert -version
Version: ImageMagick 6.0.0 08/22/07 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2004 ImageMagick Studio LLC

tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.gif

real    0m2.467s
user    0m2.312s
sys     0m0.024s
tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.png

real    0m0.085s
user    0m0.032s
sys     0m0.020s

Easy problem to fix. In the meantime try:

time convert test.miff -dither -colors 256 test.gif

Much better!

Code: Select all

tim@linux:~/RMagick/projects/RMagick/doc/ex$ convert -version
Version: ImageMagick 6.4.0 04/27/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff test.gif

real    0m40.078s
user    0m39.498s
sys     0m0.036s
tim@linux:~/RMagick/projects/RMagick/doc/ex$ time convert test.miff -dither -colors 256 test.gif

real    0m3.394s
user    0m2.604s
sys     0m0.444s

I have a C++/Win32/Com component that is used by a Web site to generate images on the fly. I am attempting to port my code from using libgd to ImageMagick++. I have ported enough code to do some testing, and while I like Magick++ much better, writing gif's is an order of magnitude slower under Magick (500ms vs 30 ms for ~600x600 image).

I am using ImageMagick-6.4.3-Q8.

As per this thread, I tried adding

Code: Select all

m_image.quantizeDither(true);
m_image.quantizeColors(256);

before writing, but it didn't materially change things. Writing a Jpg is about the same as gif for me.

As my target platform is a Web server, the half second to encode and write is a problem.

Is this issue deemed to be solved, or is it still active?

The ImageMagick design has always emphasized the quality of results over speed. The ImageMagick color reduction algorithm is a spatial subdivision algorithm that includes transparency in its search for the optimal color palette which is relatively slower than other algorithms that tend to produce inferior results. If you don't care so much about quality you can try image->quantizeTreeDepth() of says 4 or 3 to speed up the algorithm. You can of course continue to use GD. No one application solves all problems.

Another example of quality vs. speed is the simple reduction of 16-bit values to 8. Most algorithms lop off the bottom 8-bits like this, red >> 8. This is much faster than the algorithm that ImageMagick uses which is red/257. This produces less error over all the pixels but is slower. These types of quality over speed decisions are pervasive throughout ImageMagick.

Thanks for the suggestion. I tried image.quantizeTreeDepth(3) and it didn't change the results. Like I said, my initial impression of IM is very positive, but unfortunately it won't work for me this time.

Legacy ImageMagick Discussions Archive

Slow GIF coder in 6.4.0/6.4.1

Slow GIF coder in 6.4.0/6.4.1

Re: Slow GIF coder in 6.4.0/6.4.1

Re: Slow GIF coder in 6.4.0/6.4.1

Re: Slow GIF coder in 6.4.0/6.4.1

Re: Slow GIF coder in 6.4.0/6.4.1

Re: Slow GIF coder in 6.4.0/6.4.1