On Wed, 4 Mar 2009, Thomas Kaiser wrote:
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.
Yes, you did send it. My point here was to preserve the header
information, for future use. So this is a good accounting of some possible
future uses.
As to the actual contents of the header, as you describe things,
0. Do you have any idea how to account for the discrepancy between
From usb snoop.
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
and
In Linux the header looks like this:
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
(I am referring to the 00 00 as opposed to F0 00)? Or could this have
happened somehow just because these were not two identical sessions?
1. xx: don't know but value is changing between 0x00 to 0x07
as I said, this signifies the image format, qua compression algorithm in
use, or if 00 then no compression.
2. xx: this is the actual pixel clock
So there is a control setting for this?
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"
Does anyone have any idea of how actually to use this information/ for
example, since a lot of cameras are reporting some kind of
similar looking information, does anyone know if there are any kinds of
standard scales for these entries? Just what are they supposed to signify,
and how exactly is one supposed to use such values, if they have
been presented? When I say "a lot of cameras," understand, I mean still
cameras as well as webcams, and cameras with a lot of different chipsets
in them, too. So this is a question whether there is any standard system
for the presentation of such data, and how it might constructively be used
in image processing. I have had questions about this kind of thing for a
long time, and I do not know where to look for the answers.
Theodore Kilgore
--
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
