This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig000A383F2767EFF2C79866AD
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi all,
I wrote a little extension to ARToolKit (based on version 2.69) that
works quite similar to the ARTag library by Mark Fuala.
Instead of using templates it directly encodes an id (0-511) into the
marker images.
You can download this extension from
http://www.ims.tuwien.ac.at/~daniel/download/IdBasedMarkers.zip
We provide this code under the GPL and donate it to the ARToolKit project.
I hope that it will soon be part of the main ARToolKit source tree and
further improvements will be applied.
In util/IdPatGen there is a small command line tool (currently only for
windows) that creates markers.
I added all 512 markers (plus one image with all markers) and a
precompiled binary of this tool to the zip file. So there should be no
need to run this tool unless you change the marker encoding. (this tools
requires an additional library to build, please ask me if you have
problems with that)
I also included all files which i modified (only 3 in fact were
minimally changed) and two new files which have to be added to the make-
or project file.
One important note:
This add-on currently only works if the marker size is changed from
16x16 to 18x18 (and AR_PATT_SAMPLE_NUM from 64 to 72) in
include/AR/config.h.
Now some tech stuff:
How does it work?
The ID numbers are directly encoded into the marker images. Consequently
there is no template matching performed anymore which results in an
enormous speedup if many markers (>20) are used. This does not only mean
that we can use much more markers than with the standard ARToolKit, but
also that marker training is no longer required.
Currently 512 markers are supported. The 9-bit number is copied 4 times
into a 6x6 marker pattern (9x4 == 6x6). As can be seen in
http://www.ims.tuwien.ac.at/~daniel/images/id_marker.gif, the 9-bit
number is simply repeated 4 times to fill up all bits of the 6x6 checker
board. In order to prevent some numbers (such as 0 or 511) to produce
completely white or black markers, 4 different bit masks are applied via
an XOR operation - one mask to each color in the image. The XOR masks
where optimized via a brute-force search to minimize rotation ident and
intermarker similarity.
At runtime the new method bitfield_check() is called instead of
pattern_match(). bitfield_check() reduces the 18x18 marker to 6x6 and
converts it to a 36-bit number. Next it creates three copies of this
number which are rotated 90°, 180° and 270°. Finally all four rotations
are checked for validity and the one with the highest confidence (which
must be >0.90) is chosen to be the rotated marker id.
Checking a marker for validity works as following: For each of the 9
bits all four stored values (remember that we store the whole 9-bit
number four times in the pattern image) are read and compared. If all
four values are identical, the value is returned with 100% confidence.
If one value is different the correct value is returned with 50%
confidence. If two values are zero and two values are one, then zero
(which means black) is returned with 0% confidence. Black is chosen over
white since it is more likely to happen that a black area turns white
due to reflections as the other way around.
That's all for now.
If any questions come up, please reply to the mailing list.
bye,
Daniel
--------------enig000A383F2767EFF2C79866AD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFBj4/XQVW9sHd65aQRApsMAJ9aPPuugdgqeFAyMcZKh3GKL+LDzQCfUXoz
S/JgmTi/OCGeOE2FWhylpCk=
=qgj7
-----END PGP SIGNATURE-----
--------------enig000A383F2767EFF2C79866AD--
|