Is it unreasonable to try solving for the modelview transforms of 4 (of 
6 possible) marker tiles in a 640x480 mono frame and still maintain 30 
fps?  Is the toolkit multi-threaded and able to take advantage of the 
new multi-core chips?  Any thoughts on hardware to achieve the above? 
We'll definitely be using a dual-core (or dual processor) machine with 
the graphics running in a separate thread.

Cheers,
Darran.


-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com

As we showed in our recent ARToolKitPlus publication
(http://www.icg.tu-graz.ac.at/Members/daniel/Publications/ARToolKitPlus),
the tracking speed of ARToolKitPlus (and the same goes for ARToolKit on
the PC) is usually more than fast enough on modern PCs, even with many
markers visible.

E.g. on a 2 GHz Core Duo (only a single core was used) for a
multi-marker with 4 visible markers, a PC requires 2.7ms or 6.2ms
(depends on the compiler used). For a similar setup with 10 visible
markers it is still just 8.3ms or 17.5ms (again different compilers...).
More details can be found in that paper. So, if you target a framerate
of 30fps then even for the 10 marker case this is just about 25% of your
processing performance of a single core...

Phil is right that with many markers know and/or visible to the system
the performance will drop considerably when using template markers (with
N visible and M known markers, N*M*4 template matches have to be
performed). For such a case use Id-markers (which only require only N
tests, each faster than a template match) which are supported by
ARToolKitPlus and the commercial version of ARToolKit.

Both ARToolKit and ARToolKitPlus are currently single-threaded. While it
would be quite simple making parts of them multi-threaded (e.g. the
labeling or the pose estimation parts) there is currently no real reason
to do so: Tracking is only a small part of a practical AR application
(camera reading, rendering, networking, GUI, application overhead, etc.).

Daniel

Daniel Wagner wrote:
> As we showed in our recent ARToolKitPlus publication
> (http://www.icg.tu-graz.ac.at/Members/daniel/Publications/ARToolKitPlus),
> the tracking speed of ARToolKitPlus (and the same goes for ARToolKit on
> the PC) is usually more than fast enough on modern PCs, even with many
> markers visible.

I'm using 5-8 marker tracking on the Nokia 6600 cellular phone with 
109Mhz ARM CPU without floating point, with 8 frames per second. I'm not 
using ARToolkit though, but my own highly-optimized ARM-friendly fixed 
point tracker with barcode marker ID. Any semi-modern CPU 800+ Mhz more 
than enough for tracking dozens of markers.

Darran,

I've also replied to you off-list, but this is no problem for almost  
any machine. Over about 10 markers, using 2D barcode (ID-based  
markers) rather than the standard markers improves performance a lot.

ARToolKit v2.x is not multi-threaded, and will probably not be any  
time soon. The performance bottlenecks usually lie elsewhere in the  
system.

Cheers,
Phil.

On 20/02/2007, at 4:12 PM, Darran Edmundson wrote:

>
> Is it unreasonable to try solving for the modelview transforms of 4  
> (of 6 possible) marker tiles in a 640x480 mono frame and still  
> maintain 30 fps?  Is the toolkit multi-threaded and able to take  
> advantage of the new multi-core chips?  Any thoughts on hardware to  
> achieve the above? We'll definitely be using a dual-core (or dual  
> processor) machine with the graphics running in a separate thread.

Daniel Wagner wrote:
> E.g. on a 2 GHz Core Duo (only a single core was used) for a
> multi-marker with 4 visible markers, a PC requires 2.7ms or 6.2ms
> (depends on the compiler used). For a similar setup with 10 visible
> markers it is still just 8.3ms or 17.5ms (again different compilers...).
> More details can be found in that paper. So, if you target a framerate
> of 30fps then even for the 10 marker case this is just about 25% of your
> processing performance of a single core...

A follow-up to an old message ...  Just finished some benchmarking today 
of ARTk+ doing simultaneous tracking of 4 out of 5 BCH markers.  We are 
seeing ~30ms just for the detection phase, and around 15-20ms for each 
RPP solve.  That gives us a total time of ~100ms.  This is for a 640x480 
PGR Dragonfly2 mono image running on a 3Ghz Athlon64, Visual Studio .NET 
2003 SP1.  I'm seeing similar times on my 2GhZ Centrino Duo - slightly 
faster but nothing like the times above.

Our current camera calibration (done with the matlab toolbox) was only 
done with 9 images and probably isn't that good.   Question then, will a 
poor calibration affect the detection phase as well as the pose 
estimator?  If so, that's likely the source of the problem.  But if not, 
what would cause the very long 30ms marker detection?

As always, any advice is much appreciated.

Cheers,
Darran

-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com

Darran Edmundson wrote:
> A follow-up to an old message ...  Just finished some benchmarking
> today of ARTk+ doing simultaneous tracking of 4 out of 5 BCH markers. 
> We are seeing ~30ms just for the detection phase, and around 15-20ms
> for each RPP solve.  That gives us a total time of ~100ms.  This is
> for a 640x480 PGR Dragonfly2 mono image running on a 3Ghz Athlon64,
> Visual Studio .NET 2003 SP1.  I'm seeing similar times on my 2GhZ
> Centrino Duo - slightly faster but nothing like the times above.
My timings do not include reading the camera. They were (since the paper
is about AR on PDAs and Smartphones) using a 320x240 image using
simple-id markers and the standard pose estimator.
> Our current camera calibration (done with the matlab toolbox) was only
> done with 9 images and probably isn't that good.   Question then, will
> a poor calibration affect the detection phase as well as the pose
> estimator?  If so, that's likely the source of the problem.  But if
> not, what would cause the very long 30ms marker detection?
Yes, a good calibration definitely makes a noticeable difference. We
experienced applications running a lot faster when using a correct
calibration file. E.g.  25fps vs. 17 fps on a 400 MHz handheld (ARM
CPU). Since this was overall speed including rendering, animation, etc.
the pose estimation was probably more than twice as fast. I do not have
experiences with PCs though.

bye,
Daniel