Documentation:Tutorial Section 3.3 - Revision history

Jr: fix wording

2025-05-09T11:07:14Z

fix wording

Clipka: /* Advanced Texture Options */ canonicalize some version numbers

2021-06-09T15:22:50Z

Advanced Texture Options: canonicalize some version numbers

Clipka: /* Gamma in Legacy Scenes */ canonicalize some version numbers

2021-06-09T15:20:48Z

Gamma in Legacy Scenes: canonicalize some version numbers

Clipka: /* Using Ambient */ canonicalize a version number

2021-06-09T14:30:10Z

Using Ambient: canonicalize a version number

Jholsenback: file-path and wording

2020-07-23T12:00:15Z

file-path and wording

Jholsenback: couple more links

2017-11-13T01:38:23Z

couple more links

Jholsenback: added link for clarity

2017-11-13T01:15:06Z

added link for clarity

Jholsenback: version changes

2017-06-30T09:02:15Z

version changes

Clipka: Indexentries fix

2016-12-16T14:22:07Z

Indexentries fix

Show changes

Clipka: /* Gamma Handling */

2016-10-13T22:09:07Z

Gamma Handling

@@ Line 368: / Line 368: @@
 <ul>
    <li>For OpenEXR and Radiance HDR, which are officially specified to store linear light intensity values, POV-Ray <em>always</em> stores linear values, ignoring the <code>File_Gamma</code> setting.</li>
-   <li>For PNG, which explicitly allows different encoding gamma values, POV-Ray will interpret the <code>File_Gamma</code> setting as the decoding gamma to encode for, and <em>always</em> write corresponding metadata into the header; as a result, the image will always look virtually identical irregardless of the <code>File_Gamma</code> setting; however, to minimize visible encoding artifacts like color banding, it is strongly recommended to use a setting of around 2.2, or <code>sRGB</code>. If <code>File_Gamma</code> is not specified, PNG output defaults to <code>sRGB</code>. {{New}} in version 3.8, note that a setting of <code>BT709</code> or <code>BT2020</code> is possible, but cannot be conveyed correctly via PNG metadata and is therefore strongly discouraged for this file format.</li>
+   <li>For PNG, which explicitly allows different encoding gamma values, POV-Ray will interpret the <code>File_Gamma</code> setting as the decoding gamma to encode for, and <em>always</em> write corresponding metadata into the header; as a result, the image will always look virtually identical regardless of the <code>File_Gamma</code> setting; however, to minimize visible encoding artifacts like color banding, it is strongly recommended to use a setting of around 2.2, or <code>sRGB</code>. If <code>File_Gamma</code> is not specified, PNG output defaults to <code>sRGB</code>. {{New}} in version 3.8, note that a setting of <code>BT709</code> or <code>BT2020</code> is possible, but cannot be conveyed correctly via PNG metadata and is therefore strongly discouraged for this file format.</li>
    <li>{{New}} in version 3.8, for Netpbm PPM, which is officially specified to store gamma-encoded values using the ITU-R BT.709 transfer function, POV-Ray adheres to the Netpbm standard by default. However, if the <code>File_Gamma</code> setting is specified, POV-Ray will interpret it as a display gamma to pre-correct for, to account for the widespread use of competing de-facto standards, most notably the use of linear encoding (corresponding to a setting of <code>File_Gamma=1.0</code>) or sRGB gamma pre-correction (corresponding to a setting of <code>File_Gamma=sRGB</code>).</li>
    <li>For all other file formats, POV-Ray will interpret the <code>File_Gamma</code> setting as the display gamma to pre-correct for; as a result, the image will look different depending on the value used. It will also look different than the preview if you use a value other than your system's display gamma. If <code>File_Gamma</code> is not specified, these output file formats default to sRGB pre-correction.

@@ Line 490: / Line 490: @@
 <p class="Note"><strong>Note:</strong> Early versions of POV-Ray made a distinction between pigment and
 normal patterns, i. e. patterns that could be used inside a <code>
-normal</code> or <code>pigment</code> statement. Since POV-Ray 3.0 this
+normal</code> or <code>pigment</code> statement. Since POV-Ray v3.0 this
 restriction was removed so that all patterns listed in section [[Reference:Pattern|Pattern]] can be used as a pigment or normal pattern.</p>
@@ Line 1,372: / Line 1,372: @@
 or shaded parts. It would make a pretty good street light.</p>
-<p class="Note"><strong>Note:</strong> Versions of POV-Ray prior to 3.7 did not provide the <code>emission</code> keyword for finish, and it was customary to resort to <code>ambient</code> instead for such purpose. This is now discouraged, as <code>ambient</code> is now disabled when using radiosity.</p>
+<p class="Note"><strong>Note:</strong> Versions of POV-Ray prior to v3.7 did not provide the <code>emission</code> keyword for finish, and it was customary to resort to <code>ambient</code> instead for such purpose. This is now discouraged, as <code>ambient</code> is now disabled when using radiosity.</p>
 <!--<wikinav>--->
 <br>

@@ Line 453: / Line 453: @@
 <ul>
-   <li>If the scene contains an <code>assumed_gamma</code> statement, and does not explicitly specify a version of 3.7 or later, gamma handling will follow the 3.6 rules.</li>
+   <li>If the scene contains an <code>assumed_gamma</code> statement, and does not explicitly specify a version of v3.7 or later, gamma handling will follow the v3.6 rules.</li>
-   <li>If the scene does neither specify an <code>assumed_gamma</code> statement, nor explicitly specify a version of 3.7 or later, gamma correction will be turned off.</li>
+   <li>If the scene does neither specify an <code>assumed_gamma</code> statement, nor explicitly specify a version of v3.7 or later, gamma correction will be turned off.</li>
 </ul>
-<p>The 3.6 rules differ from standard behaviour with regards to <code>image_map</code> input files as follows:</p>
+<p>The v3.6 rules differ from standard behaviour with regards to <code>image_map</code> input files as follows:</p>
 <ul>
    <li>For OpenEXR, Radiance HDR and PNG, the behaviour is the same as described above.</li>
-   <li>For any other file formats, in "3.6 mode" POV-Ray will currently presume the image data to match the <code>assumed_gamma</code> (in other words, no gamma adjustment will be performed by default).</li>
+   <li>For any other file formats, in "v3.6 mode" POV-Ray will currently presume the image data to match the <code>assumed_gamma</code> (in other words, no gamma adjustment will be performed by default).</li>
 </ul>
-<p>As POV-Ray 3.6 did not have a File_Gamma setting, and used Display_Gamma for both purposes, you will have to set File_Gamma to whatever you used to set Display_Gamma to (or leave it undefined if you did not specify Display_Gamma either) in order to get the same output.</p>
+<p>As POV-Ray v3.6 did not have a File_Gamma setting, and used Display_Gamma for both purposes, you will have to set File_Gamma to whatever you used to set Display_Gamma to (or leave it undefined if you did not specify Display_Gamma either) in order to get the same output.</p>
-<p>Furthermore, backward compatibility with 3.6 for PNG input files is subject to the following restrictions:</p>
+<p>Furthermore, backward compatibility with v3.6 for PNG input files is subject to the following restrictions:</p>
 <ul>
    <li>For palette-based PNG files (an uncommon flavor of PNG), backward compatibility is provided only if gamma correction is disabled (i.e. <code>assumed_gamma</code> is <em>not</em> specified). This is due to fixes in the handling of this PNG flavor.</li>
-   <li>For non-palette-based PNG files, backward compatibility is provided only if gamma correction is enabled (i.e. <code>assumed_gamma</code> <em>is</em> specified). This is due to inconsistencies in POV-Ray 3.6's PNG file handling which would have been prohibitively difficult to reproduce with the architectural changes in POV-Ray 3.7.</li>
+   <li>For non-palette-based PNG files, backward compatibility is provided only if gamma correction is enabled (i.e. <code>assumed_gamma</code> <em>is</em> specified). This is due to inconsistencies in POV-Ray v3.6's PNG file handling which would have been prohibitively difficult to reproduce with the architectural changes in POV-Ray v3.7.</li>
-   <li>For PNG files carrying both an sRGB chunk and a fitting gAMA chunk, results will slightly differ, while for PNG files carrying an sRGB chunk but no gAMA chunk (or a wrong one), backward compatibility is not provided. This is due to POV-Ray 3.6 honoring only gAMA chunks, while POV-Ray 3.7 honors sRGB chunks as well, giving them precedence over gAMA chunks to comply with the official file format specification.</li>
+   <li>For PNG files carrying both an sRGB chunk and a fitting gAMA chunk, results will slightly differ, while for PNG files carrying an sRGB chunk but no gAMA chunk (or a wrong one), backward compatibility is not provided. This is due to POV-Ray v3.6 honoring only gAMA chunks, while POV-Ray v3.7 honors sRGB chunks as well, giving them precedence over gAMA chunks to comply with the official file format specification.</li>
 </ul>
-<p>If you experience problems with a PNG input file in a legacy scene, explicitly specify the decoding gamma to be applied for that particular image using the <code>gamma</code> statement may help. When using e.g. <code>assumed gamma 1.8</code>, some values worth trying would be <code>gamma 1</code>, <code>gamma 1/1.8</code>, <code>gamma 2.2/1.8</code> or <code>gamma 1.8</code>. (With POV-Ray 3.6's PNG file handling having been quite a mess, it is difficult to be more specific.)</p>
+<p>If you experience problems with a PNG input file in a legacy scene, explicitly specify the decoding gamma to be applied for that particular image using the <code>gamma</code> statement may help. When using e.g. <code>assumed gamma 1.8</code>, some values worth trying would be <code>gamma 1</code>, <code>gamma 1/1.8</code>, <code>gamma 2.2/1.8</code> or <code>gamma 1.8</code>. (With POV-Ray v3.6's PNG file handling having been quite a mess, it is difficult to be more specific.)</p>
 ===Advanced Texture Options===

@@ Line 1,343: / Line 1,343: @@
 <code>glass.inc</code> for some other examples.</p>
-<p class="Note"><strong>Note:</strong> As of POV-Ray 3.7, <code>ambient</code> is disabled when using radiosity, as both mechanisms are intended to simulate the same thing (albeit with different quality) and don't play well together.</p>
+<p class="Note"><strong>Note:</strong> As of POV-Ray v3.7, <code>ambient</code> is disabled when using radiosity, as both mechanisms are intended to simulate the same thing (albeit with different quality) and don't play well together.</p>
 =====Using Emission=====

@@ Line 281: / Line 281: @@
 <p class="Note"><strong>Note:</strong> We disagree with the author of the site linked to above, about which display gamma to aim for, and <em>strongly recommend</em> a gamma of 2.2, unless you know exactly what you're doing.</p>
-<p>As an additional sanity check of your system display settings (and also of your image viewing software) POV-Ray provides a sample scene custom-tailored to this purpose, to be found at <code>scenes/gamma/gamma_showcase.pov</code>. Render the scene twice as PNG, using the following options:</p>
+<p>As an additional sanity check of your system display settings (and also of your image viewing software) POV-Ray provides a sample scene custom-tailored to this purpose. Just render <code>~scenes/output/gamma_showcase.pov</code> twice, using the following options:</p>
 <pre>

@@ Line 495: / Line 495: @@
 ====Pigments====
 {{#indexentry:pigment, tutorial}}
-<p>Every surface must have a color. In POV-Ray this color is called a <code><!--<linkto "pigment">pigment</linkto>--->[[Reference:Pigment|pigment]]</code>. It does not have to be a single color. It can be a color pattern, a color list or even an image map. Pigments can also be layered one on top of the next so long as the uppermost layers are at least partially transparent so the ones beneath can show through. See also: [[Documentation:Tutorial Section 3.3#Using Transparent Pigments and Layered Textures|Using Transparent Pigments and Layered Textures]]</p>
+<p>Every surface must have a color. In POV-Ray this color is called a <code><!--<linkto "pigment">pigment</linkto>--->[[Reference:Pigment|pigment]]</code>. It does not have to be a single color. It can be a [[Documentation:Tutorial Section 3.3#Using Pigment and Patterns|color pattern]], a [[Documentation:Tutorial Section 3.3#Using Color List Pigments|color list]] or even an [[Reference:Image Map#Specifying an Image Map|image map]]. Pigments can also be layered one on top of the next so long as the uppermost layers are at least partially transparent so the ones beneath can show through. See also: [[Documentation:Tutorial Section 3.3#Using Transparent Pigments and Layered Textures|Using Transparent Pigments and Layered Textures]]</p>
 <p>Let's play around with some of these kinds of
 pigments.</p>

@@ Line 338: / Line 338: @@
 </pre>
-<p>Instead of a numerical value, you can also specify <code>Display_Gamma=sRGB</code> to explicitly tell POV-Ray that your system is calibrated to match the sRGB standard (which, as already mentioned, is actually the default setting). {{New}} in version 3.7.1, you can also specify <code>Display_Gamma=BT709</code> or <code>Display_Gamma=BT2020</code> to explicitly tell POV-Ray that your system is calibrated to match the transfer functions specified in ITU-R BT.709 or BT.2020, respectively, but you shouldn't use these unless you absolutely know what you are doing.</p>
+<p>Instead of a numerical value, you can also specify <code>Display_Gamma=sRGB</code> to explicitly tell POV-Ray that your system is calibrated to match the sRGB standard (which, as already mentioned, is actually the default setting). {{New}} in version 3.8, you can also specify <code>Display_Gamma=BT709</code> or <code>Display_Gamma=BT2020</code> to explicitly tell POV-Ray that your system is calibrated to match the transfer functions specified in ITU-R BT.709 or BT.2020, respectively, but you shouldn't use these unless you absolutely know what you are doing.</p>
 <p>Again, the gamma showcase scene can be used as a sanity check; use the following parameters:</p>
@@ Line 360: / Line 360: @@
 </pre>
-<p>Again, <code>sRGB</code> as well as, {{New}} in version 3.7.1, <code>BT709</code> or <code>BT2020</code>, are valid values, specifying that POV-Ray should apply the sRGB, ITU-R BT.709 or BT.2020 transfer function, respectively.</p>
+<p>Again, <code>sRGB</code> as well as, {{New}} in version 3.8, <code>BT709</code> or <code>BT2020</code>, are valid values, specifying that POV-Ray should apply the sRGB, ITU-R BT.709 or BT.2020 transfer function, respectively.</p>
 <p class="Note"><strong>Note:</strong> Some of the file formats supported by POV-Ray are explicitly specified to never use gamma pre-correction or gamma encoding. For such file types (currently OpenEXR and Radiance HDR), <code>File_Gamma</code> has no effect whatsoever. For certain other file types (currently PNG), <code>File_Gamma</code> does have an effect on the encoding of the image, but not on the general visual appearance.</p>
@@ Line 368: / Line 368: @@
 <ul>
    <li>For OpenEXR and Radiance HDR, which are officially specified to store linear light intensity values, POV-Ray <em>always</em> stores linear values, ignoring the <code>File_Gamma</code> setting.</li>
-   <li>For PNG, which explicitly allows different encoding gamma values, POV-Ray will interpret the <code>File_Gamma</code> setting as the decoding gamma to encode for, and <em>always</em> write corresponding metadata into the header; as a result, the image will always look virtually identical irregardless of the <code>File_Gamma</code> setting; however, to minimize visible encoding artifacts like color banding, it is strongly recommended to use a setting of around 2.2, or <code>sRGB</code>. If <code>File_Gamma</code> is not specified, PNG output defaults to <code>sRGB</code>. {{New}} in version 3.7.1, note that a setting of <code>BT709</code> or <code>BT2020</code> is possible, but cannot be conveyed correctly via PNG metadata and is therefore strongly discouraged for this file format.</li>
+   <li>For PNG, which explicitly allows different encoding gamma values, POV-Ray will interpret the <code>File_Gamma</code> setting as the decoding gamma to encode for, and <em>always</em> write corresponding metadata into the header; as a result, the image will always look virtually identical irregardless of the <code>File_Gamma</code> setting; however, to minimize visible encoding artifacts like color banding, it is strongly recommended to use a setting of around 2.2, or <code>sRGB</code>. If <code>File_Gamma</code> is not specified, PNG output defaults to <code>sRGB</code>. {{New}} in version 3.8, note that a setting of <code>BT709</code> or <code>BT2020</code> is possible, but cannot be conveyed correctly via PNG metadata and is therefore strongly discouraged for this file format.</li>
-   <li>{{New}} in version 3.7.1, for Netpbm PPM, which is officially specified to store gamma-encoded values using the ITU-R BT.709 transfer function, POV-Ray adheres to the Netpbm standard by default. However, if the <code>File_Gamma</code> setting is specified, POV-Ray will interpret it as a display gamma to pre-correct for, to account for the widespread use of competing de-facto standards, most notably the use of linear encoding (corresponding to a setting of <code>File_Gamma=1.0</code>) or sRGB gamma pre-correction (corresponding to a setting of <code>File_Gamma=sRGB</code>).</li>
+   <li>{{New}} in version 3.8, for Netpbm PPM, which is officially specified to store gamma-encoded values using the ITU-R BT.709 transfer function, POV-Ray adheres to the Netpbm standard by default. However, if the <code>File_Gamma</code> setting is specified, POV-Ray will interpret it as a display gamma to pre-correct for, to account for the widespread use of competing de-facto standards, most notably the use of linear encoding (corresponding to a setting of <code>File_Gamma=1.0</code>) or sRGB gamma pre-correction (corresponding to a setting of <code>File_Gamma=sRGB</code>).</li>
    <li>For all other file formats, POV-Ray will interpret the <code>File_Gamma</code> setting as the display gamma to pre-correct for; as a result, the image will look different depending on the value used. It will also look different than the preview if you use a value other than your system's display gamma. If <code>File_Gamma</code> is not specified, these output file formats default to sRGB pre-correction.
 </ul>
@@ Line 384: / Line 384: @@
 </pre>
-<p>This instructs POV-Ray to work with colors pre-corrected for a display gamma of whatever value you specify (in this example obviously a gamma of 1.8). You can also specify <code>srgb</code> instead of a numerical value, instructing POV-Ray to work with colors pre-corrected according to the sRGB standard. {{New}} in version 3.7.1, you can also specify <code>bt709</code> or <code>bt2020</code>, but both are strongly discouraged.</p>
+<p>This instructs POV-Ray to work with colors pre-corrected for a display gamma of whatever value you specify (in this example obviously a gamma of 1.8). You can also specify <code>srgb</code> instead of a numerical value, instructing POV-Ray to work with colors pre-corrected according to the sRGB standard. {{New}} in version 3.8, you can also specify <code>bt709</code> or <code>bt2020</code>, but both are strongly discouraged.</p>
 <p class="Note"><strong>Note:</strong> It is highly recommended to either set <code>assumed_gamma</code> to your system's display gamma for convenience, or set it to <code>1.0</code> for maximum realism. Using it for purely artistic purposes is strongly discouraged.</p>
@@ Line 426: / Line 426: @@
 </pre>
-<p>Instead of a numerical value, you can also use the <code>srgb</code> keyword to inform POV-Ray that the file conforms to the sRGB standard. {{New}} in version 3.7.1, you can also specify <code>bt709</code> or <code>bt2020</code> to inform POV-Ray that the file is gamma-encoded using the ITU-R BT.709 or BT.2020 transfer functions, respectively</p>
+<p>Instead of a numerical value, you can also use the <code>srgb</code> keyword to inform POV-Ray that the file conforms to the sRGB standard. {{New}} in version 3.8, you can also specify <code>bt709</code> or <code>bt2020</code> to inform POV-Ray that the file is gamma-encoded using the ITU-R BT.709 or BT.2020 transfer functions, respectively</p>
 <p class="Note"><strong>Note:</strong> Specifying <code>gamma bt709</code> or <code>gamma bt2020</code> only affects the <em>transfer function</em> used. Specifically, it does <em>not</em> affect the digital representation of nominal black and white, which remain at 0 and 255 (presuming 8-bit encoding), respectively, as opposed to 16 and 235 for full-fledged ITU-R BT-709 encoding.</p>
@@ Line 442: / Line 442: @@
    <li>For OpenEXR and Radiance HDR, POV-Ray will presume the data to be linear, as per official file format specification.</li>
    <li>For PNG, POV-Ray will presume the image data to be encoded according to file header information (currently sRGB or gAMA chunks); in the absence of such information, POV-Ray will presume sRGB-compliant encoding as per official recommendation.</li>
-   <li>For PPM and PGM, POV-Ray will currently presume the image data to match the <code>assumed_gamma</code> (in other words, no gamma adjustment will be performed by default). {{New}} in version 3.7.1, POV-Ray will presume the image data to comply with the Netpbm specification, i.e. being gamma-encoded using the ITU-R BT.709 transfer function.</li>
+   <li>For PPM and PGM, POV-Ray will currently presume the image data to match the <code>assumed_gamma</code> (in other words, no gamma adjustment will be performed by default). {{New}} in version 3.8, POV-Ray will presume the image data to comply with the Netpbm specification, i.e. being gamma-encoded using the ITU-R BT.709 transfer function.</li>
    <li>For any other file formats, POV-Ray will presume sRGB-compliant encoding, to match either official recommendations or common practice.</li>
 </ul>

@@ Line 241: / Line 241: @@
 <tr>
    <td width="320px">
-     <p class="tabletext">As a raytracing engine, POV-Ray internally needs to represent colors using <em>linear</em> brightness values to produce physically accurate results. However, the majority of contemporary digital image processing tools and file formats do <em>not</em>. This comes as a surprise to most people, probably because the human visual perception is non-linear as well, as can be demonstrated in the render to the right, generated with POV-Ray using physically realistic settings:</p>
+     <p class="tabletext">As a raytracing engine, POV-Ray internally needs to represent colors using <em>linear</em> light intensity values to produce physically accurate results. However, the majority of contemporary digital image processing tools and file formats do <em>not</em>. This comes as a surprise to most people, probably because the human visual perception is non-linear as well, as can be demonstrated in the render to the right, generated with POV-Ray using physically realistic settings:</p>
    </td>
      <td width="320px">
@@ Line 255: / Line 255: @@
 </table>
-<p>Both front and second row show spheres with pigments increasing from <code>rgb 0.0</code> to <code>rgb 1.0</code>. When asked which of them increases linearly, with a <em>medium grey</em> at the center, most people will go for the front row without too much hesitation. And in fact the pigment of the front center sphere <em>does</em> correspond to what Photoshop or similar image processing software would normally call <em>50% grey</em>, but the pigment is a mere 21.8% as bright as the rightmost one. The true 50% brightness sphere sits right behind it.</p>
+<p>Both front and second row show spheres with pigments increasing from <code>rgb 0.0</code> to <code>rgb 1.0</code>. When asked which of them increases linearly, with a <em>medium grey</em> at the center, most people will go for the front row without too much hesitation. And in fact the pigment of the front center sphere <em>does</em> correspond to what Photoshop or similar image processing software would normally call <em>50% grey</em>, but as a matter of fact it reflects only 21.8% as much light as the rightmost one. The sphere truly reflecting 50% as much light sits right behind it.</p>
 <p>A corresponding nonlinearity can be found in the traditional internal representation of colors in digital image processing, as implemented in file formats, graphics cards frame buffers, display APIs and so forth. Using one byte per colour component, and black and white represented by (0;0;0) and (255;255;255) respectively, a value of (128;128;128) will typically be used to encode a light intensity of just about 20%. To make matters a bit more complicated, the actual light intensity seen on the computer display may vary from one computer to the next, not only due to a historical lack of standardization in the PC display and graphics hardware market, but also due to factors such as electrical tolerances and even aging of the display. In professional environments, displays are therefore <em>calibrated</em> at regular intervals.</p>
@@ Line 350: / Line 350: @@
 ====Gamma in Output Images====
-<p>Besides being used internally in most contemporary digital image processing software, non-linear color representations are also used in most conventional image file formats. This is often called <em>gamma pre-correction</em>, in the sense that the original linear brightness information has already been transformed by a gamma function to compensate for display non-linearity. Unfortunately, due to the large variety of display gamma in the world of computing, the gamma value used for pre-correction traditionally followed no set standard either.</p>
+<p>Besides being used internally in most contemporary digital image processing software, non-linear color representations are also used in most conventional image file formats. This is often called <em>gamma pre-correction</em>, in the sense that the original linear light intensity information has already been transformed by a gamma function to compensate for display non-linearity. Unfortunately, due to the large variety of display gamma in the world of computing, the gamma value used for pre-correction traditionally followed no set standard either.</p>
 <p>In recent years the situation has changed, partly due to the adoption of the sRGB standard as the official recommendation for the World Wide Web, with major file format specifications following suit, and partly due to the advent of new file formats like PNG designed right from the start for a standardized way of gamma handling. (For such file formats, it is customary to speak of non-linear color representation not as <em>gamma pre-correction</em>, but rather as <em>gamma encoding</em>.) By now, for virtually all contemporary file formats there exists either a clear specification of how to handle gamma, or an official recommendation to adhere to the sRGB standard.</p>
@@ Line 367: / Line 367: @@
 <ul>
-   <li>For OpenEXR and Radiance HDR, which are officially specified to store linear brightness values, POV-Ray <em>always</em> stores linear values, ignoring the <code>File_Gamma</code> setting.</li>
+   <li>For OpenEXR and Radiance HDR, which are officially specified to store linear light intensity values, POV-Ray <em>always</em> stores linear values, ignoring the <code>File_Gamma</code> setting.</li>
    <li>For PNG, which explicitly allows different encoding gamma values, POV-Ray will interpret the <code>File_Gamma</code> setting as the decoding gamma to encode for, and <em>always</em> write corresponding metadata into the header; as a result, the image will always look virtually identical irregardless of the <code>File_Gamma</code> setting; however, to minimize visible encoding artifacts like color banding, it is strongly recommended to use a setting of around 2.2, or <code>sRGB</code>. If <code>File_Gamma</code> is not specified, PNG output defaults to <code>sRGB</code>. {{New}} in version 3.7.1, note that a setting of <code>BT709</code> or <code>BT2020</code> is possible, but cannot be conveyed correctly via PNG metadata and is therefore strongly discouraged for this file format.</li>
    <li>{{New}} in version 3.7.1, for Netpbm PPM, which is officially specified to store gamma-encoded values using the ITU-R BT.709 transfer function, POV-Ray adheres to the Netpbm standard by default. However, if the <code>File_Gamma</code> setting is specified, POV-Ray will interpret it as a display gamma to pre-correct for, to account for the widespread use of competing de-facto standards, most notably the use of linear encoding (corresponding to a setting of <code>File_Gamma=1.0</code>) or sRGB gamma pre-correction (corresponding to a setting of <code>File_Gamma=sRGB</code>).</li>