Hi,
I posted a message to ARforum and ARtoolkit a few days ago about exactly the
same problem I was having and I just got it sorted out, so I'll post my
findings here for everyone else to read about. I'm using ARtoolkit as a
tracker and I recalibrated my camera (instead of the default model) and the
registration got really bad after that. I had numerous emails with Hirokazu
Kato about this and the solution is as follows:
The arGetTransMat returns you back a matrix in the camera's coordinate
system. However, the camera is probably not straight and the Z axis does not
come out directly from the lens. Due to camera distortion and so forth, the
Z axis diverges and goes off in some kind of other direction. The docs
suggest you can use this matrix to find out where the object is, but not in
true 3D world coordinates so to speak - it is in special camera coordinates
which don't really mean much to the casual observer. So you can't just draw
a XYZ set of axes around the camera, because of the lens distortion. This is
where I got stuck initially.
I was trying to put this arGetTransMat matrix straight into my Tinmith scene
graph but this does not work because of the camera distortion correction. I
sorta got lucky before when it worked when I used the default model. If you
look at the example programs in ARtoolkit, they use the output of
arGetTransMat to set the GL_MODELVIEW matrix in OpenGL. If you look further
into the code, you'll see they also use a matrix called gl_cpara as the
GL_PROJECTION matrix. This matrix is taken from the camera model file which
you created when you calibrate the camera or use the default one provided.
So if you don't use the gl_cpara viewing frustum, you get poor registration.
In my case I have to use a different frustum, and we couldn't work out a way
of doing just the distortion correction without doing the frustum part as
well, Kato said that you sorta can't do that. The other thing I discovered
that is interesting is that the act of detecting the targets offsets them
according to the distortion model, and then the gl_cpara brings them back
into line later on. If you can get a nice straight camera model then this
would resolve most of the issues and get some decent output. If you forget
to use gl_cpara, the output is badly broken on my camera which was hard to
calibrate well.
Originally I was using the original default calibration file that came with
ARtoolkit, and the registration was good, although I had to apply various
scaling hacks to make the registration right. By recalibrating myself it got
really bad and so if I couldn't fix the problem I needed to use my hacks.
So I wanted to hack my camera calibration model so that it was "straight".
My original matrix looked like this:
res 352 x 288, centre=(199.5 130.5), focal=46, size=1.008024)
517.3 -1.487 209.0 0
0 559.7 94.8 0
0 0 1 0
Kato told me that the 209.9 and 94.8 values should be near 1/2 the
resolution for "undistorted" output. So I changed them to 176 and 144,
(based on my camera) and also adjusted the centre point values stored in the
camera file.
res 352 x 288, centre=(176.0 144.0), focal=46, size=1.008024)
517.3 -1.487 176.0 0
0 559.7 144.0 0
0 0 1 0
I wrote a small program to write out the new matrix and modified values to a
file which ARtoolkit can read. If you look at the struct definition for
ARparam you can just write a program which creates a struct, fill in the
values, do a byte switch on them for endianness, and then write it directly
out. When I use this new file I created I get great registration with no
other hacks required, and I do no use the gl_cpara matrix, just
arGetTransMat().
Using the example ARtoolkit programs, I found you could use any camera, no
matter how badly distorted it is, and it will work because the gl_cpara
compensates for other distortions introduced into the arGetTransMat matrix.
If you don't use gl_cpara then you need a very straight camera model to make
it work. Initially I could never work out how ARtoolkit got good
registration even when you changed the camera without recalibrating, but
this is it - the gl_cpara matrix forces it to work right all the time.
It works great for me now and I am very happy. I hope this is useful to
everyone who is trying to use ARtoolkit for something similar. Thanks to
Kato for replying to my emails to help me with my journey :) If anyone has
any questions I'd be happy to discuss this.
regards,
Wayne
----------------------------------------------------------------------------
---
Wayne Piekarski - PhD Student / Lecturer Phone:
+61-8-8302-3669
Advanced Computing Research Centre Fax:
+61-8-8302-3381
University of South Australia Mobile:
0407-395-889
Internet:
wayne@c ..............
Research & Development Manager
wayne@s ...........
SE Network Access Pty Ltd
http://www.cs.unisa.edu.au/~ciswp
----- Original Message -----
From: "Cheng LEI" <clei@e .............>
To: <artoolkit@h ..................>
Sent: Thursday, September 27, 2001 4:20 PM
Subject: A simple question
Dear Members,
I am using ARToolkit to develop a simple application based on MFC and
DirectShow.
There is maybe a too simple question. I sucessed in grab the video and
detect the
pattern. But using the result from the function of "argGetTransMat", the
overlapped
object is not at the intended place, that is, the center of the pattern, but
another fixed
place. ( I guess there maybe a transform missed for my specific program)
I don't know if the problem is caused by the default camera parameters or
other source
such as my Directshow based video grabbing and the specific of the
video-frame
raw-data. Have you ever encounted this problem? If so, would you like to
tell me the
solution or how to trace the source of this problem .
Thank you very much.
Best regards,
Cheng LEI
|