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.

Attached to Project: POV-Ray
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.

Closed by  Christoph Lipka
Saturday, 19 June 2010, 12:46 GMT
Reason for closing:  Fixed
Thorsten Fröhlich commented on Wednesday, 24 March 2010, 15:22 GMT

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.

Christoph Lipka commented on Wednesday, 24 March 2010, 16:28 GMT

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.

Christoph Lipka commented on Friday, 26 March 2010, 16:35 GMT

fixed with change #4932


Available keyboard shortcuts


Task Details

Task Editing