Hi

It seems I have some tracking problems and I dug deeply into the
tracking code. Now I am puzzled by the following code in ARToolkit

In libAR32, in lib/src/ar/arGetTransMat.c (version ARToolkit
DirectShow2.52.vrml.zip) I read the following code


static double arGetTransMatSub( ...)
{
 ....
    if( arFittingMode == AR_FITTING_TO_INPUT ) {
        for( i = 0; i < num; i++ ) {
   arParamIdeal2Observ(dist_factor, ppos2d[i][0], ppos2d[i][1],
                                             &pos2d[i][0],
&pos2d[i][1]);
        }
    }
else ....
...
}


I think that this is the place where camera distortions are corrected
for tracking. So I really would expect here a function call to
arParamObserv2Ideal (and NOT Ideal2Observ) here. I noticed this same
thing in arsGetTransMat2.
In the drawing routines, also Ideal2Observ is used (eg, GL/gsub.c in the
function argLineSeg). That's indeed where I would expect it. So it seems
the naming is as I expect it.



 

Hi,

In the function 'arDetectMarker()', positions of square vertices
are detected. In this function, camera distortions are corrected.
This does not depend on 
  arFittingMode == AR_FITTING_TO_INPUT or AR_FITTING_TO_IDEAL.

However in the case of arFittingMode == AR_FITTING_TO_INPUT,
ARToolKit fits the marker coordinates to the distorted image.
Then in the function 'arGetTransMat', positions of square vertices
have to be converted into distorted screen coordinates again.

Therefore,
>static double arGetTransMatSub( ...)
>{
> ....
>    if( arFittingMode == AR_FITTING_TO_INPUT ) {
>        for( i = 0; i < num; i++ ) {
>   arParamIdeal2Observ(dist_factor, ppos2d[i][0], ppos2d[i][1],
>                                             &pos2d[i][0], &pos2d[i][1]);
>        }
this is OK. the positions are transformed from 'Ideal' to 'Observed'.

Anyway, usually 'arFittingMode = AR_FITTING_TO_IDEAL' is better.

 
>It seems I have some tracking problems and I dug deeply into the
>tracking code. Now I am puzzled by the following code in ARToolkit
>
>In libAR32, in lib/src/ar/arGetTransMat.c (version ARToolkit
>DirectShow2.52.vrml.zip) I read the following code
>
>
>static double arGetTransMatSub( ...)
>{
> ....
>    if( arFittingMode == AR_FITTING_TO_INPUT ) {
>        for( i = 0; i < num; i++ ) {
>   arParamIdeal2Observ(dist_factor, ppos2d[i][0], ppos2d[i][1],
>                                             &pos2d[i][0],
>&pos2d[i][1]);
>        }
>    }
>else ....
>...
>}
>
>
>I think that this is the place where camera distortions are corrected
>for tracking. So I really would expect here a function call to
>arParamObserv2Ideal (and NOT Ideal2Observ) here. I noticed this same
>thing in arsGetTransMat2.
>In the drawing routines, also Ideal2Observ is used (eg, GL/gsub.c in the
>function argLineSeg). That's indeed where I would expect it. So it seems
>the naming is as I expect it.

-- 
------------------------------------------------------------------
  Hirokazu Kato
  Faculty of Information Sciences
  Hiroshima City University               Phone: +81-82-830-1705
  Email: kato@s ........................     Fax: +81-82-830-1435
  URL: http://www.sys.im.hiroshima-cu.ac.jp/people/kato/

Hi Wouter,

>Thanks for the explanation, this made things clear.So you are going to fit the
>matrix as good as possible on >>distorted<< camera image locations if
>FIT_TO_INPUT is set!? Isn't this going to give weird results?  I would think
>you should fit always to an undistorted camera image. Furthermore I would
>expect - and I thought that - texture mapping was used to distort the rendered
>image to match the camera distortions.

There are two combinations between 'drawing mode' and 'fitting mode'.

argDrawMode   = AR_DRAW_BY_GL_DRAW_PIXELS or AR_DRAW_BY_TEXTURE_MAPPING
arFittingMode = AR_FITTING_TO_INPUT or AR_FITTING_TO_IDEAL

First of all, ARToolKit was developed in 1998. In those days, graphics
hardware is not so great that texture mapping was not fast on standard 
computers.
In order to draw captured images from the camera, there are two ways:
1) using glDrawPixels
2) using texture mapping
When using glDrawPixels, it was very faster than the way using 
texture mapping a few years ago. But it cannot compensate image distortion.
However, recently fast texture mapping is available on standard PCs.
It is often faster than glDrawPixels and also it can compensate image
distortion. So ideally using texture mapping is much better than using 
glDrawPixels.

Anyway current ARToolKit support 2 ways to draw captured images:
a. using glDrawPixels
b. using texture mapping
The big difference is that glDrawPixels cannot compensate image distortion 
but texture mapping can do that.

So according to the drawing mode, ARToolKit have to change the fitting mode.
glDrawPixels    --> virtual objects have to fit to the distorted input image.
texture mapping --> virtual objects have to fit to compensated ideal perspective
                    projection image.
Then ARToolKit has two fitting mode: AR_FITTING_TO_INPUT or AR_FITTING_TO_IDEAL


You can see differences between these modes by trying sample program 'modeTest'. 


-- 
------------------------------------------------------------------
  Hirokazu Kato
  Faculty of Information Sciences
  Hiroshima City University               Phone: +81-82-830-1705
  Email: kato@s ........................     Fax: +81-82-830-1435
  URL: http://www.sys.im.hiroshima-cu.ac.jp/people/kato/
 

Hi,

>I still expect weird behaviour of that, for instance if the
>distorted camera image has non-square pixels I think would that result in 
>*rotation* of the virtual objects?

Captured image is already distorted.
After compensation, it becomes an image that can be represented by
the perspective projection from 3D camera coordinates.
So I call a captured image a distorted image or an observed image.
And also I call a compensated image an ideal image.

Your 'distorted camera image' means 'compensated image', right?
Anyway, both translation and rotation change as corresponding to
fitting mode.

-- 
------------------------------------------------------------------
  Hirokazu Kato
  Faculty of Information Sciences
  Hiroshima City University               Phone: +81-82-830-1705
  Email: kato@s ........................     Fax: +81-82-830-1435
  URL: http://www.sys.im.hiroshima-cu.ac.jp/people/kato/
 

Hi,

>I still expect weird behaviour of that, for instance if the
>distorted camera image has non-square pixels I think would that result in 
>*rotation* of the virtual objects?

Captured image is already distorted.
After compensation, it becomes an image that can be represented by
the perspective projection from 3D camera coordinates.
So I call a captured image a distorted image or an observed image.
And also I call a compensated image an ideal image.

Your 'distorted camera image' means 'compensated image', right?
Anyway, both translation and rotation change as corresponding to
fitting mode.

-- 
------------------------------------------------------------------
  Hirokazu Kato
  Faculty of Information Sciences
  Hiroshima City University               Phone: +81-82-830-1705
  Email: kato@s ........................     Fax: +81-82-830-1435
  URL: http://www.sys.im.hiroshima-cu.ac.jp/people/kato/