Re: PATCH: gspca-mercurial OV7630 light frequency filter

Hi!

I had already seen that the ov7630 has 2 additional bits, but I don't thin k

  ....
> as we won't use it. So my idea was to just leave this 2 bits at there
> defaults.
>

Well, I've been looking at Windows logs and seen that they do it that way
and it worked good for me.

Good to know that Ekiga is buggy. Usually I test with the v4lctl tool and
set the values by hand. I usually test with Camorama or MPlayer.


> Talking about testing, now that we hopefully have the correct code for
> getting
> the average luminance from the frame header for the sn9c103, autoexposure
> should work, have you tested this?
>

Autogain is not working fine, I think there's some problem with the Auto
Exposure Area or something. I've added logs to get the exposure values and
the average luminance reported by the sensor. Here are some results:

sonixb: lum: 7359
sonixb: lum: 7329
sonixb: lum: 7299
sonixb: lum: 7321
sonixb: lum: 7337
sonixb: lum: 7261
sonixb: lum: 7183
sonixb: lum: 7058
sonixb: lum: 6878
sonixb: lum: 6671
sonixb: lum: 6383
sonixb: lum: 6210
sonixb: lum: 5954
sonixb: exp: 15, reg10: 229, reg11: 1
sonixb: lum: 5881
sonixb: lum: 5819
sonixb: lum: 0
sonixb: lum: 5733
sonixb: exp: 16, reg10: 244, reg11: 1
sonixb: lum: 5627
sonixb: lum: 5536
sonixb: lum: 0
sonixb: lum: 5336
sonixb: exp: 17, reg10: 130, reg11: 2
sonixb: lum: 5354
sonixb: lum: 0
sonixb: lum: 8936
sonixb: lum: 12686
sonixb: exp: 12, reg10: 183, reg11: 1
sonixb: lum: 12109
sonixb: lum: 0
sonixb: lum: 4425
sonixb: lum: 4731
sonixb: exp: 14, reg10: 214, reg11: 1
sonixb: lum: 5089
sonixb: lum: 0
sonixb: lum: 5568
sonixb: lum: 5844
sonixb: exp: 15, reg10: 229, reg11: 1
sonixb: lum: 6034
sonixb: lum: 0
sonixb: lum: 6540
sonixb: lum: 6752
sonixb: lum: 6874

While the image is still, the lum value doesn't change, it's stable so the
exp value doesn't need to change (this value is a little low for some light
conditions, but that's another problem). When there's movement the lum
values read from the sensor doesn't make sense and that make the exposure
changes quickly until there's no more movement. Any hints about this?

I don't know why the windows driver is touching these MSB's it is basicly
> slowing the framerate by 2/3ths for some unknown reason.


I think the MSB bits are changed when the webcam is capturing in 640x480,
from what I've been testing, the image is very unstable if the framerate is
too high at that resolution.

Also note that the non-common code for the ov7660 (without the _3) also is
> only
> touching registers which we handle with v4l2 ctrl's so that can be removed
> to.
> After which we can merge the 2 ov7660 types back into one type, only having
> different init_code for the bridge when using an 101/102 versus the 103 and
> not
> having different code for the sensor, as things should be.


I think it's a good idea, I can work on it and test that it keeps working in
my webcam.

Regards,

Andoni

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Spca50x-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spca50x-devs