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.


FS#88 - File output code does not properly handle negative color values

Attached to Project: POV-Ray
Opened by Christoph Lipka (clipka) - Tuesday, 23 March 2010, 14:45 GMT
Last edited by Christoph Lipka (clipka) - Saturday, 19 June 2010, 12:46 GMT
Task Type Definite Bug
Category Frontend → Image format
Status Closed
Assigned To Christoph Lipka (clipka)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 36
Due in Version 3.70 beta 37
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.

This task depends upon

Closed by  Christoph Lipka (clipka)
Saturday, 19 June 2010, 12:46 GMT
Reason for closing:  Fixed
Comment by Thorsten Fröhlich (thorsten) - 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.

Comment by Christoph Lipka (clipka) - 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.

Comment by Christoph Lipka (clipka) - Friday, 26 March 2010, 16:35 GMT
  • Field changed: Status (Investigating → Requires testing)
  • Field changed: Percent Complete (0% → 100%)

fixed with change #4932