Hello Wayne,

first of all, thank you for your reply, really appreciated.

> Check out a paper I presented at the ART workshop a few years ago:
> 
> http://www.tinmith.net/papers/piekarski-art-2002.pdf

I found that on google too ;-)

> It talks about how we straightened out errors in the camera_para.dat
> file for use in a hand tracking application, these errors are
> accumulated during the camera calibration process. Normally ARToolkit
> doesn't have a problem with whatever the calibration is but if you
> are trying to use it as a tracking device then you need to make sure
> the camera axes are orthogonal.

Yes, I tried all that but the result is still inaccurate. I think
artoolik doesn't handle big apertures of the camera very well,
real cameras usually have very small fovs, so the error might not be
too visible (I'm not talking about radial distortion here...) in
most artoolkit applications. Just try to render a marker as a textured plane
in OpenGL with a perspective camera and try to track the output
with artoolkit.... 

Kind regards,

  Toni

Antonio Bleile wrote:

>Yes, I tried all that but the result is still inaccurate. I think
>artoolik doesn't handle big apertures of the camera very well,
>real cameras usually have very small fovs, so the error might not be
>too visible (I'm not talking about radial distortion here...) in
>most artoolkit applications. Just try to render a marker as a textured plane
>in OpenGL with a perspective camera and try to track the output
>with artoolkit.... 
>  
>
the problem is less about the FOV but rather about the radial distortion
that every camera has. usually the larger the FOV the more intense the
distortion becomes. since the OpenGL projection system is just uses a
matrix, it can not compensate for these effects (maybe using shaders...).

if you have really strong distortions and you need a accurate rendering
then you might want to undistort the camera image before tracking and
rendering. this is of course quite CPU intensive. if there was a GPU
version of ARToolKit then the image could easily be undistorted using
texture mapping and no read-back would slow down the overall process.
anybody already working on such a thing...?

Daniel

Daniel Wagner wrote:

> if you have really strong distortions and you need a accurate rendering
> then you might want to undistort the camera image before tracking and
> rendering. this is of course quite CPU intensive. if there was a GPU
> version of ARToolKit then the image could easily be undistorted using
> texture mapping and no read-back would slow down the overall process.
> anybody already working on such a thing...?

In the past, I've used Michael Herf's QuickWarp (GPLed).
It's a CPU implementation, not GPU, so it may not satisfy your
performance needs. Quality-wise, it was quite usable for me.
These are the results I got:
http://stolk.org/tmp/quickwarp/

   Bram