Root/
1 | |
2 | SN9C1xx PC Camera Controllers |
3 | Driver for Linux |
4 | ============================= |
5 | |
6 | - Documentation - |
7 | |
8 | |
9 | Index |
10 | ===== |
11 | 1. Copyright |
12 | 2. Disclaimer |
13 | 3. License |
14 | 4. Overview and features |
15 | 5. Module dependencies |
16 | 6. Module loading |
17 | 7. Module parameters |
18 | 8. Optional device control through "sysfs" |
19 | 9. Supported devices |
20 | 10. Notes for V4L2 application developers |
21 | 11. Video frame formats |
22 | 12. Contact information |
23 | 13. Credits |
24 | |
25 | |
26 | 1. Copyright |
27 | ============ |
28 | Copyright (C) 2004-2007 by Luca Risolia <luca.risolia@studio.unibo.it> |
29 | |
30 | |
31 | 2. Disclaimer |
32 | ============= |
33 | SONiX is a trademark of SONiX Technology Company Limited, inc. |
34 | This software is not sponsored or developed by SONiX. |
35 | |
36 | |
37 | 3. License |
38 | ========== |
39 | This program is free software; you can redistribute it and/or modify |
40 | it under the terms of the GNU General Public License as published by |
41 | the Free Software Foundation; either version 2 of the License, or |
42 | (at your option) any later version. |
43 | |
44 | This program is distributed in the hope that it will be useful, |
45 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
46 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
47 | GNU General Public License for more details. |
48 | |
49 | You should have received a copy of the GNU General Public License |
50 | along with this program; if not, write to the Free Software |
51 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
52 | |
53 | |
54 | 4. Overview and features |
55 | ======================== |
56 | This driver attempts to support the video interface of the devices assembling |
57 | the SONiX SN9C101, SN9C102, SN9C103, SN9C105 and SN9C120 PC Camera Controllers |
58 | ("SN9C1xx" from now on). |
59 | |
60 | The driver relies on the Video4Linux2 and USB core modules. It has been |
61 | designed to run properly on SMP systems as well. |
62 | |
63 | The latest version of the SN9C1xx driver can be found at the following URL: |
64 | http://www.linux-projects.org/ |
65 | |
66 | Some of the features of the driver are: |
67 | |
68 | - full compliance with the Video4Linux2 API (see also "Notes for V4L2 |
69 | application developers" paragraph); |
70 | - available mmap or read/poll methods for video streaming through isochronous |
71 | data transfers; |
72 | - automatic detection of image sensor; |
73 | - support for built-in microphone interface; |
74 | - support for any window resolutions and optional panning within the maximum |
75 | pixel area of image sensor; |
76 | - image downscaling with arbitrary scaling factors from 1, 2 and 4 in both |
77 | directions (see "Notes for V4L2 application developers" paragraph); |
78 | - two different video formats for uncompressed or compressed data in low or |
79 | high compression quality (see also "Notes for V4L2 application developers" |
80 | and "Video frame formats" paragraphs); |
81 | - full support for the capabilities of many of the possible image sensors that |
82 | can be connected to the SN9C1xx bridges, including, for instance, red, green, |
83 | blue and global gain adjustments and exposure (see "Supported devices" |
84 | paragraph for details); |
85 | - use of default color settings for sunlight conditions; |
86 | - dynamic I/O interface for both SN9C1xx and image sensor control and |
87 | monitoring (see "Optional device control through 'sysfs'" paragraph); |
88 | - dynamic driver control thanks to various module parameters (see "Module |
89 | parameters" paragraph); |
90 | - up to 64 cameras can be handled at the same time; they can be connected and |
91 | disconnected from the host many times without turning off the computer, if |
92 | the system supports hotplugging; |
93 | - no known bugs. |
94 | |
95 | |
96 | 5. Module dependencies |
97 | ====================== |
98 | For it to work properly, the driver needs kernel support for Video4Linux and |
99 | USB. |
100 | |
101 | The following options of the kernel configuration file must be enabled and |
102 | corresponding modules must be compiled: |
103 | |
104 | # Multimedia devices |
105 | # |
106 | CONFIG_VIDEO_DEV=m |
107 | |
108 | To enable advanced debugging functionality on the device through /sysfs: |
109 | |
110 | # Multimedia devices |
111 | # |
112 | CONFIG_VIDEO_ADV_DEBUG=y |
113 | |
114 | # USB support |
115 | # |
116 | CONFIG_USB=m |
117 | |
118 | In addition, depending on the hardware being used, the modules below are |
119 | necessary: |
120 | |
121 | # USB Host Controller Drivers |
122 | # |
123 | CONFIG_USB_EHCI_HCD=m |
124 | CONFIG_USB_UHCI_HCD=m |
125 | CONFIG_USB_OHCI_HCD=m |
126 | |
127 | The SN9C103, SN9c105 and SN9C120 controllers also provide a built-in microphone |
128 | interface. It is supported by the USB Audio driver thanks to the ALSA API: |
129 | |
130 | # Sound |
131 | # |
132 | CONFIG_SOUND=y |
133 | |
134 | # Advanced Linux Sound Architecture |
135 | # |
136 | CONFIG_SND=m |
137 | |
138 | # USB devices |
139 | # |
140 | CONFIG_SND_USB_AUDIO=m |
141 | |
142 | And finally: |
143 | |
144 | # USB Multimedia devices |
145 | # |
146 | CONFIG_USB_SN9C102=m |
147 | |
148 | |
149 | 6. Module loading |
150 | ================= |
151 | To use the driver, it is necessary to load the "sn9c102" module into memory |
152 | after every other module required: "videodev", "v4l2_common", "compat_ioctl32", |
153 | "usbcore" and, depending on the USB host controller you have, "ehci-hcd", |
154 | "uhci-hcd" or "ohci-hcd". |
155 | |
156 | Loading can be done as shown below: |
157 | |
158 | [root@localhost home]# modprobe sn9c102 |
159 | |
160 | Note that the module is called "sn9c102" for historic reasons, although it |
161 | does not just support the SN9C102. |
162 | |
163 | At this point all the devices supported by the driver and connected to the USB |
164 | ports should be recognized. You can invoke "dmesg" to analyze kernel messages |
165 | and verify that the loading process has gone well: |
166 | |
167 | [user@localhost home]$ dmesg |
168 | |
169 | or, to isolate all the kernel messages generated by the driver: |
170 | |
171 | [user@localhost home]$ dmesg | grep sn9c102 |
172 | |
173 | |
174 | 7. Module parameters |
175 | ==================== |
176 | Module parameters are listed below: |
177 | ------------------------------------------------------------------------------- |
178 | Name: video_nr |
179 | Type: short array (min = 0, max = 64) |
180 | Syntax: <-1|n[,...]> |
181 | Description: Specify V4L2 minor mode number: |
182 | -1 = use next available |
183 | n = use minor number n |
184 | You can specify up to 64 cameras this way. |
185 | For example: |
186 | video_nr=-1,2,-1 would assign minor number 2 to the second |
187 | recognized camera and use auto for the first one and for every |
188 | other camera. |
189 | Default: -1 |
190 | ------------------------------------------------------------------------------- |
191 | Name: force_munmap |
192 | Type: bool array (min = 0, max = 64) |
193 | Syntax: <0|1[,...]> |
194 | Description: Force the application to unmap previously mapped buffer memory |
195 | before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not |
196 | all the applications support this feature. This parameter is |
197 | specific for each detected camera. |
198 | 0 = do not force memory unmapping |
199 | 1 = force memory unmapping (save memory) |
200 | Default: 0 |
201 | ------------------------------------------------------------------------------- |
202 | Name: frame_timeout |
203 | Type: uint array (min = 0, max = 64) |
204 | Syntax: <0|n[,...]> |
205 | Description: Timeout for a video frame in seconds before returning an I/O |
206 | error; 0 for infinity. This parameter is specific for each |
207 | detected camera and can be changed at runtime thanks to the |
208 | /sys filesystem interface. |
209 | Default: 2 |
210 | ------------------------------------------------------------------------------- |
211 | Name: debug |
212 | Type: ushort |
213 | Syntax: <n> |
214 | Description: Debugging information level, from 0 to 3: |
215 | 0 = none (use carefully) |
216 | 1 = critical errors |
217 | 2 = significant informations |
218 | 3 = more verbose messages |
219 | Level 3 is useful for testing only. It also shows some more |
220 | informations about the hardware being detected. |
221 | This parameter can be changed at runtime thanks to the /sys |
222 | filesystem interface. |
223 | Default: 2 |
224 | ------------------------------------------------------------------------------- |
225 | |
226 | |
227 | 8. Optional device control through "sysfs" [1] |
228 | ========================================== |
229 | If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, |
230 | it is possible to read and write both the SN9C1xx and the image sensor |
231 | registers by using the "sysfs" filesystem interface. |
232 | |
233 | Every time a supported device is recognized, a write-only file named "green" is |
234 | created in the /sys/class/video4linux/videoX directory. You can set the green |
235 | channel's gain by writing the desired value to it. The value may range from 0 |
236 | to 15 for the SN9C101 or SN9C102 bridges, from 0 to 127 for the SN9C103, |
237 | SN9C105 and SN9C120 bridges. |
238 | Similarly, only for the SN9C103, SN9C105 and SN9C120 controllers, blue and red |
239 | gain control files are available in the same directory, for which accepted |
240 | values may range from 0 to 127. |
241 | |
242 | There are other four entries in the directory above for each registered camera: |
243 | "reg", "val", "i2c_reg" and "i2c_val". The first two files control the |
244 | SN9C1xx bridge, while the other two control the sensor chip. "reg" and |
245 | "i2c_reg" hold the values of the current register index where the following |
246 | reading/writing operations are addressed at through "val" and "i2c_val". Their |
247 | use is not intended for end-users. Note that "i2c_reg" and "i2c_val" will not |
248 | be created if the sensor does not actually support the standard I2C protocol or |
249 | its registers are not 8-bit long. Also, remember that you must be logged in as |
250 | root before writing to them. |
251 | |
252 | As an example, suppose we were to want to read the value contained in the |
253 | register number 1 of the sensor register table - which is usually the product |
254 | identifier - of the camera registered as "/dev/video0": |
255 | |
256 | [root@localhost #] cd /sys/class/video4linux/video0 |
257 | [root@localhost #] echo 1 > i2c_reg |
258 | [root@localhost #] cat i2c_val |
259 | |
260 | Note that "cat" will fail if sensor registers cannot be read. |
261 | |
262 | Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2: |
263 | |
264 | [root@localhost #] echo 0x11 > reg |
265 | [root@localhost #] echo 2 > val |
266 | |
267 | Note that the SN9C1xx always returns 0 when some of its registers are read. |
268 | To avoid race conditions, all the I/O accesses to the above files are |
269 | serialized. |
270 | The sysfs interface also provides the "frame_header" entry, which exports the |
271 | frame header of the most recent requested and captured video frame. The header |
272 | is always 18-bytes long and is appended to every video frame by the SN9C1xx |
273 | controllers. As an example, this additional information can be used by the user |
274 | application for implementing auto-exposure features via software. |
275 | |
276 | The following table describes the frame header exported by the SN9C101 and |
277 | SN9C102: |
278 | |
279 | Byte # Value or bits Description |
280 | ------ ------------- ----------- |
281 | 0x00 0xFF Frame synchronisation pattern |
282 | 0x01 0xFF Frame synchronisation pattern |
283 | 0x02 0x00 Frame synchronisation pattern |
284 | 0x03 0xC4 Frame synchronisation pattern |
285 | 0x04 0xC4 Frame synchronisation pattern |
286 | 0x05 0x96 Frame synchronisation pattern |
287 | 0x06 [3:0] Read channel gain control = (1+R_GAIN/8) |
288 | [7:4] Blue channel gain control = (1+B_GAIN/8) |
289 | 0x07 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled |
290 | [2:1] Maximum scale factor for compression |
291 | [ 3 ] 1 = USB fifo(2K bytes) is full |
292 | [ 4 ] 1 = Digital gain is finish |
293 | [ 5 ] 1 = Exposure is finish |
294 | [7:6] Frame index |
295 | 0x08 [7:0] Y sum inside Auto-Exposure area (low-byte) |
296 | 0x09 [7:0] Y sum inside Auto-Exposure area (high-byte) |
297 | where Y sum = (R/4 + 5G/16 + B/8) / 32 |
298 | 0x0A [7:0] Y sum outside Auto-Exposure area (low-byte) |
299 | 0x0B [7:0] Y sum outside Auto-Exposure area (high-byte) |
300 | where Y sum = (R/4 + 5G/16 + B/8) / 128 |
301 | 0x0C 0xXX Not used |
302 | 0x0D 0xXX Not used |
303 | 0x0E 0xXX Not used |
304 | 0x0F 0xXX Not used |
305 | 0x10 0xXX Not used |
306 | 0x11 0xXX Not used |
307 | |
308 | The following table describes the frame header exported by the SN9C103: |
309 | |
310 | Byte # Value or bits Description |
311 | ------ ------------- ----------- |
312 | 0x00 0xFF Frame synchronisation pattern |
313 | 0x01 0xFF Frame synchronisation pattern |
314 | 0x02 0x00 Frame synchronisation pattern |
315 | 0x03 0xC4 Frame synchronisation pattern |
316 | 0x04 0xC4 Frame synchronisation pattern |
317 | 0x05 0x96 Frame synchronisation pattern |
318 | 0x06 [6:0] Read channel gain control = (1/2+R_GAIN/64) |
319 | 0x07 [6:0] Blue channel gain control = (1/2+B_GAIN/64) |
320 | [7:4] |
321 | 0x08 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled |
322 | [2:1] Maximum scale factor for compression |
323 | [ 3 ] 1 = USB fifo(2K bytes) is full |
324 | [ 4 ] 1 = Digital gain is finish |
325 | [ 5 ] 1 = Exposure is finish |
326 | [7:6] Frame index |
327 | 0x09 [7:0] Y sum inside Auto-Exposure area (low-byte) |
328 | 0x0A [7:0] Y sum inside Auto-Exposure area (high-byte) |
329 | where Y sum = (R/4 + 5G/16 + B/8) / 32 |
330 | 0x0B [7:0] Y sum outside Auto-Exposure area (low-byte) |
331 | 0x0C [7:0] Y sum outside Auto-Exposure area (high-byte) |
332 | where Y sum = (R/4 + 5G/16 + B/8) / 128 |
333 | 0x0D [1:0] Audio frame number |
334 | [ 2 ] 1 = Audio is recording |
335 | 0x0E [7:0] Audio summation (low-byte) |
336 | 0x0F [7:0] Audio summation (high-byte) |
337 | 0x10 [7:0] Audio sample count |
338 | 0x11 [7:0] Audio peak data in audio frame |
339 | |
340 | The AE area (sx, sy, ex, ey) in the active window can be set by programming the |
341 | registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C1xx controllers, where one unit |
342 | corresponds to 32 pixels. |
343 | |
344 | [1] The frame headers exported by the SN9C105 and SN9C120 are not described. |
345 | |
346 | |
347 | 9. Supported devices |
348 | ==================== |
349 | None of the names of the companies as well as their products will be mentioned |
350 | here. They have never collaborated with the author, so no advertising. |
351 | |
352 | From the point of view of a driver, what unambiguously identify a device are |
353 | its vendor and product USB identifiers. Below is a list of known identifiers of |
354 | devices assembling the SN9C1xx PC camera controllers: |
355 | |
356 | Vendor ID Product ID |
357 | --------- ---------- |
358 | 0x0458 0x7025 |
359 | 0x045e 0x00f5 |
360 | 0x045e 0x00f7 |
361 | 0x0471 0x0327 |
362 | 0x0471 0x0328 |
363 | 0x0c45 0x6001 |
364 | 0x0c45 0x6005 |
365 | 0x0c45 0x6007 |
366 | 0x0c45 0x6009 |
367 | 0x0c45 0x600d |
368 | 0x0c45 0x6011 |
369 | 0x0c45 0x6019 |
370 | 0x0c45 0x6024 |
371 | 0x0c45 0x6025 |
372 | 0x0c45 0x6028 |
373 | 0x0c45 0x6029 |
374 | 0x0c45 0x602a |
375 | 0x0c45 0x602b |
376 | 0x0c45 0x602c |
377 | 0x0c45 0x602d |
378 | 0x0c45 0x602e |
379 | 0x0c45 0x6030 |
380 | 0x0c45 0x603f |
381 | 0x0c45 0x6080 |
382 | 0x0c45 0x6082 |
383 | 0x0c45 0x6083 |
384 | 0x0c45 0x6088 |
385 | 0x0c45 0x608a |
386 | 0x0c45 0x608b |
387 | 0x0c45 0x608c |
388 | 0x0c45 0x608e |
389 | 0x0c45 0x608f |
390 | 0x0c45 0x60a0 |
391 | 0x0c45 0x60a2 |
392 | 0x0c45 0x60a3 |
393 | 0x0c45 0x60a8 |
394 | 0x0c45 0x60aa |
395 | 0x0c45 0x60ab |
396 | 0x0c45 0x60ac |
397 | 0x0c45 0x60ae |
398 | 0x0c45 0x60af |
399 | 0x0c45 0x60b0 |
400 | 0x0c45 0x60b2 |
401 | 0x0c45 0x60b3 |
402 | 0x0c45 0x60b8 |
403 | 0x0c45 0x60ba |
404 | 0x0c45 0x60bb |
405 | 0x0c45 0x60bc |
406 | 0x0c45 0x60be |
407 | 0x0c45 0x60c0 |
408 | 0x0c45 0x60c2 |
409 | 0x0c45 0x60c8 |
410 | 0x0c45 0x60cc |
411 | 0x0c45 0x60ea |
412 | 0x0c45 0x60ec |
413 | 0x0c45 0x60ef |
414 | 0x0c45 0x60fa |
415 | 0x0c45 0x60fb |
416 | 0x0c45 0x60fc |
417 | 0x0c45 0x60fe |
418 | 0x0c45 0x6102 |
419 | 0x0c45 0x6108 |
420 | 0x0c45 0x610f |
421 | 0x0c45 0x6130 |
422 | 0x0c45 0x6138 |
423 | 0x0c45 0x613a |
424 | 0x0c45 0x613b |
425 | 0x0c45 0x613c |
426 | 0x0c45 0x613e |
427 | |
428 | The list above does not imply that all those devices work with this driver: up |
429 | until now only the ones that assemble the following pairs of SN9C1xx bridges |
430 | and image sensors are supported; kernel messages will always tell you whether |
431 | this is the case (see "Module loading" paragraph): |
432 | |
433 | Image sensor / SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120 |
434 | ------------------------------------------------------------------------------- |
435 | HV7131D Hynix Semiconductor | Yes No No No |
436 | HV7131R Hynix Semiconductor | No Yes Yes Yes |
437 | MI-0343 Micron Technology | Yes No No No |
438 | MI-0360 Micron Technology | No Yes Yes Yes |
439 | OV7630 OmniVision Technologies | Yes Yes Yes Yes |
440 | OV7660 OmniVision Technologies | No No Yes Yes |
441 | PAS106B PixArt Imaging | Yes No No No |
442 | PAS202B PixArt Imaging | Yes Yes No No |
443 | TAS5110C1B Taiwan Advanced Sensor | Yes No No No |
444 | TAS5110D Taiwan Advanced Sensor | Yes No No No |
445 | TAS5130D1B Taiwan Advanced Sensor | Yes No No No |
446 | |
447 | "Yes" means that the pair is supported by the driver, while "No" means that the |
448 | pair does not exist or is not supported by the driver. |
449 | |
450 | Only some of the available control settings of each image sensor are supported |
451 | through the V4L2 interface. |
452 | |
453 | Donations of new models for further testing and support would be much |
454 | appreciated. Non-available hardware will not be supported by the author of this |
455 | driver. |
456 | |
457 | |
458 | 10. Notes for V4L2 application developers |
459 | ========================================= |
460 | This driver follows the V4L2 API specifications. In particular, it enforces two |
461 | rules: |
462 | |
463 | - exactly one I/O method, either "mmap" or "read", is associated with each |
464 | file descriptor. Once it is selected, the application must close and reopen the |
465 | device to switch to the other I/O method; |
466 | |
467 | - although it is not mandatory, previously mapped buffer memory should always |
468 | be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. |
469 | The same number of buffers as before will be allocated again to match the size |
470 | of the new video frames, so you have to map the buffers again before any I/O |
471 | attempts on them. |
472 | |
473 | Consistently with the hardware limits, this driver also supports image |
474 | downscaling with arbitrary scaling factors from 1, 2 and 4 in both directions. |
475 | However, the V4L2 API specifications don't correctly define how the scaling |
476 | factor can be chosen arbitrarily by the "negotiation" of the "source" and |
477 | "target" rectangles. To work around this flaw, we have added the convention |
478 | that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the |
479 | scaling factor is restored to 1. |
480 | |
481 | This driver supports two different video formats: the first one is the "8-bit |
482 | Sequential Bayer" format and can be used to obtain uncompressed video data |
483 | from the device through the current I/O method, while the second one provides |
484 | either "raw" compressed video data (without frame headers not related to the |
485 | compressed data) or standard JPEG (with frame headers). The compression quality |
486 | may vary from 0 to 1 and can be selected or queried thanks to the |
487 | VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum flexibility, |
488 | both the default active video format and the default compression quality |
489 | depend on how the image sensor being used is initialized. |
490 | |
491 | |
492 | 11. Video frame formats [1] |
493 | ======================= |
494 | The SN9C1xx PC Camera Controllers can send images in two possible video |
495 | formats over the USB: either native "Sequential RGB Bayer" or compressed. |
496 | The compression is used to achieve high frame rates. With regard to the |
497 | SN9C101, SN9C102 and SN9C103, the compression is based on the Huffman encoding |
498 | algorithm described below, while with regard to the SN9C105 and SN9C120 the |
499 | compression is based on the JPEG standard. |
500 | The current video format may be selected or queried from the user application |
501 | by calling the VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 |
502 | API specifications. |
503 | |
504 | The name "Sequential Bayer" indicates the organization of the red, green and |
505 | blue pixels in one video frame. Each pixel is associated with a 8-bit long |
506 | value and is disposed in memory according to the pattern shown below: |
507 | |
508 | B[0] G[1] B[2] G[3] ... B[m-2] G[m-1] |
509 | G[m] R[m+1] G[m+2] R[m+2] ... G[2m-2] R[2m-1] |
510 | ... |
511 | ... B[(n-1)(m-2)] G[(n-1)(m-1)] |
512 | ... G[n(m-2)] R[n(m-1)] |
513 | |
514 | The above matrix also represents the sequential or progressive read-out mode of |
515 | the (n, m) Bayer color filter array used in many CCD or CMOS image sensors. |
516 | |
517 | The Huffman compressed video frame consists of a bitstream that encodes for |
518 | every R, G, or B pixel the difference between the value of the pixel itself and |
519 | some reference pixel value. Pixels are organised in the Bayer pattern and the |
520 | Bayer sub-pixels are tracked individually and alternatingly. For example, in |
521 | the first line values for the B and G1 pixels are alternatingly encoded, while |
522 | in the second line values for the G2 and R pixels are alternatingly encoded. |
523 | |
524 | The pixel reference value is calculated as follows: |
525 | - the 4 top left pixels are encoded in raw uncompressed 8-bit format; |
526 | - the value in the top two rows is the value of the pixel left of the current |
527 | pixel; |
528 | - the value in the left column is the value of the pixel above the current |
529 | pixel; |
530 | - for all other pixels, the reference value is the average of the value of the |
531 | pixel on the left and the value of the pixel above the current pixel; |
532 | - there is one code in the bitstream that specifies the value of a pixel |
533 | directly (in 4-bit resolution); |
534 | - pixel values need to be clamped inside the range [0..255] for proper |
535 | decoding. |
536 | |
537 | The algorithm purely describes the conversion from compressed Bayer code used |
538 | in the SN9C101, SN9C102 and SN9C103 chips to uncompressed Bayer. Additional |
539 | steps are required to convert this to a color image (i.e. a color interpolation |
540 | algorithm). |
541 | |
542 | The following Huffman codes have been found: |
543 | 0: +0 (relative to reference pixel value) |
544 | 100: +4 |
545 | 101: -4? |
546 | 1110xxxx: set absolute value to xxxx.0000 |
547 | 1101: +11 |
548 | 1111: -11 |
549 | 11001: +20 |
550 | 110000: -20 |
551 | 110001: ??? - these codes are apparently not used |
552 | |
553 | [1] The Huffman compression algorithm has been reverse-engineered and |
554 | documented by Bertrik Sikken. |
555 | |
556 | |
557 | 12. Contact information |
558 | ======================= |
559 | The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. |
560 | |
561 | GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is |
562 | 'FCE635A4'; the public 1024-bit key should be available at any keyserver; |
563 | the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. |
564 | |
565 | |
566 | 13. Credits |
567 | =========== |
568 | Many thanks to following persons for their contribute (listed in alphabetical |
569 | order): |
570 | |
571 | - David Anderson for the donation of a webcam; |
572 | - Luca Capello for the donation of a webcam; |
573 | - Philippe Coval for having helped testing the PAS202BCA image sensor; |
574 | - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the |
575 | donation of a webcam; |
576 | - Dennis Heitmann for the donation of a webcam; |
577 | - Jon Hollstrom for the donation of a webcam; |
578 | - Nick McGill for the donation of a webcam; |
579 | - Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB |
580 | image sensor; |
581 | - Stefano Mozzi, who donated 45 EU; |
582 | - Andrew Pearce for the donation of a webcam; |
583 | - John Pullan for the donation of a webcam; |
584 | - Bertrik Sikken, who reverse-engineered and documented the Huffman compression |
585 | algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and |
586 | implemented the first decoder; |
587 | - Ronny Standke for the donation of a webcam; |
588 | - Mizuno Takafumi for the donation of a webcam; |
589 | - an "anonymous" donator (who didn't want his name to be revealed) for the |
590 | donation of a webcam. |
591 | - an anonymous donator for the donation of four webcams and two boards with ten |
592 | image sensors. |
593 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9