[GEM-dev] pix_analyse_colors

IOhannes m zmoelnig zmoelnig at iem.at
Tue Nov 23 09:02:33 CET 2004


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




More information about the GEM-dev mailing list