The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Christoph Lipka - 2010-03-23
Last edited by Christoph Lipka - 2010-06-19
FS#88 - File output code does not properly handle negative color values
File output code for virtually all file formats performs gamma correction on unclipped color values, which leads to issues when color values happen to be negative for some reason and gamma does not happen to be an integer value such as 1.0 or 2.0. As a consequence, subsequent steps (clipping and converting to integer) apparently produce compiler-dependent results. Compiled with Microsift or Intel compilers, POV-Ray seems to write zero brightness in such cases, while compiled with g++ 4.4 (and possibly other compilers) it seems to write full brightness instead.
(See thread news://news.povray.org:119/4ba819f6@news.povray.org for examples.)
The proper solution should be to apply gamma correction after clipping.
Gamma correction after clipping would mean that the dynamic range of an image would be reduced to a value below what is supported by the file format. I think what you mean is that clipping the minimum value (to zero) should be handled before gamma correction, while the full clipping (does the gamma code accept negative gamma values?) should be performed after gamma correction.
Order of clipping is not a problem with gamma correction, as gamma adjustment always maps values in the range [0.0; 1.0] to that very same range (unless the gamma value is zero or negative, but such values are bogus anyway).
An exception are HDR file formats of course, but for those clipping is limited to making sure color values don't get negative anyway.
Should the gamma correction mechanism at some time in the future be encapsulated in a dedicated function or class so that the very same code would be shared among all file formats, the pre-gamma-correction clipping must of course be limited to forcing the value to the non-negative domain, while enforcing the upper limit would have to remain the job of the file format handler.
fixed with change #4932