blob: b3ac0e3905b3fd7922aaa9b43137f20897f3db66 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
/* ADC-65(s) camera driver
* Released under the GPL version 2
*
* Copyright 2001
* Benjamin Moos
* <benjamin@psnw.com>
* http://www.psnw.com/~smokeserpent/code/
*/
This driver is for the serial version of the Achiever Digital Camera ADC-65.
This camera is sold under various brand names, such as the "Easy Shot digit".
These cameras take 15 photos at 256x256x24. They have an 8Mbit memory. They are
very cheap, less than $30 at WalMart.
The ADC-65 has a very simple syntax. The driver only sends one-byte
commands.
Commands
--------
0x30 : Ping the camera
0x00 - 0x15 : Get a picture
Responses
---------
0x15 0x30 0x00 : Ping response
0x15 [n] [data]: Picture response.
n = number of photos in memory + 1
data = 64k of data (format not determined yet)
The windows software is extremely basic, and only uses these 17 command
bytes. If any other commands are available, they will have to be found through
experimentation.
Note that there is a "picture zero" which always exists whether or not any
actual photos have been snapped. This seems most likely to be calibration data
for the CMOS sensor. I haven't incorporated this data in my driver yet for two
reasons; 1) I haven't decided on a good way to retain this data between picture
downloads, and downloading it for each picture is too wasteful 2) We're talking
about really minor adjustments, compared to the resolution loss we already get
from converting 256x256x8 R1G2B1 data to 256x256x24 RGB.
I have included the beginnings of some colorspace stuff in the colorspace.h
and colorspace.c files. Right now all I'm using is the colorspaceRGB data
structure, but will work on using this do some image enhancement in the future.
The hardest part of this project was figuring out the image format and I
was often led astray by typos and small logic errors while reprogramming that
portion of the code again and again (and again) due to the number of possible
pertubations. Two packages were very helpful, netpbm and the Gimp. By using
rawtopgm (from netpbm) I was able to visually analyze the data. Much better
than trying to understand hexdumps :) I am inspired to write some kind of tool
to help with analyzing this sort of data, perhaps interactively testing
different possible encoding schemes.
I have based the skeleton of this driver on the "barbie" camera driver. I
have also grabbed a lot of ideas from the dimera driver as well. So I am
indebted to:
The Barbie Team
---------------
Scott Fritzinger <scottf@unr.edu>
Andreas Meyer <ahm@spies.com>
Pete Zaitcev <zaitcev@metabyte.com>
Jeff Laing <jeffl@SPATIALinfo.com>
The Dimera3500 Team
-------------------
Brian Beattie http://www.beattie-home.net
Chuck Homic <chuck@vvisions.com>
Dan Fandrich <dan@coneharvesters.com>
Gregg Berg <gberg@covconn.net>
|
