Anders Blomdell wrote: > Thomas Kaiser wrote: >> Hello Anders >> >> Anders Blomdell wrote: >>> Thomas Kaiser wrote: >>>> Hello Anders >>>> >>>> Anders Blomdell wrote: >>>>> Thomas Kaiser wrote: >>>>> which indicates that both DQT and Huffman is present in the stream. >>>> It is _not_ present in the stream. >>> Then I don't understand where it comes from... >> I do, because I implemented it into gspca V1 ;-) >> >> The cam only streams the picture data. To code the stream a _static_ >> JPEG header is used. The cam and the driver know this header. Therefor, >> the driver just builds a valid JPEG image with the known header and the >> stream from the cam. >> >>>> Anyway I did not found time to try with the JPEG header from PAC7311. >>>> And I have to apologize because I did not tell you what work I did for >>>> the PAC7311. See this: http://www.kaiser-linux.li/index.php?title=PAC7311 >>>> >>>> You should find the PAC7311 JPEG header in this source: >>>> http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz >>> Will look into it. >> Check decoder/gspcadecoder.c and search for pac7311_jpeg_header. >> >>>>>> Anyway PAC7311 is working AFAIK. >>>>> Which doesn't contradict that it's encoded in the stream from the camera. >>>> BTW, can you send me the header and some Bytes from your stream, the 02 >>>> 8a 00 a2 80 28 a0 0a 28 thing. As ASCII in Email is OK. >>> The entire (white?) image is in the attachment (QUALITY=0). >> I tried the PAC7311 header. See the result in the attached files :-( > Thanks for trying though. > > I tested some more, and by starting at offset 7 (based on that ff00 indicates > jpeg stream, and that byte 8 differs between quality 1 & 2, [byte 7 follows > quality]) > > Size=152d, quality=1 > ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 > ... > Size=152a, quality=2 > ff d8 ff fe 28 3c 02 f9 55 15 29 a5 52 95 34 a8 > > I get img0 with the DQT you found on your installation disk, while img1 is what > you get with the standard DQT. Could it be that yuv=0,0,0 implies a black image? > Length is still bogus though, and with yuv != 0 I still get garbage, so I assume > there is some problem with the huffman coding still! > > I guess what I have to do, is to transform a yuv=0,0,0 image using the 17 > different DQT tables you found and try to generate a huffman table that matches > that data and the 17 different samples I have (of course this table will have > unknowns, but it might be a starting point). > > /Anders > Hello Anders What is the resolution of your black frame? I changed the component subsampling to 4:2:0 and the image size to 320x240. No your black frame looks OK :-) The black one is frameA-1.jpg and I attached my almost white one frame5-1.jpg. Thomas