|
Re: NiVision.cpp
The way the color threshold is being used, we are sending in an RGB image, and asking it to do HSL comparisons. To do this, it converts the pixels to HSL as needed. The largest cost is the hue calculation, so this is done only when the other stuff passes. So in fact, the threshold is doing quite a bit of work. But it is still necessary and fast.
There are of course ways to speed it up. There are functions in the WPI and in the nivision libs for subsetting the image. You can extract a stripe or rect of the image to further limit what the threshold needs to process, and you can decimate the image to grab only every Nth pixel. The speed gain for the threshold call will be directly affected by the number of pixels being processed.
The LV example demonstrates this by using the extract subVI. The trick is to fix up the coordinates on your results. Decimating shrinks the returned coordinates, and subsetting shifts them. So if you implement this in C, it may be useful to look at the LV one for comparison.
Also note that the content of the image and the settings of the Lum and Sat parameters will affect the timings you take. For consistency, take a realistic image, and use it as your test case using a JPG read. The lum and sat speed up the algorithm, because the more pixels that can be excluded with lum and sat, the fewer hue calculations are needed.
Greg McKaskle
|