kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Fri, 20 Feb 2009, Thomas Kaiser wrote:
kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Fri, 20 Feb 2009, Thomas Kaiser wrote:
kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Thu, 19 Feb 2009, Thomas Kaiser wrote:
kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
Yes, what you quote is the SOF marker for all of these cameras.
The total header length, including the SOF marker ought to be 12
bytes. On all of the mr97310 cameras that I have dealt with, the
last 5 bytes are obviously related somehow to the image
(contrast, color balance, gamma, whatever). I have no idea how
to interpret those values, but we can hope
that someone will figure out how.
Two of them are luminance values (middle and edge) for the PAC207.
Which two, and how do those numbers translate into anything relevant?
Looks like I had some off list (private) email conversation about
the frame header of PAC207 with Michel Xhaard. I just paste the
whole thing in here:
michel Xhaard wrote:
Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit :
michel Xhaard wrote:
Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit :
Hello Michel
michel Xhaard wrote:
Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit :
Just relook the snoop, the header is always 16 bytes long starting
with:
ff ff 00 ff 96 64 follow
xx 00 xx xx xx xx 64 xx 00 00
let try to play poker with the asumption the R mean G0 mean B
mean G1
mean is encoded here.
Not sure about the 64 can you look at your snoop?
I never thought about that. So, you see I have not experience with
webcams.
Anyway, here are my observations about the header:
In the snoop, it looks a bit different then yours
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)
4. xx: this is changing according light conditions from 0x03
(dark) to
0xfc (bright)
5. xx: set value "Digital Gain of Red"
6. xx: set value "Digital Gain of Green"
7. xx: set value "Digital Gain of Blue"
Regards, Thomas
Thomas,
Cool good works :) so 3 and 4 are good candidate . To get good
picture
result there are 2 windows where the chips measure the ligth
condition.
Generally one is set to the center of the image the other are set
to get
the background light. At the moment my autobrightness setting
used simple
code and only one windows of measurement (the center one) .
Some more info, 3 is the center one.
:)
Did you want i try to implement these feature ? or maybe you can
have a
try :) the only problem i see is between interrupt() context and
process
context. I have set up a spinlock for that look at the code how
to use it
( spca5xx_move_data() )
Yes, please. Because I have no idea how to do this :-(
I am good in investigating :-)
I know, but can be very good in code to, as you know the hardware
:) now
let try to look at 1
^^ What does this mean?
is there the black luma level ?
I don't get it. What is the black luma level?
Regards, Thomas
--
http://www.kaiser-linux.li
By any chance, you do not have a JL2005B or JL2005C or JL2005D
camera among them, do you? AFAICT they all use the same compression
algorithm (in stillcam mode), and it appears to me to be a really
nasty one. Any help I could get with that algorithm is welcome indeed.
I have to check. Please send me the USB ID.
0x0979 is the Vendor ID from Jeilin.
0x0227 is the Product ID of the JL2005B/C/D cameras
(yes, all three of them have the same ID)
Thomas
Thanks for the information. But this is an old letter. What is
happening with Michel Xhaard these days? Do you know? I miss him.
Yes, I know it is an old letter, but these info are still valid for
the PAC207 chipset!
I don't know what happened to Michel. I didn't exchange mails with him
for a long time.
I believe you that the information is valid. The comment about the age
of the letter related to the fact that I have not heard from Michel for
approximately that long, myself. As to the information, though, what I
would really like to see is a collection started which lists the known
compression algorithms for the PAC family and, at least, their code
bytes. So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and
what else? For example, what is the next byte after the FF FF 00 FF 96
for the PAC207? That would probably be good to know, but if anyone has
recorded that information I have missed it.
Theodore Kilgore
Hello Theodore
At this time I wrote this letter, I had a lot of email conversation with
Michel. I got a cam with PAC207 chip and he got an other some weeks
later. Together, we could implement the PAC207 into spca5xx -> gspca.
For the next byte after FF FF 00 FF 96:
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
As far as I can remember (at the time I did this), the cam did
compresses sometimes and sometimes not during streaming.
So, I guess 0x07 means a compressed PAC207 frame!?
Actually, I got some frames where some lines were compressed and the
rest was raw. The line marker tells you if the line is compressed or
not. So, it doesn't make a lot of sense to send this information in the
frame header. But may be 0x07 means "you can get compressed lines"?
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
