ConfigTool needs a proper camera settings app.

[cboulay]

• Modify exposure
• Modify gain
• Toggle blue_dot/red_dot
• Show BGR image
• Show HSV image
• Put the sphere on a table. Click on a pixel in the centre of the bulb. The LED will cycle through some presets, each time recording the HSV value in the pixel. Save the mapping from LED preset to HSV. This mapped-value will be what is used by the tracker.

[HipsterSloth]

I have all of the manual calibration setting work in place. You can see the manual setting work in action here. In the current manual color calibration tool for each tracker you can now:

• Display the camera feed in three modes
  • raw BGR image
  • HSV color space
  • filtered HSV masking the original BGR image so you can see how the bulb color is getting filtered
• Modify camera gain
• Modify camera exposure
• Tweak the HSV filter parameters for each of the six tracking preset colors (magenta, cyan, yellow, red, green, blue)
• Save the camera and filter parameters to a default profile and then load those filter parameters on another tracker (useful if the other tracker has similar lighting properties)
• Save the parameters to tracker config so they persist.

This still leaves the work of automatic calibration. I think this is going to be more complicated then just sampling the HSV at a pixel click since the wrong camera and filter settings won't show any color at all. Usually it's a matter of dropping the exposure to around 16, bumping the gain a bit, and then playing with the saturation center (and maybe bumping the hue angle). But this varies from color to color and lighting condition to lighting condition. I'm not sure what the best adjustment algorithm would be yet.

So until I have a good answer for that, I'm going to move on to making the tracking work. Once that's done, I'll come back to this issue and look into auto-adjustment.

EDIT: Fixed you tube video link

[cboulay]

That looks great! I actually wasn't expecting you to feed the other video frames because that seemed like too much work.

Anyway, I hope you agree it will be worth the effort. Almost every time psmoveapi didn't work for me was because of poor colour calibration. Hopefully this fixes that problem.

Tiny detail, but it seems a bit counter-intuitive that + is to the left of -.

If I get time before I leave, which I doubt I will, I'll try to test my camera in a few conditions and send you the files. Maybe if you get a few samples you can figure out a pattern that at least gets the hue angles for each bulb colour.

[HipsterSloth]

I made the tweak to the UI to fix the +/-. So I think what remains is:

• Selecting between calibration presets
• An auto-calibration button that goes through an adjustment sequence trying to find the optimal settings for each color

[cboulay]

I think we can have an un-documented feature: only when the HSV image is shown, right clicking on a pixel will set the Hue angle and S,V centres to the value of the pixel. At my place, I was able to find good values for all colours except magenta... and that's a problem because it's the default so I couldn't test tracker algorithms updates.

[zelmon64]

I agree about magenta - it has always seemed problematic. I managed to get it working for me with these settings: It seemed to track okay in the calibration tool. Strangely the tool crashes when I try to redo calibration from the "test tracking" screen.

The colour can be set to the next one (cyan) by turning the PSMove off and on while PSMoveService is still running. I think this is because the colour setting isn't freed which I read you talking about somewhere (but I can't currently find it).

I got this to work with two cameras but with three the third one won't work stating "Can't connect any more new devices. Too many open device." in PSMoveService. Is there currently a limit to two cameras? I can't remember seeing it mentioned anywhere.

This new service is great! I'll try to chip in where I can.

[HipsterSloth]

@zelmon64 Yeah there is a bug in the test tracking state where it's skipping over some initialization that happens when you run through calibration normally.

As for the 3 camera issue there is in fact an arbitrary hard coded limit to 2 cameras. When I tried more than two camera tracking previously I had problems with the handoff between one pair of camera triangulating and another pair triangulating. The service has a new approach where I triangulate between all possible pairs and average the result. It's untested at the moment though. You can effectively enable it by setting k_max_devices in TrackerManager.h from 2 to 3. I'd be curious to see if that works for you.

Thanks for testing this out!

[zelmon64]

@HipsterSloth Thanks for the info on the bug and the hard limit on the number of trackers. I tried setting k_max_devices to 3 like you said and the service connected to the third PS3Eye fine. I then tried to access it in PSMoveConfigTool but that seems to be hard limited to a maximum of two as well. Do you know if that also has a simple variable somewhere set to two or will it require a more complicated alteration? I couldn't find anything in a brief search through but then it's a bit like a needle in a haystack for me at the moment :).

[HipsterSloth]

@zelmon64 Oh oops! My bad. Yeah you also need to change PSMOVESERVICE_MAX_TRACKER_COUNT to 3 in ClientConstants.h. Long term I should make that one constant that both the client and server refer to.

[cboulay]

I added the ability to rt-click on a pixel to use its HSV values for the filter. a20aaa788117693fc3836e53fdd852c38d7bb660

[HipsterSloth]

@cboulay Awesome. That's an elegant way to solve that. I didn't know you could get the mouse click position from imgui. I was originally thinking we'd have to plumb through the click from SDL to the appstage. One minor suggestion I would make is to get the screen resolution from "ImGui::GetIO().DisplaySize.x/y" and get the tracker buffer size from "ClientTrackerView::getVideoFrameWidth()/Height()". But those constants aren't changing any time soon (or ever?) so hard coded values are totally fine for the time being.

[cboulay]

yeah you're right. I couldn't figure out where the 800 x 600 was being set but I didn't think to query ImGui directly. While its header files is commented pretty well, I do wish it had some real docs.

[zelmon64]

@cboulay That looks like a rather nice and simple way to do it :+1: . It'll make a multi-cam setup so much quicker to do.

@HipsterSloth That variable did the trick. I set up one PSEye in front of me 7'10" away, the second slightly to the left 5'9" away and the third slightly to the right 5'2" away. The furthest one is on the red focus and the nearer two use the blue setting. The tracking seemed to behave fine. I was able to block the PSEyes one at a time by holding a keyboard in the way and nothing strange happened. It was a little jittery but I nothing a filter couldn't fix.

[HipsterSloth]

@zelmon64 Wow. That's cool to hear that worked. I'm glad you mentioned the dot setting because that reminds me that the server doesn't actually do anything with the dot setting (despite the color calibration tool allowing you to change the setting). This means that the projection math always uses the same focal length (554.2563 pixels), which is for the blue dot, not the red dot. This means the projection position computed will be wrong for the camera with red focus set. This should be fixed in PS3EyeTracker::setOptionIndex(). I actually have a TODO in there I neglected for this very case.

@cboulay Do you know what the focal length should be for the blue dot red dot setting?

[cboulay]

640 x 480 gives 800 diagonal pixels. Each lens setting has a specific FOV X. X_blue = 75; X_red = 56; Focal Length = 400 / tan(X/2)

This gives 521.2901 for blue, 752.2906 for red.

However, the sensor actually has more than 640 x 480 pixels. According to this doc, it has 656 x 488. Using the same math as above, we get Blue: 532.7626; Red: 768.8469.

This is closer to the 554 we get empirically.

[cboulay]

Hmm... the "image area" is 3984 um x 2952 um. Each pixel is 6.0 um x 6.0 um. So that gives an equivalent image area of 664 px x 492 px. Using the same math as above... Blue: 538.5018; Red: 777.1293

It's still not quite what we get empirically but it's a reasonable first guess without camera calibration.

[HipsterSloth]

As was mentioned in issue #63 by @toto5100, we should also expose camera resolution and FPS settings in the camera config tool. Not an urgent feature, but it can be useful for debugging USB bandwidth issues (see if the video stream stops stuttering when lowering the frame rate/resolution).

[HipsterSloth]

I think we can say the spirit of this issue has been solved. At this point if there are other ConfigTool requests we can just file a new issue for them.