Your editor has finally acted to bring an end to an annual embarrassment.
Each year, at the Kernel Summit, the entire group is brought together for a
photograph. Most digital cameras can do a reasonable job of taking a
portrait, but getting a reasonable image of some 70 people all together is
another story. Your editor, possessing a camera of the "other story"
variety, has been forced to post grainy, second-rate pictures of a
first-rate crowd, only to be upstaged by attendees with far superior
equipment. To be absolutely sure that he will not be shamed this year,
your editor went and picked up a shiny new Sony DSC-V3
camera. If his writing in LWN has seemed distracted recently, blame the
In the classic days of Linux, one would expect to spend a full, painful day
making a new device work with Linux. In this century, however, people have
this irrational expectation that their hardware will "just work." Linux
has gotten good at living up to that expectation in a number of ways; see
the advances in printer configuration, for example. Your editor set out to
determine if support for digital cameras has made the same sort of
It turns out that there are very few free applications which are aimed
specifically at interfacing with digital cameras. And the big ones,
reviewed below, are all based on the libgphoto2 library. So
this review did not take as long as some of the others in this series.
Gtkam is "the official GTK2
GUI" for libgphoto2. On many distributions, it is the default digital
camera interface application. Your editor tried version 0.1.12 on Fedora
and Ubuntu systems.
The initial gtkam window is mostly blank. The "camera" item on the tool
bar leads to the obvious "add camera" dialog, which, in turn, contains a
pulldown menu for
the camera model. In theory, the user need only select the right model
from this list, and all will be well. Unfortunately, this menu contains
over 500 entries, making the camera selection process unwieldy at best.
Even more unfortunately, your editor's camera - on the market since June of
last year - was not on the list. Obviously, your editor should have
checked first and bought a supported camera; somehow, however, the idea of
showing up at the Kernel Summit with a Barbie camera lacks appeal.
There is also a "detect" button next to the model pulldown; it failed to
find your editor's camera, however.
Now, the DSC-v3 has two ways of dealing with the USB bus. In its default
configuration, the camera appears to be a USB mass storage device. The
camera can also be instructed to use the "picture transport protocol" (PTP)
mode, which is an older, specialized way of talking to cameras. When your
editor put the camera into the PTP mode, and after tweaking some
permissions under /proc/bus/usb, gtkam was able to detect it - as
a Sony DSC-F707V. The model was wrong, but everything worked.
When it is talking to a camera it knows about, gtkam presents a simple
browsing interface. The left pane is the directory hierarchy as exported
by the camera, while the right shows thumbnails of any images stored in the
currently-selected directory. Many of the obvious things are not possible;
you cannot ask gtkam to display a full-resolution image, for example, and
it will not let you drag images into file browsers or other applications.
There are, in fact, exactly two things you can do: download images, and
The download window is somewhat awkward to work with, mostly because it
seems to want to provide for several possible actions. It can save the
pictures themselves, or just the thumbnails or metadata. It can feed the
images to an external application. Or it can rename the pictures, adding
an incrementing number to a user-supplied base filename. Once you get the
hang of the window, things work reasonably well, but it can take a couple
of tries at the outset.
The KDE digital camera application is digikam.
Your editor used version 0.7; that version is a bit old (there is a 0.7.2 beta out), but attempts to build
something more recent were a dismal failure. Digikam, it turns out, is not
a straightforward application to build.
The initial digikam window resembles gtkam's, in that there is not much to
be seen. The "Camera" toolbar item has an "add camera" option, which is a
nice enhancement over previous versions of digikam, which required the user
to wander into the "configure digikam" dialogs.
The camera dialog looks very much like gtkam's, and it
behaves in a very similar way. Since the same library is doing the work
underneath it all, this resemblance is not entirely coincidental. There is
one interesting addition to the digikam dialog, however: the user who
remains awake after having scrolled through some 500 possibilities will see
"USB mass storage" as a camera type. The user must provide the directory
where the camera will be mounted - and arrange for it to be actually
mounted there. With that work done, however, digicam was able to talk to
your editor's camera in its native mode. The PTP mode also works, as it
did with gtkam.
Actually, the PTP mode almost works. It will happily detect the camera
(once again calling it a DSC-F707V) and work with it - for one session.
Once the camera has been disconnected and plugged back in, however, digikam
is unable to work with it. Removing the camera from the configuration and
asking digikam to detect it from the beginning worked. It would seem that
the camera pops up with a different address under /proc/bus/usb
each time; gtkam is able to handle that change, but digikam is not.
Digikam provides the same basic operations as gtkam: download images from
the camera, and delete images from the camera. There is much more to
digikam than that, however: while gtkam forgets about images once they have
been extracted from the camera, digikam is a full image management and
manipulation framework. It implements albums, performs simple image
editing, and provides a large set of gimp-style plugins (which seem to be
mostly front ends to tools from the ImageMagick package).
Your editor reviewed gthumb
almost one year ago in this article on image
viewers and editors
. This application is not often presented as being
a tool for working with digital cameras, but the attentive user will notice
an "import images" item on gthumb's "file" menu. Selecting that option
yields the dia digital camera
It is, perhaps, the best of them all. There is no need to tell gthumb to
configure a camera; it simply goes out and talks to whatever it finds.
It found your editor's new camera without trouble (in PTP mode only), but
had to be instructed
on where to look for the old one, which is of the painful serial port
variety. The dialog has a blank marked "film," which would appear to be
the name of a subdirectory to create for the images.
Once that has been
figured out, it is simply a matter of deciding where the images should go,
whether they should be deleted from the camera, and hitting the "import"
So which is the preferred interface for a grumpy editor? Of the three
programs discussed above, gthumb has the most straightforward interface,
with a minimum of bureaucracy required before work can be done. That would
be your editor's pick.
The truth of the matter is this, however: your editor thinks the best
approach is to get a modern camera which implements the USB mass storage
protocol. Then you can simply mount the camera as a disk, move the image
files across, and be done with it. It's fast, easy, and for those who
prefer not to use the mv command, setting up hotplug scripts to
launch a file manager is relatively straightforward. There should be no
need for separate, specialized applications to interface with a digital
On the other hand, the management of images once they have been
pried from a camera's clutches is an interesting problem. Tools like
digikam and gthumb have been written with that task in mind; there are
several others out there as well. And that is likely to be your editor's
next (and rather more ambitious) exercise: a review of image management
tools. Stay tuned.
to post comments)