[kde-doc-english] [digikam-doc] digikam: remove consecutive duplicate words >how< + >been<

Burkhard Lück lueck at hube-lueck.de
Sun Feb 24 12:42:12 UTC 2013


Git commit 96e9cc1cc6e35c6e597af1e7e4d236a2ae4657d3 by Burkhard Lück.
Committed on 24/02/2013 at 13:40.
Pushed by lueck into branch 'master'.

remove consecutive duplicate words >how< + >been<

M  +1    -1    digikam/color-management.docbook
M  +1    -1    digikam/index.docbook

http://commits.kde.org/digikam-doc/96e9cc1cc6e35c6e597af1e7e4d236a2ae4657d3

diff --git a/digikam/color-management.docbook b/digikam/color-management.docbook
index 8a8fab7..01670f3 100644
--- a/digikam/color-management.docbook
+++ b/digikam/color-management.docbook
@@ -255,7 +255,7 @@
           <para>On the other hand, every time you assign a new working space profile rather than convert to a new working space (except when initially assigning a camera profile to the image file you get from your raw processing software), the appearance of the image should more or less drastically change (usually for the worse, unless the wrong profile had previously been inadvertently embedded in the image).</para>
           <para>In theory, you should be able to do multiple conversions of an image from one working space to another, and if you are using a color-managed image editor, even though all the RGB numbers in the image will change with each conversion, the image displayed on your screen should look the same. In actual fact, because of rounding errors upon each conversion, not to mention gamut-clipping when going from a larger to a smaller working space, every time you convert from one space to another the image degrades a bit. </para>
           <para><emphasis>Device-dependent</emphasis> and <emphasis>device-independent</emphasis> profiles:  The camera profile, a scanner profile, your monitor's profile, and your printer's color profile are all device-dependent profiles - these profiles only work with the specific device for which they were produced by means of profiling. Working space profiles and the PCS's are "device-independent". Once an image file has been translated by LCMS via a PCS to a device-independent working space, in a sense it no longer matters what device originally produced the image. But as soon as you want to display or print the image, then the device (monitor, printer) used matters a great deal and requires a device-dependent profile.</para>
-          <para>An <emphasis>interpolated raw file</emphasis> isn't a raw file. For some reason this simple point causes a lot of confusion. But after a raw file has been been interpolated by raw processing software and then output as a tiff or jpeg, the original raw file is still a raw file, of course, but the interpolated file is just an image file. It isn't a raw file. </para>
+          <para>An <emphasis>interpolated raw file</emphasis> isn't a raw file. For some reason this simple point causes a lot of confusion. But after a raw file has been interpolated by raw processing software and then output as a tiff or jpeg, the original raw file is still a raw file, of course, but the interpolated file is just an image file. It isn't a raw file. </para>
           <para><emphasis>Linear</emphasis> has two related and easily confused definitions. "Linear" can mean that the image tonality reflects the tonality in the original scene as photographed instead of being altered by the application of an S-curve or other means of changing local and global tonality. It can also mean that the gamma transfer curve of the color space is linear. An image can be "linear" in either, both, or neither of these two senses. A raw image as developed by dcraw is linear in both senses. The same image as developed by Canon's DPP won't be linear in either sense.</para>
           <para><emphasis>HDR and LDR</emphasis> do not refer to the bit-depth of the image. "High dynamic range" and "low dynamic range" refer to the total dynamic range encompassed by an image. A regular low dynamic range image, say encompassing a mere 5 "stops" (the average digital camera these days can easily accommodate 8 or 9 stops), can be saved as an 8-, 16-, 32-, or even 64-bit image, depending on your software, but the dynamic range of the image isn't thereby increased. Only the number of discrete steps from the brightest to the darkest tone in the image has changed. Conversely, a 22-stop scene (way beyond the capacity of a consumer-oriented digital camera without using multiple exposures) can be saved as an 8- or 16-bit image, but the resulting image will exhibit extreme banding (that is, it will display extreme banding in any given tonal range that can actually be displayed on a typical monitor at one time) because of the relatively few available discrete tonal steps from the lightest to the darkest tone in the image.</para>
           <para><emphasis>In-camera produced jpegs don't need a camera profile</emphasis>. 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. If you save your images as jpegs, then 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 don't need to be assigned a camera profile which is then translated to a working space via a PCS. Jpegs from a camera are already in a working space. </para>
diff --git a/digikam/index.docbook b/digikam/index.docbook
index e4b1930..b0446af 100644
--- a/digikam/index.docbook
+++ b/digikam/index.docbook
@@ -2076,7 +2076,7 @@ Fun stuff
            <sect3 id="setup-iccprofiles">            <title>ICC Profiles setup</title>
 
               <para>
-                 &digikam; is color-management enabled. RAW files - as they come -  are not color managed at all. Your camera provides the data it has captured in a raw format and will let you manage all the processing. Every camera has its specifics as to how how it captures color information, therefore you will need to apply a specific profile to the images you want to process. Please refer to the section <link linkend="using-iccprofile">ICC color profile management</link> for more details an explanations.
+                 &digikam; is color-management enabled. RAW files - as they come -  are not color managed at all. Your camera provides the data it has captured in a raw format and will let you manage all the processing. Every camera has its specifics as to how it captures color information, therefore you will need to apply a specific profile to the images you want to process. Please refer to the section <link linkend="using-iccprofile">ICC color profile management</link> for more details an explanations.
               </para>
               <para>
                  Basically, a profile "maps" the color information and gives information on how one should render them. It gives also information to LCMS and &digikam; on how to translate the color information from one color space to an other in order to keep the colors as accurate as possible across all rendring media.


More information about the kde-doc-english mailing list