Legacy ImageMagick Discussions Archive

Hi,

I'm using the MagickWand API in the iOS port of ImageMagick to encode animated gifs on an iPhone 4 and I'm finding the performance to be so slow that I suspect there might be something wrong in my code or perhaps I'm using the wrong API calls.

Here is the applicable code:

Code: Select all


MagickWand *gifWand = NewMagickWand();
MagickSetFormat( gifWand, "gif" );

for (UIImage *img in previewFrames) {
        MagickWand *imgWand = NewMagickWand();
        NSData *data = UIImageJPEGRepresentation( img, 0.7 );
        MagickReadImageBlob( imgWand, [data bytes], [data length] );
        MagickSetImageDelay( imgWand, delay );
        MagickAddImage( gifWand, imgWand );
        DestroyMagickWand( imgWand );
}
size_t gifSize;
unsigned char * gifBytes = MagickGetImagesBlob( gifWand, &gifSize );
NSData *gifData = [[NSData alloc] initWithBytes:gifBytes length:gifSize];
free( gifBytes );
DestroyMagickWand( gifWand );

The MagickGetImagesBlob() call is where its really lagging. In my tests, it takes about 4 or 5 seconds per 480x360 frame. In a test of a 10 frame animation, it took 91 seconds. What is even stranger is that when I run the app in release mode, it seems to double the encoding time.

I'm not expecting desktop-level performance, but this is really quite slow... much slower than what I'm used to using the php version. Can anyone help?

-Aaron

We suspect the color reduction algorithm is the bottleneck. Save to the PNM format and the PNG format. PNG should be slower than PNM because of Zip compression. What is the time differential for GIF compared to PNM and PNG? If its a significant difference, it points to the color reduction algorithm. If so, we may need to rethink how we reduce 24-bit color to 8-bits as required by the GIF image format for the iOS.

Do you mean when I created the "gifWand", I should call MagickSetFormat( gifWand, "pnm" ) or MagickSetFormat( gifWand, "png" ) ?

If so, testing "pnm" with a 10 frame 480x360 animation took 0.323478 seconds and "png" took 9.521894 seconds.

So pnm is very fast... are there any changes I could make to get that kind of speed for a gif encode?

-A

ImageMagick emphasizes the quality of the results and we use a sophisticated algorithm (http://www.imagemagick.org/script/quantize.php) to select the best 256 colors to represent the entire color gamut of a GIF animation. In addition, GIF uses LZW compression which increases processing time. For comparison we converted 10 480x360 images to a GIF and it ran in 2.28 seconds.

I'm sorry... I'm not quite sure I understand. How did you get it to process the 10 images in 2.28 seconds?

Just over 2 seconds was a conversion on our Mac laptop. If you have a need for speed, you may need to use something other than ImageMagick.

I am out of my league in this forum. But in command line, one can speed up conversion to GIF by using -treedepth. See viewtopic.php?f=1&t=19888#p78584

I too experience problems with this. My code is very similar to that of the original poster, and my iPhone 3Gs takes 34 seconds to encode 15 images sized 320x320.

I too suspected the quantizing, and so I added an explicit call to MagickQuantizeImages. The quantize, however, just take 2 seconds, while MagickGetImagesBlob takes 32. This seems to me to indicate that it is not the quantizing that is slow, but the GIF/LZW encoding. I tried installing a progress monitor using MagickSetImageProgressMonitor, but got no callbacks*. Is there any way to get some logging info out of ImageMagick?

Am I missing something, or is it just a matter of LZW speed? 2 seconds per frame seems like an awful lot. The resulting GIF is just 859 kB:s.

And slightly off-topic: "MagickQuantizeImages" seem to create one palette per sub-image (frame). Is there a way to produce a single palette to be applied to all my images? This should eliminate the jitter I see in the animations.

EDIT: * I got one progress report, "Save/Images/" with 14/15. Not much of a report when it is just reporting that it has just about finished

For more information, use debugging. You can set the environment variable MAGICK_DEBUG ALL, coder (less), or trace (lots more debugging).

To produce a single palette, use RemapImages().

So there's nothing we can do currently to speed up the process of creating a gif from pngs or jpgs? I've looked into creating the gif with extremely compressed jpgs as opposed to full quality pngs, but I didn't see a very significant time difference.

I'm also confused about how to make a MagickProgressMonitor to analyze the process.

Sure, provide a simple program that illustrates the bottleneck and detailed instructions on how to reproduce the problem under Mac OS X or the iPhone. We've tried the original program in this thread under Linux, our default development environment, and it runs in a reasonable time. The bottleneck may be related to the ARM processor, or at least something related to Mac OS X or the iPhone environment.

Sorry it took so long. Here's an example. It doesn't display the gif, but the output from the Xcode project will tell you when it's been written/where it's at on the phone.

Edit: You have to run the project on your iPhone to see the issue. When it runs in the simulator, there's not a large problem. But when it runs on the phone, it's noticeably slower.

https://github.com/ZachOrr/Gif-ImageMagick-Example

Got it. Its going to take quite some time to investigate. We need to refresh our knowledge on deploying to the iPhone and we'll need to generate new iOS libraries for ImageMagick so we can including debugging statements. Both can be quite time consuming.

I tried a few different options myself, trying to find the bottleneck.
After replacing the GIF-writing part with giflib, I discovered that was NOT the bottleneck - leaving the color reduction and dithering.
I experimented with different dithering methods and quantize settings, but none gave me the speed I needed. I failed to separate the color quantization from the dithering, so I cannot say which was the time hog.

I then replaced ImageMagick completely by reducing the color palette using code from rosettacode.org. Using this code, the quantization became really quick, leaving just dithering as the bottle neck. I tried a few algorithms, and eventually settled for a home-rolled one to reach a sweet-spot tradeoff between speed and quality.

So to summarize: I replaced color palette reduction with code from rosettacode.org; I do my own dithering, and write the GIF with giflib. In the end, this turned out to be about 30x faster than using ImageMagick!

I highly suspect the dithering to be the time thief in ImageMagick.

emilk wrote:I then replaced ImageMagick completely by reducing the color palette using code from rosettacode.org. Using this code, the quantization became really quick, leaving just dithering as the bottle neck. I tried a few algorithms, and eventually settled for a home-rolled one to reach a sweet-spot tradeoff between speed and quality.

So to summarize: I replaced color palette reduction with code from rosettacode.org; I do my own dithering, and write the GIF with giflib. In the end, this turned out to be about 30x faster than using ImageMagick!

Could you post how you did that? That's way over my head. Or else I'd attempt it myself.

Legacy ImageMagick Discussions Archive

iOS GIF very slow

iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow

Re: iOS GIF very slow