clipka wrote:

> Gamma handling is still a difficult issue; here's how to approach it *properly*:
> 
> (1) MATCH YOUR DISPLAY
> 
> Make sure you have your Display_Gamma set to properly. The following test scene
> may help:
> 
> // Render with +w800 +h600 +am2 +r3 +a0.1
> 
> #if (version <= 3.6) global_settings { assumed_gamma 1.0 } #end
> 
> camera {
>   location  <0.0, 0.0, -4.0>
>   direction 1.5*z
>   right     x*image_width/image_height
>   look_at   <0.0, 0.0, 0.0>
> }
> 
> background { rgb 0.5 }
> 
> plane { -z, -1
>   texture {
>     pigment { checker color rgb 1 color rgb 0 scale .02 }
>     finish { ambient 1 diffuse 0 specular 0 }
>   }
>   rotate x*45
> }
> 
> sphere { 0.0, 1
>   texture {
>     pigment { color rgb 0.5 }
>     finish { ambient 1 diffuse 0 specular 0 }
>   }
> }

This is NOT a good test for gamma on a CRT monitor, where the influence 
of the dynamic quality of the signal while horizontal tracing is much 
greater than the actual gamma. Only horizontal lines should be used for 
dithering gray-shades on a CRT. I'm not so sure about TFT's but it might 
work there.


> (2) DO *NOT* ADJUST OUTPUT GAMMA IN YOUR SCENE FILE
> 
> Do not make use of the global "assumed_gamma" statement (or set it to 1.0 in
> versions prior to 3.7).
> 
Agreed.


> (3) CHOOSE A PROPER OUTPUT FILE GAMMA
> 
> Choose a suitable output file gamma pre-correction; 2.20 is a very good choice,
> because it is a quasi-standard 

not a 'quasi-standard' it IS the W3C standard.

>in the internet (being a compromise between
> typical PC and Mac display gamma values). 

that's just a myth but doesn't matter in this context

> Otherwise, choosing the same as your
> Display_Gamma is not a bad idea either,

why would this be a good choice?

> but be prepared for other people to
> complain about your shots being too dark or too washed-out.

Exactly.


> 1.00 (no gamma pre-correction) would seem like a good choice theoretically, but
> it's actually bad from a dynamics point of view.
> 
Ok.


> (4) FIX YOUR COLORS
> 
> Make sure *all* your individual color values are *NOT* gamma pre-corrected, but
> linear - which means that you usually will have to "fix" colors from external
> sources (e.g. colors picked from an image in Photoshop or the like). A macro
> should do the job (I didn't throw one together yet, because I usually do color
> tweaking in POV anyway).
> 
Right.

> 
> (5) FIX YOUR TEXTURES
> 
> This is the trickiest part: By specifying File_Gamma, not only will POV-Ray
> create output files with the corresponding gamma pre-correction, but it also
> affects POV-Rays gamma handling of all *input* files!

This is NOT true (for the current beta 32), please do check such things 
before stating them.


> Unfortunately, there's
> currently no mechanism to override this. Worse yet: Even a file created with
> POV-Ray itself may not work properly as an input file, even if created with the
> same File_Gamma settings!
> 
> The good news is, the issue can be worked around as follows:
> 
> - Identify all the *color* texture files you're working with. (Don't bother
> about bump maps, specular maps or transparency maps; I guess they should be
> ok.)
> 
This greatly depends.


> - Load each texture in HDRShop, which will prompt you for a gamma value
> ("display curve"); choose the same value as your File_Gamma!
>
Huh? This does not make sense because when you choose file_gamma of 
let's say 1.0 (e.g. for OpenExr output - where btw. file_gamma is 
ignored by POV anyway 'cause HDR formats are per definition in linear 
color space) this will not help at all. Try it out!
What should be done (if you go this route) select for e.g. JPEG files 
always gamma 2.2.

> - Save the file in HDR format.
>
I guess you mean the RADIANCE format here, so be aware that this goes 
ahead with some loss of information because the RGBE storage format of
RADIANCE will not cover the full (low) dynamic range of a 8 bit/sample 
image.
The more accurate OpenEXR is not supported by HDR-Shop and TIFF or PFM 
HDR formats are not supported by POV-Ray.
Note also that HDR-Shop completely ignores any ICC color profile within 
JPEG - and these are very common for e.g. Poser textures and in many 
cases are NOT just sRGB profiles.


> - In POV-Ray, use the HDR file instead of the original one.
> 
> I'm not sure what *exactly* this does, but it works; when placed in a scene with
> ambient 1, the texture will now be output exactly as it was input. At last.

I'm not sure about what exactly you are not sure here. You are just 
using a HDR image as texture map (that is - as already mentioned - in 
linear color space by definition) and POV will use it as it is.

As an alternative what I do: I use IC to convert JPEG files to 8 or 16 
bit/sample PNG files.
This has 3 advantages:
- no loss of information.
- ICC color profiles (and any other colorimetric information) is 
properly handled.
- much smaller file size.

As an important side note: I really mean 'use IC' not because I want to 
advertise it, it's not commercial anyway, but because a lot of other 
software will write PNG files that are not correctly interpreted by 
POV-Ray. Including e.g. Photoshop CS3 that does not add a gamma-chunk to 
the PNG file but uses the colorimetric-chunk instead - and this one is 
just ignored by POV-Ray (and BTW so is also the sRGB-chunk).


-Ive

Post a reply to this message