LWN.net Weekly Edition for February 17, 2005

The Grumpy Editor plugs in his camera

This article is part of the LWN Grumpy Editor series.

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 new toy.

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 progress.

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

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 delete them.

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.

digikam

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).

gthumb

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 interface.

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" button.

Summary

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 camera.

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.

Comments (44 posted)

OSDL's desktop specificaton

The Open Source Development Labs has, just in time for LinuxWorld, announced the availability of the "Desktop Linux Capabilities" specification. This document is available in PDF format.

One of OSDL's most controversial functions is the creation of specifications for Linux in particular environments. The Carrier Grade Linux and Data Center Linux documents might indeed be an accurate reflection of the features desired by commercial interests in those sectors. But those documents also appear, to the developers who actually create Linux, as an attempt to tell them what they should be working on.

In that regard, the introduction from the desktop Linux document is likely to rub some developers the wrong way:

The people at OSDL know quite well that any attempt to "decide" that desktop Linux would not be developed independently would fail. They do not yet seem to know how to keep that sort of language out of their documents, however.

The introduction continues:

OSDL goes on from there that there should be a single desktop Linux standard. Furthermore, this standard must be chosen from one of the existing desktop environments; any attempt to combine them was regarded as not feasible. The authors are clearly not complete masochists, however: they stopped short of saying which environment they think should be chosen, or even naming a subset from which the choice should be made.

The document identifies four types of desktop deployment, ranging from "fixed function" (locked-down kiosks of one form or another) through to "technical workstation" and "basic office". The existence of a "general purpose" usage category is recognized, but not really addressed in the document.

The bulk of the document follows: it is a tiresome series of tables describing the capabilities the authors think desktop Linux should have. Many of them are obvious, and already present: x86 processor support, USB support, IPv4, and so on. Some will be controversial: DVD playback support (which "will require licenses") and implementation of digital restrictions management schemes. Some make sense, and are in the works: persistent device naming, good IPSec support, etc. And some things are strange in their absence: instant messaging, Microsoft document format support, electronic mail, internationalization, and so on.

And a few things are bizarre. It would appear that all desktop users, even those with "fixed function" systems, have an urgent need for a Linux installer which uses their preferred desktop environment. Installations must be checkpointed so that they can be restarted in the middle. Desktop users should, it is said, be able to do things like update their kernel without needing root access to the machine. Numerous pages are devoted to various aspects of the installation process - despite the fact that, in a world of widespread Linux desktop deployments - most desktop users should never do their own installations.

If Linux is to achieve desktop World Domination, quite a bit of work will have to be done. Even the most ardent desktop Linux supporter will not (or should not) say that all of the necessary pieces are in place now. When OSDL set out to create its desktop capabilities document, it had an opportunity to identify the missing pieces, the features which, were they present, would make Linux more attractive in more desktop situations. That opportunity was lost in what must have been a series of tiresome meetings creating checklists of features Linux has had for years. Meanwhile the development community continues to improve Linux (for all environments) at a staggering rate - no specification required.

Comments (9 posted)

A look at CentOS

The CentOS (Community ENTerprise Operating System) project has been thrust into the spotlight recently as a result of contact from Red Hat's lawyers regarding the use of trademarks. In reality, that's something of a non-story, since Red Hat is only asking the project to comply with Red Hat's trademark guidelines. Red Hat has enforced its trademarks before without destroying the GPL or stopping the distribution of Red Hat derivatives.

The CentOS team makes it very clear that the trademark issue is not a major obstacle, and is no threat to the future development of CentOS. But the brief flurry of press did bring our attention to the cAos (community assembled operating systems) Foundation and its CentOS and cAos Linux distributions. This writer has run into several admins who've chosen to go with CentOS as an alternative to Red Hat Enterprise Linux.

The CentOS distribution is compiled from source packages from "a Prominent North American Enterprise Linux Vendor." CentOS-3 is built from Red Hat Enterprise Linux (RHEL) 3 sources, and CentOS-2 is built from RHEL 2. The project is working on CentOS 4 as well, but it is still in beta at the moment.

Installing and using CentOS is much (almost exactly) like using RHEL. There are some cosmetic differences, the CentOS logo and name replaces Red Hat's in most places -- though Red Hat is still given due credit in copyrights and so on -- and some changes in non-free packages. For the most part, though, CentOS seems to be an acceptable drop-in replacement for RHEL.

We also tested installing binary packages compiled for RHEL 3 on CentOS 3. We didn't run into any issues with packages compiled for RHEL 3 on CentOS 3 -- so CentOS seems to be suitable for users and organizations that want to use commercial products that support RHEL 3.

Support for CentOS is offered through forums, mailing lists, IRC channels and commercial organizations. We didn't approach any of the commercial organizations, but the CentOS community seems to be very helpful and responsive. The mailing lists, in particular, are fairly active. The February archive for CentOS 3 has 318 messages already, though some of the traffic is directly tied to the trademark issue.

Updates for CentOS are available via Yum repositories, which is a suitable replacement for the Red Hat Network as far as this writer is concerned. We did a little checking to see if the packages available from CentOS were up to date. After running "yum update" on CentOS 3 to get the latest packages, we checked against the Red Hat FTP repository for updates to RHEL 3. In each instance, we found that the CentOS packages were current, or at least as current as the packages on Red Hat's site.

The cAos Foundation is also distributing cAos Linux, not based on Red Hat's sources. The cAos Linux distribution is also RPM-based, but features its own Cinch installer, and a different design philosophy than CentOS. We did not spend much time with this distribution, but it does look like an interesting project for users who are looking for a community-driven RPM distribution with a long shelf-life. (The cAos page promises a 3-5 year life cycle, which is a bit more attractive for many users than the rapid development cycle for Fedora Core.)

Red Hat may have been better off leaving the trademark issue alone, since it seems that the project has garnered some attention it might not have received otherwise. After spending some time with CentOS, this writer sees little difference between Red Hat's official offerings and the CentOS offerings that are community-supported. Official support directly from Red Hat may be necessary for some organizations, but if that's not a requirement, the CentOS distribution may be a better choice.

Comments (11 posted)