>
> If we turn the auto exposure on, the frame rate will drop from 13fps
> to 3fps in an indoor environment. But if we change to manual exposure
> and use a low exposure. Then the frame rate will be back to 13fps but
> the image will be dark again. The exposure value in the code is
> exactly how much time the image sensor will wait between two frames
> (the value is measured by rows). The windows driver shows a poor image
> with high frame rate. I guess they use a low exposure, acquire a dark
> image then light it by software.
>
It could be increasing the gain value instead of the exposure. That
would also increase the visibility
under low light conditions but have the effect of making a noisy image
instead of dropping your framerate.
> The driver defined the following pixel format,
>
> V4L2_PIX_FMT_SBGGR8,"Bayer 8bit (BGGR)", 8,0x2d
> V4L2_PIX_FMT_YUV420,"I420 (YUV 4:2:0)", 12, 0x2f
> V4L2_PIX_FMT_YUYV,"YUYV (YUV 4:2:0)", 16, 0x2e
> V4L2_PIX_FMT_JPEG,"JPEG (YUV 4:2:2)", 16, 0x2c
>
> If we choose a format, the driver will write the value in the last
> column to the bridge register 0x10e0. (For example, write 0x2d for
> V4L2_PIX_FMT_SBGGR8 format). For JPEG format, the driver will attach a
> JPEG header to the data. But the JPEG image doesn't seem to be right
> at colors. For other format, the driver will directly send the data
> from SN9C202 to applications. I guess most application will use the
> V4L2_PIX_FMT_JPEG format so the color is not right.
>
Well you have a slightly older version of the driver the current formats are
V4L2_PIX_FMT_SBGGR8,"Bayer 8bit (BGGR)", 8,0x2d
V4L2_PIX_FMT_SN9C20X,"SN9C20X I420 (YUV 4:2:0)", 12, 0x2f
V4L2_PIX_FMT_JPEG,"JPEG (YUV 4:2:2)", 16, 0x2c
Both the jpeg and i420 format are converted and/or compressed by the
sn9c20x bridge. however the bridge expects BGGR ordered bayer. Since
this sensor is returning a different ordered bayer format. This causes
colors to be wierd when converted.
> Most problems of MT9M111 sensor have be solved by now. Today I found a
> bug at the function sn9c20x_set_resolution, the line
> clrwindow[4] = ((mode->width >> 10) & 0x01) |
> ((mode->height >> 10) & 0x06);
> should to be changed to
> clrwindow[4] = ((mode->width >> 10) & 0x01) |
> ((mode->height >> 8) & 0x06);
> Otherwise in 1280x960 and 1280x1024 mode, SN9C202 will only return
> 1280x0 and 1280x0 image.
Ack, yeah thats definitely wrong, anyways i pushed a quick update out
to teh repository that should fix this bug.
> Besides this, we also need to tell the image sensor MT9M111 to switch to full
> resolution mode by adding the following code. It switchs the sensor to
> a predefined context. We can also set other registers to tell the
> sensor to not skip rows and columns. But switching context is easier.
>
> int data;
> if (mode->width==1280) {
> data=0x170F; // Context B output 1280x1024
> sn9c20x_write_i2c_data16(dev, 1, 0xC8, &data);
> } else {
> data=0x0004; // Context A output 640x512
> sn9c20x_write_i2c_data16(dev, 1, 0xC8, &data);
> }
>
> I can get 1280x1024 image from WebCam now. It's very close to make
> MT9M111 fully supported.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Lets make microdia webcams plug'n play, (currently plug'n pray)
To post to this group, send email to [email protected]
Visit us online https://groups.google.com/group/microdia
-~----------~----~----~----~------~----~------~--~---
