Chris McCormick wrote:
> My issue is that I am getting pretty flaky recognition of markers, and
> it's very dependent on the light conditions in the room in which my grid
> is housed. A marker will be detected only every ten or twenty frames. Can
> anyone give me tips for increasing the robustness of the recognition in
> this situation? The .dat file I am using is the camera_para.dat file that
> comes with the original ARToolKit - is this the most appropriate one to
> use for the EyeToy? Can I create my own .dat file, or does anyone have
> one for the EyeToy? Here are the settings for my tracker multi marker:
>
> tracker->setPixelFormat(ARToolKitPlus::PIXEL_FORMAT_RGB);
> tracker->setBorderWidth(0.25f);
> tracker->activateAutoThreshold(true); 
> (I tried setThreshold(150) as well but no dice)
> tracker->setUndistortionMode(ARToolKitPlus::UNDIST_LUT);
> tracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
> tracker->setMarkerMode(ARToolKitPlus::MARKER_ID_SIMPLE);
>
> Please note that speed is not an issue since I'm only trying to get
> about one recognition per second. I just want it to recognise as
> accurately as possible. I would rather it err on the side of seeing
> blocks than not seeing blocks.
>
> Would increasing the contrast of my images help? I could do this when
> converting from .jpg to raw. Maybe I should turn them into grey scale
> rather than using RGB? Or just two colour?
>   
hi Chris,

the autothresholding algorithm currently does only one threshold value
for the whole image. so it averages the threshold value of all found
markers. depending on the lighting condition this might not be better
than using manual thresholding.

i suggest trying the following:
- make sure you defined a large enough value for max. number of
detectable markers per image
  (last template parameter value)
- in case you use arDetectMarkerLite() - switch to arDetectMarker()
- play around with the manual threshold value (100, 125, 150, 175)
- activate full scan mode: setImageProcessingMode(AR_IMAGE_PROC_IN_FULL);
- improve your markers: instead of simple printing, use some foil that
does not reflect
   e.g. velcro - we have good success with that!
- if the markers in the image are very small, switch to thin border markers.
- using jepg is not ideal since jpeg introduces artifacts. try doing
pure uncompressed.

i also suggest creating a correct camera calibration file. you can
either use the std. tool that comes with ARToolKit, or - faster to
create and more accurate - the MATLab camera calibration toolbox (in
case you have MATLab). i don't think that the detection rate of markers
would be increased though...

if you want, send me a typical camera image and i'll check, why those
markers are not detected...

bye,
Daniel

CLG wrote:
> You should use adaptive threshold for image binarization. Calculate
> local histogramm for each point or region and use equalized value for
> threshold. Not sure if artoolkitplus support it, but it's fairly easy
> to implement yourself.
That is actually a good idea.
Since Chris stated that performance is not an issue in his case, it
would make sense to use an advanced global adaptive threshold algorithm.
But since ARToolKitPlus is oriented for real-time usage, it does not
come with such an algorithm...

Daniel

Hi All,

I'm using ARToolKitPlus in an art project. I have a wooden grid into
which vinyl cubes are inserted, each of which has an ARToolKitPlus
tag printed on one side. I'm using the SimpleStd ID tags. I'm using
an EyeToy webcam to capture a jpg image every second. The captured
images are then converted into .raw RGB 8 bits per color format using
imagemagick's conver tool. I then have a small program called detect.cpp
which reads in the .raw file and processes it with an TrackerMultiMarker
instance. It examines every detected marker, and takes an average of the
marker.vertex[][] values of each detected marker to determine in which
grid slot (2d) the marker's center is. The grid holds 6x4 different marker
cubes, and the resolution of the EyeToy is 640x480 so that's around 100
pixels per tagged cube face for recognition. The EyeToy camera image is
aligned so that one box fits into each of the 6x4 grid spaces.

My issue is that I am getting pretty flaky recognition of markers, and
it's very dependent on the light conditions in the room in which my grid
is housed. A marker will be detected only every ten or twenty frames. Can
anyone give me tips for increasing the robustness of the recognition in
this situation? The .dat file I am using is the camera_para.dat file that
comes with the original ARToolKit - is this the most appropriate one to
use for the EyeToy? Can I create my own .dat file, or does anyone have
one for the EyeToy? Here are the settings for my tracker multi marker:

tracker->setPixelFormat(ARToolKitPlus::PIXEL_FORMAT_RGB);
tracker->setBorderWidth(0.25f);
tracker->activateAutoThreshold(true); 
(I tried setThreshold(150) as well but no dice)
tracker->setUndistortionMode(ARToolKitPlus::UNDIST_LUT);
tracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
tracker->setMarkerMode(ARToolKitPlus::MARKER_ID_SIMPLE);

Please note that speed is not an issue since I'm only trying to get
about one recognition per second. I just want it to recognise as
accurately as possible. I would rather it err on the side of seeing
blocks than not seeing blocks.

Would increasing the contrast of my images help? I could do this when
converting from .jpg to raw. Maybe I should turn them into grey scale
rather than using RGB? Or just two colour?

Thanks for your help.

Best regards,

Chris.

-------------------
chris@m ...........
http://mccormick.cx

Chris McCormick wrote:


> 
> My issue is that I am getting pretty flaky recognition of markers, and
> it's very dependent on the light conditions in the room in which my grid
> is housed. A marker will be detected only every ten or twenty frames. Can
> anyone give me tips for increasing the robustness of the recognition in
> this situation? T

You should use adaptive threshold for image binarization. Calculate 
local histogramm for each point or region and use equalized value for 
threshold. Not sure if artoolkitplus support it, but it's fairly easy to 
implement yourself.

Hi Daniel,

On Fri, May 26, 2006 at 09:04:08AM +0200, Daniel Wagner wrote:
> Chris McCormick wrote:
> > My issue is that I am getting pretty flaky recognition of markers, and
> 
> - in case you use arDetectMarkerLite() - switch to arDetectMarker()
> - play around with the manual threshold value (100, 125, 150, 175)

These two seemed to help, but most of all getting the lighting right
in the room gave me much better recognition of the markers. Getting the
light as ambient and non-directional as possible seems to be the key.

I am using the 'Multi' class and running the routine calc(nImageData) on
the images from the camera and then looping through all of the detected
markers - is this the most appropriate thing to do?

Unfortunately I have no opportunity to change the printed markers
as they are already printed onto expensive vinyl cubes and can't be
changed. Another minus is that the JPEG format images come directly off
the EyeToy (it encodes them internally) so I have no option but to use
that format.

Thanks for your help, I think I've got it going well enough for the
installation now.

Best,

Chris.

-------------------
chris@m ...........
http://mccormick.cx