Tim Blechmann wrote:

hi all ...

i wrote a small object that analyses the color channels of an image ... nothing you can't build as abstraction with pix_histo, but faster (both in terms of cpu speed and coding time) ... i know pix_analyse_colors is a stupid name, but no better one came to my mind ...

hi tim.

thanks for the code. i am still wondering whether it wouldn't be better to make this behaviour with a new (and working) version of [pix_resize] and [pix_dump] (i mean: if [pix_resize] would take arguments for the new size and this size could be 1x1 *and* the resizing would do interpolation than this would do almost the same as [pix_analyse_colors] (i think it is rather [pix_mean_color], but who cares) and it would be more flexible (finally the object we need to mix/merge/... images of different sizes)

we could then have a look at performance and eventually include it as an abstraction.

but thanks anyhow. btw, have you tested the greyscale code ?

feel free to add it to the cvs, if you are interested ... if not, is there any way to build externals for gem that are distributed seperately?

this is possible (but in this case you haveis quite an elementary object that should rather go into Gem itself) under linux it is simple, on windows you probably now better than me (when i started to compile my own Gem objects i didn't bother to make them separate externals but rather built my whole Gem++, just because i was to lazy/stupid; later i became maintainer and the problem was gone)

mfg.a.sdr IOhannes