Am 20.09.2014 13:48, schrieb Thomas de Groot:
> On 19-9-2014 16:10, clipka wrote:
>> (2) PoseRay writes image_map statements with a "gamma srgb" and bump_map
>> statements with a "gamma 1.0"; both would be redundant if the scene
>> specified "#version 3.7", and it is actually recommended to /not/ use
>> these statements unless working with image files that are known to cause
>> problems with POV-Ray's automatic image gamma handling. (And while I
>> haven't tested it, using "gamma srgb" with high dynamic range images by
>> default would actually be outright wrong, because these file formats
>> default to a gamma of 1.0.)
>
> To be sure: Is this valid for /all/ usual formats as used by Poser for
> instance? jpg? png? tga?

Short answer: Yes.


Long answer:

The revised gamma handling in POV-Ray 3.7 is based on the presumption 
that each and every file format has either a documented standard, or a 
de-facto standard, for gamma encoding/precorrection. Where such a 
clear-cut standard does not exist, POV-Ray 3.7 picks one of the variants 
in common use, and documents which one that is. Unless the user 
specifies otherwise, POV-Ray will presume any input file to adhere to 
that standard (and also generate output files adhering to that standard).

For jpg, POV-Ray 3.7.0 presumes that the file adheres to the W3C 
recommendation of using the sRGB colour space and encoding function.

For png, POV-Ray 3.7.0 presumes that any encoding gamma information in 
the file header is correct: If an sRGB tag is present, the file is 
presumed to use the sRGB colour space and encoding function. Otherwise, 
if a gAMA tag is present, the file is presumed to be encoded with that 
gamma. If none of these is present, the file is presumed to adhere to 
the W3C recommendation of using the sRGB colour space and encoding function.

For tga, POV-Ray 3.7.0 presumes that the file uses the sRGB colour space 
and encoding function.

One thing that should be noted is that the above is not cut into stone: 
The policy is to adhere to official and de-facto standards, and where 
this is currently not the case POV-Ray can be considered to be wanting. 
For instance, future versions will most likely also honor colour profile 
information embedded in jpg files, but as this goes beyond mere gamma 
handling it is currently not implemented yet.

> with the exception of course of transparency maps as mentioned below by
> FlyerX, but I suppose also with all maps used as pigment_pattern{} ?

POV-Ray will apply gamma conversion to all image files that, according 
to the context in which they are used, seem to contain actual image 
data, i.e. 2d arrays of actual colour data. This includes all 
image_map{...} statements, even if they are later wrapped in something 
else like pigment_pattern{...}. (To make the rule as easy as possible, 
and also limit parser complexity, this also applies even if the wrapping 
is done in-place.)

At the same time, POV-Ray will /not/ apply gamma conversion (instead 
using the raw image data) to all image files that, according to the 
context in which they are used, seem to be "misused" as containers for 
non-colour data. This includes bump maps, but also height fields. Again, 
POV-Ray will not try to figure out what the data /actually/ ends up as; 
so if you find a way to reconstruct the original colour data from such a 
language construct, you will find that gamma conversion will not have 
happened.

In any case, a user-specified "gamma" statement will always take 
precedence. Such a statement will always be interpreted as the presumed 
gamma of the image.

Now I can't tell off the top of my head whether this will always cause 
conversion to the assumed_gamma, or whether bump maps and the like will 
still be converted to linear. IIRC the latter is the case, but I'd have 
to look it up.

Post a reply to this message