[Tutor] speeding code along

[Thomi Richards]

> Perhaps you could precalculate the closest colour for each
> input colour once for all, and store that in a dict or if need
> be, some kind of database? Then you only make a quick lookup
> for each pixel.

ok, if you think it will be faster, I'll give it a go...

> 
> A compromise might be that once you have calculated a colur,
> you store it in a dict, and then you check the dict, so that
> you don't need to test again when you run into the same colour
> several times in an image. This will give a big speedup for
> images with few colours at least.
> 

yes... I'll see what happens. I remain skeptical, because we're
rendering down 24 bit bitmaps, which have been made in blender. You very
rarely get large blocks of the same color....


> Apart from that, I imagine there are faster methods to find
> the closest colour in a palette than the brute force method
> you use.
> 

i couldn't think of any :-)
Also, this method (although it does take an age), does give better
results than the GIMP and paint shop pro... interesting. i wonder what
algorithm they use...
> 
> To store the info persistently, you could pickle the dict
> to a file, or use some other persistence mechanism.

yes, although the palette may be changed at a later date. i guess i
could say "if the palette file is the same as the last palette file
then:". but then again, over several weeks of using the same palette,
this conversion table could grow enormous...probably affecting the
speed,

> 
> I made a similar caching change to a python benchmarking
> program that used recursion to calculate Fibonacci numbers.
> That made the program roughly 6600 times faster...
> 

I'll give it a go, thanks!

-- 
This is a subliminal message.
Thomi Richards,
thomi@imail.net.nz