|
|
Subscribe / Log in / New account

Darktable 1.4

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Nathan Willis
January 1, 2014

Version 1.4 of the open source photo-manipulation tool Darktable was released on December 26, bringing with it several long-requested features. Some of these new additions (such as editing with masks) include new core functionality, while others might best be viewed as exploratory features. Darktable has always included a wide swath of image-manipulation and filtering options that lend themselves well to experimentation. But there are also usability improvements in 1.4, which are especially welcome to users who may find the toolbox-ful of experimental options tricky to navigate.

Zooming in

The 1.4 release is available for download as a source bundle and as an Ubuntu package through the project's personal package archive (PPA). Other distributions rely on community builds, so the corresponding packages may take some time to arrive; there are also Mac OS X installers provided, but no Windows builds. In keeping with the just-after-Christmas release date, the Darktable logo in the new release sports a Santa hat; no telling how well that gag will age.

The project made one other stable release (1.2) since we looked at Darktable 1.1 in December 2012. The key features in that update included a de-noising function that could be tailored to fit the profile of one's actual camera, the ability to apply several instances of each filter to an image (which enables far more complex image manipulation for most filters), and the ability to import images from Adobe Lightroom, preserving most—but not all—of the edit operations performed in Lightroom.

In a sense, the 1.4 release mirrors the 1.2 release: a handful of focused feature additions for image manipulation, an important application-compatibility feature, and a lengthy list of minor tweaks and fixes. But they all add up; Darktable has come a long way from its early days, in which it often felt like a tool with tremendous power that was impossible to decipher and use, thanks to unlabeled controls, cryptic icons and UI elements, and a penchant for hiding settings and dials in out-of-the-way corners of the interface. Darktable 1.4 is a lot closer to a standard, easy-to-discover image processor.

Edit this

Darktable offers four major modes of operation, although two of those are likely to get considerably less usage on average. The emphasis is primarily on the "lighttable" mode for browsing and organizing an image collection and the "darkroom" mode for image editing. The other two options are "tethering" mode for controlling a USB-attached camera through the application and "map" mode, which simply offers a world-map view of any georeferenced images in the collection.

Darkroom mode is where the fun happens, of course. In the early days, Darktable would have been described as a "raw converter" because it focused on manipulating raw image file formats from digital cameras. Today it is a bit more general, supporting essentially every image format available, thanks to import filters from GraphicsMagick. In darkroom mode, the interface shows an image histogram in the top right corner of the window, and users can activate any of fifty (in version 1.4) different filter and effect modules. The modules range from simple operations like cropping to special effects like "bloom" (which simulates the washed-out halo effect usually seen when directly photographing a light source like a bulb or streetlight).

In practice, the main challenge in using Darktable's filter modules is keeping them straight in one's mind. Each module has its own sliders and controls; the active modules in an image are stacked on top of each other in a column underneath the histogram, so that the user must scroll up and down through the column to see them all. There is barely enough vertical space in the interface to see more than a couple of modules at a time, and there is even less room if the user opens up the palette of modules to select another one.

This interface challenge is shared by virtually all raw photo editing applications, and no one has come up with a particularly good solution to it yet. Darktable 1.4 does make an attempt at improvement in this area, though: a new preference will keep only one module "expanded" at a time; clicking on another module opens the new module and collapses the others. It isn't perfect, but neither are the alternatives.

Masks

[Darktable 1.4]

The new showcase feature in 1.4 is support for masking off part of the image, so that a filter module only applies to part of the image. There are five mask types available: circles, ellipses, gradients, closed bezier paths, and arbitrary shapes drawn with a brush. All are resizable and allow a fade-out radius for smooth blending—in fact, the "gradient" mask is just a fade-out projected from a straight line. Users can create as many masks as they want, and name or rename them in the "mask manager" panel (which sits on the left side of the window, so it does not steal more room from the filter module list).

The easiest way to use a mask with a filter is to create the mask first. Then the filter needs to be switched on, at which point the user can change the filter's "blend" control to "drawn mask." That setting restricts the filter to the masked area. The mask can be inverted or blurred if further customization is required.

Not every filter module can be masked, however: essentially, filters that operate on all of an image's pixels can be masked (including color, sharpness, and many of the special effects modules), but modules for other effects cannot. The un-maskable modules include controls for how the original image is imported (white balance, demosaicing algorithm, and so forth).

It is hard to overstate just how powerful masking filters are in the image-editing process. Without them, almost all effects are limited to operating on the entire picture; users who need to treat one part of the image differently from another would most likely perform part of the corrections in Darktable, then export the result for further work in another program. There are a few quirks in this implementation—for example, I could not get Darktable to allow me to rearrange existing nodes on a path mask, which means the mask needs to be drawn perfectly the first time through. But the feature is a considerable step up in Darktable's power.

Scripting, modules, and other interesting bits

Also powerful, at least in theory, is 1.4's support for scripting with Lua. At the moment, there are not many Lua scripts available for Darktable, but that should change over time. Scripting languages can be a divisive subject, of course; it seems plausible that the choice of Lua was made because Adobe Lightroom uses Lua for scripting, but there are several other open source image-processing applications that also support Lua scripts.

There are several other user-visible changes introduced in 1.4, although they are not as potentially important as masking and scripting. One of them is automatic focus detection in lighttable mode. When there are multiple shots of a particular subject, it is usually important to find the sharpest image; the focus detection feature will highlight sharp zones in an image in red, and blurry zones in blue, so the user can quickly narrow down the choice of which shots to work on.

There are also three new filter modules: "contrast/brightness/saturation," "color balance," and "color mapping." The first of those is a straightforward set of sliders for the image attributes in its name, while the second two require a bit more explanation. "Color balance" allows the user to manipulate the image with gamma and gain controls, while "color mapping" allows the user to swap colors in the image, with a considerable level of control.

Most color manipulations can be arrived at in multiple ways, of course; what makes any one filter module useful is whether it is intuitive to use or simplifies a specific operation. On that front, "color balance" and "color mapping" might take some getting used to. Fortunately, as is usually the case, Darktable provides several sensible defaults to help users get started.

A new feature that might require a bit more experimentation to get the hang of is Darktable's "waveform" mode for the image histogram. Usually, an image histogram graphs the number of pixels from an image on a dark-to-light axis, so that a balanced image will not show a graph that skews significantly to the dark end or the light end. The same is true for color histograms, which chart the amount of red, green, and blue: a balanced image shows all three colors in roughly equal proportions.

[Darktable 1.4]

The new waveform histogram mode is a different beast entirely: its x-axis plots the horizontal position of the image itself, but the y-axis shows brightness, and the color of the actual point on the graph maps how many pixels in the image to the intensity of the point. Confused? Not to worry; you are not alone. This is certainly an experimental way to examine an image; with some playing around it is possible to get a feel for how the waveform plots change in response to different images and different filters. But it is hard to say so far how useful it will prove in practice.

Last but certainly not least, Darktable 1.4 includes some new utility functions, such as the ability to analyze a sample image to create a "base curve" for a camera (i.e., to profile the specific camera unit's output), and the ability to query the operating system's color management configuration.

For casual photographers, Darktable is one of the best options for creative image adjustment because its stable of filter modules offer decent presets and defaults, and because it renders the results to screen rapidly. In contrast, an application like Rawstudio can perform many of the same effects, but the user needs to play around with individual controls to achieve them. For straightforward color correction, though, Darktable's lengthy list of modules may prove intimidating, and the interface—although it has made many positive strides in recent years—can still be confusing to navigate. For demanding photographers, however, Darktable 1.4 is sure to be a favorite on the strength of masking support alone. The rest is simply gravy.


to post comments

Darktable 1.4

Posted Jan 2, 2014 13:13 UTC (Thu) by boucman2 (guest, #81743) [Link] (3 responses)

lua was chosen because it was a technology I wanted to play with :)

I discovered that it was also used by lightroom after the fact.

As for the waveform histogram, apparently it's commonly used by video people and much less by photography people. A certain number of our devs come from the video world and are comfortable with this tool. That's why they added it...

Darktable 1.4

Posted Jan 2, 2014 14:55 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

You made a great choice. The only other option would be Python, but it's much heavier and the 2 vs 3 rift is making embedding choices fairly difficult. It sure tripped up Sublime Text.

I would laugh if someone mentions Guile.

Darktable 1.4

Posted Jan 2, 2014 15:02 UTC (Thu) by peter-b (subscriber, #66996) [Link]

Laugh if you like, but Guile is actually pretty good these days. Albeit better as a general purpose programming language than as an embedded one.

Darktable 1.4

Posted Jan 2, 2014 15:07 UTC (Thu) by n8willis (subscriber, #43041) [Link]

One oddity about the waveform histogram is that it's less useful with portrait orientation -- for which you'd want the spatial data preserved on the other axis. Presumably video folks would not have noticed that since they only shoot landscape....

Nate

Darktable 1.4

Posted Jan 2, 2014 14:09 UTC (Thu) by yodermk (subscriber, #3803) [Link]

Thanks for this. I need to make it a New Year's resolution to update my photo workflow - which currently involves shooting RAW+JPEG, but generally only keeping the JPEGs because I think they're good enough, then copying said JPEGs to an increasingly messy folder structure for viewing with gthumb.

Looks like it's time to switch to Darktable! Maybe after another review of Digikam, which I kind of gave up on in the past for whatever reason.

Darktable 1.4

Posted Jan 6, 2014 11:44 UTC (Mon) by Mithrandir (guest, #3031) [Link] (2 responses)

For those new to Darktable, there are a bunch of video tutorials tucked away on the website, some of which include coverage of the new features in 1.4:

http://www.darktable.org/resources/

(This may be somewhat shameless self-promotion).

Cheers,

Rob

Darktable 1.4

Posted Jan 6, 2014 13:44 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

nice, these need to be made easier to stumble across. you may want to add a blurb to the features page pointing this out.

taking a quick glance at this, I notice the enhanced support for some models of cameras. I have the Canon 6D, and I've also purchased a set of calibrated color targets and a screen color calibrator. Who would I contact to help get the 6D added to this list?

Darktable 1.4

Posted Jan 6, 2014 13:54 UTC (Mon) by Mithrandir (guest, #3031) [Link]

Here's what's generally involved for adding camera support (there's a section on the enhanced colour matrices):

http://www.darktable.org/2012/10/whats-involved-with-addi...

Otherwise, I'd recommend asking on the developer mailing list or the IRC channel:

http://www.darktable.org/contact/

Cheers,

Rob

Darktable 1.4

Posted Jan 6, 2014 18:24 UTC (Mon) by rmano (guest, #49886) [Link] (2 responses)

First of all, thanks to all developers for the season's gift.

The masking alone is a killing feature --- it distances darktable from all other RAW manipulation software (now, if it were possible to export the masks as PNGs to use them as mask layers in Gimp...)

I switched my workflow to darktable (from Rawtherapee) thanks to this. A word of warning tough: I couldn't find a way to reset dt internal database, so decide a directory structure BEFORE starting using it. External renaming, moving and deleting of your images are not so well accepted by dt... I am not sure if the .xmp files can override automatically the internal database, so that editing on two different computers with synced directories (and deleting images with other tools) could be more straightforward. Even then, dt is really recommended.

The only thing I miss from RT is the floating window with 100% detail. But I can live without this.

Thanks again!

Darktable 1.4

Posted Jan 9, 2014 13:30 UTC (Thu) by Mithrandir (guest, #3031) [Link] (1 responses)

> A word of warning tough: I couldn't find a way to reset dt internal database, so decide a directory structure BEFORE starting using it.

The database is in ~/.config/darktable/library.db and can be opened with sqlite3 in case you want to try your hand at modifying stuff.

> External renaming, moving and deleting of your images are not so well accepted by dt... I am not sure if the .xmp files can override automatically the internal database

Not automatically, though this topic has been discussed in the IRC channel so it may or may not change in future.

> so that editing on two different computers with synced directories (and deleting images with other tools) could be more straightforward.

There are two possible workarounds for this. The first is to sync the above sqlite database between computers by say, keeping it on the removable media along with the image files. The second is to manually refresh the images' settings in your database by removing the images (in the lighttable, select the images, then in the "selected image[s]" plugin, click "remove"). Then reimport the images, which will import the settings from the xmp sidecar files. But be careful to do this before editing any images: because the database takes precedence over the xmp sidecar files, if you edit the image the xmp file will be replaced with the settings from the database.

Hope that helps.

Cheers,

Rob

Darktable 1.4

Posted Jan 9, 2014 15:10 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> ~/.config/darktable/library.db

Weird. What was the reasoning for sticking it in XDG_CONFIG_HOME rather than XDG_DATA_HOME?


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds