|
Re: TrackTwoColors execution time
The Find Color will slow down when the primary color is in view. Here is a rough overview of the processing, including those things that are variable in their computation time.
First step is decoding the JPG -- pretty fixed time.
Next, any decimation or subsetting of the image to limit where you process -- fixed.
Next, color threshold with the primary color (lets say pink). -- highly variable since we take advantage of the fast threshold on L and S before computing H. This means that dark pixels are fast because we only have to compute one thing before they are excluded. Nonsaturated pixels like white are also quite fast, two quick calculations and they are excluded. Bright and saturated pixels undergo the more complicated conversion to hue which involves trig. All bright and saturated pixels that aren't pink will be excluded.
Next is a call to get the particle properties such as size, location, etc -- pretty variable. There is no way in advance to know how many particles or where in the image your BIG target is.
Next is a sort of the particles by size -- pretty fixed.
Next is looking near the big pink particles for green ones. I'll look at the C code later today to make sure it is doing this in a good way, but since the image pieces it extracts are tiny, this should be fast, but also highly variable.
Anyway, I hope this helps explain why the algorithm behaves the way it does. It is far from realtime, and all of the optimizations we've put in have only made it more variable in time.
Please let me know of any insight you gain.
Greg McKaskle
|