GAWD! That Was More Work Than It Should Have Been!

Post date: May 02, 2012 7:37:34 AM

So I am win! on my threasholding issue. I might need a tiny bit more tuning but ultimately I think I have the real problem licked. The main issue is that the data being returned by mat.get() isn't in a format that makes any sense. Specifically when looking at the values of a pixel in HUV format I get a number like -82, 53, -17. Now there's NO REASON for V in HSV (value) to ever be negative, Can't be, nope.

And it isn't. Turns out the issue is an old well known problem where Java doesn't actually have any unsigned numeric values. So instead of getting 200. I'm getting -52. I don't know how that all works out but it does. If it was as simple as 1 turning into -128 and 200 turning into 72 I would have been able to just set the threshold lower but no it's just WAY off.

Eventually I managed to dig up a reference to the problem that I could actually understand the answer to. The fix?

This:

int pix2AsInt = kPixelData[2];

Becomes

int pix2AsInt = kPixelData[2] & 0xFF;

Now pix2AsInt has a value from 0 to 255 and it seems to be reasonably linear and actually correspond to brightness!

This I can work with. With data that makes sense I think I can set a threshold reasonably well. I went through the samples I've captured so far and while gimp renders V as a 0-100 value instead of 255 nothing with a cat in it scores over ~50. more importantly the backdrop, covered in shadow in the middle of the day scores around 84. Well above the 1/2 way mark. At night due to the auto brightness thing it's even higher, close to 100. I'd still like to turn that up to improve the FPS at night when this is the biggest problem but I'll crack that nut separately.

For now I'm going to start over with a threshold of 100 and see where that takes me.