Tracking Tools vs OptiTrack SDK

[dashesy]

Sorry for my newbie questions.

My setup:
I have purchased TT2.0 and only one V100 camera.
I need to track in 2D (i.e. x,y) up to 3 markers, so I do not need to use more than one camera.
I need to come to a choice to use TT2.0 or OptiTrack or even PointCloud in a project written in Microsoft Visual studio in C++, please answer my questions and let me know what you think, thank you.

I managed to take the COM based grayscale code written for OptiTrack into my project.
But it seems there COM is slow right?
Is there a way to directly talk to hardware in OptiTrack? How about PointCloud? I think TT2.0 is dll based, or is it talking to a COM object behind the scenes?
I also noticed that some options like Automatic Gain Control, and Automatic Exposure Control are in TT2.0 that are not available for OptiTrack and PointCloud, am I right?
Does that mean OptiTrack/PointCloud can not access those hardware features, or those features are implemented in TT2.0 software?
Which of the above have COM based interface and which have normal library-based interface?

Is there a way to use TrackingTools with one camera? I mean a way to ask it to use only one camera? I assume if I have a calibration file (that might include only the masking points), I should be able to use TT2.0 APIs with one camera but my problem is that without 3 cameras I can not make a calibration file.
What is the format of the calibration file so I can make one that is suitable for one camera?

Few more questions,
What happens if I mix different SDKs? Lets say OptiTrack and TT2.0, is it possible? What is the decision behind different SDKs you provide? I mean do all of them have access to all features of the hardware, but some implement software add-ons? Is TT2.0 written on top of PointCloud or is it OptiTrack? What is the advantage/disadvantage of each of them lets say why should I use OptiTrack instead of PointCloud?

One more question: Is it still possible to buy RigidBosy instead of TrackingTools?

Thank you

[Birch]

But it seems there COM is slow right?

The COM interface should not be slower than using a non-COM interface. An important aspect for either method is to make sure the cameras are serviced fast enough and that the frame queue is cleared out whenever you do service it (see other post from today).

Is there a way to directly talk to hardware in OptiTrack? How about PointCloud? I think TT2.0 is dll based, or is it talking to a COM object behind the scenes?

Accessing the cameras at a lower level than the OptiTrack SDK is not available to the public. The OptiTrack SDK level is usually sufficient for development needs. The Tracking Tools (and its SDK) uses a different method to access the cameras which does not involve the OptiTrack SDK.

I also noticed that some options like Automatic Gain Control, and Automatic Exposure Control are in TT2.0 that are not available for OptiTrack and PointCloud, am I right?

Does that mean OptiTrack/PointCloud can not access those hardware features, or those features are implemented in TT2.0 software?

Currently we don't have plans to implement AGC/AEC in the OptiTrack SDK, its only available in the Tracking Tools and Arena right now. Same for MJPEG. It means the OptiTrack SDK is not able to access those features.

Is there a way to use TrackingTools with one camera? I mean a way to ask it to use only one camera? I assume if I have a calibration file (that might include only the masking points), I should be able to use TT2.0 APIs with one camera but my problem is that without 3 cameras I can not make a calibration file.

The algorithm used to calibrate the cameras and their lens properties in 3D space requires at least 3 cameras in order to work. That is why "3+ OptiTrack cameras" as part of the Minimum System Requirements on the Tracking Tools page. Manual creation of calibration files is not supported.

Since you only have an interest in 2D tracking data, there shouldn't be a need to load a 3D camera calibration file.

What happens if I mix different SDKs? Lets say OptiTrack and TT2.0, is it possible?

Only one interface to the cameras should be used, more than one should *not* be used at the same time or in the same application. Likewise, only one application accessing the cameras should be run at a time.

What is the decision behind different SDKs you provide? I mean do all of them have access to all features of the hardware, but some implement software add-ons?

Is TT2.0 written on top of PointCloud or is it OptiTrack?
What is the advantage/disadvantage of each of them lets say why should I use OptiTrack instead of PointCloud?

One more question: Is it still possible to buy RigidBosy instead of TrackingTools?

The OptioTrack SDK is provided as a free 2D API to interface with our cameras. It does not provide the ability to perform, capture or track in 3D.

The Tracking Tools 2.0 (with its SDK) is an additional cost product which provides the calibration and software necessary to capture 3D data and perform 6DOF motion capture tracking with rigid bodies. Its API provides access these advanced features.

The Point Cloud and Rigid Body toolkits were the previous incarnation of the Tracking Tools 2.0, they are no longer for sale and have been officially retired. We do not recommend starting new projects using their SDKs at this time.

You may also wish to consult our software comparison page :
http://www.naturalpoint.com/optitrack/p ... rison.html

[dashesy]

Thank you I think I got my answer.
Although I am going to perform 2D tracking (for now) I will use TT SDK, because first it is better supported and second it is more powerful and will be even better suited for tracking purposes in the future. In addition, looking at your TT I have good hopes to write an application with better fps lets say.

That requires an additional cost for our customers, but I think it worth it.
One question/suggestion. Do you plan to add 2D support in TT? I mean a simple 2D rigid body tracking assuming the location and direction of the only camera is provided to the tracking algorithm.

[dashesy]

One question/suggestion. Do you plan to add 2D support in TT? I mean a simple 2D rigid body tracking assuming the location and direction of the only camera is provided to the tracking algorithm.

[Birch]

Please provide some additional information about the 2D rigid body tracking you would like to perform. If you can be more specific about your application it may help us provide a better answer. If you would prefer not to post the information on the forums you can send it to support@naturalpoint.com.

Would the rigid bodies be defined only in X,Y coordinates, or would they be defined in X,Y,Z coordinates?

Would the object(s) you are tracking be moving only in X, Y space parallel to the imager, or would the object be moving in full X,Y,Z space?

Do you want only the X,Y origin of the rigid body, without any Z estimation?

Or, are you interested in the software trying to estimate the 3D position in space of a rigid body using 2D information from a single camera (similar to what the TrackIR does with the vector clip)?

What units will the tracking data need to be returned in? (imager pixel coordinates, meters, etc)

[dashesy]

Yes every thing is in 2D including the coordinates of the rigid body. And I need the X,Y origin of the rigid body without Z estimation.
Lets say using 3 markers I would like to be able to track the position and direction of an animal in the scene (can not do it with less than 3).
The objects are moving in a plane not necessarily parallel to the imager, however even if tracking algorithm assumes they are parallel, that would be fine because knowing the location and heading of the imager relative to that plane, the computation of actual X,Y needs a simple transformation. The imager can do the same transformation knowing camera heading and position as well. To automate this transformation 3 or more points of the target plane need to be mapped to the imager plane (you can call this wanding but it should be done on the 2D plane only)

Again the units can be determined in meters from pixel units after knowing the position and heading of the camera relative to the plane.

Again as a suggestion, for rigid body tracking I think a correlation between defined rigid body templates and any combination of detected markers in the scene (after considering the constrains to reduce the search space) would work. To further enhance the tracking algorithm a Kalman filtering or particle filtering can benefit from previous location of the rigid bodies. You have more experience so consider this as a suggestion.

Thank you and hope to see an even more powerful TT