I'd just like to second rel_21's request for access to the frame buffer. I find the lack of this function very strange, especially considering the FAQ's stressing that this is a development platform and that the users should write their own tracking algorithms. How are we supposed to do that without being provided the means to?
I need that function for the camera to be of much use at all.
Example:
19. How does the software cope with occlusion?
It doesn't do anything. The OptiTrack system is a Development Platform for many tracking applications, so we provide you with the SDK and reference examples, but actual multi-object tracking using multiple cameras has to be done by your software. [...]
Image buffer access
Re: Image buffer access
quote:Originally posted by wesslen:
I'd just like to second rel_21's request for access to the frame buffer. I find the lack of this function very strange, especially considering the FAQ's stressing that this is a development platform and that the users should write their own tracking algorithms. How are we supposed to do that without being provided the means to?
I need that function for the camera to be of much use at all.
Example:
19. How does the software cope with occlusion?
It doesn't do anything. The OptiTrack system is a Development Platform for many tracking applications, so we provide you with the SDK and reference examples, but actual multi-object tracking using multiple cameras has to be done by your software. [...]We do not expect to implement support for raw access to the 1-bit framebuffer for the current generation of hardware in the OptiTrack SDK. To clarify, identification (provided in the SDK) means locating and reporting the position markers (objects) in the cameras field of view, when the FAQ refers to tracking it is talking about how the markers and their locations are utilized (particularly between consecutive frames).
The current SDK provides access to all objects identified within a video frame and makes the information about them available. The OptiTrack SDK provides basic built-in 2D object tracking and ranking capability, what it does not provide is multi-camera 3D tracking and correlation. Likewise, if you want a more advanced 2D tracking algorithm than the one included, you would need to implement it on your own.
The lack of access to the frame buffer should have a minimal impact on the ability to implement a multi-camera 3D tracking algorithm (which some OptiTrack users have implemented) since the object data is available. The FAQ entry on occlusion refers to the scenario where a marker (object) becomes occluded in the cameras view, this means that it is no longer visible to the camera and will not be present in the frame buffer. In multi-camera 3D tracking, a common technique is to utilize multiple cameras in different locations tracking the same markers (objects) in order to better handle occlusion.
It would be helpful for us if you could you explain more specifically how the current implementation is preventing you from accomplishing the tasks in your project.
[ March 23, 2006, 03:01 PM: Message edited by: NaturalPoint - Birch Zimmer ]
I'd just like to second rel_21's request for access to the frame buffer. I find the lack of this function very strange, especially considering the FAQ's stressing that this is a development platform and that the users should write their own tracking algorithms. How are we supposed to do that without being provided the means to?
I need that function for the camera to be of much use at all.
Example:
19. How does the software cope with occlusion?
It doesn't do anything. The OptiTrack system is a Development Platform for many tracking applications, so we provide you with the SDK and reference examples, but actual multi-object tracking using multiple cameras has to be done by your software. [...]We do not expect to implement support for raw access to the 1-bit framebuffer for the current generation of hardware in the OptiTrack SDK. To clarify, identification (provided in the SDK) means locating and reporting the position markers (objects) in the cameras field of view, when the FAQ refers to tracking it is talking about how the markers and their locations are utilized (particularly between consecutive frames).
The current SDK provides access to all objects identified within a video frame and makes the information about them available. The OptiTrack SDK provides basic built-in 2D object tracking and ranking capability, what it does not provide is multi-camera 3D tracking and correlation. Likewise, if you want a more advanced 2D tracking algorithm than the one included, you would need to implement it on your own.
The lack of access to the frame buffer should have a minimal impact on the ability to implement a multi-camera 3D tracking algorithm (which some OptiTrack users have implemented) since the object data is available. The FAQ entry on occlusion refers to the scenario where a marker (object) becomes occluded in the cameras view, this means that it is no longer visible to the camera and will not be present in the frame buffer. In multi-camera 3D tracking, a common technique is to utilize multiple cameras in different locations tracking the same markers (objects) in order to better handle occlusion.
It would be helpful for us if you could you explain more specifically how the current implementation is preventing you from accomplishing the tasks in your project.
[ March 23, 2006, 03:01 PM: Message edited by: NaturalPoint - Birch Zimmer ]
Re: Image buffer access
We intend to use a camera to do 3D head tracking from a set of markers on the user's glasses as well as a form of touch-screen-like interaction on a horizontal display.
EDIT: Using one camera per user, but with multiple users.
At the moment I am using the video feed by having the API draw the frame to an offscreen window and reading it back form there. Raw video access would make things much simpler.
We intend to do this for two users though, and the CPU load from obtaining the video is already very high. If we cannot get raw access then I will have to see what we can do using the bounding boxes, though this will be a compromise as not everything is going to be aligned with the camera.
[ April 03, 2006, 03:32 AM: Message edited by: wesslen ]
EDIT: Using one camera per user, but with multiple users.
At the moment I am using the video feed by having the API draw the frame to an offscreen window and reading it back form there. Raw video access would make things much simpler.
We intend to do this for two users though, and the CPU load from obtaining the video is already very high. If we cannot get raw access then I will have to see what we can do using the bounding boxes, though this will be a compromise as not everything is going to be aligned with the camera.
[ April 03, 2006, 03:32 AM: Message edited by: wesslen ]
Re: Image buffer access
OT: Well... that didn't work. Apparently the reported object position, width, and height can't be used to construct a proper bounding box (and for some reason the dimensions are badly skewed for objects near the right edge of the image, making small square objects appear to have aspect ratios in excess of 20:1 in some cases.)
Re: Image buffer access
What if I want to identify different targets with different shapes? Something similar to ARToolkit
Can I do that with optitrax?
Can I do that with optitrax?
Re: Image buffer access
quote:Originally posted by Euclides:
What if I want to identify different targets with different shapes? Something similar to ARToolkit
Can I do that with optitrax?Currently it is not possible to identify targets with specific shapes using OptiTrack, aside from the information provided about height, width and aspect ration.
We will be taking these feature requests into consideration during our ongoing development efforts.
What if I want to identify different targets with different shapes? Something similar to ARToolkit
Can I do that with optitrax?Currently it is not possible to identify targets with specific shapes using OptiTrack, aside from the information provided about height, width and aspect ration.
We will be taking these feature requests into consideration during our ongoing development efforts.
Re: Image buffer access
quote:Originally posted by wesslen:
OT: Well... that didn't work. Apparently the reported object position, width, and height can't be used to construct a proper bounding box (and for some reason the dimensions are badly skewed for objects near the right edge of the image, making small square objects appear to have aspect ratios in excess of 20:1 in some cases.)We have reproduced the issue and identified the cause, it will be corrected in future releases of the OptiTrack SDK.
If it is important for you to have the fix in the near term, please contact support@naturalpoint.com with a request for a pre-release build of the OptiTrack SDK and include a link to this forum thread.
[ May 16, 2006, 07:16 AM: Message edited by: NaturalPoint - Birch Zimmer ]
OT: Well... that didn't work. Apparently the reported object position, width, and height can't be used to construct a proper bounding box (and for some reason the dimensions are badly skewed for objects near the right edge of the image, making small square objects appear to have aspect ratios in excess of 20:1 in some cases.)We have reproduced the issue and identified the cause, it will be corrected in future releases of the OptiTrack SDK.
If it is important for you to have the fix in the near term, please contact support@naturalpoint.com with a request for a pre-release build of the OptiTrack SDK and include a link to this forum thread.
[ May 16, 2006, 07:16 AM: Message edited by: NaturalPoint - Birch Zimmer ]