Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn <elyk03@gmail.com>]

On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
> Hello Theodore
>
> kilgota@banach.math.auburn.edu wrote:
> > Also, after the byte indicator for the compression algorithm there are
> > some more bytes, and these almost definitely contain information which
> > could be valuable while doing image processing on the output. If they
> > are already kept and passed out of the module over to libv4lconvert,
> > then it would be very easy to do something with those bytes if it is
> > ever figured out precisely what they mean. But if it is not done now it
> > would have to be done then and would cause even more trouble.
>
> I sent it already in private mail to you. Here is the observation I made
> for the PAC207 SOF some years ago:
>
>  From usb snoop.
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
> 1. xx: looks like random value
> 2. xx: changed from 0x03 to 0x0b
> 3. xx: changed from 0x06 to 0x49
> 4. xx: changed from 0x07 to 0x55
> 5. xx: static 0x96
> 6. xx: static 0x80
> 7. xx: static 0xa0
>
> And I did play in Linux and could identify some fields :-) .
> In Linux the header looks like this:
>
> FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
> 1. xx: don't know but value is changing between 0x00 to 0x07
> 2. xx: this is the actual pixel clock
> 3. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (center)
> 4. xx: this is changing according light conditions from 0x03 (dark) to
> 0xfc (bright) (edge)
> 5. xx: set value "Digital Gain of Red"
> 6. xx: set value "Digital Gain of Green"
> 7. xx: set value "Digital Gain of Blue"
>
> Thomas

I've been looking through the frame headers sent by the MR97310A (the Aiptek 
PenCam VGA+, 08ca:0111).  Here are my observations.

FF FF 00 FF 96 6x x0 xx xx xx xx xx

In binary that looks something like this:

11111111 11111111 00000000 11111111
10010110 011001aa a1010000 bbbbbbbb
bbbbbbbb cccccccc ccccdddd dddddddd

All of the values look to be MSbit first.  A looks like a 3-bit frame sequence 
number that seems to start with 1 and increments for each frame.  B, C, and D 
might be brightness and contrast; minimum and maximum values for these vary 
with the image size.

For 640x480, 320x240, and 160x120:
  dark scene (all black):
    B:  near 0
    C:  0x000
    D:  0xC60

  bright scene (all white):
    B:  usually 0xC15C
    C:  0xC60
    D:  0x000

For 352x288 and 176x144:
  dark scene (all black):
    B:  near 0
    C:  0x000
    D:  0xB5B

  bright scene (all white):
    B:  usually 0xB0FE
    C:  0xB53
    D:  0x007

B increases with increasing brightness.  C increases with more white pixels 
and D increases with more black pixels.  A gray image has C and D near zero, 
while a high-contrast image (half black, half white) has C and D around 0x600 
or so.  The sum of C and D is not a constant.

I don't know how brightness and contrast are handled in V4L.  Hopefully 
someone can put this to use.
-Kyle