Image acquisition code

Hi there,

I am just starting a university project which involves building a wirelessley controlled robot, using a wireless camera to navigate. The camera will connect to the USB port in my PC, running in Windows, and I need to write some software to read in a frame from the camera, and analyse the pixels.

Does anybody know what I should include in my code to perform this function? I guess I want the software to tell the PC read in a frame of pixel data from the USB port, and store it in an array. The rest of the program would then process this array to determine the robot's location, and hence send the necessary control signals back to the robot.

Any thoughts?

Thank you!

ouch! now that's a hard one.. i too will wait for what the masters will hafta say about this...

> Any thoughts?
Find out what API's the camera comes with (if any), though a lot of cameras use a standard API.
I'm sure there's something on msdn.microsoft.com

Quote:

---

Does anybody know what I should include in my code to perform this function? I guess I want the software to tell the PC read in a frame of pixel data from the USB port, and store it in an array. The rest of the program would then process this array to determine the robot's location, and hence send the necessary control signals back to the robot.

---

This is not a good idea. You will not be able to get the robot to figure out where it is from images unless the robot has a detailed blueprint and/or 3D model of the area in it's memory to refer to.

The image you are going to receive is only 2D. You can use filters on the image, but this still will not provide depth information. What you really need is a z buffer image of the area and not a simple 2D x,y pixel image of the area.
To prove my theory fire up your fav image processing program and do some filtering on them. No matter what you do, you still won't be able to determine the depth of the pixels - essentially you won't be able to unproject the pixels.

Without using a Z buffer image, determining which objects are close and far is not going to be simple. And although it may work as a hack in a controlled area and climate, it won't work outside when light scattering effects and other atmospheric issues come into play.

AFAIK distance measurements would be the only way to 'real-time' compute a depth image or Z buffer image of the environment and then begin to process the data to determine where the robot is.

But again w/o the robot knowing firsthand something about the location, such as a 3D map, I don't think anything like this would help either.

Hell yeah, the scene analysis makes the frame grabbing a walk in the park.
Especially with today's plug and play camera's making it easy.

To even start scene extraction, you need two images of the same scene taken from two different viewpoints. This is normally done with stereoscopic cameras. I suppose you can get a similar effect from taking one image and then moving the robot forward a bit, and taking another image.

The robot will already have a map of the room stored in memory, containing at least 3 lights. The idea is to locate the centre of each light and hence determine the robot's position in the room.

However, it is the method of taking a frame from a video camera, for use in a C program that I am writing, that I could do with some help on. If I were to buy a standard USB webcam, and hook it up to my PC, then provided with the webcam would probably be a program for viewing the images. But I need to be able to convert the image into a mathematical representation of the RGB values of each pixel in the frame. This will then enable me to analyse the program in my C code.

Do all USB webcams send data to a PC in the same manner? In this case there must be some universal code out there, but I havn't been able to find any.

Thank you!

Yes. All USB webcams send data to the PC the same way. Through USB. :D


Quzah.

Yes, all computers are the same. They all use electricity. (Unless they're broken.) :D

You should let the driver handle the reading the webcam. You can make your program manipulate the file that it reads in. It would be much simpler.

OK so after each frame, the PC will store the image in a file - would this be .bmp? Where would I find it? And how could I load it into my program so that I can access each pixel? I am fairly new to programming and I don't have much experience with accessing other files from within a program I am writing. Thanks.

Damn man, don't you know how to read a manual? What format it stores in is going to be camera dependant. Seriously, if you can't figure out how to hook up a USB webcam and see where it puts its files, and what their extension is, then stop trying to play programmer, because you're just too stupid.


Quzah.

. . . check \windows\temp. (That's where my camera puts its files.) Sort by date modified just after you upload some files. If the latest folders don't have your pictures then search the hard drive for files modified within the last, say, five minutes.

Or maybe see if the documentation has anything (doubtful).

Ok, so say I have found the location of the images my webcam is updating, then how do I write the code to load this file, and then access pixel data in the form of an array?

Windows provides a couple of APIs for interacting with webcams, namely the old Video for Windows (VFW) and the newer DirectShow. Here are a few links thrown up by a web search:

http://www.codeproject.com/system/DigitalCameraConn.asp
http://www.codeproject.com/useritems...ageGrabber.asp
http://www.codeproject.com/directx/LiveVideo.asp
http://www.google.com/search?q=site%...com+vfw+webcam
http://www.google.com/search?q=site%...ect.com+webcam

For file formats, try wotsit.


Quzah.

Quote:

---

Windows provides a couple of APIs for interacting with webcams, namely the old Video for Windows (VFW) and the newer DirectShow.

---

Which has been declared deprecated by MS. It's a great API to use just beware that it may not work on future versions of the SDK. It is no longer part of the DirectX SDK but can still be obtained through the Platform SDK.

Don't ask me why b/c I don't make the decisions, MS does. I guess if they keep changing stuff they stay in business b/c they keep us in a constant state of learning and yearning.