If you know the CMOS sensor that is being used yeah. In theory you could work directly with the chip, but then you might as well just buy the chip and work wit it that way. You'd basically have to bypass all the circuitry except for the chip. Webcams tend to be far too fast and require far too much memory for a microcontroller to handle though. You would have better luck with a CMU Cam 1, 2, or 3, a POB Bot CAM, or hacking a Gameboy camera off ebay. These cameras are either much lower resolution, or have much more powerful processors integrated into them to offload the work from the microcontroller.
500x500 pixels x 8-bist/pixel x and 3 different colour layers = 732KBytes
x10 FPS = 7.15Mbytes per second
THat's a bit much for any MCU to handle, and 500x500 pixels very low resolution compared to most of the webcams available now. 1024x768 is more common, and the number of pixels increases squared with the dimension of the image. (I suggest you go monochrome anyways. 3 times less work and you don't have to correlate colours- just intensitites. It gets the job done for the most part anyways.)
You might as well just buy the evaluation kit from Omnivision or something so you don't have to bypass the webcam. I keep hearing people saying they want to use a webcam because it's low cost. How low cost is low cost? Because for me, a $150 CMU Cam or evaluation kit to save you the grief and effort of having to deal with or bypass the USB is very worth it. HOw much are webcams? I doubt they cost that much less than one of the mentioned alternatives, certainly when you account for effort and probability of failure involved. It sucks but there ARE projects that exist that cannot be pursued under certain budget limitations.
I've been looking at this for a long time, and I've come to the conclusion that you can just *barely* pull off something like this with a microcontroller only if it has 32K of RAM and the camera is a single layer (ie. one colour, or monochrome) 128x128 image. Anything else and the microcontroller doesn't have enough RAM anymore, let alone the speed to process the frames. A single image would take up half the RAM on the MCU so you can't do any operations that require you more frames or different versions of the frames. This means you can't do frame-frame comparisons unless you down sample the image greatly inside the MCU which takes a lot of time. For me, I decided it was not worth my time for what I would get out of it (my limitation is the cost of development tools for a processor capable of deal with such images), at least for the "from scratch" method where I use my own MCU.
CMU Cam and POB Cam can do a lot more due to their integrated processors, and you can actually write your own firmware for the latest generation of CMU 3 (and you always could for the POB cam) so the PIC doesn't have to (and in most cases the PIC can't). If you look at the precoded algorithms for these two cameras, they are very simple and linear. It suggests that if you want to do anything remotely "substantial" then you must go with a (very expensive) processor- this puts it out of reach of most hobbyists.
https://www-2.cs.cmu.edu/~cmucam/index.html
https://www.pob-technology.com/web/index.php
THen there is this one. They work over a UART itnerface (very slow for images, but at least you can work with it and output in JPEG format. They might output other formats too, I haven't checked. If they don't you're going to have to learn how JPEG works.) They also have no integrated processor you can code for so you have to use your own MCU. But they are very cheap.
**broken link removed**