<sect2 id="editor-cm-connection"> <title>The Color Space Connections</title>

    <para>
        So the question for each RGB trio of values in the (let us assume) 16-bit tiff produced by dcraw becomes, "What does a particular trio of RGB values for the pixels making up images produced by this particular (make and model) camera really mean in terms of some absolute standard referencing some ideal observer". This absolute standard referencing an ideal observer is more commonly called a <emphasis>Profile Connection Space</emphasis>. A camera profile is needed to accurately characterize or describe the response of a given camera's pixels to light entering that camera, so that the RGB values in the output file produced by the raw converter can be translated first into an absolute Profile Connection Space (PCS) and then from the PCS to your chosen working space. As a very important aside, for most of the open source world (including digikam), the software used to translate from the camera profile to the PCS and from the PCS to your chosen working space and eventually to your chosen output space (for printing or perhaps monitor display) is based on lcms (the <ulink url="http://littlecms.com">little color management engine</ulink>). For what it's worth, my own testing has shown that lcms does more accurate conversions than Adobe's proprietary color conversion engine. Further, for almost all raw conversion programs, including commercial closed source software such as Adobe Photoshop, the raw conversion is typically based on decoding of the proprietary raw file done by dcraw. David Coffin, author of dcraw, is the hero of raw conversion - without him we'd all be stuck using the usually windows/mac only proprietary software that comes with our digital cameras. The dcraw's interpolation algorithms (not to be confused with the aforementioned decoding of the proprietary raw file), which are part of &digikam; if properly used, produce results equal or superior to commercial, closed source software. We in the world of &Linux; and open source software are not second-class citizens when it comes to digital imaging. Far from.
    </para>

    <para>
        There are two commonly used Profile Connection Spaces - CIELAB and CIEXYZ (see <ulink url="https://en.wikipedia.org/wiki/Color_management">Color management</ulink>, section on color translation, then look up CIELAB and CIEXYZ on wikipedia).  Lcms uses the camera profile to translate the RGB values from the interpolated raw file, that is, the tiff produced by dcraw, into the appropriate Profile Connection Space (usually CIEXYZ - why CIEXYZ? I haven't taken the time to learn). A profile connection space is not itself a working space.  Rather a PCS is an absolute reference space used only for translating from one color space to another - think of a PCS as a Universal Translator for all the color profiles that an image might encounter in the course of its journey from camera raw file to final output:
    </para>

    <orderedlist>

        <listitem><para>
            Lcms uses the camera profile, also called an input profile, to translate the interpolated dcraw-produced RGB numbers, which only have meaning relative to your (make and model of) camera, to a second set of RGB numbers that only have meaning in the Profile Connection Space.
        </para></listitem>

        <listitem><para>
            Lcms translates the Profile Connection Space RGB numbers to the corresponding numbers in your chosen working space so you can edit your image. And again, these working space numbers ONLY have meaning relative to a given working space.  The same red, visually speaking, is represented by different trios of RGB numbers in different working spaces; and if you assign the wrong profile the image will look wrong, slightly wrong or very wrong depending on the differences between the two profiles.
        </para></listitem>

        <listitem><para>
            While you are editing your image in your chosen working space, then lcms should translate all the working space RGB numbers back to the PCS, and then over to the correct RGB numbers that enable your monitor (your display device) to give you the most accurate possible display representation of your image as it is being edited.  This translation for display is done on the fly and you should never even notice it happening, unless it doesn't happen correctly - then the displayed image will look wrong, perhaps a little wrong, perhaps really, really, really wrong.
        </para></listitem>

        <listitem><para>
            When you are satisfied that your edited image is ready to share with the world, lcms translates the working space RGB numbers back into the PCS space and out again to a printer color space using a printer profile characterizing your printer/paper combination (if you plan on printing the image) or to sRGB (if you plan on displaying the image on the web or emailing it to friends or perhaps creating a slide-show to play on monitors other than your own).
        </para></listitem>

    </orderedlist>

    <para>
        To back up a little bit and look at the first color profile an image encounters, that is, the camera profile (see (1) immediately above) - dcraw can in fact apply your camera profile for you (dcraw uses lcms internally). But (i)the generating of the tiff composed of the interpolated RGB values derived from the camera raw file, and (ii)the application of the camera profile to the interpolated file, are two very distinct and totally separable (separable in theory and practice for dcraw; in theory only for most raw converters) steps.  The dcraw command line output options "-o 0 [Raw color (unique to each camera)] -4 [16-bit linear] -T [tiff]" tell dcraw to output the RGB numbers from the raw interpolation into a tiff without applying a camera input profile (the words in brackets explain the options but should not be entered at the command line). Then, if you truly enjoy working from the command line, you can use the lcms utility tifficc to apply your camera profile yourself.  The advantage of doing so 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.
    </para>

    <sect3 id="using-iccprofile">
        <title>Where to find camera profiles</title>

        <para>
            So where do we get these elusive and oh-so-necessary camera-specific profiles that we need to translate our interpolated raw files to a working color space? The <ulink url="http://ufraw.sourceforge.net/Colors.html">UFRAW website </ulink> section on color management has a bit of information on where to find ready-made camera profiles. 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 (and Adobe, but ACR hides the Adobe-made profiles inside the program code), for example, have to make their own profiles for all the cameras that they support - keep this proprietary propensity of your camera manufacturer in mind next time you buy a digital camera.
        </para>

        <para>
            But back to finding a camera profile for your camera - the real answer (assuming you don't find a ready-made profile that makes you happy) is to make your own camera profile or have one made for you.  There are quite a few commercial services who provide profiling services (for a fee, of course).  Or you can use LPRof or Argyll to profile your camera yourself.  I haven't yet walked down that road so I cannot speak about how easy or difficult the process of profiling a camera might be.  But I would imagine, knowing how very meticulous the people behind Argyll, LPRof, and lcms are about color management, that making your own camera profile is very do-able and very likely the results will be better than any proprietary profile. After all, Canon (and also Bibble and Phase One for that matter) didn't profile MY camera - they just profiled a camera like mine.
        </para>

        <para>
            Working Spaces:
        </para>

        <para>
            So now your raw file has been interpolated by dcraw and you've obtained a camera profile and used lcms tifficc to apply your camera profile to the tiff produced by dcraw (or you've asked dcraw to apply it for you).  What does all this mean?  The real answer involves a lot of math and color science that goes way over my head and likely yours.  The short, practical answer is that neither the camera profile space nor the Profile Connection Space is an appropriate space for image editing.  Your next step is to choose a working space for image editing.  And then you (or rather the lcms color management engine that your open source digital imaging software uses) actually perform a double translation. First lcms uses the camera profile to translate the RGB values of each pixel in the dcraw-output-image-without-camera-profile-applied into the aforementioned Profile Connection Space. Then it translates the RGB values of each pixel from the PCS to your chosen working space.
        </para>

        <para>
            Confusions and confusing terminology:
        </para>

        <para>
            Before talking more about working spaces, some confusions and confusing terminology needs to be cleared up:
        </para>

        <para>
            First, sRGB is both a working color space and an output color space for images intended for the web and for monitor display (if you have a spiffy new monitor with a gamut larger than the gamut covered by sRGB, obviously you might want to reconsider what output profile to use to best take advantage of your wonderful and hopefully calibrated and profiled monitor, but please convert your image to sRGB before sending it on to your friends!).  sRGB is also the color space that a lot of home and mass-production commercial printers expect image files to be in when sent to the printer.  It is also the color space that most programs assume if an image does not have an embedded color profile telling the program what color space should be used to interpret (translate) the RGB numbers. So if you choose to not use color-management, your color-management choices are simple - set everything to sRGB.
        </para>

        <para>
            Second, all jpegs (or tiffs, if you have an older Minolta Dimage camera) coming straight out of a camera (even if produced by point-and-shoots cameras that don't allow you to save a raw file) start life inside the camera as a raw file produced by the camera's A to D converter.  The processor inside the camera interpolates the raw file, assigns a camera profile, translates the resulting RGB numbers to a working space (usually sRGB but sometimes you can choose AdobeRGB, depending on the camera), does the jpeg compression, and stores the jpeg file on your camera card.  So jpegs (or tiffs) from your camera NEVER need to be assigned a camera or input profile which is then translated to a working space via a PCS. Jpegs from a camera are already in a working space.
        </para>

        <para>Third, in case anyone is unsure on this point, note that an interpolated raw file is no longer a raw file - it has been interpolated and then output as a tiff whose RGB values need to be translated to a working space, using the camera profile, the PCS, and lcms. Fourth (strictly for future reference), to introduce a bit of commonly heard color-management terminology here - the camera profile and your printer's color profile are both device dependent, whereas the working space will be device-independent - it can be used with any image, with any properly color-managed software, without regard for where the image originated.</para>

        <para>
            Fifth, above I have used the words translate and translation as a descriptive metaphor for what lcms does when it translates RGB values from one color space to another via the PCS. The usual and correct terminology is convert and conversion, which I will use below. The four methods of conversion from one color space to another are: perceptual, relative colorimetric, absolute colorimetric, and saturation.  Which method of conversion you should use for any given image processing step from raw file to final output image is beyond the scope of this tutorial. The standard advice is: when in doubt, use perceptual.
        </para>

        <para>
            Sixth (and again, strictly for future reference), assign a profile means change the meaning of the RGB numbers in an image by embedding a new profile without changing the actual RGB numbers associated with each pixel in the image; convert means embed a new profile, but also change the RGB numbers at the same time so that the meaning of the RGB values - that is, the real-world visible color represented by the trio of RGB numbers associated with each pixel in an image - remains the same before and after the conversion from one space to another. You should be able to do multiple conversions of an image from one working space to another, and with a properly color-managed image editor, even though all the RGB numbers in the image will change with each conversion, the image on your screen should look the same (leaving aside the usually unnoticeable small but inevitable changes from accumulated gamut mismatches and mathematical rounding errors). However, every time you assign a new working space profile rather than convert to a new working space, the appearance of the image should more or less drastically change (usually for the worse).
        </para>

        <para>
            Finally, (and this is a crucially important point), color management is NOT only relevant if you shoot raw.  Color management affects every stage of the image processing pipeline, whether you start with a raw file that you, yourself interpolate and translate into a tiff, or if you start with a jpeg or tiff produced by your camera.
        </para>

        <para>
            Copyrighted and copyleft working spaces:
        </para>

        <para>
            I will take it as given that ALL the ordinarily encountered working spaces, such as:
        </para>

        <orderedlist>

            <listitem><para>
                The several variants of sRGB (see <ulink url="http://www.color.org/v4spec.xalter">color.org</ulink>).
            </para></listitem>

            <listitem><para>
                <ulink url="http://www.brucelindbloom.com">BruceRGB</ulink>.
            </para></listitem>

            <listitem><para>
                The various ECI (European color initiative) working space <ulink url="http://www.eci.org/doku.php?id=en:colourstandards:workingcolorspaces">profiles</ulink>.
            </para></listitem>

            <listitem><para>
                AdobeRGB, Adobe WideGamutRGB, and Kodak/Adobe ProPhotoRGB (Kodak and Adobe ProPhoto are the same, just branded differently) and their <ulink url="http://www.behrmann.name/index.php?option=com_content&amp;task=view&amp;id=34&amp;Itemid=68">non-branded, non-copyrighted</ulink> counterparts (Oyranos includes a non-branded version of AdobeRGB).
            </para></listitem>

            <listitem><para>
                And quite a few others that could be added to this list are all more or less suitable as working spaces. Which working space you should use depends only and solely on YOU, on YOUR requirements as the editor of YOUR digital images with YOUR eventual output intentions (web, fine art print, &etc;).
            </para></listitem>

        </orderedlist>

        <para>
            However, as a critical aside, if you are using Adobe (or other copyrighted) working space profiles, these profiles contain copyright information that shows up in your image exif information.  Lately I've been perusing the openicc mailing lists. Apparently lcms can be used to produce nonbranded, copyleft working space profiles that are just the same as - actually indistinguishable from - the branded, copyrighted working space profiles. It would be a wonderful addition to digikam if a set of "copyleft" working space profiles, including nonbranded, relabelled versions of ProPhotoRGB, AdobeRGB, and Adobe WidegamutRGB (perhaps in two flavors each: linear gamma and the usual gamma), could be bundled as part of the &digikam; package.
        </para>

        <para>
            Which working space: gamma
        </para> 

        <para>
            Now, the next question is: which working space should I use? <ulink url="https://en.wikipedia.org/wiki/Color_management#Working_spaces">Wikipedia says: </ulink> <blockquote><para>Working spaces, such as sRGB or Adobe RGB, are color spaces that facilitate good results while editing. For instance, pixels with equal values of RGB should appear neutral. Using a large (gamut) working space will lead to posterization, while using a small working space will lead to clipping. This trade-off is a consideration for the critical image editor</para></blockquote>
        </para>

        <para>
            Well, that quote from wikipedia is about as clear as mud and I don't know if I will be able to explain it more clearly, but I will try. "[P]ixels with equal values of RGB should appear neutral" just means that for any given pixel in an image that has been converted to a suitable working space, if R=G=B you should see grey or black or white on your screen.
        </para>

        <para>I am not aware of a list of other technical requirements for a suitable working space, though undoubtedly someone has produced such a list. But most working space profiles are characterized by: </para>

        <orderedlist>

            <listitem><para>
                RGB primaries which dictate the range of colors, that is, the gamut covered by a given profile.
            </para></listitem>

            <listitem><para>
                White point, usually D50 or D65, which dictates the total dynamic range of the working space, from 0,0,0 (total black) to the brightest possible white.
            </para></listitem>

            <listitem><para>
                Gamma.
            </para></listitem>

        </orderedlist> 

        <para>
            The practical consequences that result from using different RGB primaries, leading to larger or smaller working spaces, are discussed below. The practical consequences for different choices for the working space white point are beyond the scope of this tutorial. Here I will talk a little bit about the practical consequences of the working space gamma (for an excellent article and references, look up gamma on wikipedia).
        </para>

        <para>
            The gamma of a color profile dictates what power transform needs to take place to properly convert from an image's embedded color profile (perhaps your working color space) to another color profile with a different gamma, such as (i)the display profile used to display the image on the screen or (ii)perhaps to a new working space, or (iii)perhaps from your working space to your printer's color space.
        </para>

        <tip>
            <para>
                Mathematically speaking, for a power transform you normalize the RGB numbers and raise the resulting numbers to an appropriate power depending on the respective gammas of the starting and ending color space, then renormalize the results to a new set of RGB numbers. Lcms does this for you when you ask lcms to convert from one color space to another; however, if ALL you are doing is a power transform, use imagemagick instead of lcms and just manipulate the RGB numbers directly - the results will be more accurate.
            </para>
        </tip>

        <para>
            One practical consequence of the gamma of a working space is that the higher the gamma, the more tones are available for editing in the shadows, with consequently fewer tones available in the highlights. So theoretically, if you are working on a very dark-toned (low key) image you might want a working space with a higher gamma.  And if you are working on a high key image, say a picture taken in full noon sunlight of a wedding dress with snow as a backdrop, you might want to choose a working space with a lower gamma, so you have more available tonal gradations in the highlights. But in the real world of real image editing, almost everyone uses working spaces with either gamma 1.8 or 2.2.
        </para>

        <para>
            Some people are trying to standardize on gamma 2.0.  sRGB and LStar-RGB are not gamma-based working spaces. Rather, sRGB uses a <ulink url="https://en.wikipedia.org/wiki/SRGB">hybrid gamma</ulink>, and LStar-RGB uses a luminosity-based tonal response curve instead of a gamma value - see <ulink url="http://www.colormanagement.org/en/workingspaces.html">here</ulink> for more information, and then google around for more in-depth information.
        </para>

        <para>
            In addition to gamma 1.8 and gamma 2.2 the only other gamma for a working space that gets much mention or use is gamma 1.0, also called linear gamma. <emphasis>Linear gamma</emphasis> is used in HDR (high dynamic range) imaging and also if one wants to avoid introducing gamma-induced errors into one's regular low dynamic range editing. Gamma-induced errors is a topic outside the scope of this tutorial, but see <ulink url="http://www.4p8.com/eric.brasseur/gamma.html">Gamma errors</ulink> in <ulink url="http://www.21stcenturyshoebox.com/essays/color_reproduction.html">picture scaling,</ulink> for gamma-induced color shifts.
        </para>

        <para>
            Unfortunately and despite their undeniable mathematical advantages, linear gamma working spaces have so few tones in the shadows that (in my opinion) they are impossible to use for editing if one is working in 8-bits, and still problematic at 16-bits.  When the day comes when we are all doing our editing on 32-bit files produced by our HDR cameras on our personal supercomputers, I predict that we will all be using working spaces with gamma 1; Adobe Lightroom is already using a linear gamma working space "under the hood" and Lightzone has always used a linear gamma working space.
        </para>

        <para>
            Which working space: <emphasis>large gamut</emphasis> or <emphasis>small gamut</emphasis>
        </para>

        <para>
            One major consideration in choosing a working space is that some working spaces are bigger than others, meaning they cover more of the visible spectrum (and perhaps even include some imaginary colors - mathematical constructs that don't really exist).  These bigger spaces offer the advantage of allowing you to keep all the colors captured by your camera and preserved by the lcms conversion from your camera profile to the really big profile connection space.
        </para>

        <para>
            But keeping all the possible colors comes at a price.  It seems that any given digital image (pictures of daffodils with saturated yellows being one common exception) likely only contains a small subset of all the possible visible colors that your camera is capable of capturing.  This small subset is easily contained in one of the smaller working spaces.  Using a very large working space mean that editing your image (applying curves, saturation, &etc;) can easily produce colors that your eventual output device (printer, monitor) simply cannot display.  So the conversion from your working space to your output device space (say your printer) will have to remap the out of gamut colors in your edited image, some of which might even be totally imaginary, to your printer color space with its much smaller gamut, leading to inaccurate colors at best and at worst to banding (posterization - gaps in what should be a smooth color transition, say, across an expanse of blue sky) and clipping (your carefully crafted muted transitions across delicate shades of red, for example, might get remapped to a solid block of dull red after conversion to your printer's color space).
        </para>

        <para>
            In other words, large gamut working spaces, improperly handled, can lead to lost information on output. Small gamut working spaces can clip information on input. Like Wikipedia says, it's a trade-off. Here is some oft-repeated advice:
        </para>

        <orderedlist>

            <listitem><para>
                For images intended for the web, use (one of the) sRGB (variants - there are several).
            </para></listitem>

            <listitem><para>
                For the most accuracy in your image editing (that is, making the most of your "bits" with the least risk of banding or clipping when you convert your image from your working space to an output space), use the smallest working space that includes all the colors in the scene that you photographed, plus a little extra room for those new colors you intentionally produce as you edit.
            </para></listitem>

            <listitem><para>
                If you are working in 8-bits rather than 16-bits, choose a smaller space rather than a larger space.
            </para></listitem>

            <listitem><para>
                For archival purposes, convert your raw file to a 16-bit tiff with a large gamut working space to avoid loosing color information. Then convert this archival tiff to your working space of choice (saving the converted working tiff under a new name, of course). See <ulink url="http://simon.tindemans.eu/essays/scenereferredworkflow">here</ulink> for more details.
            </para></listitem>

        </orderedlist>

        <para>
            The whys of these bits of advice regarding which working space are beyond the scope of this tutorial.  See Bruce Lindbloom's excellent website (<ulink url="http://www.brucelindbloom.com/">Info, Information about RGB Working Spaces</ulink>) for a visual comparison of the gamut (array of included colors) of the various working color spaces.  See <ulink url="http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml">here</ulink> and <ulink url="http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm">here</ulink> for a pro and con presentation, respectively, of the merits of using large gamut working spaces. And while you are on the <ulink url="http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm">cambridgeincolour.com</ulink> website, check out the tutorial on color management.
        </para>

    </sect3>

    <sect3 id="softproofing">
        <title>Soft Proofing</title>

        <para>
            Soft Proofing is a way of previewing on the screen (monitor) the result to be expected from an output on another device, typically a printer. Soft proofing will show you the difference to be expected before you actually do it (and waste your costly ink). So you can improve your settings without wasting time and money.
        </para>

    </sect3>

    <sect3 id="rendering-intention">
        <title>Rendering intention</title>

        <para>
            Rendering intent refers to the way gamuts are handled when the intended target color space cannot handle the full gamut.
        </para>

        <itemizedlist>

            <listitem><para>
                <emphasis>Perceptual</emphasis>, also called Image or Maintain Full Gamut.  This is generally recommended for photographic images. The color gamut is expanded or compressed when moving between color spaces to maintain consistent overall appearance. Low saturation colors are changed very little. More saturated colors within the gamuts of both spaces may be altered to differentiate them from saturated colors outside the smaller gamut space. Perceptual rendering applies the same gamut compression to all images, even when the image contains no significant out-of-gamut colors.
            </para></listitem>

            <listitem><para>
                <emphasis>Relative Colorimetric</emphasis>, also called Proof or Preserve Identical Color and White Point.  Reproduces in-gamut colors exactly and clips out-of-gamut colors to the nearest reproducible hue.
            </para></listitem>

            <listitem><para>
                <emphasis>Absolute Colorimetric</emphasis>, also called Match or Preserve Identical Colors.  Reproduces in-gamut colors exactly and clips out-of-gamut colors to the nearest reproducible hue, sacrificing saturation and possibly lightness. On tinted papers, whites may be darkened to keep the hue identical to the original. For example, cyan may be added to the white of a cream-colored paper, effectively darkening the image. Rarely of interest to photographers.
            </para></listitem>

            <listitem><para>
                <emphasis>Saturation</emphasis>, also called Graphic or Preserve Saturation.  Maps the saturated primary colors in the source to saturated primary colors in the destination, neglecting differences in hue, saturation, or lightness. For block graphics; rarely of interest to photographers.
            </para></listitem>

        </itemizedlist>

    </sect3>

    <sect3 id="iccprofile-links">
        <title>Links</title>

        <itemizedlist>

            <listitem><para>
                <ulink url="http://www.oyranos.org/wiki/index.php?title=Main_Page">Color wiki</ulink>
            </para></listitem>

            <listitem><para>
                <ulink url="https://en.wikipedia.org/wiki/Lab_color_space#CIELAB">CIELab</ulink>
            </para></listitem>

            <listitem><para>
                <ulink url="http://en.wikipedia.org/wiki/Gamut">Gamut explained</ulink>
            </para></listitem>

        </itemizedlist>

    </sect3>

</sect2>

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