So, here is the current status of what I'm busy implementing:

* Philosophy

- POV-Ray shall always operate in a linear RGB color space based on 
light intensity (as opposed to perceived brightness), to properly 
compute physical effects. (In the long run, this should also include a 
clear definition of the RGB primaries and white point, but at present 
this definition is limited to gamma issues.)

- In General, all image-format input files sall be converted to 
POV-Ray's operating color space before any further processing. (In the 
long run, this should include full color profile handling; however, at 
present it is limited to gamma correction.)

- For file formats with an official specification of gamma handling (and 
later also regarding color profile handling), conversion shall be based 
on that definition or recommendation. For any other files, conversion 
shall be based on a common assumed input file color space, which shall 
be configurable in the scene file and default to sRGB.

- Image-format input files used immediately in certain language 
constructs obviously indicating that they are mere data containers (e.g. 
height fields) shall be exempt from the aforementioned conversion, and 
the raw encoded values used instead. (Note however that this does not 
apply to indirect use of input image files.)

- For any individual image input file (including files otherwise exempt 
from conversion), the user shall be able to override the conversion 
rules via SDL, in order to handle files not adhering to standards, or 
adapt to the intended use of the file.

- To the extent possible in the framework designed to achieve these 
goals, reasonable effort shall be made to emulate POV-Ray 3.6 behaviour 
for legacy scenes. However, where such behaviour is obscure and/or 
difficult to emulate consistently, backwards compatibility shall not be 
preserved.


* Syntax:

- The assumed input file gamma (to be used for all input file formats 
lacking a proper definition or recommendation) can be set in the 
global_settings section as follows:

     global_settings {
         file_gamma GAMMA
     }

where GAMMA is either the keyword 'srgb' (to indicate that input files 
are assumed to match sRGB) or a numeric expression (to indicate that 
input files are assumed to be pre-corrected for displays with the 
specified gamma value).

(Note that sRGB is /not/ perfectly equivalent to a gamma 2.2 
pre-correction, though it comes very close.)

At present, the setting is global, and should therefore /not/ be messed 
with in "library" include files.

- The input file gamma of a particular file can be overriden by 
specifying "file_gamma GAMMA" after the file name, e.g.:

     image_map {
         exr "foobar.exr" file_gamma 1.8
         interpolate 2
     }

(Note that for parser design reasons, the "file_gamma" statement must 
/immediately/ follow the file name.)

This will bypass any gamma or gamma-alike adjustment normally performed 
according to the file format standards, and use a decoding gamma curve 
as specified by the user instead.


* Legacy Behaviour:

- In the presence of an 'assumed_gamma 1.0' statement, gamma correction 
of input files is always turned on, but global file_gamma defaults to 
1.0, effectively disabling gamma correction of input files /by default/ 
(for most file types; see below).

- In the presence of an 'assumed_gamma 2.2' statement (or whatever 
happens to be the hard-coded default Display_Gamma on the particular 
machine), gamma correction of input files is always turned /off/. The 
file_gamma statement can still be used on individual files to enforce 
gamma-adjustment, in order to allow for some flexibility, but it will 
/not/ automatically compensate for the assumed overall scene gamma.

- Any other value of 'assumed_gamma' will be ignored (matching the 
behaviour of all recent betas).

- Global 'file_gamma' and 'assumed_gamma' will not mix; if both are 
encountered, 'assumed_gamma' will be ignored.

- In POV-Ray 3.6, non-paletted PNG files with gAMA chunks were the 
/only/ input files which were ever gamma-adjusted, and these were 
/always/ gamma-adjusted (unless used in a data-container context). This 
will be changed even for legacy scenes; fortunately, this will not give 
different results for standard PNG files; however, it /will/ change the 
look of PNG files with a gAMA of 1.0.


* Related Changes:

- 8-bit paletted PNG files will now be gamma-adjusted (or not) just like 
ordinary 24/32-bit PNG fils.

- An sRGB chunk in PNG files will now take precedence over a gAMA chunk, 
and will actually cause the sRGB transport function to be applied 
instead of a plain 2.2 power law gamma; this is likely to cause minor 
differences in the look of most PNG input images, but will be "more 
correct".

- Gamma adjustment of files is now exclusively performed /after/ 
conversion to floating-point format, in order to improve quality.

- Several bugs in the file readers have been eliminated.

- "Out-of-the box" transparency support for GIF files has been added.


* Implementation

- High dynamic range images (presently only OpenEXR and Radiance HDR) 
are gamma-corrected "on the fly" while reading the file.

- Paletted images are gamma-corrected by adjusting their palette data 
accordingly.

- Non-paletted integer images are kept in "native" format without 
applying gamma adjustment, in order to save memory. Gamma correction is 
instead applied at render time, using a pre-computed lookup table in 
hope of gaining a bit of a speed advantage. (Lookup tables are shared 
between images with the same gamma curve of course.)


Hmm... did I forget to mention anything? Probably yes, but I guess I 
can't help it :-)

Post a reply to this message