Main Menu
Donations
Support Our Site!
Make donations with PayPal!
Donat-o-Meter Stats
September's Goal: $150.00
Due Date: Sep 30
Gross Amount: $0.00
Net Balance: $0.00
Surplus: $-150.00

Donations
Linux Projects Forum Index
   Users - SN9C1xx
     SN9C10 Compression
Register To Post

Threaded | Newest First Previous Topic | Next Topic | Bottom
Poster Thread
_nigu_
Posted on: 2004/10/31 18:19
Not too shy to talk
Joined: 2004/9/19
From: Liverpool
Posts: 33
Re: SN9C10 Compression
Luca,

could you possibly patch the driver to allow us catch a compressed frame? A "compression=1" to enable that as a driver init parameter (default compression=0) should do, without compromising the driver's integrity.

The compressed-raw result should be a buffer the size of a normal frame, but padded with zeroes to the end. This would allow us to test the decompression algorithm in userspace and to use existing code to grab the raw compressed frames.

Please let me know!
luca
Posted on: 2004/10/31 18:35
Webmaster
Joined: 2003/1/9
From:
Posts: 172
Re: SN9C10 Compression
Quote:
Luca,

could you possibly patch the driver to allow us catch a compressed frame? A "compression=1" to enable that as a driver init parameter (default compression=0) should do, without compromising the driver's integrity.


I will add the interface to do that in the next release.

Luca
bertrik
Posted on: 2004/10/31 21:30
Quite a regular
Joined: 2004/10/17
From: Netherlands
Posts: 43
Re: SN9C10 Compression
_nigu_, very interesting link!
Things are getting clearer now. Looking at the log for the test pattern, I see about 22 repetitive 'chunks' per line, which translates to 16 pixels per chunk. Each chunk seems to take 20 bits, often like 48.00.0 (hex), or 0100.1000.0000.0000.0000 (bin). My gues is that 100 is a code for +4 and 0 is a code for +0 (which matches the 16 pixels), but this does not exactly match the info from your link unfortunately (so I'll need to keep looking...)
The jump from 0x3F back to 0x00 around horizontal pixel 256 might give us info about how negative steps are encoded.
_nigu_
Posted on: 2004/10/31 22:49
Not too shy to talk
Joined: 2004/9/19
From: Liverpool
Posts: 33
Re: SN9C10 Compression
I think we should follow Krauss' advice and ignore byte/nibble boundaries, to focus on the bit sequence interpretation. What might have changed since the compression algorithm was created is the mapping from bit strings to delta values.

BTW Another thing I guess is that the variable xxxxx may be some sort of exponent , that is

instead of

11101xxxxx : =8*(xxxxx)+4

it should be

11101xxxxx : =exp(b,xxxxx)+k

b, k to be determined

For our comfort, I report some of the juiciest parts. Other than that, I think we must have a close look to the the decompression code, that is VERY interesting.

--------------------------------------
The frame header is 12 bytes long (0xff 0xff 0x00 0xc4 0xc4 0x96 0x00 0x<*1> 0x<*2> 0x<*3> 0x<*4> 0x<*5>). <*1> seems to be a frame counter (bits 6 and 7) and a size indicator (bits 1 and 2: 00=VGA, 01=SIF, 10=QSIF) Bit 0 seems to be always 1, 4 and 5 seem to be always 0. Bit 3 is often 0 (but not always).<*2> to <*5>'s meanings are probably some sort of brightness summary/average.

After that, the video lines follow. Each line starts with a 16-bit line header with two 8-bit starting values - since it's a Bayer pattern, there are two color components alternating in each line. Both components are tracked individually and independently (just alternating).

After the line header, the actual pixels follow. Th line lengths don't match exactly their named formats - for example, VGA mode seems to have only 638 Pixels in a row. For each pixel, there's a code in the stream that describes the next component value. It can either be described as a change from the last value of that component or as a direct value.


These codes are not bound to bytes - it's a pure bitstream. Codes have different lengths, according to their likeliness. The algorithm is similar to Huffman compression, the main differences are a) the two modes, b) the bit codes seem to be handmade, c) there's some redundancy because of the two description modes and d) not all possible values exist - therefore, the values had to be quantized (i.e. this compression algorithm is lossy).

The codes are as follows (they are not completely correct, I have to figure out a better way to decipher this, but they basically work):

0 : 0 (leave as is)
1000 : +8
1001 : -8
101 : +3
110 : -3
11100 : +18
11101xxxxx : =8*(xxxxx)+4 (these values seem to be unprecise - especially for low values)
1111 : -18

Luca is working on a patch that will allow us to pick a compressed frame from an application. I can't wait!

bertrik
Posted on: 2004/11/1 0:33
Quite a regular
Joined: 2004/10/17
From: Netherlands
Posts: 43
Re: SN9C10 Compression
Quote:
Luca is working on a patch that will allow us to pick a compressed frame from an application. I can't wait!

But we can already get compressed frames using a user-space application that uses libusb, no driver needed!
arek_s
Posted on: 2004/11/2 15:24
Just popping in
Joined: 2004/10/26
From: poland
Posts: 10
Re: SN9C10 Compression
which register is responsible for compression? i my model (0x0c45 0x602a, sn9c102), i can get only compressed frames.

regards.
bertrik
Posted on: 2004/11/3 13:27
Quite a regular
Joined: 2004/10/17
From: Netherlands
Posts: 43
Re: SN9C10 Compression
Maybe the differences in compression codes can be explained by the compression mode (high or low quality).

Arek_s, IIRC, the compression is enabled by bit 7 in register 0x18, the quality (high/low) is determined by bit 0 in register 0x17. To be completely sure, check out the SN0C102 datasheet. See http://sourceforge.net/project/showfiles.php?group_id=97224&package_id=104178
arek_s
Posted on: 2004/11/3 14:35
Just popping in
Joined: 2004/10/26
From: poland
Posts: 10
Re: SN9C10 Compression
thanks,
i've found this specification after my post.

even if i set compression bit to 0 and compression quality to low, data from camera is still in unknow format (im sure its not bayerrgb). from my observation first frame is usually 0x7f4 bytes long (with header), second frame is only header. i'm setting registers like windows applications (basing on usbsnoop logs).
combination with register 0x19 gives me less compressed frames ( much longer frame-data), but in this case, i'm not sure that is right operation.

have anybody any conclusions about compression format? i'm doing my best to crack it, but probably i'm stuck.

regards.
luca
Posted on: 2004/11/3 14:49
Webmaster
Joined: 2003/1/9
From:
Posts: 172
Re: SN9C10 Compression
Bad initialization. That's all. Donate the webcam to the author of the driver so that you'll have it supported in less than 1/2 hour.

Luca
arek_s
Posted on: 2004/11/3 15:39
Just popping in
Joined: 2004/10/26
From: poland
Posts: 10
Re: SN9C10 Compression
as i understand, responsible for the compression is sn9c102 chipset. i'm doing initialization for this chip accordingly to windows applications.
combination on the registers 0x18 and 0x17 practically nothing changes.
thoes the sensor initialization has anything to compression effect?

i think that my situation is similar to post in this thread:
http://linuxfromscratch.org/pipermail/lfs-chat/2003-May/012923.html

luca, your work is great. i belive, that for you, add support for my webcam is no-problem. from my side, problem is more literal - money.

if this is possible, maybe you can write some howto about reverse-engeneering usb webcams? ;)

thanks for the answer.

ps. maybe you can look into logs from my cam?
« 1 (2) 3 4 »
Threaded | Newest First Previous Topic | Next Topic | Top

Register To Post
 
Login
Username:

Password:


Lost Password?

Register now!