Hi! > I've been examining some more snoops and have come the conclusion that > the driver is doing everything in software once it captures the bayer > image, so we're stuck with a software solution until some datasheets > magically appear or someone shows me an .csr file that makes sense.
I think that we still have a chance with the ov9650 since we know from its datasheet that it's able to hand over native RGB data. We have to toggle on the right bits in the format registers *and* potentially rewrite the urb completion handler since the data may come formatted in some other way, not compatible with the current handler code. So as a first step, we have to see first what happens once we toggle those lovely bits, i.e are we still going to receive some data from the cam? how much? using which format? We need to answer these three questions separately. The previous time, you said that the cam went off once you changed the format register. Do you mean that the urb completion handler received data but wasn't able to figure out the header or is it that the completion handler didn't receive any data at all? There is a huge difference. > As I told you before, the Bayer to RGB decoding algorithm is busted. Oh yeah, I agree.. It's about components' offsets in the decoders. > Have you verified that it works? Did you derive the algorithm by > yourself or did you base it from some previous work? No, I got that code from Willem's driver which is in the project's trunk. The algorithm itself isn't rocket science and it's pretty much about color interpolation. So basically you have some missing alternate red, green or blue components for pixels that you're going to recover from the neighborhood. Check this http://www.siliconimaging.com/RGB%20Bayer.htm page and google for more information. The process isn't deterministic, i.e the resulting picture (quality) depends on the interpolation technique you're gonna use and it relies on a lot of memory lookups. > What work that remains to do is: > 1) Fix RGB32, RGB24 algorithms > 2) Enable scaling to lower resolution I still think that the m5602/ov9650 can deliver sub-VGA pictures... I did it for my m5603c/mt9v011. > 3) Add some cleanups to the init code which I have in my tree > 4) Release for wider testing > 5) Submit upstream for review and inclusion Definitely. Best regards, Ilyes Gouta. > Comments? Suggestions? > Regards, > Erik > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ M560x-driver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
