[ux] Disable point size and treshold meter while having 'automatic treshold' selected

[MathijsG]

Until recently I didn't have the 'automatic treshold' selected, because it was a quite recent option and I didn't know its function.

Now I have, and it's quite handy, somehow it still only sees my 3 leds while the webcam being exposed in full sunlight. That's great! :)

I discovered hower that the slider gets ignored with it, so does the point size.

Maybe grey this out when the checkbox is checked? So it seems more logic?

[sthalik]

The slider isn't ignored, and there are some cases where it matters.

In the tree slider bounds are more sensible, i.e. slider position gets more useful. See if it regresses https://www.dropbox.com/s/fl98hv16mu47wgh/opentrack-hatire-test-v13.7z

The old slider position is comparable to the linked version's maximum value.

As for point sizes, they're definitely useful. Min point size is sensible for small unrelated blobs. Max point size filters out background stuff that gets illuminated.

It mostly matters for exposure set for the image to be visible in general. It also gives less noise as minimum exposure filters out everything but the brightest part of the LED-emitted light.

[sthalik]

The linked version also darkens out non-uniform-white light. It's an improvement from my usage but I'm not completely sure. Sure do tell if there are regressions.

[MathijsG]

With this version no matter what slider value, I get constantly one of me leds not detected. I do use infrared leds. By the way will this break functionality for people using regular red leds?

[sthalik]

What size are your LEDs in the overlay text? The constant needs adjusting.

It'll break non-white light sources. I need to back off the non-white darkening.

[MathijsG]

Can't you make the white light thingy optional? Maybe it does work better for people with IR leds (most of them I think), and while making it optional it won't kill headtracking for regular led users.

[sthalik]

@MathijsG it might improve things a bit with dim gray lights but bright white light is by definition more bright in grayscale than other colors. It'll work somewhat worse on slightly overexposed images.

But another issue is that the SIMD math needed takes a lot of CPU time compared to the previous version.

[sthalik]

@MathijsG please compare https://www.dropbox.com/s/gv19i6heicrhmxt/opentrack-pt-v14.7z. It should work on some slider position for you now.

[MathijsG]

It's working fine here with that version. But I still don't really get what the 'auto treshold' checkbox really does. I need to test further with daylight (it's evening in here now).

However I do get some (probably) unrelated problem with it, also with the previous version I got this, it's a messed up octopus: https://www.youtube.com/watch?v=7f5jTOBzBJU

[sthalik]

@MathijsG you have N bright color occurences, according to slider 0->400. Auto threshold goes over the image, starting from the brightest color and decrementing, until it finds all the N or more of pixels that bright or more. The color value that "fills" the N colors is treated as a threshold. This threshold value is then multiplied by 240/256. This is the automated threshold value.

You can find the logic from here https://github.com/opentrack/opentrack/blob/unstable/tracker-pt/point_extractor.cpp#L57 until the commented out qDebug() line.

[sthalik]

@MathijsG The octopus took some PCP and ketamine. I have no idea otherwise. Also, death is just two blue spheres.

[sthalik]

@MathijsG in the v16 build, how is auto thresholding on your model?

[MathijsG]

Haven't got any problems with it. Although it isn't that sunny anymore, but current tests show no weirdness.

But when you have the checkbox treshold auto, the slider still DOES something? Because I won't notice differences sliding this slider while having auto.

[sthalik]

Slider sets the brightness color to look at.

If you have 10 pixels of brightest color and slider set to more than 10/255 of its length, it's going to look for less bright colors as well during extraction. It looks for at most 400 pixels. It's going to lower the brightness value until it finds as many pixels as the slider selects per a fraction of 400 pixels.

If you have a point of radius r, you can use the formula 3(pi r^2) assuming perfectly circular points. Then give some leeway, reducing the value by 20-30%.

[sthalik]

IOW if you increase the FOV, lower exposure to min, move away from the camera, a higher slider value will catch background noise as points also.

[sthalik]

Also we need a high max value, as on rotations some points are way less bright than others. It can detect two points but skip the lowest one, with big points and a slider capped to way less than 400.

[MathijsG]

So lowest treshold is best until you encounter problems like detecting not all 3 the leds?

Also speaking CPU-wise.

[sthalik]

Not exactly. If you yaw with a clip, at least one point will be darker by virtue of being rotated more. It could be not detected. This is the scenario with points that aren't totally small.

We previously had this slider fuckup since I thought max slider value was 100 but it's 255, which is logical.

[sthalik]

CPU-wise doesn't matter. Using auto threshold uses a bit of CPU to do the histogram but you won't notice. Larger slider value will do few more iterations but it's so small a CPU time you won't notice that in any way. It was profiled and tested.

[sthalik]

@MathijsG are we good in rc49p1?

[MathijsG]

Yeah I guess there wasn't really a problem here anyway rather me not knowing that treshold still is a factor while having the 'auto treshold' selected.