wv9557@yahoo.com (Will) wrote in message news:<4a885870.0405111513.6507803e@posting.google.com>...> john@jrobot.net (john orlando) wrote in message news:<cc4b5d44.0405110517.4271d58b@posting.google.com>... > > > One possible culprit is that I am sampling a line of pixels (actually, > > two lines of pixels), sending them up over serial, waiting for the > > next frame, sampling the next two lines of pixels, etc...which is why > > I am wondering if there is something I'm not understanding regarding > > the possibility of the images being interlaced. > > John, > I haven't worked with this specific sensor, so can't offer you any > solutions. > It sounds like you have to wait for 30 frames (or whatever the max fps > this sensor can do) before you can get a whole image. If you have > SRAM in your configuration, maybe you can arrange to capture the whole > frame in SRAM > before uploading it to the PC. Just a thought. Good luck.Well...for what its worth, I figured out what was going on (kind of) and finally have images that look right. I ended up basically brute-forcing my way to a solution. In other words, in my PC app that was retrieving the pixels and displaying them, I just kept interpreting the data in slightly different ways until I got images that looked right. I then went back and analyzed it to start to determine how the camera data is being output. The final combination that worked required me to sample pixel data in every other frame (still don't know why exactly) as well as flipping every fourth line of pixels around (i.e., even though I think I should be sampling green and blue pixels, treat them as if they were red and green). I wish I could give a better explanation, but at least for now it will allow me to move forward. I'm sure the answer will be obvious (as soon as I find it ;-) Thanks again for everyone's help with this headache....it has subsided for now... Regards, John
OV6620 image sensor headaches
Started by ●May 11, 2004
Reply by ●May 12, 20042004-05-12
Reply by ●May 22, 20042004-05-22
You can try 408-542-3197 Denis Luo, He is the designer of OV6620 john@jrobot.net (john orlando) wrote in message news:<cc4b5d44.0405110517.4271d58b@posting.google.com>...> Hello, > I am currently working on a project using the Omnivision OV6620 CMOS > color image sensor (the same one used by the CMUcam). I have the > OV6620 interfaced to an Atmel AVR microcontroller, and I am able to > extract images from the camera and display them on a PC (through a PC > app I wrote...the images get sent up over the serial port). > > Anyway...my question has to do with the Bayer image format used by the > camera. The datasheets claim that the camera is a progressive scan > camera (some of the later models such as the OV7620 offer both > interlaced and progressive). However, there is an FODD output of the > camera (which is used to indicate when the "odd" portion of the frame > is being output). Further, this output toggles with every tick of > VSYNC (vertical synch pulse), which would seem to indicate that the > camera is really doing an interlaced output. The datasheet even makes > mention in its register definition section of several things that are > active in only progressive or interlaced mode. Also, the first Note > on page 20 of the data sheet makes reference to the Even/Odd field > timing when interlaced mode is active, and my oscilloscope shows the > same timing pulses as they mention for interlaced mode. > > Incidentally, I am using the camera in its 16-bit mode, utilizing both > the Y and the UV busses of the camera. Thus, for each tick of the > pixel clock, I read one red and one green (or one green and one blue) > pixel, depending on where I'm at in the current line. This is > different than the CMUcam, which uses the 8-bit mode. > > This whole thing is causing my headaches because the color images I am > extracting from the camera are not quite right. For example, when I > hold a red object up to the camera, the image I capture with it has > green lines every fourth line that shouldn't be there (I believe my > display code thinks that green pixels should be displayed for these > lines, but is somehow out of synch and is reading red values, thus > ending up with bright green lines). I've viewed both the raw Bayer > data as well as a bi-linear interpolation of the data (to smooth > things out) and neither looks quite right. > > One possible culprit is that I am sampling a line of pixels (actually, > two lines of pixels), sending them up over serial, waiting for the > next frame, sampling the next two lines of pixels, etc...which is why > I am wondering if there is something I'm not understanding regarding > the possibility of the images being interlaced. > > Are there any OV6620 experts out there? I've emailed Omnivision but > haven't heard back from them. If they only knew...oh well... > > Any help would be appreciated. I'd be more than happy to give as much > detail as needed regarding this project if someone could offer some > help. > > Thanks in advance! > > John
Reply by ●May 24, 20042004-05-24
I don't suppose you have an email address for him...I'd hate to bother him over the phone :-) Email me off list if you wouldn't mind at the listed email address (john@jrobot.net) Thanks, John lipzip2003@yahoo.com (lipzip) wrote in message news:<dae5142.0405221130.54bbf9ab@posting.google.com>...> You can try 408-542-3197 Denis Luo, He is the designer of OV6620 > > john@jrobot.net (john orlando) wrote in message news:<cc4b5d44.0405110517.4271d58b@posting.google.com>... > > Hello, > > I am currently working on a project using the Omnivision OV6620 CMOS > > color image sensor (the same one used by the CMUcam). I have the > > OV6620 interfaced to an Atmel AVR microcontroller, and I am able to > > extract images from the camera and display them on a PC (through a PC > > app I wrote...the images get sent up over the serial port). > > > > Anyway...my question has to do with the Bayer image format used by the > > camera. The datasheets claim that the camera is a progressive scan > > camera (some of the later models such as the OV7620 offer both > > interlaced and progressive). However, there is an FODD output of the > > camera (which is used to indicate when the "odd" portion of the frame > > is being output). Further, this output toggles with every tick of > > VSYNC (vertical synch pulse), which would seem to indicate that the > > camera is really doing an interlaced output. The datasheet even makes > > mention in its register definition section of several things that are > > active in only progressive or interlaced mode. Also, the first Note > > on page 20 of the data sheet makes reference to the Even/Odd field > > timing when interlaced mode is active, and my oscilloscope shows the > > same timing pulses as they mention for interlaced mode. > > > > Incidentally, I am using the camera in its 16-bit mode, utilizing both > > the Y and the UV busses of the camera. Thus, for each tick of the > > pixel clock, I read one red and one green (or one green and one blue) > > pixel, depending on where I'm at in the current line. This is > > different than the CMUcam, which uses the 8-bit mode. > > > > This whole thing is causing my headaches because the color images I am > > extracting from the camera are not quite right. For example, when I > > hold a red object up to the camera, the image I capture with it has > > green lines every fourth line that shouldn't be there (I believe my > > display code thinks that green pixels should be displayed for these > > lines, but is somehow out of synch and is reading red values, thus > > ending up with bright green lines). I've viewed both the raw Bayer > > data as well as a bi-linear interpolation of the data (to smooth > > things out) and neither looks quite right. > > > > One possible culprit is that I am sampling a line of pixels (actually, > > two lines of pixels), sending them up over serial, waiting for the > > next frame, sampling the next two lines of pixels, etc...which is why > > I am wondering if there is something I'm not understanding regarding > > the possibility of the images being interlaced. > > > > Are there any OV6620 experts out there? I've emailed Omnivision but > > haven't heard back from them. If they only knew...oh well... > > > > Any help would be appreciated. I'd be more than happy to give as much > > detail as needed regarding this project if someone could offer some > > help. > > > > Thanks in advance! > > > > John
Reply by ●May 24, 20042004-05-24
I don't suppose you have an email address for him...I'd hate to bother him over the phone :-) Email me off list if you wouldn't mind at the listed email address (john@jrobot.net) Thanks, John lipzip2003@yahoo.com (lipzip) wrote in message news:<dae5142.0405221130.54bbf9ab@posting.google.com>...> You can try 408-542-3197 Denis Luo, He is the designer of OV6620 > > john@jrobot.net (john orlando) wrote in message news:<cc4b5d44.0405110517.4271d58b@posting.google.com>... > > Hello, > > I am currently working on a project using the Omnivision OV6620 CMOS > > color image sensor (the same one used by the CMUcam). I have the > > OV6620 interfaced to an Atmel AVR microcontroller, and I am able to > > extract images from the camera and display them on a PC (through a PC > > app I wrote...the images get sent up over the serial port). > > > > Anyway...my question has to do with the Bayer image format used by the > > camera. The datasheets claim that the camera is a progressive scan > > camera (some of the later models such as the OV7620 offer both > > interlaced and progressive). However, there is an FODD output of the > > camera (which is used to indicate when the "odd" portion of the frame > > is being output). Further, this output toggles with every tick of > > VSYNC (vertical synch pulse), which would seem to indicate that the > > camera is really doing an interlaced output. The datasheet even makes > > mention in its register definition section of several things that are > > active in only progressive or interlaced mode. Also, the first Note > > on page 20 of the data sheet makes reference to the Even/Odd field > > timing when interlaced mode is active, and my oscilloscope shows the > > same timing pulses as they mention for interlaced mode. > > > > Incidentally, I am using the camera in its 16-bit mode, utilizing both > > the Y and the UV busses of the camera. Thus, for each tick of the > > pixel clock, I read one red and one green (or one green and one blue) > > pixel, depending on where I'm at in the current line. This is > > different than the CMUcam, which uses the 8-bit mode. > > > > This whole thing is causing my headaches because the color images I am > > extracting from the camera are not quite right. For example, when I > > hold a red object up to the camera, the image I capture with it has > > green lines every fourth line that shouldn't be there (I believe my > > display code thinks that green pixels should be displayed for these > > lines, but is somehow out of synch and is reading red values, thus > > ending up with bright green lines). I've viewed both the raw Bayer > > data as well as a bi-linear interpolation of the data (to smooth > > things out) and neither looks quite right. > > > > One possible culprit is that I am sampling a line of pixels (actually, > > two lines of pixels), sending them up over serial, waiting for the > > next frame, sampling the next two lines of pixels, etc...which is why > > I am wondering if there is something I'm not understanding regarding > > the possibility of the images being interlaced. > > > > Are there any OV6620 experts out there? I've emailed Omnivision but > > haven't heard back from them. If they only knew...oh well... > > > > Any help would be appreciated. I'd be more than happy to give as much > > detail as needed regarding this project if someone could offer some > > help. > > > > Thanks in advance! > > > > John
Reply by ●May 30, 20042004-05-30
I thought I would add my own OV6620 headaches here to this thread. Seemed like there are many experts in using the camera here and I didn't want to start a whole new thread regarding the camera. Firstly, I am having some trouble configuring the camera over I2C. The default pixel clk of the camera is 8.8mhz. Once I do a write to COMA, to do a soft reset, the pixelclk went down to 268khz. I can't figure out why it does that. Secondly, it seems that some registers are not meant to be written, but they are printed as r/w in the datasheet. The register that I am interested in is COMB, which I can set if I want 8bit/16bit data output. And the default that was set is 0x80 not 0x01 as shown on the datasheet.
Reply by ●June 1, 20042004-06-01
"bingee" <acalan21@hotmail.com> wrote in message news:<b007887a6389cb6a747ba1d3be2e0347@localhost.talkaboutelectronicequipment.com>...> I thought I would add my own OV6620 headaches here to this thread. Seemed > like there are many experts in using the camera here and I didn't want to > start a whole new thread regarding the camera. > > Firstly, I am having some trouble configuring the camera over I2C. The > default pixel clk of the camera is 8.8mhz. Once I do a write to COMA, to > do a soft reset, the pixelclk went down to 268khz. I can't figure out why > it does that. > > Secondly, it seems that some registers are not meant to be written, but > they are printed as r/w in the datasheet. The register that I am > interested in is COMB, which I can set if I want 8bit/16bit data output. > And the default that was set is 0x80 not 0x01 as shown on the datasheet.You should be able to write to both of those registers without a problem (well, I should qualify that to say that you should be able to modify the bits in those regs that are read/write). I have written to both of these registers for other reasons (COMA when I want to switch to YCrCb, and turn AWB off...COMB when I want to enable 8-bit mode). I have never seen the pixel rate drop to 268 KHz when I perform a soft reset of the camera. Is it possible that you ended up writing to register 0x11 instead of 0x12 (COMA)? This would explain the reduction in frame rate, because the low 6 bits of register 0x11 are the prescalar for the pixel clock. John