<sect2 id="editor-cm-rawfile">
    <title>The Camera Profile and Raw File Development</title>

    <sect3>
        <title>What's the next step in color management? </title>

        <para>
            First and for the record, many excellent professional and amateur photographers save all their images as in-camera jpegs and work exclusively in the sRGB color space. But if you want to work in a larger color space, or if you want to work with raw files (even if you output sRGB image files from your raw files), read on.
        </para>

        <para>
            Judging from questions asked in the &digikam; user's forum, if you are reading this tutorial you probably are shooting raw images with a digital dSLR and you are hoping that somewhere in the arcane waters of color management lies the answer to how to get a nice picture from your raw image file. And you're right! The next thing you need is the right camera profile for developing your raw image. But first let's answer the question you really might have been asking.
        </para>

    </sect3>

    <sect3>
        <title>
            Why doesn't the image produced by raw converters like dcraw or ufraw look like the embedded preview displayed by digikam?
        </title>

        <para>
            Glad you asked. All digital camera images start out as raw files, whether or not the camera allows the user the option to save the image as a raw file. When you ask the camera to save jpegs instead of raw files, the camera uses its on-board processor to convert the raw file to a jpeg. That embedded preview is what your final image would have looked like if you had set your camera to save jpegs instead of raw files.
        </para>

        <para>
            From here I will speak from my experience as a Canon user, but I will guess that most or all entry-level and mid-range dSLRs behave in a similar manner. Canon offers the user several picture styles - neutral, standard, portrait, landscape, and so forth - that determine what kind of processing will be done to the raw image file to produce the final image, whether or not the processing is done "in-camera" or later, using the proprietary Canon DPP software. The Canon DPP raw processing software does give the user additional control, but still manipulates the raw image file in accordance with the chosen picture style. Most of the Canon picture styles add a heavy S-curve and extra color saturation to give the picture more "pop". Even if you choose the "neutral" picture style (the Canon picture style that gives you the least modified tonality); and select "less contrast", "less saturation", "no noise reduction", and "no sharpening" in the DPP raw development dialog, you will find, if you know what to look for, that an S-curve and also shadow denoising has been applied to your image.
        </para>

        <para>
            Libraw (which &digikam; uses to convert raw files to image files) doesn't add an S-curve to your image tonality. Libraw gives you the lights and darks that are actually recorded by the camera sensor. According to <ulink url="http://21stcenturyshoebox.com/essays/scenereferredworkflow.html">Tindeman</ulink>, an excellent read and source of good advice, with links to equally good sources of additional information, dcraw is one of only a handful of raw developers that actually gives you the "scene-referred" tonality. Ufraw also produces a scene-referred image by default (although ufraw gives the user the option to modify the scene-referred image by changing the tonal distribution and saturation). And the dcraw/ufraw scene-referred image IS flat-looking, because the camera sensor records light linearly, whereas our eyes are constantly interacting with our brain to accommodate dim and bright areas in a scene, meaning our brain to some extent "applies an S-curve" to the scene to enable us to better focus in on the areas of particular interest as we look around
        </para>

    </sect3>

    <sect3>
        <title>
            The embedded jpeg preview looks so much nicer than dcraw's output. What is the value in scene-referred tonality?
        </title>

        <para>
            When you take a picture, presumably you have an idea of what you want the final image to look like. It is much easier to achieve that final image if you don't have to "undo" stuff that has already been done to your image. Once Canon (or Nikon, or Bibble, &etc;) has applied their proprietary S-curves and shadow-denoising, sharpening, &etc; to your image, then your shadows, highlights, edge detail, &etc; are already squashed, clipped, chopped, and otherwise altered and mangled. You've thrown information away and you cannot get it back. Especially in the shadows, even with 16-bit images (actually, 12- or 14-bits, depending on the camera, but it's encoded as 16-bits for the computer's convenience), there just isn't that much information to begin with.
        </para>

        <para>
            It seems to me that the heart and soul of image processing is the deliberate manipulation of image tonality, color, selective sharpening, and so forth, such that the viewer focuses in on what you, the photographer, found of particular interest when you took the picture. Why give the art of image processing over to some proprietary raw processing software?  In other words, "flat is good" if you'd rather give your images your own artistic interpretation. The alternative is to let the canned, proprietary algorithms produced by Canon, Nikon, Bibble, &etc; interpret your images for you. (On the other hand, there is no denying that for many images, those canned algorithms are really pretty good!)
        </para>

    </sect3>

    <sect3>
        <title>
            I can see the value in starting my image-editing with a scene-referred rendition instead of the eye-popping rendition that I see in the embedded jpeg. But I'm telling you, the images produced by digiKam/libraw look really really bad! Why?
        </title>

        <para>
            Well, that depends. If the image looks very dark, then you asked dcraw to output a 16-bit file and you have run into a problem with dcraw not applying a gamma transform before outputting the image file. You can use imagemagick to apply the appropriate gamma transform to the image file produced by Libraw. Or you can find or make a camera profile with a gamma of 1. Or you can use ufraw, which applies the gamma transform for you.
        </para>

        <para>
            If your image has pink highlights, there's a solution. For an explanation of the problem, along with the command line cure for this problem, see <ulink url="http://www.luminous-landscape.com/forum/index.php?topic=23430.0">this "Luminous Landscape" forum post</ulink>.
        </para>

        <para>
            If the image isn't dark but it looks really weird, probably you made some injudicious choices in the Libraw user-interface.   The Libraw interface conveniently allows you to "dial in" options that you would otherwise have to specify at the command line. However, convenience always comes at a price.  First, the interface might not provide access to all the options that are available at the command line. And second, to get the most from the Libraw interface, you have to know what the buttons, sliders, &etc; in the interface actually do. Which means you need to know what happens at the command line if you want to get the best results from using the interface. (This tutorial will not attempt to document how to use the Libraw user interface. Digikam is developing at a rapid pace and anything I might write about the Libraw interface will surely be outdated in the near future.)
        </para>

        <para>
            For example, if your embedded jpeg has very nice deep rich shadows but the Libraw-produced jpeg or tiff has blotchy red line patterns in the shadow areas, then you probably put an "x" in the "Advanced, Black point" option, with the slider set to 0. Uncheck the Black point box and try again. This box in the Libraw interface corresponds to the "-k" option when using dcraw at the command line. The "-k" option allows you to override dcraw's best estimate of where, in the shadow tones of your image, does digital signal start to override background noise. If you don't use the "-k" option at the command line, then dcraw calculates an appropriate value for you, based on its estimate of background noise. For my Canon 400d/xti, the dcraw-calculated background noise value is usually around 256 (the command line option "-v" will tell dcraw to tell you what it's doing as it processes your raw file). If, however, I use the "-K /path to blackframe.pgm" option to tell dcraw to subtract out a black frame, then dcraw will report the black point as "0", as there is now no need to set it higher to avoid the deepest shadows in the image, where noise typically drowns out signal. (A "black frame" is an exposure taken with the lens cap on, with the same exposure settings as, and ideally right after, taking the image being processed. The "-K" option allows dcraw to subtract background noise from the image.)
        </para>

    </sect3>

    <sect3>
        <title>Where do I find good information on digital noise?  </title>

        <para>See the following excellent articles:</para>

        <itemizedlist>

            <listitem><para><ulink url="http://www.ronbigelow.com/articles/noise-1/noise-1.htm" /></para></listitem>

            <listitem><para><ulink url="http://www.cambridgeincolour.com/tutorials/noise.htm" /></para></listitem>

            <listitem><para><ulink url="http://www.clarkvision.com/imagedetail/digital.signal.to.noise/" /></para></listitem>

        </itemizedlist>

    </sect3>

    <sect3>
        <title>Why are the Canon and Nikon colors better than the colors produced by Libraw?</title>

        <para>
            Color rendition is one place where the Canon (and presumably Nikon) proprietary raw developing software does a really, really good job. Why?  Because the proprietary raw processing software is coupled with camera profiles that are specific to raw images coming from your make and model of camera, when processed using your make and model camera's proprietary raw processing software. I've checked extensively, using an "eyedropper" to  compare the output of various raw developers using various camera profiles from various sources - a very tedious though instructive process. With ufraw and dcraw (from the command line if not from digikam's dcraw user interface), you can apply Canon's camera-model-picture-style-specific color profile(s) to the dcraw output during the raw development process, and the colors will still NOT be exactly the same as what Canon produces. Likewise, Bibble profiles work pretty well with the Bibble software, but they don't work quite as well, in my opinion, with Libraw as they do with Bibble's own software. And so on. And so forth.
        </para>

    </sect3>

    <sect3>
        <title>Why is a camera profile specific to a given make and model of camera? </title>

        <para>
            Digital cameras have an array of millions of little light sensors inside, making up either a CCD or a CMOS chip. These light-sensing pixels are color-blind - they only record the amount, not the color, of light falling on them. So to allow pixels to record color information, each pixel is capped by a transparent red, green, or blue lens, usually alternating in what is called a Bayer array (except for Faveon sensors, which work differently). A raw image is nothing more than an array of values indicating "how much light" passed through the red, blue, or green lens cap to reach the sensor.
        </para>

        <para>
            Clearly, pixel response to light is the result of lots of camera-specific factors including: the nature of the sensor array itself, the precise coloring/transmissive qualities of the lens caps, and the particular analog-to-digital conversion and post-conversion processing that happens inside the camera to produce the raw image that gets stored on the card.
        </para>

    </sect3>

    <sect3>
        <title>What does "analog-to-digital conversion" mean?</title>

        <para>
            "Analog" means continuously varying, like how much water you can put in a glass. "Digitizing" an analog signal means that the continuously changing levels from the analog signal source are "rounded" to discrete quantities convenient to the binary numbers used by computers. The analog-to-digital conversion that takes place inside the camera is necessary because the light-sensing pixels are analog in nature - they collect a charge proportionate to the amount of light that reaches them. The accumulated charge on each pixel is then turned into a discrete, digital quantity by the camera's analog-to-digital converter. Which by the way explains why a 14-bit converter is better than a 12-bit converter - more precision in the conversion output means less information is thrown away in the conversion process.
        </para>

    </sect3>

    <sect3>
        <title>
            Why is a camera profile specific to the raw processing program used to develop the raw file?
        </title>

        <para>
            The whole point of interpolation using demosaicing algorithms such as dcraw's default AHD is to guess what color and intensity of light actually fell on any given pixel by interpolating information gathered from that single pixel plus its neighboring pixels (see <ulink url="https://en.wikipedia.org/wiki/Demosaicing">Wikipedia article</ulink>). Every raw processing program makes additional assumptions such as "when is it signal and when is it background noise?",  "at what point has the sensor well reached full saturation?", and so forth. The resulting output of all these algorithms and assumptions that raw processing software makes is a trio of RGB values for each pixel in the image. Given the same raw file, different raw processors will output different RGB values.
        </para>

    </sect3>

    <sect3>
        <title>Where do I find a generic profile for my camera?</title>

        <para>
            The ufraw website <ulink url="http://ufraw.sourceforge.net/Colors.html">section on color management</ulink> has information on where to find ready-made camera profiles. If you poke around the &digikam; users forum archives, you'll find additional advice. If you keep hunting and experimenting, likely you will find a generic profile that works "well enough". However, as stated above, it's an unfortunate fact of digital imaging that the camera profiles supplied by Canon, Nikon, and the like don't work as well with raw converters other than each camera manufacturer's own proprietary raw converter. Which is why Bibble and Phase One, for example, have to make their own profiles for all the cameras that they support. So eventually you may decide that you want a camera profile that is specific to your camera, your lighting conditions, and your raw processing workflow.
        </para>

        <para>
            <screenshot>
                <screeninfo></screeninfo>
                <mediaobject>
                    <imageobject>
                        <imagedata fileref="&path;editor-cm-iccworkflowlogic.png" format="PNG"/>
                    </imageobject>
                    <textobject>
                    <phrase></phrase>
                    </textobject>
                </mediaobject>
            </screenshot>
        </para>

    </sect3>

    <sect3>
        <title>
            How do I get a camera profile specific to my camera, lighting conditions, and raw workflow?
        </title>

        <para>
            Many commercial services provide profiling services, for a fee, of course. Or you can use LPRof to profile your camera yourself. If you want to profile your own camera, you will need an "IT8 target", that is, an image containing squares of known colors. Along with the IT8 target, you will receive the appropriate set of known values for each square of color on the target.
        </para>

        <para>
            If you plan to use LProf to profile your camera, check the documentation for a list of recommended targets. To profile your camera, you photograph the IT8 target under specified lighting conditions (for example, in daylight, usually taken to mean noon on a sunny day in the summer, with nothing nearby that might cast shadows or reflect color casts) and save the image as a raw file. Then you process the raw file using your particular raw processing software+settings and run the resulting image file through the profiling software. The profiling software compares the RGB values in the image produced by your camera+lighting conditions+raw processing routine with the RGB values in the original target and then produces your camera (icc) profile.
        </para>

        <para>
            Profiling a camera is exactly analogous to profiling a monitor. When profiling a monitor, the profiling software tells the graphics card to send squares of color with particular RGB values to the screen. The spectrophotometer measures the actual color that is produced on the screen. When profiling a camera, the known colors are the RGB colors in the original patches on the IT8 target, which the profiling software compares to the colors produced by the digital image of the target, which was photographed in selected lighting conditions, saved as raw, then processed with specific raw processing software plus settings.
        </para>

        <para>
            <ulink url="http://lprof.sourceforge.net/help/ufraw.html">Here</ulink> is a link to a "how to" for using LProf v1.11 and ufraw (and by analogy, any other raw processor) to produce a camera profile. Debian Lenny has LProf 1.11.4 in the APT repositories. More recent versions can be built from CVS. And here is a link to an affordable, well-regarded <ulink url="http://www.targets.coloraid.de/">IT8 target</ulink>.
        </para>

    </sect3>

    <sect3>
        <title>
            How do I apply a camera profile to the 16-bit image file produced by my open source raw processing software?
        </title>

        <para>
            If you are using the Libraw interface, <ulink url="help:/digikam/using-setup.html#setup-iccprofiles">here</ulink> is how to tell &digikam; which camera profile to use. If you are using dcraw from the command line, you have the choice of outputting your 16-bit image file with or without the camera profile already applied. If you ask dcraw to output the file without applying the camera profile, you can use LCMS's tifficc utility (also at the command line) to apply the camera profile. The advantage of using tifficc is that you can tell LCMS to use high quality conversion (dcraw seems to use the LCMS default medium). The disadvantage, of course, is that applying your camera profile from the command line adds one extra step to your raw workflow. If you are using ufraw, consult the ufraw user's guide.
        </para>

    </sect3>

</sect2>

<!--
Local Variables:
mode: sgml
sgml-minimize-attributes:nil
sgml-general-insert-case:lower
sgml-indent-step:0
sgml-indent-data:nil
End:
-->
