I was Googling around and found a blob detection library that we can potentially use. The only thing is that it's written in Java; we'll need to port it to C first before we can try it with the video footage we've captured so far. The nice thing about Java is its similarity to C--there should be no problems porting it to the C language.
I'd also like to figure out what algorithm it's using, and compare it with the currently available algorithms out there. This will require reading the library code, though.
Wednesday, January 24, 2007
Friday, January 19, 2007
Video differences
We now have a video diff application. Here is a processed version of the clip posted previously. It looks pretty promising, and better than I expected. Right now, it compares all subsequent frames with the first frame captured from the camera, but we eventually want to diff from the previous frame instead (to account for changes in scenery/time of day).
The current code for the video diff program is on Subversion, at svn://svn.lifeafterking.org/cse190/videodiff/. To compile:
The current code for the video diff program is on Subversion, at svn://svn.lifeafterking.org/cse190/videodiff/. To compile:
gcc -O2 -march=pentium4 -mtune=pentium4 -mmmx -g -o videodiff videodiff.cTo run:
ffmpeg -vcodec ppm -f image2pipe | ./videodiff | ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg4 [output file]And there you have it. :)
Wednesday, January 17, 2007
Initial video capture
This was taken earlier this morning from the sixth floor of EBU1. Near the end of the video, it shows a van leaving a parking space and stopping in the middle of the parking lot. After, the driver gets out, puts something in the trunk, and gets back in. I preferred footage of someone walking to his/her car, but this works for the time being.
Anyways, off to class.
Anyways, off to class.
Tuesday, January 16, 2007
Initial footage from camera
So, it looks like the command for ffmpeg is actually incorrect with the version that I'm using. It should be:
ffmpeg -an -s 960x720 -vcodec ppm -f image2pipe test.ppm
or this for B&W:
ffmpeg -an -s 960x720 -vcodec pbm -f image2pipe test.pbm
(of course, replacing test.pbm/ppm with "-" to output to standard output)
Result (clicking on image goes to the full sized version):
ffmpeg -an -s 960x720 -vcodec ppm -f image2pipe test.ppm
or this for B&W:
ffmpeg -an -s 960x720 -vcodec pbm -f image2pipe test.pbm
(of course, replacing test.pbm/ppm with "-" to output to standard output)
Result (clicking on image goes to the full sized version):
Friday, January 12, 2007
schmoozing
i talked with professor Guest today at work. he is excited about the idea of finding out which parking spots were open using a webcam. he said he's been meaning to do a similar project on his own. work was rather slow and the bosses were away at lunch, so we didn't have much to do related to our jobs.
i also saw doctor Movellan last night at robotics. when Movellan heard that we only had 9 weeks, he said he didn't think that was enough time. He suggests that we use frame-by-frame difference to track moving objects.
ekiga will display video just fine, but i can't get ffmpeg, luvcvideo, and mplayer to do any video capture. i might just have to go straight debian. mooneer was able to get both my camera and his working. none of this ubuntu stuff.
i'm off to class, k c u later bye.
i also saw doctor Movellan last night at robotics. when Movellan heard that we only had 9 weeks, he said he didn't think that was enough time. He suggests that we use frame-by-frame difference to track moving objects.
ekiga will display video just fine, but i can't get ffmpeg, luvcvideo, and mplayer to do any video capture. i might just have to go straight debian. mooneer was able to get both my camera and his working. none of this ubuntu stuff.
i'm off to class, k c u later bye.
Forget DirectShow, we're using Linux
So, it turns out that there's actually a lot of stuff out there for Linux video/webcam capture. This stuff is also much easier than trying to deal with DirectShow. For instance, this shows a ffmpeg command that will convert the webcam input to a series of grayscale PGM images, one per frame. I can even use prerecorded video instead of the camera by using the filename of the video instead of /dev/video0. With some well-written scripts and the actual detection application, a GUI for the entire system isn't even needed.
Oh yeah, and Linux supports the Logitech camera using the uvcvideo driver. Excellent. :)
Anyways, we'll record some video for testing this weekend.
Oh yeah, and Linux supports the Logitech camera using the uvcvideo driver. Excellent. :)
Anyways, we'll record some video for testing this weekend.
Monday, December 4, 2006
DirectShow fun
Yesterday, I bought a webcam from Fry's. Originally, the proposal said that an iSight would be used, but I realized a few things:
I installed the software that came with the camera and played around with it. The included software seems to come with a built-in face tracker. My informal tests showed that it wouldn't really track all that well; the camera wouldn't pan sometimes when my face disappeared from the picture. But no matter--I don't believe we're going to use this functionality in the software we'll be writing.
I also discovered something else--it turns out that video support doesn't cap out at 640x480. There's an additional "HD" mode--960x720--that seems to provide more information. There are two disadvantages to this mode, however. One is that pan/tilt doesn't work; the built-in software simply ignores any requests to move the camera. The other is that there is obvious lag; it doesn't operate at 30 frames per second like the 640x480 mode. Perhaps we can test the operation of our software in both modes.
Anyhow, I should study for finals and such. Good luck with yours also!
BTW: I also played around with DirectShow a bit and put everything I have so far up on Subversion. Using TortoiseSVN, access svn://svn.lifeafterking.org/cse190/. You'll need DirectShow .NET and Visual Studio 2005 to compile. Now I'm gone for real...
- Fry's doesn't seem to carry them in the store.
- Newer Apple computers come with an iSight built-in, so finding a new iSight may be difficult. (Actually, it seems like you can still buy them from the Apple Store...)
- The iSight requires Firewire. As the primary development machine will be an IBM Thinkpad--which doesn't have any Firewire ports--the camera will be unusable without additional equipment.
I installed the software that came with the camera and played around with it. The included software seems to come with a built-in face tracker. My informal tests showed that it wouldn't really track all that well; the camera wouldn't pan sometimes when my face disappeared from the picture. But no matter--I don't believe we're going to use this functionality in the software we'll be writing.
I also discovered something else--it turns out that video support doesn't cap out at 640x480. There's an additional "HD" mode--960x720--that seems to provide more information. There are two disadvantages to this mode, however. One is that pan/tilt doesn't work; the built-in software simply ignores any requests to move the camera. The other is that there is obvious lag; it doesn't operate at 30 frames per second like the 640x480 mode. Perhaps we can test the operation of our software in both modes.
Anyhow, I should study for finals and such. Good luck with yours also!
BTW: I also played around with DirectShow a bit and put everything I have so far up on Subversion. Using TortoiseSVN, access svn://svn.lifeafterking.org/cse190/. You'll need DirectShow .NET and Visual Studio 2005 to compile. Now I'm gone for real...
Subscribe to:
Posts (Atom)