72 lines
2.8 KiB
Plaintext
72 lines
2.8 KiB
Plaintext
/* 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
|
|
perturbations. 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>
|