Decoding raw digital photos in Linux

Welcome! If you are wondering how to connect your digital
camera and download images to a Linux PC, go to the
gPhoto homepage.
My software is for processing those images after
downloading them.

If you're downloading JPEG files, you don't need my software
at all. The image has already been processed inside the
camera. Almost all digital cameras made since 1997 produce
JPEG images, so why would you want to do it any other way?

Well, despite the convenience and ubiquity of JPEG, there are
some disadvantages. JPEG is a lossy format -- to fit a big
image into a small file, a lot of information is thrown away.
That's why midrange and high-end digital cameras offer an
alternative: Raw, unprocessed CCD data files, for which the
camera manufacturer provides special decoding software.

Of course this software is for Windows and Macintosh only,
with no source code. So it's useless to users of other
operating systems, programmers hoping to design a better
interpolation algorithm, and historians not yet born in an
era when the only Windows machines will be in museums.

So here is my mission: Write and maintain an ANSI C program
that decodes any raw image from any digital camera on any
computer running any operating system.

That program is called dcraw
(pronounced "dee-see-raw"),
and it's become a standard tool within and without the
Open Source world. It's small (about 9000 lines), portable
(standard C libraries only), free (both "gratis" and "libre"),
and when used skillfully, produces better quality output
than the tools provided by the camera vendor.

Here's my resume.
I do freelance consulting related to dcraw, and I'm also
available for full-time software work in the Northeast USA.

I can be reached by sending e-mail to cybercom dot net with
the username "dcoffin".

My Code

Unless otherwise noted in the source code, these programs are free
for all uses, although I would like to receive credit for them.
Donations are welcome too, if you're making money from my code.

Note to Linux distributors: The only executable files that
should be installed by a dcraw package are "dcraw", "clean_crw",
and maybe "fuji_green", "fujiturn", and "fujiturn16". My shell
scripts are dangerous and should only be installed in a "doc"
directory without execute permission.

To build a unilingual, self-contained DCRAW.EXE for DOS/Windows,
use a source file from this directory instead.

To add another language, send me translations of
this manpage and
this message table
in UTF-8 encoding.
Translate only from my original English and Esperanto texts --
other languages may contain factual errors invisible to me.

Do not translate "Cannot do X" as "It is impossible to do X".
Dcraw is not perfect, so if it cannot do something, that does
not mean that the task is impossible. Computers must never use
the pronoun "I", so write "dcraw cannot do X".

When in doubt, translate everything. I proofread these texts
before releasing them, and it's much easier for me to correct
over-translation than under-translation.

Dcraw has made it far easier for developers to support a wide
range of digital cameras in their applications. They can call
dcraw from a graphical interface, paste pieces of dcraw.c into
their code, or just use dcraw.c as the documentation that camera
makers refuse to provide:

Ostensibly to stop memory leaks, Microsoft decided that programs
using the old MS-DOS API, including anything compiled with
DJGPP,
shall be confined to 32MB of memory.
This limitation can be removed by some combination of service packs
and registry hacks, or you can compile dcraw to use the newer Win32 API.
Thomas Nicely (of Pentium FDIV fame) has a
page describing the problem and various workarounds.

For the latest cameras, I get samples from
Photography Blog.
A "Full Review" at
Imaging Resource
usually includes a few raw shots.
www.rawsamples.ch
is no longer updated, but it has samples from older cameras.
For $800, I sell a complete test suite on six DVDs containing
every camera supported by dcraw, and provide web-based updates
for $300/year.

I'm designing a digital camera. How do I convert its raw
photos into something that dcraw and Adobe Photoshop can open?

Any algorithm that combines each pixel with its neighbors is
going to have problems near the edges. C code is cheap, so dcraw
applies a different algorithm to edge pixels. Hardware logic is
expensive, so cameras crop off the edge pixels after processing.

I shot a raw photo with no light. Why does it appear
all noisy, when it should be solid black?

No matter how dark an image is, dcraw's auto-exposure stretches
it so that one percent of its pixels appear white. The "-W" option
avoids this behavior.

I bracket plus/minus two stops, but all five shots look
almost the same in dcraw. Why?

See the previous question.

Why is 16-bit output dark / unreadable?

If you want pretty pictures straight out of dcraw, stay with
8-bit output. 16-bit linear output is the best raw material
for professional image editors such as
Photoshop and
CinePaint,
but it's no good for most image viewers.

What does the "-f" (four color RGB) option do?

If you see patterns like this
or this in your output images, first
try "dcraw -a". If these patterns persist, use "dcraw -f" to
get rid of them.

I have decided that dcraw shall be a command-line program
written in C, and that any further abstraction layers must be
added around this core, not inside it.

Library code is ugly because it cannot use global variables.
Libraries are more difficult to modify, build, install, and
test than standalone programs, and so are inappropriate for
file formats that change every day.

Take a three-color RGB image. At each pixel, set two color
values to zero.

Reconstruct the original three-color image as best you can
from the remaining one color per pixel.

Dcraw currently gives a choice of four methods:
Bilinear, Variable Number of Gradients (VNG),
Patterned Pixel Grouping (PPG),
and Adaptive Homogeneity-Directed (AHD).

The Foveon X3 Capture chip requires a different kind of interpolation.
Unlike CCD arrays, it captures three colors at every pixel location.
But the colors are not well separated, so the raw data looks very gray.
Much processing is needed to enhance color while suppressing noise.