version 6.4.2-3 "CPU hog" with GIF files?

[redna379]

Hello.
I have some thoughts i'd like to share.

I use IM to generate images for an online signs designer.
Till one month ago, i had version 6.3.7 installed. All was fine, but at some point i needed to be able to limit memoty usage and i noticed the new limit memory and map option. So i updated to 6.4.2-1.
But that verion had some issues with GIF files: converting a PNG with transparent BG to GIF caused the GIF to have black BG. And so, yesterday, i updated to the very last version 6.4.2-3. Gladly i saw that the GIF BG issue was fixed.

GIF would not be needed by me, but i have to keep it: as i have to face the damned Intenret Explorer6 issues with PNG, i simply created a final step in my script that converts the final image to GIF if the client is an IE6.

I have a simple popup that allows users to choose a font. In it, i render a small image for each font using user's text, so that they can choose better. Basically, a page that load around 40 small images in one page, and all generated via IM.
With FireFox (and so having IM serving PNG images), no major issues.
But opening that popup with IE6 (and so having IM serving GIF images converted from the abovementioned PNGs) caused a true nightmare. The server was completely frozen, i had to request a reboot.
Trying on another machine and looking at "top" output (i'm on a linux server), i noticed an incredibly high CPU usage when using IE6 to load that page. Around 6-8% CPU for each conversion from PNG to GIF.

The commands i'm using are really simple, here they are:

Generate the PNG font image:
convert -background none -font SOMEFONT -pointsize 15 -fill "rgb(0,0,0) label:"SOMETEXT" PNGFILE

Converting it in GIF if the client is IE6:
convert PNGFILE -background none -flatten GIFFILE

With 6.3.7, i never experienced something like that. What i would like to know is if this is a known behavior or not.
If i don't want to freeze the server, it's quite obvious i'll need a version with this solved before updating again, evenif this can't be properly called a "bug".

Any thought on this?

[magick]

Sounds like there is a bug in IE6 and it should be reported to Microsoft. In regards to ImageMagick, its a question of does IM produce GIF images that follow the GIF standard or not? If you think ImageMagick is producing improper GIF images, tell us why you think so and post an example. We will investigate further.

Note, we were unable to reproduce the problem you reported. We tried your commands with ImageMagick 6.4.2-4 and IE6 displayed with images without complaint.

[redna379]

Thank you for your reply, but the point is different.

The GIF bug was in 6.4.2-1, i already know it's now fixed (as i wrote, i updated to 6.4.2-3 precisely because of this).
What i'm talking about is not properly an issue, but a question about the latest GIF implementation.
With the 6.4.2-3 i've tried, GIFs are fine also in IE6.

But the 2nd command i mentioned:
convert PNGFILE -background none -flatten GIFFILE

looks really heavy on server.
Executing it with 6.4.2-3 shows a "convert" CPU usage which is around 5-8%, much more higher than in past. Probably too high, considering they're really small images.
This is natuarlly an issue to me, as i often have more than 40 converts like that called from a single page.
5-8% * 40... the result is a frozen server.

So now i had to go back to 6.3.7, which does not have the -limit option that would help me, but at least generate fine GIFs without eating so much CPU.

My question was about the GIF implementation itself: it's only me experiencing such grown usage of system resources?

[magick]

The color reduction algorithm was improved to support transparency. Its possible if you add +matte to your command line to turn off transparancy, you may get faster results.

[redna379]

I will try, thank you for the hint.
Anyhow wow... the improved algorithm needs so much power also for small images?

[magick]

It uses a a tree structure which expands from 8 children for each node to 16 if the image is transparent.

[redna379]

Thank you for the additional infos.