Re: [Spca50x-devs] PATCH: gspca-mercurial OV7630 light frequency filter
- Date: Tue, 22 Jul 2008 12:37:00 +0200
- From: Hans de Goede <j.w.r.degoede@xxxxxx>
- Subject: Re: [Spca50x-devs] PATCH: gspca-mercurial OV7630 light frequency filter
Andoni Zubimendi wrote:
> So can you please give things a try in 640x480 mode with the divisor
> kept at 3
> or higher, and no changes to 2a / 13 ?
> After a weekend away from home (visit a sister in another town), I came
> back and made some tests following your suggestions. Taking away the
> modifications to the register 0x76, and not touching 0x2a and register
> 0x13, I can see a clear image in both resolutions.
> I get 30 fps in 320x240 and 10 fps (1/3) in 640x480. The light filter
> works fine in both resolutions (tested). As the modifications to 0x2a /
> 13 is not needed anymore, I've deleted that part.
Thanks! The code is beginning to look much cleaner now.
> After that, I begin playing with the exposure, the reg10_max, I find out
> that it's better as you've said, keeping the 0x76 register constant and
> playing with register 0x10, 0x11. The value 0x41 is a good value for the
> reg10_max, the transition now is smooth when the register 0x11 changes.
> Playing with the exposure and changes in the registers gave me 2
> problems, when the register 0x11 was changed, one frame was empty (the
> one with 0 avg. lum in the logs) and the next one had half of the
> picture normal, and the other half more bright (that's why the avg.lum
> of the next frame is too high compared with the others values). It
> appears that we're changing a register in the middle of a frame.
> I've made a patch that keeps the record of the value of the reg11, and
> write it only when the value changes, this made the previous problem
> appear only when reg11 changed. To make the bad frames not to be
> processed I've added the option to drop 2 frames, when the avg. lum == 0
> is detected.
Good, I've modified your patch todo the same for the sn9c101/2 bridsge as I was
seeing similar issues.
> With this modifications, I can make the Auto Exposure control work
> smooth, now (with this patches) it's working fine.
Yes! But you still left it disabled by default? (fixed in my version of the patch)
You can pull my latest version with a (somewhat cleaned up) version of your
Changes I made are:
1) Don't restrict reg11 to 3 or more when in 352x288 mode on sif cams
2) Compared to the old code from before adding exposure we were changing the
high nibble of reg11 (vsync/ hsync polarity) from 0x00 to 0xC0 on the
ov7630, appaerantly this is not a problem with your cam, but to be sure
I've modified the code to not change the high nibble compared to the
3) I've gotten rid of the in my eyes artificial difference between
OV7630 and OV7630_3
Some things I would like you to test:
1) Make sure my cleanup didn't break anything
2) Maybe 160x120 will work now, I would like to get
rid of the (product == 0x60b0) special case
in the setting up of cam_modes
3) I think that the special probe sequence send at the
end of sd_config for your cam is not really necessary,
can you comment it and see if things still work?
(The led might be left on after plugging in the cam,
until you've started a v4l app atleast once. I have that issues with one my
cams too, and I'm planning on writing a generic fix for this).
Thanks & Regards,
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Spca50x-devs mailing list