AGFA ePhoto CL18

A "point and shoot" released by AGFA in May 2000 that was apparently "made on earth by man" (whatever that means). It cost 150 USD back then. I got both mine at a Habitat for Humanity store for 2 dollars each. Both work, at least to take photos. Both even get recognised by gPhoto2 but only one stays connected when downloading photos from it. The other quits halfway through and even sometimes causes my USB-A Framework module to get confused enough to stop working. I was able to get two pictures off that one, but then it stopped responding at all no matter what I tried.

At least the other one appears to work perfectly. I haven't found any way to get it to work as a webcam on Linux yet. There are Windows 98 drivers that could be worth tying out in a VM.

Using the cameras on Linux

gPhoto2 has support for this camera built into it... for now. It looks like the project isn't shy about cutting support for unpopular cameras. This one gets support via the soundvision driver for libgphoto2. On Arch, where I originally got this working, the libgphoto2 package does not come compiled with the soundvision "camlib" as the PKGBUILD uses the default, smaller set of camera drivers. The default set includes a sensible and still diverse list of cameras. Can't blame them for that. The easiest way to get the extended set is to modify the PKGBUILD for the AUR libgphoto2-git package with the diff below. The essential change is to pass --with-camlibs=everything to the compilation script.

diff --git a/PKGBUILD b/PKGBUILD
index 54edde2..da91bd1 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -7,7 +7,7 @@

 pkgname=libgphoto2-git
 _pkgname=libgphoto2
-pkgver=2.5.27+125+g590698165
+pkgver=2.5.30+5+g6d7787f0a
 pkgrel=1
 pkgdesc="Digital camera access library"
 url="http://www.gphoto.org/"
@@ -33,9 +33,9 @@ prepare() {

 build() {
   cd $pkgname
-  ./configure --prefix=/usr --disable-rpath
+  ./configure --prefix=/usr --disable-rpath --with-camlibs=everything
   sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0 /g' -e 's/    if test "$export_dynamic" = yes && test -n "$export_dynamic_flag_spec"; then/      func_append compile_command " -Wl,-O1,--as-needed"\n      func_append finalize_command " -Wl,-O1,--as-needed"\n\0/' libtool
-  make
+  make -j8
 }

 package() {

Anyway, your mileage may vary. I haven't tried this out more recently on Fedora.

In any case, once you get it working, you'll be able to list photos with gphoto2 -L and download them with gphoto2 -P. It's worth noting that on my current setup with KDE, I have to use sudo when running gphoto2. It might be caused by KDE's auto-mounting and could be fixed, but I haven't spent time on it yet.

The CL18 does not support the -D flag to delete all photographs from the camera. gphoto2 -a claims it's capable of deleting a single photo, but I haven't gotten that to work, I always end up with an I/O error and the camera frozen, requiring a power cycle.

To delete the photos, I instead use the camera itself. Following the manual's instructions:

1. Turn the camera on and put it in rec/play mode by pressing the rec/play button
2. To delete a single image, press the shutter button, which will cause it to show a trash can icon. Press the shutter button again to confirm. It will delete the number in the upper right hand corner indicates which photo it will delete. Use the quality or flash/timer buttons to move through the list.
3. To delete all the images on the camera, press the quality or flash/timer button until "ALL" appears instead of a photo number. Press the shutter button once to activate the trash can icon, and once more to confirm the action to delete all photos.

Example photos

Here are some example photos from this camera. They're not as bad as I was expecting. These are the JPEG files straight out of the camera. They were taken one after another under all the same conditions.

Other than the higher quality image being a bit brighter, which is nice, I think I prefer the lower quality one. Considering it doubles the number of shots the internal memory (2 MB) can hold, for good conditions the lower quality option is probably the right choice. I want to do some different lighting condition tests to see whether different lighting conditions would be better off with the higher quality option instead. Here's a shot from medium lighting, indoors, only under natural light on a cloudy day. I'm actually impressed with how well the shots rendered considering the lighting.

These were taken with the camera resting on the table and with the self-timer so to minimise movement. More or less the same results though. The "fine" quality results in a brighter image. I think this time because there wasn't as much "going on" in the photo, the higher quality option won handily. The camera itself is compressing the image, so it makes sense that the lower quality would be better on such a busy image like the trees above versus the relatively simple image of the Canon AE-1. There was a lot more (and very bad) noise on the higher quality image of the trees, probably from the compression issue.