I'm pretty sure that I am not, and will not be, the only one who gets
confused about the new (I suppose better) approach at gamma correction in
POV-Ray 3.7, which differs from the way 3.6 did it, and which results in
images looking different, and different approaches having to be used.
This will create a lot of questions related to this subject, repeated
over and over, especially when the final 3.7 is published.

  Thus I think it would be a great idea if we created a concise, clear and
easy-to-understand section to be included in the official documentation so
that we can simply direct people to it rather than having to explain things
over and over again. I was hoping we could come up with something in this
thread.

  Preferably this tutorial would be somewhere in the documentation that makes
it prominent and visible, rather then buried under hundreds of similar
subsections.

  My ideas about what this section should have:

  1) A simple and clear explanation behind the reasoning and motivation behind
the new gamma correction approach, why it makes sense and why it's better
than what POV-Ray 3.6 did.

  Also: Why POV-Ray 3.7 will render scenes differently than 3.6, when using
default settings and "#version 3.6" is not used.

  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
why they shouldn't be abused for visual effects (because that's not their
purpose).

  3) The difference between PNG and other output image file formats in this
regard.

  4) How to render an old 3.6 scene using POV-Ray 3.7 so that it will look
the same (basically, by adding "#version 3.6" to the scene file; I also hope
that the small problem of the gamma metadata being written to the PNG file
regardless of that #version directive being used gets fixed, for full
backwards "emulation").

  5) How to pre-gamma-correct input images (if and when this feature is
implemented in POV-Ray 3.7) and why this has to be done (and why it doesn't
need to be done for input PNG images which already have a proper gamma
metadata in them). Likewise, how to pre-gamma-correct color values from
other programs (such as color pickers).

  Might not be the proper place for this, but perhaps also:

  6) If the user needs to do it, how to create an image which has no gamma
correction at all, only non-corrected raw pixels. The example of rendering
an image to be used for creating a heightfield could be mentioned.

-- 
                                                          - Warp

Post a reply to this message

On 6 Sep 2009 08:02:40 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  I'm pretty sure that I am not, and will not be, the only one who gets
>confused about the new (I suppose better) approach at gamma correction in
>POV-Ray 3.7

You're not the only one and I think that it is a good idea.
Onwards and upwards. :)
-- 

Regards
     Stephen

Post a reply to this message

Absolutely correct! Imo, this should be placed in the section "Getting 
started" of the "Introduction to POV-Ray"

Thomas

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4aa3a4e0@news.povray.org...
>  Thus I think it would be a great idea if we created a concise, clear and
> easy-to-understand section to be included in the official documentation so
> that we can simply direct people to it rather than having to explain 
> things
> over and over again.

Agreed! If you'll gather the information and get it all polished up, then 
post your final on a talk page (on the Wiki) where it should be included, 
I'll make sure it get's in the next gen documentation!

Jim

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Likewise, how to pre-gamma-correct color values from
> other programs (such as color pickers).

  About that... I wonder if POV-Ray should offer some kind of function to
do that, for convenience. In the same way as eg. degrees() and radians()
exist for convenience, even though they don't really save a whole lot of
work compared to if they didn't exist.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> Likewise, how to pre-gamma-correct color values from
>> other programs (such as color pickers).
> 
>   About that... I wonder if POV-Ray should offer some kind of function to
> do that, for convenience. In the same way as eg. degrees() and radians()
> exist for convenience, even though they don't really save a whole lot of
> work compared to if they didn't exist.

I think that definitely yes, POV-Ray should have such a feature. It is 
perfectly possible to roll your own macro to do that, but if POV-Ray is 
going the full way for proper gamma handling, it should - I'd even say 
/must/ - provide some standard procedure to do it, if only to make a 
clear statement along the lines of "yes, /this/ is the right way to deal 
with it". And I'd go as far as to say that it should work without having 
to include a particular file, so it should be a built-in language 
contruct, not just a macro.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa43552$1@news.povray.org...
>
> I think that definitely yes, POV-Ray should have such a feature. It is 
> perfectly possible to roll your own macro to do that, but if POV-Ray is 
> going the full way for proper gamma handling, it should - I'd even say 
> /must/ - provide some standard procedure to do it, if only to make a clear 
> statement along the lines of "yes, /this/ is the right way to deal with 
> it". And I'd go as far as to say that it should work without having to 
> include a particular file, so it should be a built-in language contruct, 
> not just a macro.

Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
a good example of such a picker. I use it quite a lot and I recommend it 
warmly. Built into POV-Ray would be a nice addition.

Thomas

Post a reply to this message

Thomas de Groot schrieb:
>> And I'd go as far as to say that it should work without having to 
>> include a particular file, so it should be a built-in language contruct, 
>> not just a macro.
> 
> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
> a good example of such a picker. I use it quite a lot and I recommend it 
> warmly. Built into POV-Ray would be a nice addition.

Well, I wasn't thinking about a built-in color picker, but a built-in 
language syntax for gamma conversion.

Of course having its own built-in color picker would be a neat feature 
(and I do second this idea), but for instance on Unix systems, where 
POV-Ray does not come with an "IDE", a feature built into the SDL to 
perform gamma conversion math would still be required.

Post a reply to this message

Thomas de Groot wrote:
> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
> a good example of such a picker. I use it quite a lot and I recommend it 
> warmly. Built into POV-Ray would be a nice addition.
> 

Are you aware that this tool (like most others) will not apply the 
required inverse gamma correction and will result in the usual washed 
out colors similar to jpeg image maps when used with 3.7 or 
assumed_gamma 1.0 ?
And to mention it again: wrong gamma correction does not only give wrong 
brightness intensities, it changes also the hue.

-Ive

Post a reply to this message

"Ive" <"ive### [at] lilysoftorg"> schreef in bericht 
news:4aa4f79e@news.povray.org...
> Thomas de Groot wrote:
>> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) 
>> is a good example of such a picker. I use it quite a lot and I recommend 
>> it warmly. Built into POV-Ray would be a nice addition.
>>
>
> Are you aware that this tool (like most others) will not apply the 
> required inverse gamma correction and will result in the usual washed out 
> colors similar to jpeg image maps when used with 3.7 or assumed_gamma 1.0 
> ?
> And to mention it again: wrong gamma correction does not only give wrong 
> brightness intensities, it changes also the hue.
>

Ah... yes...? I had not really/consciously thought of that... This means 
that picking a color from a RGB/HSL color chart in any paint application 
will show this problem?

Thomas

Post a reply to this message

Thomas de Groot wrote:
> Ah... yes...? I had not really/consciously thought of that... This means 
> that picking a color from a RGB/HSL color chart in any paint application 
> will show this problem?
> 

Yes. Unless it does not explicit state that the working color space is a 
linear one like e.g. scRGB (note the 'c'). You can use the histogram 
window of IC and move the mouse across the viewing window to get the 
color value of images in scRGB that could be used directly within 
POV-Ray. Press CTRL + left mouse button to 'lock' any value. This makes 
it easier when you move the mouse to the POV editor for writing the 
value down ;)
Should I add the possibility to copy the color value directly to the 
clipboard?

-Ive

Post a reply to this message

"Ive" <"ive### [at] lilysoftorg"> schreef in bericht 
news:4aa4fcf0@news.povray.org...
>
> Yes. Unless it does not explicit state that the working color space is a 
> linear one like e.g. scRGB (note the 'c'). You can use the histogram 
> window of IC and move the mouse across the viewing window to get the color 
> value of images in scRGB that could be used directly within POV-Ray. Press 
> CTRL + left mouse button to 'lock' any value. This makes it easier when 
> you move the mouse to the POV editor for writing the value down ;)

I had not yet found that in IC (shame on me)

> Should I add the possibility to copy the color value directly to the 
> clipboard?

Yes, that would be excellent.

Thomas

Post a reply to this message

By the way, there is a "palette" option in IC, but it is greyed out. How can 
we use it? That would be the correct color picker...

Thomas

Post a reply to this message

Thomas de Groot schrieb:
> By the way, there is a "palette" option in IC, but it is greyed out. How can 
> we use it? That would be the correct color picker...

I guess that's for GIF files and such, so maybe not what you seem to 
expect ;-)

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa60e3b$1@news.povray.org...
> I guess that's for GIF files and such, so maybe not what you seem to 
> expect ;-)

Oh pity.... I had high hopes..... :-)

I would like a *correct* palette as a color picker...

Thomas

Post a reply to this message

Ive wrote:

> Are you aware that this tool (like most others) will not apply the 
> required inverse gamma correction and will result in the usual washed 
> out colors similar to jpeg image maps when used with 3.7 or 
> assumed_gamma 1.0 ?
> And to mention it again: wrong gamma correction does not only give wrong 
> brightness intensities, it changes also the hue.


Proper gamma handling on input images is definitely needed, especially 
for formats that do not carry information, there needs to be a way of 
specifying the intended gamma for that image.

I can deal with adjusting the colors I use easily, but adjusting images 
could get tiresome.

I've found in images where I started with 3.7 or assumed_gamma of 1.0, I 
get the right saturation in the final image.
-- 
~Mike

Post a reply to this message

clipka wrote:
> Warp schrieb:
>>> Likewise, how to pre-gamma-correct color values from
>>> other programs (such as color pickers).
>> 
>>   About that... I wonder if POV-Ray should offer some kind of function to
>> do that, for convenience. In the same way as eg. degrees() and radians()
>> exist for convenience, even though they don't really save a whole lot of
>> work compared to if they didn't exist.
> 
> I think that definitely yes, POV-Ray should have such a feature.

In addition, a built-in gamma_correct() could use an internal lookup table
shared with the internal image-loading and image-saving functionality.
A macro couldn't do that.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> Likewise, how to pre-gamma-correct color values from
> >> other programs (such as color pickers).
> > 
> >   About that... I wonder if POV-Ray should offer some kind of function to
> > do that, for convenience. In the same way as eg. degrees() and radians()
> > exist for convenience, even though they don't really save a whole lot of
> > work compared to if they didn't exist.

> I think that definitely yes, POV-Ray should have such a feature.

  One problem I see with a gamma-precorrection function is that it can be
tedious to use if tons of colors have to be specified. For example, imagine
specifying a large color_map with tens of colors, each one of which would
have to be enclosed with some function call.

  Another option I can think of is to have some #-command which turns on
gamma pre-correction for all colors from that point forward. It would be
local to the current file, so #included files wouldn't be affected. That
way you could do something like:

#assume_gamma 2.2

color_map
{ [0 rgb <whatever>]
  [.1 rgb <whatever>]
  etc...
}

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Another option I can think of is to have some #-command which turns on
> gamma pre-correction for all colors from that point forward. It would be
> local to the current file, so #included files wouldn't be affected. That
> way you could do something like:
> 
> #assume_gamma 2.2
> 
> color_map
> { [0 rgb <whatever>]
>   [.1 rgb <whatever>]
>   etc...
> }

One problem with this is POV-Ray's way of handling colors very much the 
same as vectors. So you may have 3rd-party macros expecting and/or 
returning vectors instead of colors, which will pretty much mess up the 
whole thing:

- You can't gamma-correct vectors.
- At the moment where the vectors are turned into colors, the 
information about which file they were defined will be long forgotten.
- Some vectors intended to become colors may be subject to math (e.g. to 
tune the brightness of a light) before being explicitly turned into 
colors, but gamma-correction will normally have to be applied before the 
math.

I agree that this would be beneficial, but with the current SDL 
structure it would open up a can of worms, and probably cause more 
confusion than ease of use. (One more reason why I do advocate a 
dedicated syntax for color literals in a POV 4 SDL)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>I'm pretty sure that I am not, and will not be, the only one who gets
>confused about the new (I suppose better) approach at gamma correction in
>POV-Ray 3.7,

I add my voice to those who are sufficiently confused and frustrated already
to state that you are definitely already not the only one.

Here's my 2 cents on your list:

>  1) A simple and clear explanation behind the reasoning and motivation behind
> the new gamma correction approach, why it makes sense and why it's better
> than what POV-Ray 3.6 did.

That's good information to have but it should definitely not be number 1) on the
list. I would put this into some appendix somewhere ("If you were
wondering ... see section ...").

For me as a user of POVray, what is important is "how do I make the program
do this" and "what did I do wrong when the output looks like X rather than like
Y".

The precise reasoning behind any part of the behaviour is mostly secondary.
Interesting, for sure, but not what I would fire up the documentation for.

>  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
>values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
>why they shouldn't be abused for visual effects (because that's not their
>purpose).

I still don't understand this, to be honest. If PCs "usually" have a gamma
of 2.2, why do I still have to tell the PC version of POVray these things? Why
can the *default* behaviour on a PC not be the one that the majority of
users will expect?

Why do I have to futz around with ini files (and make the same change every
single time a new beta comes out because the old ini files get replaced with
the new ones every time) just to get the behaviour that one would expect for
a run-of-the-mill PC?

>  4) How to render an old 3.6 scene using POV-Ray 3.7 [...]

Definitely.

>  5) How to pre-gamma-correct input images [...]

Kinda specialized.

>  Might not be the proper place for this, but perhaps also:

>  6) If the user needs to do it, how to create an image which has no gamma
> correction at all, only non-corrected raw pixels. The example of rendering
> an image to be used for creating a heightfield could be mentioned.

Quite frankly I'd put this very high on the list. If I cannot get POVray to
do what I want, I want it to do nothing. Just keep your hands off gamma and
similar things. If I want gamma correction, I'll do it myself in a paint program
after the fact.

That's a lot easier for me than reading up online for every minor revision how
gamma is supposed to work this week and doing render after render to get to
something that actually looks the way I wanted it (because this week the preview
doesn't actually show what I get in my file).

I can think of a hundred possible scenarios where an image gets rendered on a
different computer than where it is viewed and what not, but I'd be willing
to bet dollars to donuts that the vast majority of POVray users render and view
on the same machine and have no real need for for anything beyond "I want this
to look as it does in the preview".

Notably absent from your list is what I would put on the list as number one.

You need to acknowledge that most users will read documentation NOT preemptively
to understand the subtleties of the programming, but because they're trying to
do something and it doesn't work. Number 1 on the list would be

1) My image looks (over- / under-) exposed. What should I do to make
it (darker/brighter)?

Just sayin ...


  -- S

Post a reply to this message

Sven Geier schrieb:

>>  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
>> values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
>> why they shouldn't be abused for visual effects (because that's not their
>> purpose).
> 
> I still don't understand this, to be honest. If PCs "usually" have a gamma
> of 2.2, why do I still have to tell the PC version of POVray these things? Why
> can the *default* behaviour on a PC not be the one that the majority of
> users will expect?

The default values /do/ match the standard of 2.2. The problem is that 
there are some other things that don't work as a user may expect, unless 
he knows a bit about the background.

> Why do I have to futz around with ini files (and make the same change every
> single time a new beta comes out because the old ini files get replaced with
> the new ones every time) just to get the behaviour that one would expect for
> a run-of-the-mill PC?

Well, what exactly /is/ the behaviour you'd expect? And why would it 
require futzing around with ini files?

My guess would be that you're doing something wrong elsewhere.


>>  6) If the user needs to do it, how to create an image which has no gamma
>> correction at all, only non-corrected raw pixels. The example of rendering
>> an image to be used for creating a heightfield could be mentioned.
> 
> Quite frankly I'd put this very high on the list. If I cannot get POVray to
> do what I want, I want it to do nothing. Just keep your hands off gamma and
> similar things. If I want gamma correction, I'll do it myself in a paint program
> after the fact.

Note that this would require you to virtually /always/ post-process the 
image. I don't think that is what the majority of POV-Ray users would want.

Therefore, /by default/, POV-Ray /does/ perform gamma encoding (which 
for various file formats is equivalent to gamma pre-correction). But you 
can easily disable this by setting File_Gamma=1.0.

Note however that this does not make any difference at all for file 
formats that provide meta-information about encoding gamma.


> That's a lot easier for me than reading up online for every minor revision how
> gamma is supposed to work this week and doing render after render to get to
> something that actually looks the way I wanted it (because this week the preview
> doesn't actually show what I get in my file).

You know that you're exaggerating here. The betas are not released 
/that/ frequently - and gamma handling hasn't changed for a year or so.

Also keep in mind that we're talking about beta releases: They are 
positively /not/ intended for people who just want to run POV-Ray "out 
of the box" and bother about nothin'. It is instead a development 
version, released to the public for everyone willing to be a guinea pig.

This shouldn't keep you from pointing out what irritates you about it, 
and what you'd expect to be different - to the contrary, that's 
absolutely desired - but please keep it fair, bearing in mind that it 
should be /expected/ to still be in a state as to irritate you here and 
there - and also to still be subject to change.


> You need to acknowledge that most users will read documentation NOT preemptively
> to understand the subtleties of the programming, but because they're trying to
> do something and it doesn't work. Number 1 on the list would be
> 
> 1) My image looks (over- / under-) exposed. What should I do to make
> it (darker/brighter)?

Yes, the Questions & Tips section in POV-Ray's online help could be 
improved I guess.

This one is not a particularly gamma-related problem though, as there 
may be plenty of other reasons leading to similar effects; too high 
ambient is probably the most common cause.

Post a reply to this message

Sven Geier <.sven.at.sgeier.dot.net.nospamplease> wrote:
> >  1) A simple and clear explanation behind the reasoning and motivation behind
> > the new gamma correction approach, why it makes sense and why it's better
> > than what POV-Ray 3.6 did.

> That's good information to have but it should definitely not be number 1) on the
> list. I would put this into some appendix somewhere ("If you were
> wondering ... see section ...").

  Except that its purpose it to explain why the feature has changed in
POV-Ray 3.7 compared to 3.6.

> >  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
> >values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
> >why they shouldn't be abused for visual effects (because that's not their
> >purpose).

> I still don't understand this, to be honest. If PCs "usually" have a gamma
> of 2.2, why do I still have to tell the PC version of POVray these things? Why
> can the *default* behaviour on a PC not be the one that the majority of
> users will expect?

  Because not everyone's system has a gamma correction of 2.2?

> Why do I have to futz around with ini files (and make the same change every
> single time a new beta comes out because the old ini files get replaced with
> the new ones every time) just to get the behaviour that one would expect for
> a run-of-the-mill PC?

  How is that related to this thread?

> >  5) How to pre-gamma-correct input images [...]

> Kinda specialized.

  You won't find it "kinda specialized" if you try to use image maps with
POV-Ray 3.7.

> >  6) If the user needs to do it, how to create an image which has no gamma
> > correction at all, only non-corrected raw pixels. The example of rendering
> > an image to be used for creating a heightfield could be mentioned.

> Quite frankly I'd put this very high on the list. If I cannot get POVray to
> do what I want, I want it to do nothing. Just keep your hands off gamma and
> similar things. If I want gamma correction, I'll do it myself in a paint program
> after the fact.

  You are thinking of gamma correction in the wrong end of the process.
Gamma correction is not an image post-processing filter like brightness,
contrast or gaussian blurring. (Yes, some people abuse post-processing
gamma correction to adjust brightness and contrast, but that's not what
gamma correction is for.)

  Gamma correction is about how your *input* values are mapped to the
output values. In other words, when in the *input* you say "I want 50%
gray", gamma correction tells the program what it should write to the
output image in order to get 50% gray.

  Gamma correction is also about telling in the image data that "this
should be interpreted as 50% gray" so that if you view the image in a
different system with a different display hardware with different gamma,
that color will look like 50% gray there as well, and not eg. 40% or 60%
gray.

  Skipping gamma correction altogether has its own uses, but those are
seldom related to regular images. (One example is when using an image file
as a storage format for heightfield data.)

> That's a lot easier for me than reading up online for every minor revision how
> gamma is supposed to work this week and doing render after render to get to
> something that actually looks the way I wanted it (because this week the preview
> doesn't actually show what I get in my file).

  If you specify "50% gray" in your scene file, and the end result is not
50% gray on your screen, is that how you wanted it to work? Because that's
how POV-Ray 3.6 works.

  Basically in POV-Ray 3.6 if you want a 50% gray color, you just can't
use "rgb 0.5". You have to manually find some value which will look like
what you want.  POV-Ray 3.7 wants to change that: It wants that "rgb 0.5"
means "50% gray".

> I can think of a hundred possible scenarios where an image gets rendered on a
> different computer than where it is viewed and what not, but I'd be willing
> to bet dollars to donuts that the vast majority of POVray users render and view
> on the same machine and have no real need for for anything beyond "I want this
> to look as it does in the preview".

  As I said, it's not only a question of whether the image will look the same
in another computer, but also about more consistent interpretation of colors
in the scene file. "rgb 0.5" should mean "50% gray", not something else,
because that's the most logical interpretation.

  In order to achieve that goal, gamma correction is needed.

  Currently in POV-Ray 3.6 the only way to get exactly what you want is to
try manually rgb values until you end up with something that looks like what
you want.

> Notably absent from your list is what I would put on the list as number one.

> You need to acknowledge that most users will read documentation NOT preemptively
> to understand the subtleties of the programming, but because they're trying to
> do something and it doesn't work. Number 1 on the list would be

> 1) My image looks (over- / under-) exposed. What should I do to make
> it (darker/brighter)?

  Gamma correction is precisely the wrong tool for that problem. Gamma
correction is *not* a post-processing filter to adjust brightness and
contrast. It has been extensively abused for that purpose, but it's not
what it exists for, and never has been.

  Gamma correction is used to map linear rgb values to colors which will
look on your screen equivalently linear (because your screen does *not*
show pixel values with a linear brightness). Gamma correction is not a
brightness/contrast knob for your rendered image.

-- 
                                                          - Warp

Post a reply to this message

Gentlemen,

being a trained photographer the whole gamma issu is becomming a bit of 
a non issue to me, but alas

Gamma is a necessary evil. It has to be explained, so, yes a tutorial 
is needed. The differences in output between 3.6 & 3.7 are of minor 
importance to me. In the time since the 3.6 release I gues over 80% of 
the users have switched from CRT to LCD that has no gamma at all. So an 
old image will never look the same on a new monitor. The spread of 
quality between LCD's I find quite big, so big a "gamma" adjustment 
would be needed.

Digital imaging has progressed over time, digital camera's are commen 
now. People will expect the "same" output of a renderer as from their 
camera. So, I would suggest a simple setting for the user to choose 
colour space, not just gamma. Most digital devise use sRGB now, so for 
many platforms that would be the default. A special colour space could 
be "linear" for a gamma = 1 output (it's been some time ago, but 
doesn't the hf_gray setting automagically create gamma = 1 images).

For the common problem of gamma abuse in the past, for that "tone 
control" or contrast control would be nice.

ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> In the time since the 3.6 release I gues over 80% of 
> the users have switched from CRT to LCD that has no gamma at all. So an 
> old image will never look the same on a new monitor.

  Actually that's exactly what gamma correction data in the images is
trying to fix: To actually make the image look the same when you switch to
a different monitor technology (assuming you configure your system gamma
settings properly). That's the whole idea of gamma information.

  (Of course how well this will succeed in practice depends on a ton of
things. It requires for the OS to have a proper gamma correction setting
in its display device driver, among other things.)

> For the common problem of gamma abuse in the past, for that "tone 
> control" or contrast control would be nice.

  Actually a full post-processing scripting language would be nice, and
many times discussed, but ton of work to design properly.

-- 
                                                          - Warp

Post a reply to this message

ingo schrieb:

> In the time since the 3.6 release I gues over 80% of 
> the users have switched from CRT to LCD that has no gamma at all. So an 
> old image will never look the same on a new monitor. The spread of 
> quality between LCD's I find quite big, so big a "gamma" adjustment 
> would be needed.

While it is true that technically an LCD /panel/ has no gamma worth 
mentioning, LCD /displays/ usually do include some gamma curve using a 
look-up table - for the sole purpose of being compatible with CRTs in 
this respect.

High-end LCDs for multimedia production may be yet a different story, 
but the average PC user is likely to have either a low-end LCD, or a 
high-end LCD for gaming purposes.

> Digital imaging has progressed over time, digital camera's are commen 
> now. People will expect the "same" output of a renderer as from their 
> camera. So, I would suggest a simple setting for the user to choose 
> colour space, not just gamma. Most digital devise use sRGB now, so for 
> many platforms that would be the default. A special colour space could 
> be "linear" for a gamma = 1 output (it's been some time ago, but 
> doesn't the hf_gray setting automagically create gamma = 1 images).

I think going for full-fledged colour management would be pretty 
far-fetched ATM - even if output would be limited to two hard-coded 
color profiles (e.g. sRGB, as well as a linear color space using the 
sRGB primaries and white point) - as it would appear to carry an 
implicit promise that...

- the colors with which POV-Ray is operating internally would be 
precisely defined with respect to wavelength-dependent effects (which is 
not the case at present)

- POV-Ray would do full-fledged colour management for input files as 
well (which it doesn't, and due to complexity and lack of manpower is 
unlikely to do in the near future)

What does seem feasible at present would be to provide an option to use 
the /gamma function/ defined in the sRGB standard (and even make it the 
default) instead of a classic constant-gamma power law encoding.

Post a reply to this message

"Sven Geier" <.sven.at.sgeier.dot.net.nospamplease> wrote:
> Why do I have to futz around with ini files (and make the same change
> every single time a new beta comes out because the old ini files get
> replaced with the new ones every time) just to get the behaviour that one
> would expect for a run-of-the-mill PC?

Because it's a beta, maybe?

If you don't want to futz around with that kind of things, use a final
release version.

Post a reply to this message

Okay, I see I've stumbled onto this discussion a couple months late, but only
because of the linear 1.0 gamma issues I *thought* I was having recently. So I
started searching the groups for gamma topics and here it is.

Anyway, I've been reading for hours online about the gamma issue and I now
realize the problems I've been seeing are related to my new 26 in. LCD monitor
and video card, not POV-Ray 3.7 per-se (and since I only recently actually
started using the beta consistently, it was just bad synchronicity). I finally
located the gamma correction utility in my NVidea control panel and got that
sorted (doh!).

Now my only real issue is with gamma pre-correction on my image map files (so
v3.7's linear 1.0 rendering and post file_gamma correction don't wash out my
image maps). I'd like to be able to simply tell POV-Ray to gamma pre-correct my
input images as needed by using some simple math, say 1.0 divided by display
gamma, something like:

image_map { jpeg "myfile" pre_gamma 1/2.2 }

Then when using any PNGs with embedded gamma I could skip that (or just use
pre_gamma 1)

Is that anything like what's planned/coming in the future?

(And thanks for bearing with me on this gamma issue everyone - I needed to
educate myself a bit on this topic - never really considered it much until very
recently)

-Rob

Post a reply to this message

Robert McGregor schrieb:

> Now my only real issue is with gamma pre-correction on my image map files (so
> v3.7's linear 1.0 rendering and post file_gamma correction don't wash out my
> image maps). I'd like to be able to simply tell POV-Ray to gamma pre-correct my
> input images as needed by using some simple math, say 1.0 divided by display
> gamma, something like:
> 
> image_map { jpeg "myfile" pre_gamma 1/2.2 }
> 
> Then when using any PNGs with embedded gamma I could skip that (or just use
> pre_gamma 1)
> 
> Is that anything like what's planned/coming in the future?

Yes, definitely. As a matter of fact, a corresponding patch has been 
implemented already, and I expect it to feature in the next beta.

The syntax will differ in some details of course; for instance, the 
keyword is likely to be "file_gamma" and the parameter value will 
actually be the inverse of your proposal; it will also be conceptually 
an override, not an additional adjustment, which will make a difference 
for PNG files; e.g. if a PNG file is encoded pre-corrected for a display 
gamma of 2.2, and "file_gamma 2.2" is specified, POV-Ray will still 
apply a total gamma adjustment of x^2.2, not x^(2.2*2.2).


> (And thanks for bearing with me on this gamma issue everyone - I needed to
> educate myself a bit on this topic - never really considered it much until very
> recently)

I guess you're not the only one. I didn't wrap my head around it in a 
single day either.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> [a number of interesting things]

I have to say: If the value of a message is measured by the amount of thinking
it inspires, then this was one of the most valuable messages I've seen on the
Internet in a while. After quite a bit of pondering, this is the most coherent
answer I can come up with.

Let me start here:

>Gamma correction is about how your *input* values are mapped to the
>output values. In other words, when in the *input* you say "I want 50%
>gray", gamma correction tells the program what it should write to the
>output image in order to get 50% gray.
>
> Gamma correction is also about telling in the image data that "this
>should be interpreted as 50% gray" so that if you view the image in a
>different system with a different display hardware with different gamma,
>that color will look like 50% gray there as well, and not eg. 40% or 60%
>gray.

I think these two paragraphs sum up a bit of a conflict: is gamma about the
input or the output? If you say that it specifies how I want a pixel to appear
on the screen, then it sure looks like it is a post-processing step after the
color of the pixel has already been computed in the linear rgb space. An
afterthought, if you will, to take care of the different output devices this
pixel might be displayed on. Which is in conflict with the claim that it is
about input conversion.

At this point, it might actually be nice to have a clear "mission statement"
that actually tells us what purpose all the futzing with gamma in POV is
actually supposed to have. Input? Output? Both? Some high-level declaration
against which we can measure any one change that is occuring: "does *this*
change really serve *that* purpose?"

But the real beef, the part that really made me think, was this innocent little
question:

>  If you specify "50% gray" in your scene file, and the end result is not
>50% gray on your screen, is that how you wanted it to work? Because that's
>how POV-Ray 3.6 works.

I had never really thought much about it, but I actually think *about POV-Ray*
in two different (sometimes incompatible) ways.

On the one side, I think of it in terms of physics. Photons interacting with
surfaces, watts per square meter per steradian emitted in certain given spectral
bands and then absorbed somewhere else. Diffraction, illumination, scattering.
All the wonderful bits of math involved. Conservation of energy. That kind of
thing.

From this perspective, your question up there doesn't make much sense: a
specification of "rgb 0.5" in my scene file is about the reality of a given
object, namely that it emits half as many watts per area into some solid angle
(given by things like specularity) as it received. This specification is
completely unrelated to any kind of output device - an object specified as "50%
grey" can appear on any one monitor as any one color, depending on the
illumination of that surface by light sources and other surfaces and by the
angle to and distance from the camera.

Heck, even if there is no camera at all. The object is still specified as "50%
grey" and that is still a property of the object and this "50% grey"-ness
influences how it reflects light onto other things even if the camera points in
the opposite direction. Whether this object is ever taken into account in the
creation of any one image depends on its geometric relationship with its
environment and the direction in which any one camera might be pointed. And if
it is in view in any one image, then it can appear on my screen as anything from
pitch black to pure white and anything in between, depending on the actual
illumination conditions.

The other perspective I have on POV-Ray is about art. A tool to make pretty
images. Here I care about composition, lighting, shapes, structure, texture etc.
The physical background goes away entirely.

I might look at a scene and say: "That thing there looks too dark compared to
what I am trying to achieve. I'd like to make it a little lighter". In this
context, I could not care less what *number* there is attached to any one
specification - like the "rgb ..." value in some pigment. If I want it lighter,
I might increase it. Until it looks right. Or do something completely different
like increase "ambient" or such.

What I am concerned about there is the actual pixels on my screen, the image
that is being created - and all the vectors and color specs and whatnot become
mere utilities to that end. I want a grey that "looks a little lighter than that
and a shade colder" and from an artistic perspective I know I can make it a
little colder by making it a little bluer which I can achieve by raising the
blue component in my "ambient" statement and voila: I have changed the
appearance of an object even though its pigment is still specified as "rgb 0.5".
Or maybe "rgb 0.1" or "rgb 5.7". Or whatever I may have tinkered with to make
something *look* right.

From this perspective your question doesn't make much sense either - if I want
50% grey then there's a million buttons to turn and very rarely will there
happen to be a number "0.5" in there somewhere. Maybe the object is specified as
"0.7" and with a negative ambient illumination or something weird like that -
because it served some artistic purpose elsewhere.

All this said, here's my take on your question:

>  If you specify "50% gray" in your scene file, and the end result is not
>50% gray on your screen, is that how you wanted it to work?

If I specify "50% gray" in a scene file and there happens to be a pixel on my
screen that happens to come out 50% gray, then this would be mere coincidence.
It's not that I "want" it to come out differently, but it sure isn't like I
"wanted" it to come out this way either. From a physics perspective the "50%
grey" in the input is the reality and the resulting image (if any) is just
incidental to that reality and carries the properties of my camera and my light
sources in it - and from an arts perspective the image is all there is to it and
whether any of the numbers that entered into making the image happens to be
"0.5" or "128" or or "#808080" or "374629.4432" makes no difference to the end
result.

All that said - my preferred way of looking at POV-Ray is from an arts
perspective. I'm a physicist and if I have a situation where I really care about
the reality of the light propagation I'll run Zemax or Code-V; POV-Ray doesn't
cut it there. It's a toy, in the end.

And from an arts perspective, the recent betas of 3.7 have produced results that
looked like foot. But looked a lot better if I take them individually into a
paint program after the fact - and reduce gamma by about ~50%.

Am I the only one who looks at things this way? Who is the target audience here,
really? And what do they want and think? I am honestly curious.

Post a reply to this message

Sven Geier <.sven.at.sgeier.dot.net.nospamplease> wrote:
> >Gamma correction is about how your *input* values are mapped to the
> >output values. In other words, when in the *input* you say "I want 50%
> >gray", gamma correction tells the program what it should write to the
> >output image in order to get 50% gray.
> >
> > Gamma correction is also about telling in the image data that "this
> >should be interpreted as 50% gray" so that if you view the image in a
> >different system with a different display hardware with different gamma,
> >that color will look like 50% gray there as well, and not eg. 40% or 60%
> >gray.

> I think these two paragraphs sum up a bit of a conflict: is gamma about the
> input or the output?

  It's related to mapping input values to output values. Input values are
abstract, for example "50% gray", while output values are concrete pixel
values which will show up on your screen. What the gamma value does is to
tell the hardware how to convert the input values so that they will show
up on screen correctly. This is needed because different hardwares have
different mappings between input and output.

  Most programs don't care about this mapping and skip gamma correction
altogether. In these programs if you specify, for example "50% gray", what
you will get is a pixel with color components which are exactly in the
middle of the color component range (eg. on a 24 bits-per-pixel display
it will result in a pixel with values 127,127,127). That will not produce
a 50% gray with most monitors. However, people are so used to this that
they don't even notice that the mapping is incorrect.

  POV-Ray 3.6 is, basically, such a program. POV-Ray 3.7 wants to change
that and abstract the meaning of color definitions so that "rgb 0.5" really
means "50% gray" and not "whatever your monitor will show when you use a
pixel value of 127,127,127". A proper gamma setting is the tool for that.

> If you say that it specifies how I want a pixel to appear
> on the screen, then it sure looks like it is a post-processing step after the
> color of the pixel has already been computed in the linear rgb space.

  "Post-processing" is a change done to the pixel after it has been rendered
and before it's written to the image file (or previewed on screen). Gamma
correction goes beyond that (at least for image file formats which support
gamma information): It also writes to the file information which an image
viewing program can use to correct the pixels properly before showing them
on a different hardware with a different gamma than the computer where the
image was created. This means that in different computers, with different
gamma correction settings, what ends up being sent to the display hardware
may be different pixel values, with the goal that what you see on screen
will end up looking the same (rather than darker or lighter than in the
original computer).

> An
> afterthought, if you will, to take care of the different output devices this
> pixel might be displayed on. Which is in conflict with the claim that it is
> about input conversion.

  It is about input conversion in the sense that the original data (eg. in
this case an SDL scene file) had for example "50% gray", and the gamma value
is used during the entire process of rendering and displaying in order to
make sure that it will look like "50% gray" on the screen as well. Without
this gamma correction it won't look like that.

> From this perspective, your question up there doesn't make much sense: a
> specification of "rgb 0.5" in my scene file is about the reality of a given
> object, namely that it emits half as many watts per area into some solid angle
> (given by things like specularity) as it received. This specification is
> completely unrelated to any kind of output device - an object specified as "50%
> grey" can appear on any one monitor as any one color, depending on the
> illumination of that surface by light sources and other surfaces and by the
> angle to and distance from the camera.

  Of course lighting will affect how the color ends up on the final image.
However, gamma correction makes sure that the end result will be proper,
according to the math. For example if a 50% gray color is dimmed by lighting
by half, then you want a 25% gray to show up on screen, not something else.
And gamma correction is the tool for that. Without gamma correction you won't
get 25% gray.

> The other perspective I have on POV-Ray is about art. A tool to make pretty
> images. Here I care about composition, lighting, shapes, structure, texture etc.
> The physical background goes away entirely.

> I might look at a scene and say: "That thing there looks too dark compared to
> what I am trying to achieve. I'd like to make it a little lighter". In this
> context, I could not care less what *number* there is attached to any one
> specification - like the "rgb ..." value in some pigment. If I want it lighter,
> I might increase it. Until it looks right. Or do something completely different
> like increase "ambient" or such.

  Wouldn't you want for the image to look the same in someone else's computer
as it does in yours?

  Improper (or lack of) gamma correction will not only change the brightness
of the colors, but also their hue (because if different color components have
different values, they will be affected non-linearly by the display hardware;
this means that a pixel value of eg. 192,128,64 will have a slightly different
hue with different display hardwares).

  So gamma correction *does* make a difference even from an artistic point
of view.

-- 
                                                          - Warp

Post a reply to this message

Sven Geier schrieb:

> At this point, it might actually be nice to have a clear "mission statement"
> that actually tells us what purpose all the futzing with gamma in POV is
> actually supposed to have. Input? Output? Both? Some high-level declaration
> against which we can measure any one change that is occuring: "does *this*
> change really serve *that* purpose?"

It's actually about in- /and/ output.

For output, it is about converting from linear light intensity values to 
whatever it takes to make the CRT or LCD display generate just exactly 
that light intensity.

For input, it is about converting e.g. texture images that /already/ 
have undergone such a conversion process (or individual colors "picked" 
from such an image), back to linear light intensity values as needed to 
properly perform the raytracing computations.

Voila.

The current settings


>>  If you specify "50% gray" in your scene file, and the end result is not
>> 50% gray on your screen, is that how you wanted it to work? Because that's
>> how POV-Ray 3.6 works.
> ...
> On the one side, I think of it in terms of physics. Photons interacting with
> surfaces, watts per square meter per steradian emitted in certain given spectral
> bands and then absorbed somewhere else. Diffraction, illumination, scattering.
> All the wonderful bits of math involved. Conservation of energy. That kind of
> thing.
> 
> From this perspective, your question up there doesn't make much sense: a
> specification of "rgb 0.5" in my scene file is about the reality of a given
> object, namely that it emits half as many watts per area into some solid angle
> (given by things like specularity) as it received. This specification is
> completely unrelated to any kind of output device - an object specified as "50%
> grey" can appear on any one monitor as any one color, depending on the
> illumination of that surface by light sources and other surfaces and by the
> angle to and distance from the camera.

Let me rephrase Warp's question a bit:

If you specify an object with a checkered pattern, colored as "50% grey" 
and "100% grey" (i.e. white) - how do you expect the "50% grey" squares 
of the object to appear /in relation to/ the adjacent white squares?

If you specify two spotlights, with brightness of "rgb 1.0" and "rgb 
0.5", illuminating a uniformly colored object - how do you expect the 
illuminated spots to appear /in relation to/ each other?

If you specify two spotlights with brightness of "rgb 0.5" each, shining 
at the /same/ spot on an object - how do you expect the illuminated spot 
to appear /as compared to/ a single light source with brightnes of "rgb 
1.0" instead?

If you specify a light with brightness of "rgb 0.5" illuminating an 
object with a color of "red 1.0", how would you expect that object to 
appear /as compared to/ a similar scene having a light brightness of 
"rgb 1.0" and a color of "red 0.5"?


Of course you cannot name an /absolute/ value for how a color should 
appear in an image, unless you know exactly how bright "1.0" really is 
physically; but you can alway specify /relationships/ between multiple 
color or brightness levels you have specified in your scene. Gamma does 
not only affect the /absolute/ values, but also with the /relative/ ones.


> And from an arts perspective, the recent betas of 3.7 have produced results that
> looked like foot. But looked a lot better if I take them individually into a
> paint program after the fact - and reduce gamma by about ~50%.
> 
> Am I the only one who looks at things this way? Who is the target audience here,
> really? And what do they want and think? I am honestly curious.

I guess since this is an open source project and none of the developers 
get anything out of it except the fun of developing an interesting piece 
of software and/or get an improved version of their favorite ray tracing 
software, the target audience of POV-Ray is people having the same 
mindset about 3D rendering as the developers themselves.

I can't speak for the dev team, but I can speak for myself as a 
contributing developer: As a hobbyist I don't have access to 
professional physical light simulations; but having always been 
interested in natural science, my approach at trying to achieve effects 
is a very physics-oriented one; I'm not asking "how does /this/ software 
package happen to allow me to create that effect", but "how does /real 
life/ create it. And therefore that's how I want POV-Ray to operate, 
too, so I can more easily wrap my head around how to get the software to 
produce what I want.

I also think that it makes sense to follow this way even if other people 
approach it with that other mindset of "how does /POV-Ray/ allow me to 
create that effect" - because for those folks it wouldn't matter whether 
the rules by which POV-Ray operates are close to real-world physics, or 
some magic fantasy science.


Now as for your problems with POV-Ray 3.7, I suppose that they result 
not from this mindset per se, but rather from a change in the way how 
POV-Ray does things (especially gamma handling) that you just haven't 
got accustomed to - or from the known issues with input file gamma, 
which will be addressed with the next beta.

Post a reply to this message

"Sven Geier" <.sven.at.sgeier.dot.net.nospamplease> wrote:
> All that said - my preferred way of looking at POV-Ray is from an arts
> perspective...And from an arts perspective, the recent betas of 3.7 have produced
results that
> looked like foot. But looked a lot better if I take them individually into a
> paint program after the fact - and reduce gamma by about ~50%.
>
> Am I the only one who looks at things this way? Who is the target audience here,
> really? And what do they want and think? I am honestly curious.

Wow, ouch, "foot" doesn't sound so good (although I'm not sure what that means
where you live), but I definitely look at POV from an artist's perspective too.
And even though I'm a programming geek I try to put aside most of the technical
trivia and just get shots to look the way I want, using whatever means I need to
achieve that look.

Anyway, as for me, this 3.7 gamma change has really hampered me this last
several weeks since I (finally) started using the beta, because I just didn't
understand what it was all about, my old POV mindset was so ingrained I thought
something had gone whacky (which from that point of view, it did).

Now I've realized that I need to learn more about how colors and intensities of
those colors are propagated to various hardware devices, and that gamma
correction is the tool to make sure we all see the same thing, regardless of
what system we're using (assuming default gamma settings are correct on various
computers, which it seems they're not, and that bugs me).

I'd honestly prefer to work in linear 1.0 floating point gamma space and have my
output be a non-dithered, non-clamped HDR/EXR so there's no information lost,
but to be able to see that image as a properly gamma corrected preview on my
render window that looks like what my non-linear human eye would expect it to.

Or maybe I should just take up oil painting again... it's so analog.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> I guess since this is an open source project and none of the developers
> get anything out of it except the fun of developing an interesting piece
> of software and/or get an improved version of their favorite ray tracing
> software, the target audience of POV-Ray is people having the same
> mindset about 3D rendering as the developers themselves.

> I can't speak for the dev team, but I can speak for myself as a
> contributing developer: As a hobbyist I don't have access to
> professional physical light simulations; but having always been
> interested in natural science, my approach at trying to achieve effects
> is a very physics-oriented one; I'm not asking "how does /this/ software
> package happen to allow me to create that effect", but "how does /real
> life/ create it. And therefore that's how I want POV-Ray to operate,
> too, so I can more easily wrap my head around how to get the software to
> produce what I want.

Well said Chris! I couldn't agree more :D

> Now as for your problems with POV-Ray 3.7, I suppose that they result
> not from this mindset per se, but rather from a change in the way how
> POV-Ray does things (especially gamma handling) that you just haven't
> got accustomed to - or from the known issues with input file gamma,
> which will be addressed with the next beta.

That's certainly been a real pain in my "foot" lately (cool, I've learned a new
slang expression from Sven!)

I await the new beta with high hopes for it helping my gamma problems vanish
forever.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4aa3a4e0@news.povray.org...
>  Preferably this tutorial would be somewhere in the documentation that 
> makes
> it prominent and visible, rather then buried under hundreds of similar
> subsections.

I see that there has been some activity on the Wiki with this issue ...

I have some ideas on places in the docs this should go:

In the reference there is already a section on setting display gamma:
http://wiki.povray.org/content/Documentation:Reference_Section_1.1#Setting_your_Display_Gamma

or

A new sub-section in the tutorial advanced features section with a link in:
http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Introduction

perhaps expanding the list item 3 sentence in the intro to include a mention 
gamma, radiosity ... whatever.

any other ideas?

Jim

Post a reply to this message

Jim Holsenback schrieb:

> I see that there has been some activity on the Wiki with this issue ...
> 
> I have some ideas on places in the docs this should go:
> 
> In the reference there is already a section on setting display gamma:
>
http://wiki.povray.org/content/Documentation:Reference_Section_1.1#Setting_your_Display_Gamma
> 
> or
> 
> A new sub-section in the tutorial advanced features section with a link in:
> http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Introduction
> 
> perhaps expanding the list item 3 sentence in the intro to include a mention 
> gamma, radiosity ... whatever.
> 
> any other ideas?

I think there are two major areas to cover on gamma:

(1) What is it all about?

(2) How to deal with gamma issues properly
(2a) How to set up POV-Ray
(2b) How to deal with issues creeping up later


We might want to place (2a) right in the "getting started" instructions, 
or at the very least reference it from there.

(1) and (2b) might go together somewhere in the tutorial section, and 
(2a) might be mentioned there again; however, given how much can be 
written about gamma, I think the whole topic is worth a "page" on its own.

Post a reply to this message