Re: MR97310A and other image formats

[Thomas Kaiser <v4l@kaiser-linux.li>]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Fri, 20 Feb 2009, Thomas Kaiser wrote:
> 
>> kilgota@banach.math.auburn.edu wrote:
>>>
>>>
>>> On Thu, 19 Feb 2009, Thomas Kaiser wrote:
>>>
>>>> kilgota@banach.math.auburn.edu 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.

> 
>>
>> PS: Now we have the 5. season in Liechtenstein, Fasnacht (means 
>> carnival). So, you can guess what I am doing the next couple of days :-)
>>
> 
> I don't know. Eat too much Wienerschnitzel? Temporarily transform into 
> "ein Bierfass"? Um Verzeihung. Ich hole sofort den Hut...

... party .....


Thomas