Frame times, absolute time, and sync'ing

[noam.gilmore]

Hello

My setup includes the OptiTrack SDK v1.1.1 and 2 TrackIR-5 cameras. I need to know, for frames captured from both cameras:

1) Ideally: the computer time at which each frame was taken
2) Less ideally: their order and distance in time (which came first, and what the delta is)

My questions, thus:

1) Is there a cookbook way of doing this?
2) is CameraLibrary::Frame->TimeStamp() the camera time at which the frame was taken? I assume there's no guarantee about the relation between different camera's TimeStamp()'s? (order btween them, a constant delta)
3) Assuming a "no" to Q.1, will emptying the queue and registering a CameraListener on each help? I'll just register the PC time at which the FrameAvailable callback was called, and take the corresponding frame's TimeStamp(). I'll then have a baseline for converting each camera's frame's TimeStamp() to PC timestamp.
4) I understand #3 is only as accurate as the latency between the frame's availability and my callback being called. In what thread will the callback be called? Will this even work with my given camera and SDK?

Cheers,
Noam

[beckdo]

Yes, for TIR5 frame->TimeStamp() is all you have and it's the CPU time (in seconds) at the moment the data was received by the PC from the device. I would assume you're trying to essentially synchronize the incoming frames so you can get a frame group which is a frame from each camera matched as closely in time as possible so you could do triangulation for example?

Use frame->TimeStamp() as the time the frame arrived, it's extremely accurate unless your computer is slow or bogged down.

If you want to sync up the two cameras, we've already got that functionality...use the synchronizer.

cModuleSync *sync = new cModuleSync();

sync->AddCamera(camera1);
sync->AddCamera(camera2);

At that point instead of calling GetFrame() on a camera, that job has been taken over by the synchronizer. Call sync->GetFrameGroup(); which will return a frame from each camera and it will grab the ones closest in time with each other.

[beckdo]

In regards to your last question, the callbacks are literally triggered from the USB read thread, so they are designed to be minimum latency. Same goes for the synchronizer callbacks if you use those.

[noam.gilmore]

Thanks Doug.

It's nice to have frames from the same point in time, but it's not a hard requirement for me: I am tracking objects, and can predict where they'll be in "the future", so I can bring 2 frames to the same point in time if required.

As to minimum latency -- all I planned on doing was noting the PC time, but that's when I thought frame->TimeStamp() was camera time. I assume given your first reply (TimeStamp() being PC time, plus use cModuleSync) that's redundant now.

Also, how exactly does cModuleSync() work? How does it know the "real" timestamp on a frame (when it was captured)? Because you mentioned "it will grab the one closest in time w/ e/o".

Finally -- is there something like sync->GetLatestFrameGroup()? (note the "Latest").

Cheers,
N.

[NaturalPoint - Mike]

The timestamps are applied to the frame when they are received by the system.