Possible position + 1 bug in Object Mode?

[LinusA]

Hi, I'm using an OptiTrack V100R2:FS cam with the Camera SDK 1.0.1 beta1.

I've got the exact same mainloop (displaying frame data and object information with OpenCV) running while changing the video mode. While the object's position (float .X() and .Y()) always remains correct, the .Left() and .Top() boundary box seems to move off 1 pixel. This also seems true for the detected object pixel. I attached 4 pictures with Segment, Object, Precision and MJPEG mode.

Legend: Red circle and red cross is the object's position X(), Y(), and it's Radius(). Green box is the rect (Left(), Top(), Width() + 1, Height() + 1). Green cross is my own center of mass detection inside the green box...

You probably have to save the pictures and switch through them quickly to understand what I mean.

Best regards, Linus









(follow the links to get full size raw pics)

[LinusA]

Oh and please note: When I said: "green box is left, top, width+1, height+1", I just meant that for nicer display, I painted the thin green line OUTSIDE the enclosed pixels at the bottom right.

Anyway, this is the same setting in all pictures, so it's not the problem.

You can also note how in object mode, the red circle and cross don't match the rasterized pictured anymore...

[beckdo]

As you've noticed from the SDK, regardless of what tracking mode you are running the camera in you are always presented with the same object information...position, size, area, width & height, etc.

Under the hood, the actual information coming from the cameras ranges from most to least in this order: Precision Mode, Segment Mode, then Object Mode. In the case of Object Mode, the left, top, width, and height are approximated and because they are integers the results of the approximation are less than stellar. If you are specifically using left/right/width/height in your tracking application I would recommend Segment or Precision Mode.

I will take a look at this.

[LinusA]

[quote=NaturalPoint - Doug]In the case of Object Mode, the left, top, width, and height are approximated and because they are integers the results of the approximation are less than stellar.
[/quote]
Yes, it's ok that they are integers, and for that precision, their values seem ok. What I meant: If you compare Precision / Segment Mode with Object Mode, you'll notice that the actual pixels inside the bitmap (after the call to Rasterize()) are shifted 1 pix to the left and 1 pix to the top. This is reproducable. It looks like inside the rasterization or object detection process, this error (roundoff, -1, or "wrong" integer casting) is introduced. The according bounding boxes (left, top, etc.) are correct for their images, respectively. It's the actual image that seems odd. That's what I just wanted to let you know...

[quote=NaturalPoint - Doug]
If you are specifically using left/right/width/height in your tracking application I would recommend Segment or Precision Mode.
[/quote]
Yes, thanks. That's what I do at the moment.

If you need a sample app or more pictures, let me know...