quetzlzacatenango imagemagick.org wrote:
>> help me figure out why the new build is much slower
on GIFs?
>>
>>
>
>Our new color reduction algorithm takes into account
transparency. We had
>to expand from 8 children per Octtree node to 16.
Dealing with 16
>instead of 8 children is slower but returns superior
results. However,
>in case that is not the reason for the slowdown, post a
URL to one of
>your problematic images and we will download and compare
timing to see if
>we can speed up the process.
>
>
>
ftp://ftp.nwa.com/incoming/nat1844.png
converts to
ftp://ftp.nwa.com/incoming/nat1844.gif
In this simple test, the old version runs
time convert nat1844.png nat1844.gif
real 0m0.55s
user 0m0.39s
sys 0m0.14s
The new version runs
time /home/a26811/im/bin/convert nat1844.png nat1844.gif
real 0m1.71s
user 0m0.85s
sys 0m0.23s
I ran a unix diff against the two created gifs, they are
identical, so I
don't think
there is any compression difference.
This difference, while quite noticeable using convert,
really becomes
significant
in my application that uses the Wand API, and converts
dozens per minute.
In the real application, the input source is a RGB,
outputing to a gif
or png.
I'm giving you a png input because its easier to deal with
and my RGB images
never exist as a file, but rather inside my application's
memory. If
you really
want the original RGB, I can mod my program to write it out.
But the effect
is the same.
Thanks,
Brian
_______________________________________________
Magick-users mailing list
Magick-usersimagemagick.org
http://studio.imagemagick.org/mailman/listinfo/magick
-users
|