A Review of FLOSS Raw Processors, Part 1
This is a thoroughly biased review of the following free and open source raw processors: dcraw, darktable, the digiKam raw processor, Photivo, Rawstudio, Rawtherapee, and UFRaw. Biased in what way? By default, raw processors are set up to produce enhanced output (ie, already sharpened, with increased color saturation and increased mid-tone contrast, not unlike in-camera-produced jpegs). But I don't want "enhanced" output. I want radiometrically correct, scene-referred output as the first step in a linear gamma image editing workflow.
Written in October 2012. Last update in July 2016.
Please note: the raw-processor-specific information on this page has not been updated since November 2013. The outlined criteria for evaluating raw processors still applies, but some of the raw-processor-specific information is out of date, and the PhotoFlow raw processor has not yet been included in the review.
Introduction: evaluating raw processors
What this review does and doesn't cover
All of the raw processors considered on this page can perform various post-interpolation image enhancements. Some of the raw processors are also digital asset management (DAM) programs. However, this review only covers raw processing, by which I mean raw interpolation (demosaicing) and also any denoising techniques that are only applicable to raw images.
I've been using dcraw, and more recently my floating point version of dcraw, as my "go to" raw processor for many years. My personal goal while writing this review is to see if any of today's high-powered, multi-functional free and open source raw processors might:
- Produce radiometrically correct output that's at least as good as my floating point version of dcraw.
- Provide the convenience of a gui — it's nice to be able to see the interpolated image before it's saved to disk!
- Offer some raw file repair options (automatic repair of dead pixel and chromatic aberration, dark frame subtraction, and etc) that my floating point version of dcraw doesn't have.
The usual raw processor review: enhanced vs radiometrically correct, scene-referred output
"Radiometrically correct, scene-referred output" means the channel values in the interpolated image are proportional to the amount of light that was recorded in the raw file. Scene-referred output tends to be flat and unappealing. This is the reason why all raw processors provide default settings that include image enhancement algorithms: "auto-levels", a tone curve to increase mid-tone contrast, sharpening, highlight recovery, and so forth.
The usual way to compare raw processors is to:
- Select one or more sample raw files.
- Process the raw file(s) using each raw processor's default (i.e. image enhancing) settings.
- Compare the resulting interpolated images.
The problem with this approach is that enhancement algorithms can't be applied until after the raw file has been interpolated. So in effect the usual raw processor review is more a review of the raw processor's default image enhancing algorithms than its actual capabilities as a raw processor.
Why radiometrically correct, scene-referred output is important
For many digital darkroom tasks you need radiometrically correct output as your starting point. For example:
- Combining multiple exposures into one image — for capturing additional dynamic range detail, or to obtain cleaner shadow areas, or to create a panorama — should be done in a linear gamma working space. Sharpening, tone mapping, and other image enhancing algorithms ideally should be applied after the images have already been combined into one image.
- Converting an image to black and white also should be done in a linear gamma working space, before applying any sharpening, tone mapping, and other image enhancing algorithms.
In my own workflow, almost always I want radiometrically correct, scene-referred output rather than enhanced output. In other words, I want the digital equivalent of a "flat print" that is suitable for further (and sometimes extensive) processing.
This review examines raw processor options and output strictly from the point of view of producing radiometrically correct, unenhanced output. In the tables below that compare various raw processor features, ameans a feature that I consider very important for outputting radiometrically correct images. A indicates a reason to exclude a raw processor from further consideration for me (but maybe not for you).
Theprovide supplementary information and/or detailed comparisons on various features and should be skipped right over unless you really want more information on that particular topic.
Processing and output bit-depth
Raw processing bit depth
Even though raw data by it's nature is integer data, and even though very few (any?) digital cameras store true 16-bit raw data, some raw processors do all their internal raw processing and subsequent image manipulation using 32-bit floating point values:
|16-bit integer||32-bit floating point|
|the digiKam raw processor||(?)||(?)|
Available output file formats
The raw processors considered in this review provide various output file format and bit depth options. Almost all the raw processors provide for 8-bit jpeg, png, and tiff output, plus 16-bit png and tif output. In the table below I used bold, italized type to indicate the more unusual output file formats offered by some of the raw processors:
|8-bit integer output||ppm
|16-bit integer output||ppm
|32-bit floating point output||pfm
At this point in time darktable is the only 32-bit floating point raw processor that also provides for 32-bit floating point output. Cinepaint, Krita, Gimp from git, ImagaMagick, deLaboratory and no doubt other floss image editors can process 32-bit floating point images. Leaving to one side the question of whether 32-bit floating point raw processing of itself produces superior results, compared to 16-bit integer raw processing, it puzzles me that none of the other floating point raw processors allow floating point output.
White balance options
Setting the right white balance is usually the first and arguably the most important step when processing a raw file. All raw processing programs provide one or more means of white-balancing a raw file during the demosaicing process:
- Camera (the white balance RGB multipliers stored by the camera in the raw file metadata)
- Presets (camera-specific white balance multipliers for various lighting conditions)
- Fixed D65 (a type of camera preset supported by dcraw)
- Automatic (often calculated simply by taking an average over the entire image)
- Spot (averaging over a user-selected neutral patch)
- Temp/Tint and/or RGB multipliers (explained below in the gray box)
|dcraw (1, 6)||darktable||digiKam||Photivo||Raw-
|Spot||✓ (3)||✓ (3)||(6)||✓ (3)||✓ (4)||✓ (5)||✓ (3)|
- Regular dcraw offers several different methods for setting the white balance. My floating point version of dcraw only accepts RGB multipliers for setting the white balance.
- The darktable "spot" white balance defaults to selecting the central 95% of the image, which effectively provides automatic white balance.
- At one extreme, for "Spot" white balancing dcraw (regular, not my floating point version), darktable, Photivo, and UFRaw allow you to draw any size box, anywhere in the image, up to and including the whole image.
- At the other extreme, for "Spot" white balancing Rawstudio seems to use a single pixel, which is not at all adequate, especially in noisy images.
- Somewhere in the middle, for "Spot" white balancing Rawtherapee allows you to use a box that is either 2x2, 4x4, 8x8, 16x16, or 32x32 px in size, which is adequate for most cases, but not, for example, when you are trying to select a narrow strip of neutral-colored pixels in a noisy image.
- The digiKam raw processor and my floating point version of dcraw don't provide "Spot" white balancing. The workaround for my floating point version of dcraw is to open the raw file with UFRaw and determine the RGB multipliers for the chosen "spot". I haven't found a workaround for digiKam.
Because my in-camera white balance is set to uniwb (also see Uniwb: Make Camera Display Reliable), and because I often use a (real, not digital) CC40 magenta filter, I need a raw processor that provides "Spot" white balancing. So a consideration of the available white balance options eliminates the digiKam raw processor from further consideration for me. If you don't use uniwb and you don't use physical color correcting filters on your camera, then digiKam might be perfectly suited to your own workflow. Also, having worked with quite a few noisy raw files, I know how hard it is to set a white balance using just a single pixel, so I'm inclined to also eliminate Rawstudio from further consideration.
Available interpolation algorithms
By definition, all raw processors make available one or more raw file interpolation algorithms:
|AMAZE||✓ (1)||✓||✓||✓ (3)||✓|
|AHD-V2||✓ (4)||✓ (4)|
- Any interpolation algorithm can be added to the dcraw c code. VNG, VNG4, PPG, and AHD are included in the default dcraw c code. DCB was written by Jacek Góźdź and the source code for dcraw modified to use DCB can be downloaded from LinuxPhoto.org "algorithms". Also my own floating point version of dcraw includes DCB, along with AMAZE, LMMSE, VCD, and AFD.
- I was unable to find documentation to verify, but I looked at the Rawstudio code and I'm pretty sure it uses PPG.
- Back in 2012 when I started working on this review, the Photivo website says AMAZE might not work, but it works just fine.
- I'm making the assumption that "AHD modified" and "AHD V2" refer to the same algorithm.
For general processing (i.e. an image that isn't excessively noisy or underexposed and was shot using a low ISO), I prefer to use DCB or AMAZE. Compared to the default dcraw's AHD, DCB and AMAZE produce what seems to me to be a somewhat more film-like, less "digital" grain in the interpolated image. If the image has strong diagonals, I use AMAZE. So on the basis of available interpolation algorithms, I can narrow my list of potential floating point dcraw replacements down to darktable, Photivo, and Rawtherapee.
However, in most cases distinguishing between one interpolation algorithm and another requires moderate to extreme pixel peeping. So the available interpolation algorithms may or may not be a relevant factor for you, given your workflow, your camera, and especially your pixel-peeping habits. Just because a raw processor doesn't provide a long list of available interpolation options, doesn't mean it's not an excellent raw processor.
Ways to track and avoid clipped pixels
I really, really dislike dealing with clipped pixels. So I want to make sure that I don't introduce clipped pixels into an interpolated image, other than any pixels that were already clipped in the raw file. (I try to avoid clipped pixels in the raw file, too, but that is another topic altogether.)
There are two commonly used ways of tracking clipped pixels and one very important way to avoid introducing additional clipped pixels (beyond what was already clipped in the raw file):
- A raw histogram shows you whether you indeed have any clipped pixels in the raw file.
- A clipped pixel indicator allows you to see exactly where the clipped pixels are located in the interpolated image.
- True raw exposure compensation allows you to set white balance multipliers and/or use a poorly made custom camera profile without introducing additional clipped pixels.
|Raw histogram?||no||? (1)||? (1)||? (1)||no (2)||✓||✓|
|Clipped pixel indicator?||no||✓ (3)||✓||✓||✓ (4)||✓||✓|
|True raw exposure comp?||✓||✓||✓||✓||✓ (5)||✓||no (6)|
- I was not able to decipher what kind of histogram darktable, the digiKam raw processor or Photivo provide. darktable seems to provide a histogram based on the input profile, with no regard to the output profile. Photivo provides three different histograms: linear, preview, and output, but "linear" doesn't seem to be the same as "raw".
- Rawstudio only provides a histogram of the interpolated image (not the raw image) in one of the following preset output spaces: sRGB, AdobeRGB, or ProPhotoRGB.
- darktable has a clipped pixel indicator, but it's not clear to me whether it's for the image with just the input profile applied, or for the image after it's been converted to the output profile. When I figure it out, I'll amend this article.
- Rawstudio has an exposure mask that nicely shows clipped highlight pixels, but not clipped shadow pixels.
- When using a custom ICC profile, the Rawstudio exposure compensation slider seems to provide true raw exposure compensation. When using a Rawstudio DCP profile, the resulting histogram (and eventual output) seems to indicate that the exposure compensation slider is no longer providing true raw exposure compensation. However, further investigation revealed that when using DCP, Rawstudio applies a "film curve" that severely compresses highlight detail.
- UFRaw 0.18 and before had a serious issue with clipped pixels caused by its apparent lack of true raw exposure compensation. UFRaw 0.19 seems to have considerably mitigated this issue; however, I'm not sure whether UFRaw 0.19 now has true raw exposure compensation or not, because there is still a tiny peak in the highlights of my "highlights" test raw file.
Raw histogram to show whether pixels are clipped in the raw file
Histograms are a visual representation of the distribution of red, blue, and green channel pixel values. The point of a raw histogram is to show you whether you really have clipped pixels in your raw file. During raw file interpolation, and even more so during post-interpolation image enhancement, it is all too easy to create an output image that has clipped pixels, when the raw file itself doesn't actually have any clipped pixels:
The standard by which all raw histograms should be measured is Rawnalyze. Among other useful features, Rawnalyze shows the "long tail" of highlight pixels by setting the height of "only 1 pixel in a bin" to a size tall enough to actually see. Rawnalyze also allows you the option of seeing where all the clipped pixels are located:
Among the raw processors reviewed on this page, it seems that only Rawtherapee and UFRaw provide a raw histogram. None of the raw processors have histograms (raw, output, or otherwise) that show the "long tail" of clipped highlight pixels, which somewhat limits the usefulness of having a histogram.
Clipped pixel indicator
If you are trying to set raw exposure compensation to avoid clipping any pixels that weren't already clipped in the raw file, a clipped pixel indicator is absolutely necessary. Ideally it would be possible to toggle between showing clipped pixels in the raw file and clipped pixels in the output image.
True raw exposure compensation
"True raw exposure compensation" means access to the equivalent of the dcraw "-S" switch. What this means mathematically is the ability to scale the interpolated raw RGB values so they all fit within a specified maximum value (eg 65535 for 16-bit integer values, 255 for 8-bit integer values, and 1.0 for floating point values; or some smaller maximum value may be required for poorly made camera profiles).
True raw exposure compensation is useful in (at least) the following situations:
- When making multiple "faux HDR" interpolated image files from one raw file.
- When white balance multipliers push one or more channels over the camera sensor saturation value:
When using white balance multipliers that push one or more channels over the camera sensor saturation value, not having true raw exposure compensation means risking a loss of channel information:
- When using certain poorly made camera profiles:
The Argyllcms "xicclu" utility can be used to graph which RGB values correspond to which XYZ "Y" values. For some camera profiles, "max Red", max Green", and/or "max Blue" is less than 100 on the xicclu graph. These "max" values represent those R, G, and B values for which the corresponding XYZ "Y" value equals 1 (which corresponds to an RGB value of 255 on an 8-bit scale, or 65535 on a 16-bit scale). When using a profile of this type, after converting from your camera profile to a standard working space, you will have clipped pixels anywhere the pre-conversion RGB values were greater than "max Red", max Green", and/or "max Blue":
For me, true raw exposure compensation is so important that not having it is sufficient reason to exclude a raw processor from further consideration. Except for UFRaw (versions of UFRaw more recent than 0.18 have at least partially mitigated this problem), all the raw processors reviewed on this page do provide true raw exposure compensation. However, there is quite a bit of inconsistency in the provided interfaces. Details are in the gray box below:
Options related to radiometrically correct output
As already stated, my raw processing goal isn't to produce a final, enhanced image. Rather I want radiometrically correct output, which means the channel values in the interpolated image are proportionate to the amount of light that was recorded in the raw file, which in turn means:
- No image enhancing algorithms have been applied to the image.
- The camera profile is not a "look" profile. That is, it doesn't of itself enhace the image by altering image colors and tonality.
- Channel information isn't lost from any default ICC profile conversions through CIELAB or a standard RGB color space such as the ProPhotoRGB color space.
Also, I use Argyllcms to make custom camera profiles, so it's important to me that a raw processor allow me to use a custom camera profile.
|All image enhancements can be disabled?||✓||✓||✓||✓||✓||✓||✓|
|Linear gamma raw color output?||✓||✓||no (1)||✓||?||✓||✓|
|Use linear gamma, simple matrix ICC camera profiles, and also custom camera profiles?||✓||✓||no (1)||✓||✓ (2)||✓ (3)||✓|
|Use Dng Camera Profiles (DCP)?||no||no||no||no||yes||yes||no|
|By default process images thru a bounded mode ICC profile conversion?||no||no||no||yes||yes||yes||no|
- The digiKam raw processor can use a custom ICC camera profile and it can output a raw color image file. But it is hard-coded to use the default dcraw sRGB-like tone curve during raw processing, and so cannot use a linear gamma camera profile and cannot output a linear gamma raw color image file. Technically speaking, radiometrically correct output doesn't require that the camera input profile use a linear gamma tone curve, because the tone curve and the camera profile are applied after raw processing. However, hard-coding a raw processor to use an sRGB-like tone curve complicates making a custom camera profile, and I've never gotten around to creating a custom camera profile just for use with the digiKam raw processor.
- Rawstudio allows the use of a custom camera matrix profile, but doesn't provide access to the dcraw default camera matrix.
- Rawtherapee allows the use of a custom camera matrix profile, and also the use of "standard" dcraw default matrix profiles, except that some of the default matrix profiles have been replaced by "enhanced" profiles; I don't know what "enhanced" might mean.
All image enhancements can be disabled?
"Radiometrically correct output" requires that all post-interpolation image enhancement options must be disabled. All the raw processors reviewed here can output radiometrically correct images, though "how" is not always obvious and can require a good deal of poking around to accomplish. The problem is, the more processing options a raw processor provides, the more complicated the gui needs to be. Fortunately, the three raw processors that offer the most processing options — DarkTable, Photivo, and Rawtherapee — also allow you to save and load presets:
- darktable allows you to completely deactivate any modules you don't want to use, so you don't even have to look at them, and also allows you to store presets for the remaining modules. darktable indicates the active modules with a (not especially visible) icon that can be clicked to disable the module in question.
- Photivo signals where to look for active enhancement options by lighting up a bright blue "button" and also provides a "Neutral_absolute.pts" preset which disables all the image enhancement algorithms.
- Rawtherapee provides a "Neutral Processing Profile" that conveniently disables most, but not all, enhancement algorithms. So after you choose the "Neutral Processing Profile", to get radiometrically correct output you need to go through and check every single image enhancing option to make sure they are all disabled, and then save a custom processing profile.
Use linear gamma, simple matrix ICC camera profiles?
All of the default dcraw/Adobe camera matrices, are simple linear gamma matrix ICC camera profiles and can be used to produce radiometrically correct output (though many people feel that the resulting color is anemic). Except for Rawstudio (and possibly Rawtherapee, which seems to have replaced some of the default matrix profiles with "enhanced" matrix profiles which hopefully are still simple matrix profiles), all the raw processors reviewed on this page provide the choice of using the default dcraw/Adobe camera matrix profiles.
I don't use the Adobe matrix for my camera. Instead I use a custom ICC camera profile created with the open source program Argyllcms. All the raw processors reviewed on this page allow the use of custom camera ICC profiles, and all of them except the digiKam raw processor can use a linear gamma camera profile.
Allow linear gamma raw color output?
Raw color output is what you get when the raw file has been interpolated, but no camera profile has been applied to the image and no conversion to a standard working space (eg sRGB, ProPhotoRGB) has been performed. Regular dcraw lets you output raw color by choosing the "-o 0" option. My floating point dcraw only outputs raw color. Rawtherapee provides a button for outputting raw color. I haven't found the procedure (if there is one) for the other raw processors. But in reality most raw processors allow you to get raw color, by means of a trick:
- Assign your desired input profile and set all the raw processing options to the values that you want.
- Now go back and change the input profile to sRGB. Set the working space to sRGB (or to any larger color space). And set the output color space to sRGB. Use the exact same profile for the input profile and the output color space, preferably a linear gamma version of sRGB. Now the image will look washed out.
- Output the washed-out looking image. It will have the sRGB color space embedded, so you need to assign your preferred linear gamma custom camera input profile, at which point the proper colors and tonality will reappear. Or use the image "as is" when using Argyllcms to profile your camera (the Argyll command line utilities will ignore the embedded sRGB profile).
You can't use the above procedure with digiKam because digiKam requires a camera input profile with an sRGB-like tone response curve (I don't think it's exactly an sRGB tone response curve, but it's close).
Use Dng Camera Profiles (DCP)?
Everyone is entitled to an opinion. I don't like Dng or Dng Camera Profiles (DCP). Dng is a proposed answer to the serious problem of proprietary raw formats, and possibly I will like Dng a little more if/when the dng specification is placed under the control of a suitable standards organization, rather than being subject to the Adobe DNG Specification Patent License. But I still won't like DCP because DCP "profiles" by design alter color and tonality and by accident can cause the loss of channel detail that was contained in the raw file.
A DCP "profile" starts with a real linear gamma camera matrix profile, uses that matrix profile to convert to ProPhoto (thus clipping any channel information that doesn't fit inside the ProPhotoRGB color gamut), converts all the resulting image RGB values to "Hue, Saturation, Value" values, applies a look-up table to alter the HSV values, then converts the resulting image HSV values back to RGB/XYZ. For details, see Adobe Digital Negative (DNG) Specification, Version 220.127.116.11, June 2012, section on "Applying the Hue/Saturation/Value Mapping Table".
The net result? DCP deliberately alters scene-referred colors and tonality in order to create "pleasing colors" or to imitate the "look" of different films or different proprietary camera raw processors, which is wonderful if that is what you want to do.
For an introduction to DCP, see "DNG Profiles and Profile Editor". For an overview of some of the potential problems with using DCP, see "Hue Twists in DNG Camera Profiles", and "Visualizing DNG Camera Profiles Part 1" (parts 2 and 3 are worth a read, also). Finally, there are several interesting tests on how well DCP works in practice as a camera profile at Le pagine di Gialandra.
By default process images thru an ICC profile conversion?
Some raw processors by default do ICC profile conversions, even if you don't ask for any image enhancements and even if your input and output color spaces are exactly the same. The problem with a processing pipeline that by default always includes an interim ICC profile conversion is that — depending on the camera input profile, the actual scene, the white balance, and so forth — interpolated image files sometimes have color gamuts that don't quite fit inside any of the regular RGB working spaces and also don't fit inside the CIELAB or XYZ color spaces. The picture below illustrate the problem:
Of course an image's channel information looks different, depending on what color space it's in. But if the image color gamut fits comfortably inside the destination color space profile, theoretically there should be no loss of channel detail after performing a round-trip ICC profile conversion. However, in reality, after converting the yellow flower image from the camera profile to ProPhoto and then back to the camera input profile (#4 above, lower right), there is a visible loss of blue channel detail.
Where did the Blue channel detail go? After applying my camera's custom ICC matrix profile to the interpolated yellow flower image, there is a color gamut mismatch between the flower image's color gamut and the ProPhoto color gamut. There is also a color gamut mismatch between the flower color gamut and both CIELAB and CIEXYZ, because converting to either of these reference color spaces will cause some values fall outside of predefined ranges (eg negative XYZ values or a* and b* values beyond the provided encoding limitations). Upon conversion to ProPhoto, out of gamut colors (in the ProPhoto color space and also in the XYZ profile connection space) are clipped unless unbounded mode ICC profile conversions are used. You don't get the clipped colors back just by converting back to the original color space.
I posted this review in October, 2012, using darktable 1.0.5. At that time I said that it looked like darktable ran the image through the ProPhoto color space by default, even when the the camera input profile is also selected as the output profile. Upon rechecking in November, 2013 using darktable 1.2.3, it's obvious that darktable does not run the image through any interim bounded mode ICC profile conversions.
I really hate it when I make mistakes, so I rechecked all the raw processors considered in this review, except for Rawstudio (Rawstudio throws errors when trying to install from Gentoo portage). When my custom camera input profile is chosen to be the input profile and also the output profile for the yellow flower image:
- darktable and UFRaw do not clip the yellow flower's Blue channel detail.
- Photivo and Rawtherapee do clip the yellow flower's Blue channel detail. So somewhere these two processors are doing an interim (and completely gratuituous and unnecessary, given that the input and output profile were identical and all image enhancements were disabled when processing the yellow flower raw file) ICC profile conversion.
- Rawstudio (as of October, 2012) doesn't allow you to choose the camera input profile as the output profile. The largest output color space allowed by Rawstudio is ProPhoto, which means the yellow flower's Blue channel detail necessarily is clipped upon output.
As an aside, some non-floss raw processors also destroy blue channel information. See this Cambridge in Color forum thread on Viable alternatives to Photoshop, where one photographer refers to "the ACR converter's nasty habit of clipping the blue part of the yellows to zero while decoding raw data into it's working space".
This problem of clipped channel detail during raw processing, even when the input and output color spaces are both set equal to the input camera profile, is a function of how saturated the image is, as interpreted by the camera input profile, as well as whether the raw processor by default pushes the image through interim bounded mode color space conversions. I've seen clipped channel detail in saturated greens and oranges as well as saturated yellows. With less saturated images, clipping from interim ICC profile conversions isn't a problem regardless of which raw processor you use.
Summary and conclusions:
floating point dcraw, DarkTable, Photivo, Rawtherapee
The table below gives a summary of all the raw processor features considered above, and assigns a point value according to how important the feature is when the goal is outputting radiometrically correct interpolated raw files:
|Points for:||floating point dcraw||darktable||digiKam||Photivo||Raw-
|1. White balance options (30 points)|
|Spot white balance||20||20||0||20||5 (2)||15 (3)||10|
|2. Available interpolation options (20 points)|
|3. Ways to track and avoid clipped pixels (30 points)|
|True Raw Exposure Compensation?||20||20||20||20||20||20||0|
|Clipped pixel indicator?||0||5 (4)||10||10||5 (5)||10||10|
|4. Radiometrically correct output (20 points)|
|Default CIELAB/ProPhoto conversion? (5)||-0||-0||-0||-10||-10||-5||-0|
|Use linear gamma matrix ICC profile?||10||10||0||10||10||10||10|
|Linear gamma raw color output?||10||10||0||10||0||10||10|
|4. Bonus for OpenEXR output (10 points)|
|32-bit floating point OpenEXR output?||0||10||0||0||0||0||0|
|Total points out of 100: (6)||90||95||50||90||30||80||50|
- Disabling all image enhancements is absolutely necessary for outputting radiometrically correct images. All the raw processors reviewed here allow you to disable all image enhancements, so I didn't put this crucial item in the Summary table. Also, although I think a raw histogram is a important feature that every raw processor should have, I didn't include having or not having a raw histogram in the Summary table because none of the raw processors reviewed on this page have histograms that show the "long tail" of clipped pixels.
- Even though Rawstudio offers spot white balancing, it only uses a single pixel to set the white balance, which is simply not adequate for setting a reliable white balance, so I only gave it 5 points out of 20.
- Rawtherapee restricts the size and shape of the white balancing "box" to a square with a maximum of 32x32 pixels, which can present a problem when trying to select a narrow strip of pixels in a noisy image, so I gave it 15 points out of 20.
- The darktable clipped pixel indicator seems to show clipped pixels for the image in camera input color space, not the output color space; also, so far I haven't found any way to show individual channel clipping information, so I gave it 5 points out of 10.
- The Rawstudio clipped pixel indicator shows clipped highlight pixels, but not clipped shadow pixels, so I gave it 5 points out of 10.
- Circumventing default CIELAB or ProPhoto color space conversions is cumbersome, so I took off points if the raw processor by default runs the image through an unnecessary color space conversion. The "work-around" is to output raw color. Rawtherapee provides a convenient button for outputting raw color, which makes the "work-around" less cumbersome.
- All of the raw processors reviewed on this page are very good raw processors, so the "points out of 100" numbers should not be taken too seriously or out of context. In particular:
- Even though UFRaw only scored 50 points, when I want fast, enhanced (not radiometrically correct) output, I use UFRaw with its base tone curve.
- I have very little experience using Rawstudio, but it's obvious from the limited testing that I've done, that someone with a very different workflow than my own would find Rawstudio to be fast, convenient and very user-friendly.
- I quite like the digiKam raw processor interface, even though the lack of spot white balancing is a deal-breaker for me (but not necessarily for you, given your workflow). Also, the digiKam raw processor is capable of producing output that will be radiometrically correct output as soon as it's converted to a suitable linear gamma working space. So the "by the specs" points total is not entirely fair to digiKam.
My personal goal in writing this review was to see if there is a gui raw processor is more convenient to use than my floating point version of dcraw, and that gives results that are at least as good as my floating point version of dcraw. So far I've only examined features rather than actual output. On the basis of features, I can exclude some of the raw processors from further consideration:
- The digiKam raw processor can be excluded primarily because it can't do spot white balancing and also because it can't use a linear gamma camera profile.
- Rawstudio can be excluded because its spot white balancing only uses a single pixel, it can't output raw color, and it doesn't include the DCB or AMAZE interpolation algorithms.
- UFRaw can be excluded because it doesn't provide true negative exposure compensation (update: UFRaw 0.19 has at least partially mitigated this problem) and because it doesn't include DCB or AMAZE interpolation algorithms.
darktable, Photivo, and Rawtherapee all look promising. However, the true test of a raw processor isn't how it stacks up "by the specs", but rather how well it processes raw files. Part 2 of this review will compare actual interpolation results.
Note: Open source software changes rapidly. The raw processors reviewed on this page are all under active development. This review was initially written in October, 2012 using darktable 1.0.5, the digiKam 2.9.0 raw processor, Photivo 2012-09-30, Rawstudio 2.1-svn4282, Rawtherapee 4.0.9, UFRaw 0.18, and several versions and variants of dcraw. It was most recently updated in November, 2013, using the latest versions of each raw processor as available from Gentoo portage.