Previewing digiKam 3.0.0

DigiKam, the KDE-based photo organization tool, is slated to release version 3.0.0 at the end of January (to coincide with the release of KDE 4.10). The digiKam project has a rapid release schedule — with four or more stable releases per year being typical in recent years — which can make staying up to date a challenge. But the circumstances of my personal photo collection dictated an upgrade, so I spent some time at the end of December working with the latest build. DigiKam is not quite a one-stop-solution for photographers, although each release adds more features, but it still excels at the task of managing a large collection of images.

The "circumstances" I refer to are not unique to me; they are a common issue with digital photography and open source software. It started with the purchase of a new (as in just-released) DSLR camera. New hardware is an area where Linux photographers still suffer at the hands of the camera-makers, because the companies routinely change details in their cameras' raw photo formats. These companies typically provide their own Windows and OS X software for working with the new formats, but open source projects like dcraw and LibRaw must reverse-engineer those formats by examining donated sample images. Consequently, I was forced to use pre-release versions of various raw conversion applications in order to use the files produced by the new camera.

Working with pre-release editing software is not particularly painful, since daily builds and snapshots are standard practice for most of the projects — but then again, raw converters have the distinct advantage of being non-destructive, never touching the original file. It is riskier (at least to a degree) to use unstable code to manage the database of archived images, because data loss could occur and potentially harm many files at once. As a result, I ended 2012 with several thousand images that I had not imported into a digiKam collection. When the digiKam 3.0.0 release candidate was announced on December 29, I decided it was time to take the plunge (on a subset of the new images, to simplify matters).

DigiKam relies on a sizable number of external libraries, including several that are specific to KDE, so it can be an undertaking to compile if you do not run a recent version of KDE. That said, it did not require the absolute latest versions of its KDE dependencies, so it does not require installing bleeding-edge dependencies. In addition, digiKam does not impose nearly as many dependencies as some other KDE applications, so there is not significant overhead for those users running a GNOME or LXDE environment.

For the uninitiated, digiKam offers four major modes: the main collection manager, an image editor, a batch processor, and a "light table." The light table is a comparison tool designed to help you inspect multiple images in detail. In one sense it is just another view into the image collection, but it functions in its own window. In practice, a user would locate a set of images in the collection manager, then drag-and-drop them into the light table to zoom in and compare similar options side by side. The digiKam image editor is not as full-featured as any of the standalone Linux photo editors (such as Darktable or Rawstudio), and in particular it offers fewer features for working with raw image formats. Whether it meets any individual user's needs for a particular task is going to vary. The same would be said of the batch processor; most of the raw photo editors offer batch processing as well, and digiKam's batch support does not include every feature available in the editor, but it does include quite a few.

What's new in editing and export

In fact, the 3.0.0 release adds batch-processing support for several new effects and tools. Perhaps the most important is raw demosaicing, which allows the user a choice among multiple methods for transforming a raw image file's data into standard RGB pixels. Raw formats are in theory wrappers around minimally-processed sensor data, which often means that they incorporate different numbers of red, green, and blue pixels, arranged in specific patterns, and at unusual bit-depths. There is a never-ending disagreement on how best to interpolate this raw data into more traditional RGB triples; hence there are multiple demosaicing algorithms to choose from. The average user might not notice the difference, but sticklers for detail will enjoy the ability to choose.

Several other new batch-processing options have been added, including color transformation effects and cropping, both of which are more common tasks than choosing a custom raw demosaicing algorithm. It is also noteworthy that the batch processor was rewritten to parallelize image operations. As a result, processing a batch queue where several operations are performed on each file should be noticeably faster on multi-core machines by pipelining the images.

There is just one noteworthy addition to the image editing tools, automatic noise reduction, which was implemented as a student project during 2012's Summer of KDE program. This function uses digiKam's existing wavelet-based noise reduction feature, but it estimates the amount of noise in the open image and attempts to hone in on an appropriate level of denoising that will not adversely soften important image features. This feature may prove useful for batch processing, when the user cannot spare the time to inspect every image file, but it is also handy to simply start off with a good guess at the amount of noise needing to be removed.

DigiKam offers users a variety of export options beyond the simple still image, and the 3.0.0 release adds to the list. First, the application's database can now import metadata tags for video files, and users can incorporate videos into "slideshow" output. That does stretch the definition of "slide," but since most digital cameras support recording video, it is undoubtedly a useful feature. Second, at some point in the recent past digiKam evidently lost the ability to export photos directly to KDE's wallpaper collection (the environment's Plasma framework allows for automatic wallpaper rotation and other fanciful effects); 3.0.0 restores this functionality. Last but certainly not least, digiKam can now act as a Digital Living Network Alliance (DLNA) media server, which enables users to discover and browse image collections by album on any DLNA-aware product, such as the many "smart" TVs on the market.

Import and management

With the image editing and export tools, it is certainly possible to work entirely within digiKam, but I have always preferred to make use of its collection management features and jump back and forth between an array of other applications for editing. The 3.0.0 release only introduces one change to the image management tools: the ability to pre-assign labels and tags to a set of images at the time they are imported from a camera and into the collection. This is a time-saver; as memory card capacities increase, importing a card-full of photos takes longer and longer. In my experience, the chief reason most people do not maintain good metadata about the location and subject of their photos is that the tools make it too difficult. Adding tag metadata while importing them may not solve the problem entirely, but it helps — after all, the user is guaranteed to be present when attaching the camera and starting the import.

One of digiKam's biggest strengths is that is offers so much flexibility in where an image collection is stored and how it can be searched. Unlike most photo organizers, it can track images stored locally, on remote servers, and on removable media all in the same database. The search options include geotagging, time and date information, user-supplied text tags, a broad assortment of metadata options, and some more esoteric options like "image fingerprints." Fingerprints allow the user to sketch out an image, which is then compared against a mathematical decomposition of the images in the collection — it is essentially a find-by-visual-similarity search.

On the other hand, there is also one oft-requested feature that still has not made it into digiKam of 3.0.0: face recognition. Face recognition is a tricky task, to be sure, but in digiKam's case the feature was a Google Summer of Code project that was started but dropped by the student before it was complete. Cynics might suggest that this is an inherent problem with the Summer of Code method for feature-addition, but it is not preventable. After all, there is nothing that prevents a non-student contributor from dropping out of a project either. You can still manually tag individuals in an image, which is a feature that the facial-recognition search will presumably hook into. On its own, though, tagging an individual in the People search tab does not offer any advantage over putting the person's name into a text tag.

The 3.0.0 release candidate offers a nice set of new features for digiKam users, but it is probably still wise for the average user to wait until the final release. In my limited test, the application failed to import and convert the existing, older version of digiKam's collection database to the new schema used by 3.0.0. Although there are workarounds, such as manually moving the database with the application's built-in database migration tool, corrupting the database of a hefty collection is a major problem. The automatic schema conversion problem has been reported, so it will hopefully be fixed before 3.0.0 is released. Once the kinks are worked out and the final release is available, it is certainly worth a look.