When the DJ-1000 compact digital camera dropped below $100 (at Cyberian Outpost at least) I bought one figuring it was a good way to find out if a digital camera was something I'd ever use. Nearly 150 pictures later, I've found that having the camera in a pocket all the time means I'll take a lot more gratuitous pictures, since they cost nothing beyond a little battery consumption and some downloading time.
The camera itself is definitely of very low picture quality; it would be disappointing for anything more than web page snapshots. However, it is tiny, easily fits in a pocket, runs a long time on a pair of AAA batteries (unless you leave it turned on overnight, oops); the Compact Flash (CF) card is easily upgradable, and the whole thing has effectively no moving parts: there's a push button trigger, the "shutter" is entirely electronic, an on-off switch, and push-to-eject button for the CF card.
The manual reports the following details:
If you're using the camera with a Windows(tm) machine, you're all set, nothing to see here, please move along. However, if you're using anything else, you're not supported by the vendor...
The images are stored on the CF card as 128K files in a "FAT12
(DOS) Filesystem." This is convenient because it is a primitive
enough filesystem that just about anything can read it; Linux
and NetBSD PCMCIA support works fine, and even the Psion 5
palmtop has no problem finding the individual
MDSC0001.DAT files on the card. (FAT12 is an
interesting limit by itself - a FAT12 filesystem is at most 16M,
and thus can hold no more than 127 pictures.) With Windows(tm),
of course, you just drag and drop the files off the card as if
it were a floppy.
UPDATE: F.Chin-Joe sent me some detailed analysis based on some information he found on the net about the actual CCD used; this may be helpful to anyone else attempting to work with this camera. I haven't hacked on it myself recently, having switched to a Largan Lmini-350, which has a more cooperative vendor.
The problem is the interpretation of the images. The vendor
supplies a simple utility that lets you convert them one at a
time, preview them, try different sizes and resolutions, and
save them out as BMP files. They only supply versions
for Windows 95 and Windows 3.1 (though in English and Japanese.)
No source code, no file format specifications, and the vendor
has been unforthcoming (though there has apparently been some
difficulty making the request understood.) Newer software
(which I have not actually tried myself) appears to be available
at ftp.ado.co.jp:/pub/dj1000
and is reported to include a "batch" mode that might make
experimenting with modified images easier.
Some manual analysis of the image files generated made it clear that there were effectively four image planes, with different sensitivities. The planes are 8 bits per pixel, and some experimentation with feeding modified images to the vendor software seems to indicate that the pixels are assumed to be physically offset from each other, which is how they get from 256x128 to 504x378. The images have a 4x3 aspect ratio, so one must scale from the 2x1 ratio of pixels when viewing the slices. In my experiments, I've used panelhack.c to split the image apart into a set of four 256x124 24-bit PPM files (the 8 bit value is just copied to each of R, G, and B columns, so they are uniformly grey.) This is not a particularly efficient format but was easy to manipulate with perl, emacs, xv, The Gimp, and other tools.
The two "missing" scan lines at the end appear to be zero except for some meta data at offset 0x1f600:
C4,B2,E3,22; without
these bytes at this position, the vendor software will not
attempt to process the image00,02,00,03 appears as "camera version 2.03"
01
Some experimentation determined that the mapping between colors
photographed and bits stored was not consistent; if you look at
the #ifdef ATTEMPT_COLOR_HACK code in
panelhack.c you'll see remnants of an
attempt to apply a single mapping based on some processing of
some pictures of known colors using
Octave
to perform the matrix inversion. One interesting experiment was
a few pictures of a computer screen showing primary and
complementary colors, combined with black or complementary
backgrounds. It turns out that the colors were often "washed
out" and it was hard to distinguish which color was actual
present against black. This was rather frustrating...
The next experimentation involved creating solid color
DAT files using the information learned so far; a
simple perl script, mkpict.pl takes
four numbers on the command line, and outputs a 128K image. At
the time, I didn't have the updated software, so testing these
results meant a lot of manual clicking through the interface
(and finding bugs in the conversion tool, such as file handle
limits.) Now I don't have a convenient Windows system with
which to experiment further, so I have yet to construct a
working color converter; if anyone out there has the patience to
gather raw data, I can probably come up with useful
transformations. A variant on mkpict.pl
that included multiple colors might be a good starting point, as
well, since the big problem with the tests I ran was that images
with vast ranges of values ended up with the same color and
intensity results.
DAT files into one
PPM per plane.DAT files.