On Nov 14, 2011, at 12:30 PM, Ricardo Fabbri wrote:
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.
That sounds very useful! I believe that operation is called a color mask. Isn't there something like pix_mask?
.hc
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 GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom