Isn't manipulation of pixels supposed to be done on a linear scale, i.e.
=before= gamma correction for the monitor?  The comments in the source even
say "this is done exactly once per pixel displayed/saved".  But the
supersampling gamma corrects each value individually before averaging them
together.  I'm confused as to the meaning here.

From the docs, it's clear that the intent is for all new scenes to have
"assumed gamma" of 1 ("strongly recomended" it explains, "since that's the
way light works in the real world", and this is adjusted for the display
gamma when it is output.

So shouldn't all manipulation be done on the computed values (in the
assumed_gamma), and then the final pixel value be adjusted once?  Doing the
gamma correction first will give different results for different display
gamma values, which is exactly what the docs say is =not= supposed to
happen.

--John

Post a reply to this message

Huh? ;)

This kind of thing is what I have trouble with. It's simply a two way
street it seems and they always seem to turn out to be one way streets.
Metaphoricly typing of course...

I think I understand your meaning here, that the gamma is getting done
per processed pixel and yet the following pixels are not done so until
after they are sampled along with the previous pixels, right? Maybe not
right?
Anyway, I am thoroughly confused now.


"John M. Dlugosz" wrote:
> 
> Isn't manipulation of pixels supposed to be done on a linear scale, i.e.
> =before= gamma correction for the monitor?  The comments in the source even
> say "this is done exactly once per pixel displayed/saved".  But the
> supersampling gamma corrects each value individually before averaging them
> together.  I'm confused as to the meaning here.
> 
> From the docs, it's clear that the intent is for all new scenes to have
> "assumed gamma" of 1 ("strongly recomended" it explains, "since that's the
> way light works in the real world", and this is adjusted for the display
> gamma when it is output.
> 
> So shouldn't all manipulation be done on the computed values (in the
> assumed_gamma), and then the final pixel value be adjusted once?  Doing the
> gamma correction first will give different results for different display
> gamma values, which is exactly what the docs say is =not= supposed to
> happen.
> 
> --John

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

OK, as I read the code, it's sending out multiple rays for one pixel,
summing as it goes.  The, it divides by the number of samples, producing the
average which is the actual result.

It does gamma correction before summing.
I would think it should do gamma correction after dividing.

I've not thought about the meaning of post-corrected pixels above and left
of the current pixel and its role in adaptive supersampling.  But that might
be part of the reason for this code.

Just do a search on "gamma".  You'll find something like 6 hits in a .C
file, including the
function which does it, and three places where it's called as part of a
supersampling process.

--John



Bob Hughes wrote in message <36E6E739.D8B637EB@aol.com>...
>Huh? ;)
>
>This kind of thing is what I have trouble with. It's simply a two way
>street it seems and they always seem to turn out to be one way streets.
>Metaphoricly typing of course...
>
>I think I understand your meaning here, that the gamma is getting done
>per processed pixel and yet the following pixels are not done so until
>after they are sampled along with the previous pixels, right? Maybe not
>right?
>Anyway, I am thoroughly confused now.
>
>
>"John M. Dlugosz" wrote:
>>
>> Isn't manipulation of pixels supposed to be done on a linear scale, i.e.
>> =before= gamma correction for the monitor?  The comments in the source
even
>> say "this is done exactly once per pixel displayed/saved".  But the
>> supersampling gamma corrects each value individually before averaging
them
>> together.  I'm confused as to the meaning here.
>>
>> From the docs, it's clear that the intent is for all new scenes to have
>> "assumed gamma" of 1 ("strongly recomended" it explains, "since that's
the
>> way light works in the real world", and this is adjusted for the display
>> gamma when it is output.
>>
>> So shouldn't all manipulation be done on the computed values (in the
>> assumed_gamma), and then the final pixel value be adjusted once?  Doing
the
>> gamma correction first will give different results for different display
>> gamma values, which is exactly what the docs say is =not= supposed to
>> happen.
>>
>> --John
>
>--
> omniVERSE: beyond the universe
>  http://members.aol.com/inversez/POVring.htm
> mailto:inv### [at] aolcom?PoV

Post a reply to this message

I thought I had the source files for 3.0 here, apparently not. Only the
2.2 version sources. No such word as gamma it seems in those, far as I
could tell. Didn't really expect to find it anyhow, but I thought just
maybe there had been a hidden gamma routine in there none-the-less.
Perhaps I've overlooked it if so.
I understand your meaning better now, the gamma being before anything
else instead of following the actual pixel writing to the image and not
when it is being written (saved).
On the subject of the gamma, wonder what the head count of people would
be that use assumed_gamma 2.2 (or any other number) as default instead
of 1.0 for the basis of corrections?
I've just done several different test renders (single light_source color
rgb 1) using Display_Gamma=1.0, assumed_gamma 2.2 and opposite of this,
also both as 1.0 or 2.2. The appearance changes drastically as you might
guess. Unfortunately to my eyes the render doesn't seem quite right when
used as suggested. Probably because I tend to think in terms of more
than one light since I seldom use only one lone light source and
combining them makes things more difficult to adjust the scene
color/brightness/contrast.
Anyhow, I'm going to give the defaults for my PC here a trial run for a
while and see what comes of it.


"John M. Dlugosz" wrote:
> 
> OK, as I read the code, it's sending out multiple rays for one pixel,
> summing as it goes.  The, it divides by the number of samples, producing the
> average which is the actual result.
> 
> It does gamma correction before summing.
> I would think it should do gamma correction after dividing.
> 
> I've not thought about the meaning of post-corrected pixels above and left
> of the current pixel and its role in adaptive supersampling.  But that might
> be part of the reason for this code.
> 
> Just do a search on "gamma".  You'll find something like 6 hits in a .C
> file, including the
> function which does it, and three places where it's called as part of a
> supersampling process.
> 
> --John
> 
> Bob Hughes wrote in message <36E6E739.D8B637EB@aol.com>...
> >Huh? ;)
> >
> >This kind of thing is what I have trouble with. It's simply a two way
> >street it seems and they always seem to turn out to be one way streets.
> >Metaphoricly typing of course...
> >
> >I think I understand your meaning here, that the gamma is getting done
> >per processed pixel and yet the following pixels are not done so until
> >after they are sampled along with the previous pixels, right? Maybe not
> >right?
> >Anyway, I am thoroughly confused now.
> >
> >
> >"John M. Dlugosz" wrote:
> >>
> >> Isn't manipulation of pixels supposed to be done on a linear scale, i.e.
> >> =before= gamma correction for the monitor?  The comments in the source
> even
> >> say "this is done exactly once per pixel displayed/saved".  But the
> >> supersampling gamma corrects each value individually before averaging
> them
> >> together.  I'm confused as to the meaning here.
> >>
> >> From the docs, it's clear that the intent is for all new scenes to have
> >> "assumed gamma" of 1 ("strongly recomended" it explains, "since that's
> the
> >> way light works in the real world", and this is adjusted for the display
> >> gamma when it is output.
> >>
> >> So shouldn't all manipulation be done on the computed values (in the
> >> assumed_gamma), and then the final pixel value be adjusted once?  Doing
> the
> >> gamma correction first will give different results for different display
> >> gamma values, which is exactly what the docs say is =not= supposed to
> >> happen.
> >>
> >> --John
> >
> >--
> > omniVERSE: beyond the universe
> >  http://members.aol.com/inversez/POVring.htm
> > mailto:inv### [at] aolcom?PoV

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

On Thu, 11 Mar 1999 01:49:38 -0600, Bob Hughes <inv### [at] aolcom>
wrote:

>I've just done several different test renders (single light_source color
>rgb 1) using Display_Gamma=1.0, assumed_gamma 2.2 and opposite of this,
>also both as 1.0 or 2.2. The appearance changes drastically as you might
>guess. Unfortunately to my eyes the render doesn't seem quite right when
>used as suggested.

If you are using pigments from color.inc, remember that many of them
were created before POV had gamma correction, mostly on pc's with
gamma 2.2 or so, and are designed to look "right" with that gamma.
Thus, if you use assumed_gamma 1.0 (the Right Thing to do), you will
need to alter them accordingly.  This also applies to most of the
other standard includes (woods, stones, metals etc.).  Here is a
little macro I have used for the purpose.

// Begin POV code

#macro Fixcols(Badcol)
	color rgb <pow(Badcol.red, 2.2), pow(Badcol.green, 2.2),
pow(Badcol.blue, 2.2)>
	filter Badcol.filter transmit Badcol.transmit
#end

// End POV code

Just wrap it around the color to be adjusted thus, for example:

pigment { Fixcols(HuntersGreen) }


Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

Bob Hughes wrote in message <36E77592.D8E028ED@aol.com>...

>I understand your meaning better now, the gamma being before anything
>else instead of following the actual pixel writing to the image and not
>when it is being written (saved).

Actually, gamma correction is done before saving -- the output file contains
pixels corrected to Display_Gamma.

>On the subject of the gamma, wonder what the head count of people would
>be that use assumed_gamma 2.2 (or any other number) as default instead
>of 1.0 for the basis of corrections?

Everyone who didn't read the manual.

>I've just done several different test renders (single light_source color
>rgb 1) using Display_Gamma=1.0, assumed_gamma 2.2 and opposite of this,
>also both as 1.0 or 2.2. The appearance changes drastically as you might
>guess.

>Unfortunately to my eyes the render doesn't seem quite right when
>used as suggested. Probably because I tend to think in terms of more
>than one light since I seldom use only one lone light source and
>combining them makes things more difficult to adjust the scene
>color/brightness/contrast.

Because (1)you are used to that, and (2)all the textures you know and love
were designed that way.


>Anyhow, I'm going to give the defaults for my PC here a trial run for a
>while and see what comes of it.


Likewise.  I need to redo the scene to have it look right with gamma=1.0,
but the benifit will be portability of the file (specifically, to service
bureu that prints it on an IRIS), and use of tools that use ICC color
profiles.

If wose comes to worse, take the resulting file and post-process it to
Display_Gamma, and it will be just like it would have been, barring roundoff
errors (not a problem with 16 bits per sample).

I'll update my writeup as more develops.  Let me know what comes of it for
you.

--John

Post a reply to this message

Wonderful idea!  Thanks.

I knew that the textures were developed for pre-gamma support, but didn't
think to simply translate everything in the color_map ...

--John

Jerry Anning wrote in message <36e7ec62.3365811@news.povray.org>...
>On Thu, 11 Mar 1999 01:49:38 -0600, Bob Hughes <inv### [at] aolcom>
>wrote:
>
>>I've just done several different test renders (single light_source color
>>rgb 1) using Display_Gamma=1.0, assumed_gamma 2.2 and opposite of this,
>>also both as 1.0 or 2.2. The appearance changes drastically as you might
>>guess. Unfortunately to my eyes the render doesn't seem quite right when
>>used as suggested.
>
>If you are using pigments from color.inc, remember that many of them
>were created before POV had gamma correction, mostly on pc's with
>gamma 2.2 or so, and are designed to look "right" with that gamma.
>Thus, if you use assumed_gamma 1.0 (the Right Thing to do), you will
>need to alter them accordingly.  This also applies to most of the
>other standard includes (woods, stones, metals etc.).  Here is a
>little macro I have used for the purpose.
>
>// Begin POV code
>
>#macro Fixcols(Badcol)
> color rgb <pow(Badcol.red, 2.2), pow(Badcol.green, 2.2),
>pow(Badcol.blue, 2.2)>
> filter Badcol.filter transmit Badcol.transmit
>#end
>
>// End POV code
>
>Just wrap it around the color to be adjusted thus, for example:
>
>pigment { Fixcols(HuntersGreen) }
>
>
>Jerry Anning
>clem "at" dhol "dot" com

Post a reply to this message

Don't think I'm going to be going to that assumed_gamma 1.0 after all.
From what I've been seeing it doesn't conform too well at all for
anything I've tried yet. All I ever get is a washed out image, loss of
contrast. I think my monitor is setup pretty much as should be. I don't
even have it too bright or low contrasted to begin with because I like a
darker screen. I don't have very bright room light most of the time is
why.
I just don't get this Display_Gamma=2.2 in the Povray.ini coupled with a
suggested assumed_gamma 1.0 more than ever. If one light_source of color
rgb 1 (White) is used it might pass with the lowering of all other color
values as Jerry Anning pointed out. But what's the point there? Those
are POV-Ray colors and textures which came with the program, makes no
sense they would not be right already (note: I'm never complaining, even
if I appear to be. Just so everyone knows).
When using a couple or more lights at a reduced color value for each, to
add up to a reasonable amount of light_source color, there still is the
low contrast look. And if ambient were reduced next to nothing it might
work out once again, but ambient is a necessary evil for certain
situations.
Anyhow, as far as I can tell if assumed_gamma is used at all it simply
cannot be 1.0, only 1.6 or above to maybe 2.6 is my range of light to
dark (or low contrast to high) while keeping a good image with realism.
So I am totally failing to find the reasoning or true answer to the
gamma question. I would bet that I may have tried as the DOC said at
first to use those suggested values and came up with the equaling the
two instead for similar results to the older, pre-gamma corrected
scenes. I'm not going to question the fact that there is probably a well
thought out reasoning to what the POV-Team decided upon but it won't
work for me.
I checked using Display_Gamma=1.0 and 2.2, assumed_gamma 2.2 and 1.0 (PC
here, can you tell yet?) and only the both set to 2.2 does best in my
eyes. Or as you might say it possibly would with all rgb values brought
down by a fixable factor. This is of course the questionable part: why
it wouldn't be the same rendered image as what older versions rendered.
Think that is why I must have figured it as a ratio to each setting, ie.
1.0 being both 2.2 and any other deviation from each other higher or
lower than 1.0 making it a relative scale type thing, not an actual
value to use. Okay, how wrong am I? Doesn't matter, I have to use the
values that work not anything else anyhow... Just please don't take my
POV-Ray render license away.
Well, I better stop writing, turning into a short story here.
Oh and thanks Ken for the refresher on gamma in the DOC, I needed that.
Understand it yet is another matter, thanks though.


"John M. Dlugosz" wrote:
> 
> I'll update my writeup as more develops.  Let me know what comes of it for
> you.
> 
> --John

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Bob Hughes wrote in message <36E96C53.A74EB89D@aol.com>...
>Don't think I'm going to be going to that assumed_gamma 1.0 after all.
>From what I've been seeing it doesn't conform too well at all for
>anything I've tried yet. All I ever get is a washed out image, loss of
>contrast

I'm having much better luck.
I've translated the colors in my scene by raising them to the 2.2 power, and
did the same
for the light sources, and the overall look is about the same.  Except for
reflections and other places where rays are mixed, I would expect =exactly=
the same output.  After all, before, the colors were picked for monitor
display values.  After, the colors are gamma corrected before display, and I
performed the inverse transform to pick the color, so they should cancel out
exactly.

Until I take a closer look at a full render, I can't tell for sure if any
differences are due to these combining differences affecting layered
textures, an error translating the stone include, or if I have a loss of
contrast due to some as-yet-unknown effect.

--John

Post a reply to this message

Jerry Anning wrote in message <36e7ec62.3365811@news.povray.org>...
>If you are using pigments from color.inc, remember that many of them
>were created before POV had gamma correction, mostly on pc's with
>gamma 2.2 or so, and are designed to look "right" with that gamma.
>Thus, if you use assumed_gamma 1.0 (the Right Thing to do), you will
>need to alter them accordingly.  This also applies to most of the
>other standard includes (woods, stones, metals etc.).  Here is a
>little macro I have used for the purpose.
>
>// Begin POV code
>
>#macro Fixcols(Badcol)
> color rgb <pow(Badcol.red, 2.2), pow(Badcol.green, 2.2),
>pow(Badcol.blue, 2.2)>
> filter Badcol.filter transmit Badcol.transmit
>#end
>
>// End POV code
>
>Just wrap it around the color to be adjusted thus, for example:
>
>pigment { Fixcols(HuntersGreen) }
>
>
>Jerry Anning
>clem "at" dhol "dot" com


I've converted colors from Metals and Stones, as well as the primitive
colors, and analysed the effects mathematically as well as empirically.  I
discovered that you need to apply the 2.2 factor to the Transmit channel as
well, for the colors of a layered texture to look the same (assuming I
understand Transmit correctly).  I'm not sure about Filter, since I don't
know how filter works mathematically, but I would guess that applying the
2.2 correction to that too is either also correct, or is at least closer to
the original if it can't match exactly.

There is also a difference in lighting, if you have more than one light
source.

I'll add my data and detailed conclusions to my web page on the subject,
over the next few days.

--John

Post a reply to this message