PointTracker crashes on launch

[brokenhands]

As a preface, I've had OpenTrack working with the Aruco previously, and got FTNoIR working with PointTracker 1.1. My hardware is a Kinect with a custom IR rig. I've been using this to access the IR camera: https://github.com/falahati/NiVirtualCam

When I try to start tracking with PointTracker selected and NiVirtualCam going, OpenTrack32 CTDs. It does this regardless of which of the cameras are selected (Kinect/NiVirtualCam). If I close the OpenNi proxy app it ceases to crash, engages the Kinect (motors spin up and it levels), but show no video widget.

If there's a way of accessing the IR camera directly from OpenTrack we could eliminate the DirectShow filter layer and go direct to the device; I just don't know a way of pulling that off.

[sthalik]

So basically it crashes if camera's already in use?

dshow's an abstraction layer for accessing cameras. We won't talk to the kernel directly. The filter layer's necessary for dshow to give us frames. It also implies your graph settings' messed up, are they?

[brokenhands]

Somewhat, it crashes if the NiVirtualCam is in use. I mention FTNoIR because the plugin seems to work there. It seems to behave as if OpenTrack isn't respecting the selected camera index, and trying the native device instead of the virtual one that I've selected (pure speculation). The ini file looks pretty similar between apps, both of them have the camera index as "1" instead of "0".

"It also implies your graph settings' messed up, are they?"

Not clear on which graph we're talking about here. This is the only app that exhibits issues with the NiVirtualCam&PointTracker; it works flawlessly for Skype/EmbeddedFlash/FTNoIR/etc. For testing purposes I was able to launch the Aruco tracker again through the IR camera in this method, with no crash. Everything worked flawlessly outside of the tracking (there was no graphic to track), I was able to see the IR camera's widget in OpenTrack.

Thanks for looking into this and reading my long-winded issue explanations. Let me know if there's any additional testing I could do to assist. In the meantime I'll be trying to open the camera without the extra layer.

[sthalik]

Meant dshow graph.

Can you try a different camera and see why/when it crashes? Hint, try a one that's already in use by other software.

If that won't help, we need a backtrace to actually know what the hell's happening.

[brokenhands]

Considering picking up a PS3Eye to replace the Kinect and remove the weirdness layer. If I do I'll go back and test the issue for you, because I think this setup is pretty common and super cheap heh.

I still believe the PointTracker 1.1 just isn't respecting the ini/ui setting for the camera's index. At the top it says "Kinect - Not Connected", whereas that should show "OpenNiVirtualCam - Not Connected" or whatever. For testing I switched back to Aruco yesterday, was able to use the virtual device with no problem. I even toggled which camera it was streaming from their software, and OpenTrack didn't skip a beat or crash (there's a banner image when it's not broadcasting from a camera).

So in short: the other tracking dlls seem to correctly use the UI/ini index setting for the camera with no issue. PointTracker displays index 0 actual device regardless of configuration, and crashes on use if the streaming app is active (same behavior as if I was trying to use the index 0 device on purpose here).

I'd debug or look at the code, but I do UI/UX so my C is terrible.

[sthalik]

Agree about index. The functionality merely preserves ordinal of the device, not a serial, USB port id, anything of actual meaning.

The label in the top right corner in stable version just shows first connected device. It also went the way of the dodo. It ran out of cake.

Try unplugging camera during tracking and see how drivers + opentrack react.

[sthalik]

Note, if we're to provide sensible camera celection logic for some OS-en, it's an issue in itself and let's track it separately. What do you and others think about that?

[sthalik]

@brokenhands run the binary build unstable/opentrack-windows-flush-20141005-20141011-d283cfb.tar.xz and see if it works.

[sthalik]

Waiting three more days before closing abandoned.

[brokenhands]

Sorry bud, my release this week was less than smooth and eating my gaming/testing time. I managed to test today over VNC because you've been waiting so patiently. As such I can't give you a ton of feedback on responsiveness, but I have some good news:

I was able to get the video widget going, tracking 3 points with beautiful green crosses.

A few points of note:

1) The new UI is a big improvement over the last one: good job. 2) It took starting and stopping tracking twice to grab the video stream. Not sure if that was just timing or specific to my machine, or if it wasn't inited. 3) The dialog for PointTracker showed 0 FPS under "Camera Info". Since I can't move the headset over VNC, I'm not sure if I'm seeing a single frame, or if the capture is working but not updating the UI.

Thanks for poking at this. I'm happy to continue doing any Kinect&OpenNi testing you'd need.

[sthalik]

No one reported bugs on PT and they piled up. There were internal changes and PT hasn't caught up till now. Thanks for the report.

[sthalik]

Commits listed twice cause dev/ewma branch fast-forwarded to unstable, and github considers them two separate events.