Interview with the author of PhotoFlow
1) First thing, some questions on yourself. What’s your name? What’s your job?
2) How did you get involved in the programming world?
3) And in the photography world?
The typical workflow of a Linux photographer is to do the initial processing with a RAW developer like RawTherapee or Darktable, and then switch to GIMP for the final touch-ups. This is simply because none of the Open Source photo editors provides at the same time high-quality RAW development, adjustment layers and non-destructive local editing. That’s where PhotoFlow enters the game…
I remember having followed a discussion on the Rawtherapee forums about adding support for adjustment layers. The conclusion was simple: it would imply rewriting a good portion of the processing pipeline. The current situation with Darktable is better, as it supports local editing through blending masks for most of the tools, however adjustment layers are not in the todo list of the developers.
Last but not least, they are both limited to single images. No way for example to combine two or more exposures in a single image with extended dynamic range.
So I decided to take a different approach: define my ideal photo editor, see what building blocks could be used as a starting point, and eventually incorporate code from both Rawtherapee and Darktable whenever possible, just to avoid re-inventing the wheel.
First of all, what could be the characteristics of an ideal photo editor? Here is my shopping list:
- allow the direct processing of RAW files
- be non-destructive
- provide a real-time preview of the current editing
- allow to combine multiple images
- support adjustment layers as well as layers grouping, to achieve complex effects
- allow local editing with grayscale blending masks
- allow the editing of rather large images (100 mega-pixels or more), without “killing” your machine
Developing a suitable processing pipeline has been my first big problem, and the main initial showstopper for the project. I’m not a professional programmer, and PhotoFlow is developed entirely in my limited spare time, therefore I could not afford one or more years for writing a decently optimized and fast processing engine. Luckily, I came across a little software gem called VIPS, an image processing library originally written for processing multi-spectral images of ancient paintings. VIPS is designed to process large images in a memory-efficient way, is intrinsically multi-threaded, and provides one of the fastest and better optimized processing frameworks on the Open Source market. No surprise that Wikipedia uses VIPS to scale-down large images (http://blog.wikimedia.org/2013/09/12/vipsscaler-implementation-wikimedia-sites/). Last but not least, the library is still in active development, and the authors are very responsive to user requests. After few email exchanges, it was clear to me that PhotoFlow was going to be built on top of VIPS.
From there on, PhotoFlow has been entirely built on top of VIPS, re-using existing code whenever possible. For example, the RAW processing part is largely derived from Darktable (RAW decoding and color matrices) and RawTherapee (Amaze, LMMSE and IGV demosaicing algorithms).
Last but not least, PhotoFlow saves sidecars files in XML format, without modifying the initial image(s). The XML files simply “register” all the editing steps, which are then “replied” by PhotoFlow whenever the file is opened. As such, any aspect of an edit can be modified and tweaked without any limits.
To conclude, PhotoFlow might well replace both your favorite RAW converter and GIMP in your daily photo retouching work, so why not give it a chance?
I’m using OSX for work, but Linux for anything else (even my TV set is hooked to a MythBuntu machine…). Honestly, for photography work I can switch between one system and the other without noticing any difference, except maybe for printing support which is better under OSX.
Nikon, of course! I almost always owned Nikon cameras and lenses, including a second-hand F4 before buying the D300 that I’m still using today, after almost 10 years (in the digital era, 10 years is like a century…).