Subject:
|
Re: Vision command + linux
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 12 Dec 2003 22:28:09 GMT
|
Original-From:
|
Steve Baker <sjbaker1@*stopspammers*airmail.net>
|
Viewed:
|
1040 times
|
| |
|
|
Chris Phillips wrote:
> > I've test a new filter for the camera .... In my first study I applied a
> > filter only in one image .... Now I take the "time" parameter ! I make a
> > difference between two image and here is the result
My son is into adding 3D graphics to video footage to create short movies
with stuff like flying saucers attacking our car.
http://www.sjbaker.org/telamom/movies/index.html
(Check out the "Making of" link up at the top somewhere).
To do that, we needed figure out where to draw the 3D graphics, so we need to
know how the camera was moving when we took the original footage.
It seems to me that some of the techniques might be applicable to this kind
of navigation problem.
What I did was to divide the image into small regions (4x4 pixels each)
and find the 16 highest contrast regions in the image. Then, I take
two consecutive frames and try to find a match for each of those regions
from the first image in the second image. Using the sum of the squares
of the differences in pixel colour, I measure the 'goodness of fit' of
4x4 pixel blocks that are offset by 1, 2, 3 or 4 pixels in each direction.
When I've done this for all 16 high contrast regions, I try to match the
motion of these blocks to a combination of pitch, roll, yaw and motion
in X, Y, and Z. This is a bit tricky because sometimes the system
makes mistakes - but with many more test regions than I need, I can
toss out the ones that fit the motion of the other regions least well.
That data for the supposed camera motion can then be filtered and smoothed.
The result is a fairly fast algorithm that can (in principle) track how
the camera moved from just looking at the video.
In practice, this works suprisingly well for scenes of things like buildings
and cars - but fails miserably when all that's in shot is a very low frequency
image (like clouds) - or a very 'noisy' image - like the leaves of a tree or
blades of grass. It also (currently) has a tendency to latch onto vertical
or horizontal edges and to slide along them randomly. I need to have the
program look for more corners in the initial 16 regions and to ignore very
high frequency parts of the image.
The resulting image 'track' tends to be a bit jittery when the images are
relatively low resolution. My digital camera takes movies at 320x200 - which
makes for quite shakey tracking. Increasing the screen resolution helps
quite a bit. I can filter out the jittering - but that causes some lag
when the camera suddenly starts or stops moving.
When the camera is stationary - just panning and tilting - the algorithm
works suprisingly well - but it has trouble telling the difference between
panning and moving the camera bodily sideways (for example).
When I'm done with it, I'll probably release it as OpenSource - but that
may be a way off yet.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
