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