> i would go for [pix_colorclassify]. > if you agree and are willing to change the name in your branch, i'll > import it as is.
I agree and have just renamed it and it compiles cleanly here. You can fetch the changes in the same 'color' branch. > - - it would be great if the user could modify those labels. e.g. [1 0 0] > sounds like a great label for "red", but some weird user might chose to > prefer [0.5 1 0.8]. That will come with a later contribution. I wrote a [pix_equal] external which can change any pixels "equal" to some value within a given cosed r & g & b range. I use it to separate the colors into different images, change the color label, etc. > > it would also be nice to be able to parameterize the detection code, but > i guess it is too fine tuned to the six given classes (so it would both > complicate things from the dev's and the user's povs) > I guess we should go with the simple algorithm at first, then improve it if needed. I noticed that even with very bad lighting conditions and offset colorbalance, at least 2 or 3 colors work robustly, so this should be useful without tweaking. The parameters have already been tuned on a large database of exemplars. But, I agree, decreasing the sensitivity to e.g. 'red' would be nice. I say we wait for further demands and beta-testing prior to making the external more complex. Thanks! Ricardo Fabbri labmacambira.sf.net _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
