Ive <"ive### [at] lilysoftorg"> wrote:
> 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.

Agreed - for CRTs it's not ideal (but better than nothing); scaling the checker
pattern by <5,1,1> or something alike should help. For TFT's it does a pretty
good job - especially through the anti-aliasing, which in the upper part of the
image will blur some of the squares to 50% grey in a moiree-like fashion, giving
you prominent moiree-like effects if gamma isn't set properly.

> > (3) CHOOSE A PROPER OUTPUT FILE GAMMA
>
> > Otherwise, choosing the same as your
> > Display_Gamma is not a bad idea either,
>
> why would this be a good choice?

Because chances are that your standard image viewers don't care about gamma.


> > (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.

Be assured that it *is* true - I actually *tested* it.


Setup was as follows:

- added another plane to that gamma test shot
- mapped the (.png) *output* of a previous run to that plane
- size the texture so that antialiasing would kick in on the checkered part

Antialias did kick in on the texture, and did blur the checkered parts to what I
guess was a nice 50% grey - but the circle in the texture came out significantly
brighter than the original sphere, and so did the upper parts of the texture,
creating a prominent gradient.

Using the described procedure to convert to HDR did fix this issue. But the
proper gamma to choose in HDRShop did *not* depend on the File_Gamma with which
the file was *created*, but rather with which it was to be *used*.


Try for yourself.

I guess that's why it is "File_Gamma", and not "Output_File_Gamma".


> > - 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.

That's the "guess" part of my statement.


> > - 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.

I guess you're somewhat mistaken here: From all I see, the .HDR format *does*
seem to be able to use a gamma encoding for the pixel values, as specified in
the optional "GAMMA=..." header string. (I don't know what the default is, but
it may well be 1.0, i.e. linear encoding.)

At any rate, even though it may appear queer (it does to me), the approach I
described *does* do some good.

As you say yourself: Try it out!


> > - 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.

This is of course only true when using linear encoding. But yes, that's what
HDRShop outputs.

Note however that this loss of dynamic range primarily applies to low color
component values in an otherwise comparatively bright color (for dark colors,
all components will be scaled up and E adjusted accordingly), and therefore has
not much effect on overall brightness or color anyway.


> The more accurate OpenEXR is not supported by HDR-Shop and TIFF or PFM
> HDR formats are not supported by POV-Ray.

OpenEXR also has the disadvantage of being unavailable in out-of-the-box custom
builds of 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.

What's the point in having perfect ICC profile handling if POV-Ray gets the
gamma wrong.


> > 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.

The point is that the very same texture file - even when using HDR - will work
as a texture with some File_Gamma=... setting, but not with another.


> 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.

.... and probably doesn't work either (see above).

(Whatever IC is, anyway...)

Post a reply to this message