[EMAIL PROTECTED] 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
[email protected]
http://studio.imagemagick.org/mailman/listinfo/magick-users
