 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 }
}
}
(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).
(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 in the internet (being a compromise between
typical PC and Mac display gamma values). Otherwise, choosing the same as your
Display_Gamma is not a bad idea either, but be prepared for other people to
complain about your shots being too dark or too washed-out.
1.00 (no gamma pre-correction) would seem like a good choice theoretically, but
it's actually bad from a dynamics point of view.
(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).
(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! 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.)
- Load each texture in HDRShop, which will prompt you for a gamma value
("display curve"); choose the same value as your File_Gamma!
- Save the file in HDR format.
- 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoft org"> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> schreef in bericht
news:web.4a3a19c5b683ece6e01952250@news.povray.org...
>
> (Whatever IC is, anyway...)
>
>
http://www.lilysoft.org/IC/ic_index.htm
It can nicely be used instead of HDR-Shop, which (imo) asks to many private
information before downloading....
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
>> why would this be a good choice?
>
> Because chances are that your standard image viewers don't care about gamma.
>
So what you mean is: it's a good choice because some people might use a
crappy piece of software. Seems not like a good advice to me.
> 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".
>
You are using the output file as input file so how can this be a proof
that File_Gamma does effect the file used as image_map on input? Try a
much simpler test by just using any jpeg file as image_map, use various
settings for File_Gamma, keep Display_Gamma the same and compare.
> 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.)
>
Read the RADIANCE documentation about this, for short a RADIANCE HDR
file is always linear no matter what.
> 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!
No need to try, it is obvious that this does work, I do not even see
what seems so queer to you, I just mentioned some back drafts.
> 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.
Huh. There is no loss of dynamic range (how should it) there is 'just'
some loss of information caused by the way data is stored.
> What's the point in having perfect ICC profile handling if POV-Ray gets the
> gamma wrong.
In many cases (and ALL files created by e.g. Photoshop, or MOST files as
distributed within Poser or by DAZ) POV-Ray gets the gamma wrong
*because* it cannot handle ICC color profiles.
In fact POV-Ray only gets the gamma right when it uses a PNG file that
does include a gamma-chunk (but ONLY in this case), the sRGB-chunk, the
chromaticity-chunk and the ICC-chunk are ignored by POV-Ray and therefor
it does not work correctly with a PNG as e.g. written by Photoshop CS3.
And POV-Ray gets Radiance and OpenEXR right because it correctly assumes
a linear color space there.
> .... and probably doesn't work either (see above).
Nope. This definitely works (for exactly the same reason Radiance does
work) and I have no intention of getting into a fight about this because
both of our 'solutions' use the same workarounds to overcome some
serious limitations POV-Ray has in this regard.
>
> (Whatever IC is, anyway...)
And I was pretty sure you have visited my HP, maybe you should look
around a bit next time when you are there... ;)
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoftorg"> wrote:
> >> why would this be a good choice?
> >
> > Because chances are that your standard image viewers don't care about gamma.
> >
> So what you mean is: it's a good choice because some people might use a
> crappy piece of software. Seems not like a good advice to me.
Note that I didn't call it a good choice - I called it not a bad choice. It
depends on what you want to do with the image. I warned about the consequences,
so I see no problem there.
> You are using the output file as input file so how can this be a proof
> that File_Gamma does effect the file used as image_map on input? Try a
> much simpler test by just using any jpeg file as image_map, use various
> settings for File_Gamma, keep Display_Gamma the same and compare.
That's a bad suggestion, because it will change the output file gamma, and
therefore make the output files not comparable anyway.
What I observed was that
(1) The output file didn't work as input file.
(2) Processing the file as described did the job, provided that the "display
curve" value used in the generation of the HDR file matched the File_Gamma
setting.
(3) When changing the File_Gamma between generation of the image and using it as
input file, the process worked fine when using the new File_Gamma setting, but
did not when using the old value.
The first is proof that POV-Ray's gamma handling is still far from ideal.
The second and third, combined, are proof that there is *some* effect of
File_Gamma on *input* files - even if this is the case only for HDR images.
Note that the effects observed when using the image as input are clearly
indicative of a problem either with the input material, or the process of
coverting the input material to linear color space.
If the fix depends on a particular POV-Ray setting at the time the file is used
as *input*, it is also indicative of this setting affecting the conversion of
input material to linear color space.
Any logical loopholes I'm missing here?
> > 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!
>
> No need to try, it is obvious that this does work, I do not even see
> what seems so queer to you, I just mentioned some back drafts.
I wouldn't be that perplexed if the correction to be applied would depend on the
File_Gamma with which a file was *created* - but for some mysterious reason the
proper value to supply to HDRShop depends on the File_Gamma with which the file
is to be *used*.
> > 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.
>
> Huh. There is no loss of dynamic range (how should it) there is 'just'
> some loss of information caused by the way data is stored.
If you interpret that information loss as noise, we're talking about dynamic
range again.
> > What's the point in having perfect ICC profile handling if POV-Ray gets the
> > gamma wrong.
>
> In many cases (and ALL files created by e.g. Photoshop, or MOST files as
> distributed within Poser or by DAZ) POV-Ray gets the gamma wrong
> *because* it cannot handle ICC color profiles.
May well be. But I'm talking about solutions here, not root causes. And if that
solution gets the Gamma fixed at the cost of the ICC information, then I say
it's a comparatively small price to pay. (Although of course I agree that it
would be better to have both right.)
> In fact POV-Ray only gets the gamma right when it uses a PNG file that
> does include a gamma-chunk (but ONLY in this case), the sRGB-chunk, the
> chromaticity-chunk and the ICC-chunk are ignored by POV-Ray and therefor
> it does not work correctly with a PNG as e.g. written by Photoshop CS3.
> And POV-Ray gets Radiance and OpenEXR right because it correctly assumes
> a linear color space there.
Interestingly enough, it even gets the gamma from its own output wrong.
> > (Whatever IC is, anyway...)
>
> And I was pretty sure you have visited my HP, maybe you should look
> around a bit next time when you are there... ;)
Now that Thomas pointed me there, I found out that I did see the site earlier.
"IC" didn't stick with me though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> But I'm talking about solutions here, not root causes.
A solution does always require full knowledge of root causes, everything
else is 'just' a workaround. To be fair, I'm pretty sure you know that
and given the rest of your posts it seems very much that you are looking
for root causes yourself and just want to figure out everything by
yourself. Thats absolutely fine with me.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive,
I answered to your message last week (2 replies) but they could not be
delivered for 5 days apparently. Don't know why.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
>
> Choose a suitable output file gamma pre-correction; 2.20 is a very good choice,
> because it is a quasi-standard in the internet (being a compromise between
> typical PC and Mac display gamma values). Otherwise, choosing the same as your
> Display_Gamma is not a bad idea either, but be prepared for other people to
> complain about your shots being too dark or too washed-out.
BTW, a nice page to check your screen gamma:
http://www.lagom.nl/lcd-test/gamma_calibration.php
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
