Question

I am using XNA to build a project where I can draw “graffiti” on my wall using an LCD projector and a monochrome camera that is filtered to see only hand held laser dot pointers. I want to use any number of laser pointers — don’t really care about differentiating them at this point.

The wall is 10′ x 10′, and the camera is only 640×480 so I’m attempting to use sub-pixel measurement using a spline curve as outlined here: tpub.com

The camera runs at 120fps (8-bit), so my question to you all is the fastest way to to find that subpixel laser dot center. Currently I’m using a brute force 2D search to find the brightest pixel on the image (0 – 254) before doing the spline interpolation. That method is not very fast and each frame takes longer to computer than they are coming in.

Edit: To clarify, in the end my camera data is represented by a 2D array of bytes indicating pixel brightness.

What I’d like to do is use an XNA shader to crunch the image for me. Is that practical? From what I understand, there really isn’t a way to keep persistent variables in a Pixel Shader such as running totals, averages, etc.

But for arguments sake, let’s say I found the brightest pixels using brute force, then stored them and their neighboring pixels for the spline curve into X number of vertices using texcoords. Is is practical then to use HLSL to compute a spline curve using texcoords?

I am also open to suggestions outside of my XNA box, be it DX10/DX11, maybe some sort of FPGA, etc. I just don’t really have much experience with ways of crunching data in this way. I figure if they can do something like this on a Wii-Mote using 2 AA batteries than I’m probably going about this the wrong way.

Any ideas?

Answer 1

You’re dealing with some pretty complex maths if you want sub-pixel accuracy. I think this paper is something to consider. Unfortunately, you’ll have to pay to see it using that site. If you’ve got access to a suitable library, they may be able to get hold of it for you.

The link in the original post suggested doing 1000 spline calculations for each axis – it treated x and y independantly, which is OK for circular images but is a bit off if the image is a skewed ellipse. You could use the following to get a reasonable estimate:

x_c = sum (x_n.f(x_n)) / sum (f(x_n))

where x_c is the mean, x_n is the a point along the x-axis and f(x_n) is the value at the point x_n. So for this:

          *
       *  *
       *  *
       *  *
       *  *
       *  *
       *  *  *
    *  *  *  *
    *  *  *  *
 *  *  *  *  *  *
------------------
 2  3  4  5  6  7 

gives:

sum (x_n.f(x_n)) = 1 * 2 + 3 * 3 + 4 * 9 + 5 * 10 + 6 * 4 + 7 * 1

sum (f(x_n)) = 1 + 3 + 9 + 10 + 4 + 1

x_c = 128 / 28 = 4.57

and repeat for the y-axis.