Web lists-archives.com

Re: [Spca50x-devs] PATCH: gspca-mercurial OV7630 light frequency filter




Andoni Zubimendi wrote:

<snip>
> 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

<snip>

> 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?

Yes your reg10max value is wrong, looking at the piece of the debug printk's
you've quoted above, lets see what happens:

> sonixb: lum: 6210
> sonixb: lum: 5954
> sonixb: exp: 15, reg10: 229, reg11: 1

lum drops below 6000 which is more then 1000 below our desired lum of 7000,
autogain_n_exp kicks in and raises exp one step.

> sonixb: lum: 5881
> sonixb: lum: 5819
> sonixb: lum: 0
> sonixb: lum: 5733
> sonixb: exp: 16, reg10: 244, reg11: 1

We now get 2 frames lum info based on the old settings and then a lum of 0,
which probably means the lum wasn't valid that frame as the changed settings
took into effect. This is not a problem as after each change we ignore lum for
3 frames.

Then we get a lum of 5733 with the new settings, which is still too low, so
autogain_n_exp kicks in again and raises exp one step again to 16. Notice how
sofar it has only been changing reg10, with seemingly little effect, atleast
not enough to compensate for the cause (movement) of lum loss (most likely
because reg10max = 0x41, so increasing it above 65 has no effect).

> sonixb: lum: 5627
> sonixb: lum: 5536
> sonixb: lum: 0
> sonixb: lum: 5336
> sonixb: exp: 17, reg10: 130, reg11: 2

Again 2 frames with old setting, one frame without valid lum, all 3 ignored,
yet despite increasing reg10 again the declining trend of lum continues, so
again it seems that increasing reg10 has no effect, most likely because its
above its max value.

Notice how autogain_n_exp no raises exp to 17 which causes reg11 to change to 2
halving the framerate, and thus doubling the exposure time !! To compensate for
this doubling reg10 gets approximately halved (halving the part of the frame
time which gets actually used for exposure) so that if reg10max is correct the
increase in exposure between 16 and 17 should roughly be as large as between 15
and 16, this is also the reason why reg10 doesn't get exactly halved, because
then the resulting exposure would not change at all (assuming a valid reg10max
value).

Look what happens now:

> sonixb: lum: 5354
> sonixb: lum: 0
> sonixb: lum: 8936
> sonixb: lum: 12686
> sonixb: exp: 12, reg10: 183, reg11: 1

One frame with the old settings, then a frame without lum, then a frame with
the new settings coming into effect (still ignored, its number 3) and then a
frame with the new settings fully into effect with a lum of 12686, which is
about double of the lum of our previous settings with exp 16 !

Conclusion, the framerate halving has doubled the exposure and the halving of
reg10 has not compensated (because both the old and new reg 10 are most likely
above the correct reg10 max!!

Since the new lum is way above what we want autogain_n_exp drops exp multiple
steps to compensate to an exp of 12, which is much too low as 16 was to low, so
then it starts increasing it again and the cycle restarts.

I strongly believe this is all caused by a wrong reg10max !!

As said before you should first disable autogain and then manual change exp one
step at a time and make sure all steps are equally large. If they are not
reg10max is of. Once you've got exposure to be a continues scale even though it
changes 2 registers, then you can re-enable autogain and hopefully it will work
much much better.

>     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.
> 

Yes, that figures I've been doing some math. 30 fps works fine at 352x288, 
352x288 generates 101376 bytes / frame. So with compression enabled the sonix 
brdige can clearly transport 30 * 101376 = 3041280 bytes per second.

640 * 480 * 30 would do 9216000 bytes / sec, which is 3 times as much and that 
indeed even with compression is most likely too much for an usb-1.1 connection, 
so I'm not surprised that 640x480 does not work at max ( == 30) fps, but given 
the code you've added to the setexposure method:

+
+		/* In 640x480, if the reg11 has less than 2, the image is
+		   unstable. */
+		if (gspca_dev->cam.cam_mode[(int) gspca_dev->curr_mode].priv == 0
+		    && reg11 < 3)
+			reg11 = 3;

Which means that you've reduced the max frame rate by a facto of three, I would 
expect no further mucking with the framerate adjust register to be necessary. 
Also keep in mind that further mucking with the framerate adjustment register 
will lead to framerates which are not a clean division of 30 or 25 fps killing 
the artificial light flicker filtering of the setfreq function.

So can you please give things a try without making any modifications to reg 2a ?

Also I see in the patch in your next mail that you are also playing with bit 7 
(mask 0x80) of register 0x13. This changes the assumption of the sensor about 
its clock crystal from 27Mhz to 24MHz, this sort of counter acts the lowering 
of the clock frequency done by the changes to the MSB of the framerate adjust 
register (reg 2a) as this changes the framerate in the opposite direction.

Summarizing, you're playing with the framerate in 3 different ways:
1 through register 11 which sets the final framerate divisor, this is fine
   as this is needed to control exposure. Not allowing the divisor to drop
   below 3 when in 640x480 mode also is fine
2 through reg 2a and 2b (the framerate adjust registers), this really should
   only be used to change the non divised framerate between 30 and 25 fps to
   match the powerline frequency and stop flicker caused by powerline frequency
   / base framerate mismatch. The adjustment needed to remove the powerline
   flicker is so small that the msb register (2a) never needs to be touched
3 through reg 13 bit 7, which changes the sensors assumption about its driving
   clock / cristal. This should really never be changed, this is only meant to
   allow using the sensor with different crystals, not as a method of playing
   tricks with the framerate.

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 ?

Thanks & Regards,

Hans



-------------------------------------------------------------------------
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
Spca50x-devs@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/spca50x-devs