Jérôme Belleman
Home  •  Tools  •  Posts  •  Talks  •  Travels  •  Graphics  •  About Me

Raw Photo Editors in a Techie's Workflow

28 Jan 2018

A review of raw photo editors by somebody who doesn't know much about photos, for somebody who doesn't know much about photos, but does know their UNIX.

1 Context

I was looking for a raw editor which could help me process and make use of my pictures quickly. In my particular use case, this means three things:

2 darktable

My first serious experience with raw photo editing was darktable, and I was immediately impressed. They say darktable is the tool of choice for people who are familiar with Adobe Lightroom – which I wasn't either, but I did see what other people do with it and I liked it.

If I couldn't find a getting-started guide from the darktable website, only more of a reference manual, I found that the community is sufficiently enthusiastic to provide video tutorials. One of these brought me up to speed: in a matter of half an hour, I knew how to give my photos a quality I never thought I could. And that's possibly also thanks to the ease of use of darktable.

While darktable offers a so-called lighttable to organise, tag, sort and filter my photos, it doesn't pretend to be an end-to-end photo manager. I will be able to give it as argument a directory or a list of photos. In fairness, it may take with a pinch of salt the path to a specific file I'm giving it and will just satisfy itself loading all the pictures in the same directory as the last one I passed.

The first thing I do each time I load a picture is to adjust the exposure histogram simply by pulling it left and right. The widget may not always be comfortable to use, especially when I need to pull the histogram rather far, causing the mouse to drop off it, stopping the control and forcing me to pull again from a different point. But the results on my pictures are staggering.

Pulling on the ends of a histogram is often all it takes to give a photo a stunning look
Pulling on the ends of a histogram is often all it takes to give a photo a stunning look

There are many modules coming with darktable, and I content myself with using only a minute fraction of them. For ignorant would-be photographs such as myself, the developers added the nice touch of grouping the modules, and one of them is called basic group, meaning somebody like me will find most of what they need in there.

I was pleased to hear that darktable will never touch the original photo, but will record any changes in a so-called sidecar XMP file. The XMP files are simply XML files, which I thought was a good idea at first, until I tried changing values in there manually; I soon realised they were rather obscure and that I couldn't quickly get away with it without using the graphical user interface. The purpose of these XMP files is actually unclear, and I realised as much so when I once removed one of them with the hope to reset some changes in a picture. However, next time I started darktable, not only were the changes still there; the XMP file came back! It turns out darktable keeps the same change information inside SQLite databases under ~/.config/darktable, sadly making the interaction fuzzy and rather unusable.

I particularly admire the choice of offering a darktable CLI, which makes fitting it into a workflow possible. I soon saw myself adding darktable commands to a makefile to fix a picture I had included into an Inkscape file which then clips it. Sadly though, my first attempt which was to have an Inkscape window with my clipped picture, a darktable window to further adjust it as I watched the end result in Inkscape and a shell to run darktable-cli failed miserably, because the changes I make interactively in darktable aren't saved to the XMP file immediately. So the XMP file darktable-cli uses isn't up-to-date and I won't see the changes happen live in Inkscape.

I resorted to the much more tedious operation of exporting the processed image with the darktable graphical interface, but even this soon became a pain; it turns out that the on conflict setting defaults to create unique filename, and even if I set it to overwrite, it will switch itself back to create unique filename after the next export. Is this really what the developers intended?

3 RawTherapee

My next stop was RawTherapee, and equally powerful raw editor, which also offers a CLI and many settings to tweak. Like darktable, it won't touch the original photo but will instead keep any changes to it in a sidecar PP3 file. It is also human-readable, much more so than the XMP files used by darktable and I daresay it's because it's not XML but something resembling more an INI file. The values also appear to relate more to those I see in the graphical interface.

RawTherapee definitely has a file browser, but the least I can say is that it didn't get in the way. Giving it a list of files as argument will only open the first one. Fair enough, that's how rawtherapee -h advertises it. But giving it a directory should have opened the file browser, and it just showed an empty window instead. Oh well, I didn't want it to manage my photo collections, so I won't complain.

I welcomed the getting started guide available on the RawTherapee website which briefly discusses the interface and the main settings a basic user may want to use. However, I couldn't help but notice that getting to the same result as with darktable required more expertise. RawTherapee won't let me pull the exposure histogram and working out how to adjust the many sliders to achieve the same effect as with darktable is – well I never managed, actually. Call me obtuse.

It's a shame, because I found the RawTherapee interface more consistent than the darktable one. Tooltips are everywhere to suggest sensible keyboard shortcuts which I would have loved to use. I found the Before/After view more convenient and exporting post-processed pictures is faster.

And would RawTherapee have fitted in my sample raw-to-Inkscape workflow better? Not much so, in fact, as running rawtherapee-cli suffers from the same problems as darktable-cli does: changes in the graphical user interface aren't immediately reflected in the sidecar PP3 file, and it's not entirely clear when they are. Certainly, restarting RawTherapee will do the business, but it's not what I'd want in a makefile. At least, the PP3 file is the only place where changes are kept, there is no database on the side. As a result, removing the sidecar file will indeed result in removing all the changes made to a picture.

4 Shotwell

Shotwell put me off from the start. First it offers to import all my photos, which I thankfully can promptly tell it not to. Giving it as argument a directory won't work as it expects a file – and a single one. Conversely, the File → Import from Folder... dialogue only expects a directory. If I do use it, a message will warn me that Shotwell is configured to import photos to your home directory, which made me think it makes a copy of pictures which it will alter, to avoid touching the original ones.

I confirmed this behaviour when I started altering a picture, which Shotwell offered me to save a copy of when I intended to exit it. No sidecar file, then. No workflows either, the command line interface letting me only open pictures – and only just. I briefly played with the Adjust dialogue to work with the exposure, but I never could get even close to what I can seamlessly achieve with darktable. I thought I wouldn't dwell on Shotwell any longer.

5 digiKam

I moved on to digiKam with a sense of nostalgia, as I remembered it was back in the olden days the best tool there was to load pictures from a camera. I didn't try to use it then to edit raw photos, a format I couldn't be bothered with at the time.

digiKam is one of these programs deeply rooted in the KDE ecosystem and it's with deep reluctance that I accepted to install literally half a gigabyte's worth of libraries to use it. That alone would have been good enough a reason to decide I wasn't going to. I'd much rather use this disk space for my pictures, to be brutally honest. But for the sake of this post I decided to plough on. For all I know, digiKam will be brilliant after all.

Just like Shotwell, digiKam first asks where I keep pictures, with the intention to manage them, which I don't want. Annoyingly, hitting the Cancel button makes it abort completely and quit. It disregarded the path I specified on the command line interface – a command line interface that isn't one at all, as it turns out. When I resigned to give it a path anyway, it then asked me where I wanted to keep a database. It appears so far that digiKam makes a conscious effort to do precisely all which I don't want.

Need I really go any further? I don't know how easy it is to improve the look of my pictures with digiKam, but in fairness I already know I prefer darktable in many respects. No, let's free this half gigabyte again and move on.

6 UFRaw

Back in the realm of tools that do one thing and do it well, UFRaw offers a command line interface expecting one or more files, which it will let me edit one after the other. If I give it a directory, it will open a dialogue to let me chose which files therein I wish to work on. I have to confess that it feels particularly fast, even if it's not a requirement I particularly had, nor a problem I particularly suffered from with any of the previous programs.

UFRaw is deliberately kept simple and it is intended for photographers who know what they're doing – not unlike RawTherapee. As a result, it is again much harder for me to achieve the compelling results darktable gave me.

Any changes I make to a picture will be recorded into ~/.config/ufrawrc, and applied to any subsequent picture until I change them again. It's slightly convoluted, but on the plus side, there's no database, and I could use ~/.config/ufrawrc as a sidecar file by copying it somewhere else and loading it again with the --conf option:

ufraw --conf ~/pictures/foo/IMG_8323.ufrawrc IMG_8323.CR2

Note that --conf=~/pictures/..., i.e. with an equal sign instead of a space, will not work as UFRaw doesn't understand the meaning of the twiddle. This approach will not get me far, as hitting the Save button once I'm done enhancing my photo results in saving a PPM file, and another file located in ~/.config/ufrawrc instead of overwriting the one passed to the --conf argument. Trying to bend its purpose would be looking for trouble.

7 dcraw and GIMP

To quote the man page, dcraw is a command-line decoder for raw digital photos and that consequently makes it spot on for fitting in a workflow. It comes with several options to perform some simple changes. However, I can't realistically expect to be able to work more comfortably repeatedly running the command with different options than by adjusting sliders and seeing the effect live.

However, dcraw can also be used as a GIMP plug-in: I just need to give a raw file as argument to GIMP, and I'm in business. Discussing what GIMP has to offer to work with pictures is probably beyond the scope of this post, given the sheer power of this software. However, I have to admit that fiddling with the Colors → Levels dialogue as I would have done with the darktable exposure histogram once again did not deliver.

This being GIMP, I wouldn't attempt to save some sort of sidecar file, and there are probably other ways to record changes made to a picture so they can be rolled out again programmatically later on. Again, beyond the scope of this post.

8 Outlook

Writing the last lines of this post, I would have expected to end up saying something like all these options were more or less OK, they really depend on what I'm looking for. But in truth, I found darktable remarkable, and I'm sure I will be able to solve the clumsiness around exporting pictures once I get to know it better and find a workaround.

And maybe by that time I will have become knowledgeable enough to treat myself to RawTherapee and enjoy the slightly more sensible sidecar data management which doesn't rely on using databases.

9 References