User:Clipka/Gamma - Revision history

Clipka: /* PNG files */

2017-11-20T23:15:22Z

PNG files

Clipka: /* Gamma Settings */

2017-11-20T23:08:14Z

Gamma Settings

Clipka: /* Getting Individual Colors Right */

2017-11-20T22:46:13Z

Getting Individual Colors Right

Clipka: /* Getting The Output Image File Right */

2017-11-20T22:43:11Z

Getting The Output Image File Right

Clipka: /* Getting The Render Preview Right */

2017-11-20T22:29:38Z

Getting The Render Preview Right

Clipka: /* Getting Individual Colors Right */

2017-11-20T22:28:33Z

Getting Individual Colors Right

Clipka: /* Backward Compatibility */

2017-11-20T22:16:39Z

Backward Compatibility

Clipka: /* Migrating a Scene */

2017-11-20T22:09:39Z

Migrating a Scene

Clipka: /* PNG Input Files */

2010-11-28T15:21:41Z

PNG Input Files

Clipka: /* PNG Input Files */

2010-11-28T15:12:46Z

PNG Input Files

@@ Line 160: / Line 160: @@
 Due to architectural changes, bug fixes and improvements, backward compatibility for PNG input files is subject to the following exceptions:
-''(Note: Tbe following was written before POV-Ray 3.7 gamma handling was finalized, and may need reviewing.)''
+''(Note: The following was written before POV-Ray 3.7 gamma handling was finalized, and may need reviewing.)''
 * For palette-based PNG files (an uncommon flavour of PNG), backward compatibility is provided only if <code>assumed_gamma</code> is not specified.

@@ Line 65: / Line 65: @@
 * The <code>Display_Gamma</code> INI file setting, which specifies the ''display gamma'' for which to pre-correct render preview output.
 * The <code>gamma</code> scene file keyword applied to input images, which overrides the default ''decoding gamma'' rules.
-* The <code>gamma</code> scene file keyword applied to color values, which forces POV-Ray to apply gamma decoding to individual colors.
+* The <code>srgb</code> scene file keyword applied to color values, which forces POV-Ray to apply gamma decoding to individual colors.
 In addition to these, there is also an <code>Antialias_Gamma</code> INI file setting. however, this is a somewhat different animal, as it does not affect the colors in the scene, nor the output file encoding, but merely serves to optimize the antialiasing mechanism (see the section on antialiasing for details).

@@ Line 100: / Line 100: @@
 Note that in order for this syntax to give you proper color values, your colour picker software should be set up to use the sRGB colour space. (If you are not familiar with colour spaces,
-chances are your computer is reasonably close, as the colour space was designed specifically to approximate an average computer display.)
+chances are your computer is reasonably close, as the sRGB colour space was designed specifically to approximate an average computer display.)
 This syntax also allows for using the ''sRGB transfer function''; as the sRGB color space has become quite widespread through the influence of the World Wide Web, where it is the official standard,  it is probably an even better bet than a power-law function with a gamma of 2.2:

@@ Line 113: / Line 113: @@
 === Getting The Output Image File Right ===
-In order to get gamma right in output image files, you may or may not need to set the <code>File_Gamma</code> INI file variable, depending on the file format you use (note that the numeric value specifies the ''decoding'' gamma, which is the inverse of the ''encoding'' gamma; e.g. the default value of 2.2 corresponds to an encoding gamma of about 0.45):
+In order to get gamma right in output image files, you may or may not need to set the <code>File_Gamma</code> INI file variable, depending on the file format you use (note that the numeric value specifies the ''decoding'' gamma, which is the inverse of the ''encoding'' gamma; e.g. a value of 2.2 corresponds to an encoding gamma of about 0.45; alternatively, you may specify <code>File_Gamma=srgb</code> to use the
 * When using OpenEXR (<code>+FE</code>) or Radiance HDR (<code>+FH</code>) high dynamic range output, you do not need to worry about <code>File_Gamma</code>, as it has no effect with these formats; both are explicitly defined to store linear light intensity values, using floating-point or similar numeric representations instead of gamma encoding, and POV-Ray will always comply with this convention.
-* The PNG file format (<code>+FN</code>) provides a reliable means to inform reading applications (e.g. file viewers) about the encoding gamma used, so most software will display the output image virtually identical regardless of the encoding gamma you choose; however, it is recommended to leave <code>File_Gamma</code> at the default value of 2.2 for PNG files, as this will make the image display reasonably well even with applications that ignore the encoding gamma information, and is also of benefit to prevent excessive color banding in dark areas.
+* The PNG file format (<code>+FN</code>) provides a means to inform reading applications (e.g. file viewers) about the encoding gamma used, so software may display the output image virtually identical regardless of the encoding gamma you choose; however, this mechanism seems to be falling out of favour. It is recommended to leave <code>File_Gamma</code> at the default value (<code>srgb</code> for PNG files), as this will make the image display realiably well even with applications that ignore the encoding gamma information, and make the image conform to the web standard. The setting also prevents excessive color banding in dark areas, which would occur with <code>File_Gamma=1.0</code>.
-* All other output formats available in POV-Ray do not provide a reliable means to inform about the encoding gamma used; for these, <code>File_Gamma</code> needs to be set according to the encoding gamma expected by the reading application, or the image will not display correctly. If you don't know which gamma to use, or intend to distribute the image to a wide audience, it is recommended to leave <code>File_Gamma</code> at the default value of 2.2.
+* All other output formats available in POV-Ray do not provide a reliable means to inform about the encoding gamma used; for these, <code>File_Gamma</code> needs to be set according to the encoding gamma expected by the reading application, or the image will not display correctly. If you don't know which gamma to use, or intend to distribute the image to a wide audience, it is recommended to leave <code>File_Gamma</code> at the default value (<code>srgb</code> for most file types).
-<p class="Note"><strong>Note:</strong> POV-Ray now also allows to use the ''sRGB transfer function'' for display and file output, by setting <code>File_Gamma</code> and/or <code>Display_Gamma</code> to <code>sRGB</code>. While this is currently not the default, it is probably an even better choice.</p>
+Occasionally you may want to render a scene to generate a data set instead of an actual picture, and have the resulting data be encoded linearly (e.g. when creating height field data). You can achieve this by setting <code>File_Gamma</code> to 1.0. (Note that this is not strictly necessary when outputting to OpenEXR or Radiance HDR, but it doesn't hurt either; also note that when outputting to PNG you will not see a difference in some image viewers.) For such use cases, it is recommended to set <code>Antialias_Gamma</code> to 1.0 as well.
 === Getting Input Image Files Right ===

@@ Line 109: / Line 109: @@
 In a nutshell, the answer is: Calibrate your system, and encourage others to do the same.
-See [[Documentation:Reference_Section_1.1#Setting_your_Display_Gamma]].
+See [[Reference:Display_Output_Options#Setting_your_Display_Gamma]].
 === Getting The Output Image File Right ===

@@ Line 90: / Line 90: @@
 <p class="Note"><strong>Note:</strong> Transparency information is ''not'' normally gamma-encoded, so you'll want to apply this formula to R, G and B components only.</p>
-If you frequently pick colors, or feel more at home with defining colors by pixel values rather than physical brightness levels, you can use the <code>gamma</code> keyword to have POV-Ray do the computations automatically for you, e.g.:
+If you frequently pick colors, feel more at home with defining colors by pixel values rather than physical brightness levels, or want a more accurate conversion,
 <source lang="pov">
-#local MyColor = color rgb <255,128,0>/255 gamma 2.2;
+#local MyColor = color srgb <255,128,0>/255;
 </source>
 This syntax also allows for using the ''sRGB transfer function''; as the sRGB color space has become quite widespread through the influence of the World Wide Web, where it is the official standard,  it is probably an even better bet than a power-law function with a gamma of 2.2:
 === Getting The Render Preview Right ===

@@ Line 152: / Line 152: @@
 '''Under Construction'''
-In a nutshell, the answer is: Legacy scenes will generally continue to work, as long as they have a proper <code>#version</code> statement, and don't use <code>assumed_gamma</code> for artistic effect; a notable exception are PNG in- and output files.
+In a nutshell, the answer is: Legacy scenes will generally continue to work, as long as they have a proper <code>#version</code> statement; a notable exception are PNG in- and output files.
 ==== PNG files ====
@@ Line 170: / Line 158: @@
 PNG output file handling has been changed significantly in POV-Ray 3.7, and is not fully backward compatible. If the PNG output does not suit your needs, it is recommended to use a different output file format instead, and use an external image processing tool to convert to PNG if required.
-==== Planned Compatibility Behaviour ====
+Due to architectural changes, bug fixes and improvements, backward compatibility for PNG input files is subject to the following exceptions:
-For backward compatibility with legacy scenes, POV-Ray 3.7 will mimick the gamma handling of POV-Ray 3.6 if the scene has a <code>#version</code> statement specifying a version of 3.6x or earlier, and/or specifies an <code>assumed_gamma</code>, with the following exceptions:
+''(Note: Tbe following was written before POV-Ray 3.7 gamma handling was finalized, and may need reviewing.)''
 * For palette-based PNG files (an uncommon flavour of PNG), backward compatibility is provided only if <code>assumed_gamma</code> is not specified.

@@ Line 200: / Line 200: @@
 * Change <code>#version</code> to <code>3.7</code>.
 * Add <code>gamma 1.0</code> to any input image files.
@@ Line 214: / Line 213: @@
 * Change <code>#version</code> to <code>3.7</code>.
-* Remove the <code>assumed_gamma</code> statement.
+* Change <code>assumed_gamma</code> to <code>1.0</code>.
-* Add <code>gamma 2.2</code> to any color literal, except where ultimately used to compute non-color values.
+* Make use of the <code>srgb</code> keyword (or its siblings) for any color literals, except where ultimately used to compute non-color values.
-* Add <code>gamma 2.2</code> to any place where a non-color value is used as a color.
+* Make use of the <code>srgb</code> keyword (or its siblings) in any places where a non-color value is used as a color.
 * Add <code>gamma 1.0</code> to any input image file used for non-color purposes, e.g. transparency maps, bump maps, height fields, or mere data containers.
@@ Line 228: / Line 227: @@
 * Change <code>#version</code> to <code>3.7</code>.
 * Add <code>gamma 1.0</code> to any input image file used for non-color purposes, e.g. transparency maps, bump maps, height fields, or mere data containers.

@@ Line 184: / Line 184: @@
 Due to architectural changes, bug fixes and improvements, backward compatibility for PNG input files is subject to the following exceptions:
-* For palette-based PNG files (an uncommon flavour of PNG), backward compatibility is not provided whatsoever.
+* For palette-based PNG files (an uncommon flavour of PNG), backward compatibility is provided only if <code>assumed_gamma</code> is not specified.
 * For non-palette-based PNG files, backward compatibility is provided only if <code>assumed_gamma</code> is specified.
 * For PNG files carrying both an sRGB chunk and a fitting gAMA chunk, results will slightly differ.

@@ Line 184: / Line 184: @@
 Due to architectural changes, bug fixes and improvements, backward compatibility for PNG input files is subject to the following exceptions:
-* If <code>assumed_gamma</code> is specified and does not match the effective <code>Display_Gamma</code>, backward compatibility is not provided for palette-based PNG input files (an uncommon flavour of PNG).
+* For palette-based PNG files (an uncommon flavour of PNG), backward compatibility is not provided whatsoever.
-* If <code>assumed_gamma</code> is not specified, backward compatibility is provided only for palette-based PNG input files.
+* For non-palette-based PNG files, backward compatibility is provided only if <code>assumed_gamma</code> is specified.
-* For PNG input files carrying both an sRGB chunk and a fitting gAMA chunk, results will slightly differ.
+* For PNG files carrying both an sRGB chunk and a fitting gAMA chunk, results will slightly differ.
-* For PNG input files carrying an sRGB chunk but no gAMA chunk (or a wrong one), backward compatibility is not provided.
+* For PNG files carrying an sRGB chunk but no gAMA chunk (or a wrong one), backward compatibility is not provided.
 If you experience problems with a PNG input file, it is suggested to explicitly specify the decoding gamma to be applied for that particular image, using the <code>gamma</code> statement.