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)
you are right with the name ...
we could then have a look at performance and eventually include it as an abstraction.
right ... at the moment pix_histo / pix_dump would imply quite some pd message handling overhead ...
but thanks anyhow. btw, have you tested the greyscale code ?
works on my machine ...
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
hm ... i might have a look into it ... but not today ...
btw, i don't think, you judge me right ... i'm not really a windoze ... hacker ... in fact the whole asio code was written on linux with a smb connection to win ...
cheers ... tim