skip to main content

Floating Point Dcraw + DCB, AMaZE, LMMSE, AFD, & VCD
Part 1: Floating point processing — What software was that?

I've always hankered after a floating point version of dcraw. As nobody else was obliging enough to code one up for me, I coded it up myself and I'm sharing it with you.

Written in 2011.

Using an artificial test target, the article Festina Lente on the LibRaw website shows a startling difference in AHD interpolation done with floating point processing, compared to the usual integer processing. The floating point output has far fewer mazing and color artifacts. Festina Lente concludes with an invitation to "Try it, and you will see". But alas, the article doesn't mention the name of the software used to do the interpolations and no-one seemed willing to tell me when I asked.

Further investigation (that is, searching the dpreview forums threads) suggests that the software used to produce the floating point AHD interpolation of the test target might have been the closed-source, MacIntosh only "Raw Photo Processor", which leaves this Linux-using pixel-peeper out in the cold, so to speak.

Not to be discouraged, I decided to try my hand at modifying dcraw to use floating point math. It took me about two weeks (I'm not an experienced c coder), plus another week to make my floating point code useable for (some, but not all) cameras other than my own Canon 400D.

(By the way, if you have or know of another floating point version of dcraw "floating around" I would love to hear from you, but I couldn't find one.)

Is floating point processing really better?

Artificial target shots

The Festina Lente test target ("porcupine.dng") can be downloaded at the bottom of a very interesting LibRaw article comparing how different interpolation algorithms handle Bayer moire. The actual test target itself (what a perfect interpolation would look like) is pictured at the top of the Bayer Moire article, with a link to a full-resolution version of the test target. The AHD floating point and integer versions pictured in the Festina Lente article likewise link to full resolution images.

Unfortunately, so far I have failed to get AHD floating point processing to work properly (it segmentation faults). However, as luck would have it, in a dpreview forum thread discussing Festina Lente, there is a comparison of AHD interpolation of the porcupine.dng target using integer and floating point version of RawTherapee. That comparison did find differences, though not nearly as extreme as the differences in the Festina Lente article. (In case you haven't heard the news, RawTherapee now uses floating point processing!).

Wanting to investigate further, I made an integer version of dcraw, "dcraw-dcb-integer", that includes DCB in addition to the usual dcraw interpolation algorithms. Compared to DCB integer output, the DCB floating point version of DCB produced a very slightly (not drastically) cleaner rendition of the test target.

Read world (camera-generated) raw files

Truth be told, I'm enjoying using dcraw-float more because now I have command-line access to some really great interpolation algorithms, than because dcraw-float uses floating point processing.

One of these days (don't hold your breath) I'll make some comparisons between integer and floating point processing. When I'm done, I'll post them on this page. Based on what I've seen so far, and at least with my Canon 400D raw files, I'm inclined to conclude that in most real-world images, you will be hard-pressed to find photographically significant differences between an image processed using floating point and integer versions of the same algorithm.

One place where there might be potentially photographically significant differences between floating point and integer processing is in deep shadow areas. I've seen some differences in highlight detail, but I suspect that is more because of how my dcraw-float code handles sensor saturation and interpolation "clipping points", rather than because my code uses floating point processing.

The image on the left, processed with dcraw-float, clearly has fewer blown highlights than the image on the right, which was processed with regular dcraw. But I think the difference has more to do with how dcraw-float handles highlights, than with the fact that dcraw-float uses floating point processing.

More information about my floating point version of dcraw with DCB, AMaZE, LMMSE, AFD, and VCD

Once I got deep enough into the dcraw code to make the necessary modifications to switch from integer to floating point processing, it was relatively easy to add in (also in floating point) some of the great new processing algorithms that people have produced in the last few years.

Having produced a floating point version of dcraw that also includes DCB, AMaZE, LMMSE, AFD, and VCD, it occurred to me that other die-hard dcraw command-line users (I can't be the only one left) might also be interested in using or further modifying my code. Hence this article. However, before you get too excited, my floating point code requires that you use a custom camera profile and it doesn't work with every camera (for sure it won't work with Foveon cameras).

If you'd like to know more about floating point dcraw + DCB, AMaZE, LMMSE, AFD, & VCD, see Parts 2, 3, and 4 (you are reading Part 1 right now).

"Part 2: How to use dcraw-float" explains the differences between dcraw-float and the default dcraw command line options. Some highlights:

If you want to know how the dcraw-float floating point c code works, see "Part 3: Overview of the dcraw-float floating point c code". Highlights include:

"Part 4: The legal stuff — dcraw-float license, limitations, source code" gives license information for dcraw-float, discusses the code's purpose and limitations, provides links back to the various source codes that I used when writing dcraw-float, and provides download links and compilation instructions for the dcraw-float and dcraw-dcb-integer source code.