Thomas Kaiser wrote:
Hello Theodore
kilg...@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
And I forgot to say that the center brightness sensor was used to do
auto brightness control in the old gspca driver. Pixel clock was changed
on the fly to get better brightness in dark light conditions.
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
