The Herd Of Kittens - Mitsubishi DJ-1000 Digital Camera

What is it?

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:

F2.8 f=5.4mm
electronic shutter
focus range
20" (0.5m) to infinity
image pickup device
1/5" CCD, total 250,000 pixels
image size
320x240pixels (or 504x378)
total thickness of the camera
25/32" (19.8mm)

So what?

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 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:

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, 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 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.
Vendor software upgrade for the camera.
Bryan Biggers' page about the camera, lots of sample pictures and info on buying and using it.
source code from Jun-ichiro Hagino for a different camera but supposedly modified for the DJ-1000; I couldn't get much use out of it myself.
My source code for splitting the DAT files into one PPM per plane.
Simple perl script to generate simulated solid-color image DAT files.