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