Re: Particle Analysis Report Problems
 

I looked through the documentation, but couldn't find specifics. At least for the LV entry points the API is pretty forgiving and pretty intelligent. The underlying call to imaqColorThreshold takes in Range* datatypes for the three color specifications. A Range is two ints, which can encode 32 bit ints. I tested the LV entry points and they pin the ints into a reasonable range, so 256 is the same as 255. I'd expect the C functions to do the same. I don't have the signature for the RGBThreshold wrapper in WPILib, but as long as it uses ints and not int8s, there shouldn't be a problem, and even then, it would depend a bit on the ABI and implementation details.

Greg McKaskle

Re: Particle Analysis Report Problems
 

I can see your point, but the reality is that these images are 24-bit HSL or 24-bit RGB ... 8 bits for each of H,S,L or 8-bits for each of R,G,B... so when you filter against them, you are filtering these exact 8-bit values in or out. So even though the API may take larger than 8-bit numbers, the max value you want to put in your filter is 255.

Thanks,
bob

Re: Particle Analysis Report Problems
 

I completely agree. It is confusing and possibly brittle to use a number that won't fit into an int8, but as long as the RGBThreshold wrapper doesn't cause it to be cast, the underlying IMAQ functions appear not to treat 256 as 0, but instead treat 256 as 255. In other words, they pin the input number into range rather than cast it.

Again, I'm basing that on the behavior of the LV entry points, and the C version could be different.

Also, the IMAQ analysis functions also support int16 monochrome, float monochrome, and even RGB64 images, so the pinning is useful for those cases as well.

Greg McKaskle

Re: Particle Analysis Report Problems
 

Hi, why do you use a for loop in your function? We have been trying to get the particle analysis working so we can use the FindColor function of TrackAPI.