I partially agree that it can be annoying.  But I like being able to specify
color rgb 0.25 and it mean 25% gray, if the input was taken as a gamma
corrected value I may have to do something like color rgb 0.53 to get the same
result on one monitor (gamma 2.2) and 0.56 for a different monitor (gamma
0.56).

If anything I think the existing keywords should keep their meanings, color 0.5
should mean 50% gray, and the new keywords should un-gammacorrect the input:
display_color 0.5 should represent 21% gray if the display gamma is 2.2.

I agree when loading image maps I may want it to avoid correction in some cases
and apply it in others.  Sometimes a value 128 means 128 (~0.5, for height
fields generated by a custom program/script), and other times when loading it
should correct (or uncorrect) the image into POV-Ray colorspace.

Post a reply to this message

Allen <bri### [at] yahoocom> wrote:
> I partially agree that it can be annoying.  But I like being able to specify
> color rgb 0.25 and it mean 25% gray

  What do you mean by "25% gray"? It could mean one of two different things:

- The pixel (if completely non-shaded) ends up having a value of (64, 64, 64)
  in a 24 bits-per-pixel image.

- The brightness of the pixel will be exactly 1/4 of the maximum brightness.

  Those two things are totally different. A pixel value of (64, 64, 64) might
not be even close to 1/4 of the maximum brightness of a pixel on your
display.

  Which one do you mean?

> if the input was taken as a gamma
> corrected value I may have to do something like color rgb 0.53 to get the same
> result on one monitor (gamma 2.2) and 0.56 for a different monitor (gamma
> 0.56).

  Well, the whole idea with gamma correction is that it's enough for you
to specify just the value "rgb 0.25" and then with gamma correction make
it look exactly 1/4 of the maximum brightness in your display. You just
adjust the gamma correction rather than the color values.

  OTOH IMO gamma correction should not be force-fed, and it should be
possible to turn it completely off. Sometimes you *want* "rgb 0.25" to
mean exactly the pixel value (64, 64, 64) and nothing else, regardless
of how it may *look* on the screen. Images are sometimes used for purposes
other than just displaying them, and gamma correction might just be a
hindrance than anything else.

-- 
                                                          - Warp

Post a reply to this message

>> if the input was taken as a gamma
>> corrected value I may have to do something like color rgb 0.53 to get the 
>> same
>> result on one monitor (gamma 2.2) and 0.56 for a different monitor (gamma
>> 0.56).

That's why I suggest we have two options for entering colours/images in the 
SDL, one will apply inverse of whatever your gamma setting is, the other 
will just use it linearly.

Your suggestion might be better ie:
color rgb 0.25  // this is 25% the brightness of rgb 1.0 inside the engine, 
ie 25% the photons, 25% the power, whatever. if you are using gamma 
correction, the output pixel value will not be 64,64,64

display_color rgb 0.25 // this is what rgb 64,64,64 would look like on your 
monitor, will come out as rgb 64,64,64 no matter what gamma setting you 
have.  use this if you have chosen a colour from html, some image editor etc 
and you want the output gamma corrected colour to be the same.

>  Well, the whole idea with gamma correction is that it's enough for you
> to specify just the value "rgb 0.25" and then with gamma correction make
> it look exactly 1/4 of the maximum brightness in your display.

Yes, that's true if you know what 25% brightness is, which POV does when it 
works out light/shadow calculations, it says "i want this pixel to be 25% 
brightness" and then the gamma correction fixes it so it looks realistic on 
your monitor.  But sometimes you know what you want the output colour to 
look like, eg RGB 255,128,64, currently there is no way to tell POV to use 
that colour without doing some complex inverse gamma calculation by hand.

>  OTOH IMO gamma correction should not be force-fed, and it should be
> possible to turn it completely off.

You should be able to set display_gamma as 1.0 in an ini file and it should 
actually do that.

> Sometimes you *want* "rgb 0.25" to
> mean exactly the pixel value (64, 64, 64) and nothing else, regardless
> of how it may *look* on the screen.

Agreed, which is why I suggest having two methods for entering 
colours/images.  Note that for colours it is more important than greys, 
because gamma correction actually changes the colour hue, not just the 
brightness.

Post a reply to this message

"Warp" wrote
>   Which one do you mean?

I'm sorry I didn't specify.  I meant 25% visual maximum brightness.

>  Well, the whole idea with gamma correction is that it's enough for you
> to specify just the value "rgb 0.25" and then with gamma correction make
> it look exactly 1/4 of the maximum brightness in your display. You just
> adjust the gamma correction rather than the color values.

I agree.  I think it's nice that POV-Ray has it's own internal linear color
space that works this way so that the same image can be rendered anywhere and
appear the same.  It also, at least for me, makes more sense when trying to mix
certain colors that the values should represent relative brightnesses.

"scott" <sco### [at] scottcom> wrote:
> display_color rgb 0.25 // this is what rgb 64,64,64 would look like on your
> monitor, will come out as rgb 64,64,64 no matter what gamma setting you
> have.  use this if you have chosen a colour from html, some image editor etc
> and you want the output gamma corrected colour to be the same.

Well I don't think it will be exactly 64, 64, 64 on the output.  It would be
translated to the equivalent for input, but because of lighting, shadows, etc
etc, it may not be exactly 64, 64, 64 on output.  One way to make it may be to
set diffuse 0 and ambient 1, and have no other translucent objects that may
alter the color.


> >  OTOH IMO gamma correction should not be force-fed, and it should be
> > possible to turn it completely off.
>
> You should be able to set display_gamma as 1.0 in an ini file and it should
> actually do that.

That's true you could put it in the scene-specific ini file and turn it off for
that scene.  But for display_color to work, it would need to know how to 'undo'
the gamma correction of the color to convert it to POV-Ray internal color space,
so a valid display_gamma would be needed.  With a display_gamma of 1, color and
display_color would behave exactly the same, so you couldn't use color rgb 0.5
to get 50% output brightness.  Perhaps instead a global_settings {
output_gamma_correction off }, so that display_gamma could still work with
display_color to convert it internally to a color.


> Agreed, which is why I suggest having two methods for entering
> colours/images.  Note that for colours it is more important than greys,
> because gamma correction actually changes the colour hue, not just the
> brightness.

For input specifications, a 'display_color' could work and 'undo' the gamma
correction to get the correct rgb values.

For input images and maps, two things may be needed.  During the loading stage,
a way to specify the input gamma correction or not for decoding the image.  For
example, in a .bmp, should an input of 128,128,128 be kept 0.5,0.5,0.5 or
'adjusted' to something like 0.27,0.27,0.27.  I noticed when reading the source
code, for height fields and some other things, the input image is taken as is
with not decoding gamma correction, but for other things it does do gamma
correction for decoding, so maybe only one flag would be needed saying whether
or not to do gamma correction for rendering of the image.  If it should be
corrected the the image can be left as-is in memory, but if it should not be
corrected, then the image may need to have an inverse gamma correction applied
so when rendered it will be correct.


I've noticed that on the same display, colors that are and are not gamma
corrected do have a different hue.  But on two different displays with
different gammas, the gamma corrected hue bar always looks the same as long as
the program gamma correction is set to match the monitor.  It also seems that
the gamma corrected hue bar is more natural.  In the attachment, the left is
not gamma corrected and the right is.  The left, the secondary colors get a
very small section on the hue bar compared to the primaries (magenta, cyan, and
yellow have a smaller space than red, green, blue parts), but when gamma
correction is enabled on the right, it seems they have more of an equal section
on the hue bar.  Also the bars on the right looks the same on two different
monitors I have with different gammas.

Post a reply to this message

Attachments:
Download 'gamma.png' (9 KB)

Preview of image 'gamma.png'

I think that the following are the most likely situations:

Colors:

1. I want 0.5 to mean 50% brightness

Use color rgb 0.5 and povray stores internally as 0.5

2. I want 0.5 to mean an output of RGB 128,128,128

Use display_color rgb 0.5 and povray would do an inverse correction based on
display_gamma to store it internally something like 0.217


Images as maps for heightfields, color/texture maps

1. I want 128 in the image to represent 50% height, or 0.5 in the
color_map/texture_map

When loading the image, ignore any file gamma and let RGB 128,128,128 be
internally treated as 0.5

3. I want the true brightness of the image to represent the height or position
in color_map,texture_map

When loading the image, apply gamma correction based on the file gamma, so that
if the file gamma of a PNG is 0.4545454 and a pixel is 128,128,128, it would
represent ~ 0.217, about 21.7% height or 0.217 in color_map and height_map


Images as images/textures:

1.  I want 128 to represent 50% brightness

When loading the image, do not do any gamma correction based on the file gamma
so 128 loads as 0.5, when rendering, output gamma correction will make it 50%
brightness, depending on other scene factors

2. I want 128 input to represent 128 output

When loading the image, do not do any gamma correction based on file gamma so
128 loads internally as 0.5.  Then with the 0.5 do a correction like with
display_color, so that 0.5 becomes corrected to 0.217 if display_gamma is 2.2

3. I want the original brightness of the image to be the output brightness as
well.

When loading the image, perform gamma correction based on file gamma to get the
original brightness values, then output gamma correction will keep the
brightness.

4.  Probably a lesser situation.  I want the original brightness value to be the
pixel output value. (an input of 196 may represent 50% brightness, so should
have an output 'pixel' of 128)

When loading the image, perform gamma correction based on file gamma to get the
original brightness values.  Then perform yet another gamma correction like
display_color on those brightness values.



For colors, color and display_color could be used.

For input images, perhaps a flag gamma_method could be used to indicate which
method to use when decoding the input image, 0-4, 0 = default based on the
type, 1-4 represents on of the above.  For height fields, etc 0 would mean 1
from above, for everything else, 0 would mean 3 from above.

Post a reply to this message

> Well I don't think it will be exactly 64, 64, 64 on the output.  It would 
> be
> translated to the equivalent for input, but because of lighting, shadows, 
> etc
> etc, it may not be exactly 64, 64, 64 on output.  One way to make it may 
> be to
> set diffuse 0 and ambient 1, and have no other translucent objects that 
> may
> alter the color.

Yes that's what I meant, of course lighting shadows etc will affect the 
brightness (but not the colour).

> That's true you could put it in the scene-specific ini file and turn it 
> off for
> that scene.  But for display_color to work, it would need to know how to 
> 'undo'
> the gamma correction of the color to convert it to POV-Ray internal color 
> space,
> so a valid display_gamma would be needed.

It should just work with whatever value of display_gamma you specify, 
whether than be 2.2, 1.8, 1.0 or 0.5.

> With a display_gamma of 1, color and
> display_color would behave exactly the same,

That's right.

> so you couldn't use color rgb 0.5
> to get 50% output brightness.

Why not? If you've set display_gamma to 1.0 then both color 0.5 and 
display_color 0.5 will give 50% brightness.

> For input specifications, a 'display_color' could work and 'undo' the 
> gamma
> correction to get the correct rgb values.

That is exactly the functionality I would like to see.  I'm not that 
bothered about how it is implemented, but it's a pain having to "undo gamma" 
for RGB values and images that I want to use in POV scenes.


> I noticed when reading the source
> code, for height fields and some other things, the input image is taken as 
> is
> with not decoding gamma correction, but for other things it does do gamma
> correction for decoding,

Oh really? I've never experienced any undo-gamma for reading in images, 
maybe I'll have to try and look at the source to find out under which 
circumstances this is done.

> so maybe only one flag would be needed saying whether
> or not to do gamma correction for rendering of the image.  If it should be
> corrected the the image can be left as-is in memory, but if it should not 
> be
> corrected, then the image may need to have an inverse gamma correction 
> applied
> so when rendered it will be correct.

This would be useful if you are using photos or other images from the web 
that are already gamma corrected, you don't want to gamma correct them again 
because the colours will be all wrong then (not to mention the 
contrast/brightness).

> I've noticed that on the same display, colors that are and are not gamma
> corrected do have a different hue.

That is the main reason I am asking for this capability. 
Brightness/contrast you can usually mostly fix with diffuse/ambient terms, 
but you can't fix incorrect colours within POV.

> But on two different displays with
> different gammas, the gamma corrected hue bar always looks the same as 
> long as
> the program gamma correction is set to match the monitor.  It also seems 
> that
> the gamma corrected hue bar is more natural.  In the attachment, the left 
> is
> not gamma corrected and the right is.

Of course you should gamma correct the output from POV to match the display 
device, that's the whole point of gamma correction, and obviously if you 
don't gamma correct the result is going to look false and "unnatural".

Post a reply to this message

> Use display_color rgb 0.5 and povray would do an inverse correction based 
> on
> display_gamma to store it internally something like 0.217

Exactly what I was asking for.  That way if you see a colour like 255,128,64 
used on a web page, or maybe it's your company's corporate colour, or maybe 
you grabbed it from a photo, whatever, you should be able to use that colour 
directly in SDL and get the same colour out no matter what output gamma 
settings you are using.

> Images as maps for heightfields, color/texture maps
>
> 1. I want 128 in the image to represent 50% height, or 0.5 in the
> color_map/texture_map
>
> When loading the image, ignore any file gamma and let RGB 128,128,128 be
> internally treated as 0.5

Yup, makes total sense for height fields.

> Images as images/textures:
> 2. I want 128 input to represent 128 output
>
> When loading the image, do not do any gamma correction based on file gamma 
> so
> 128 loads internally as 0.5.  Then with the 0.5 do a correction like with
> display_color, so that 0.5 becomes corrected to 0.217 if display_gamma is 
> 2.2

I think this would be the most used situation, if someone uses an image they 
have made in a photo editor, or taken with their camera, or rendered 
previously with gamma correction in POV, they want the colours to be the 
same in the POV rendered scene as the original colours appear on their 
monitor.  For this reason, POV should use the inverse of display_gamma for 
the input.

Post a reply to this message

> Why not? If you've set display_gamma to 1.0 then both color 0.5 and
> display_color 0.5 will give 50% brightness.

If display_gamma is 1.0, then no output gamma correction would occur and it
would give an output pixel of 128,128,128, which is for 2.2 gamma only about
~21% brightness.  If display_gamma is 2.2, then it would give an output of
186,186,186 for 'color' and still about 128,128,128 for display_color

> > Images as images/textures:
> > 2. I want 128 input to represent 128 output
> >
> > When loading the image, do not do any gamma correction based on file gamma
> > so
> > 128 loads internally as 0.5.  Then with the 0.5 do a correction like with
> > display_color, so that 0.5 becomes corrected to 0.217 if display_gamma is
> > 2.2
>
> I think this would be the most used situation, if someone uses an image they
> have made in a photo editor, or taken with their camera, or rendered
> previously with gamma correction in POV, they want the colours to be the
> same in the POV rendered scene as the original colours appear on their
> monitor.  For this reason, POV should use the inverse of display_gamma for
> the input.

I think this or 3.  If your are using images from the web, their gamma may not
be the same as your monitor gamma.  In this case you would probably want the
true original brightness on the output in which case 3 makes sense.  If the
file gamma matches the monitor gamma, then option 3 is like option 2 because
loading the image would 'undo' the file gamma instead of undoing the display
gamma, which both would have the same values.

Post a reply to this message

>> Why not? If you've set display_gamma to 1.0 then both color 0.5 and
>> display_color 0.5 will give 50% brightness.
>
> If display_gamma is 1.0, then no output gamma correction would occur and 
> it
> would give an output pixel of 128,128,128, which is for 2.2 gamma only 
> about
> ~21% brightness.

Oh OK, I was assuming that you would set display_gamma correctly for 
whatever device you wanted to "view" the output on.  Of course if you set 
that incorrectly then everything is going to be screwed up, including 
shadows, diffuse lighting etc let alone the colours.

> I think this or 3.  If your are using images from the web, their gamma may 
> not
> be the same as your monitor gamma.

Oh I didn't realise that colours on the web had gamma, I thought that 
255,128,64 would display the same no matter if it was in HTML color 
statement or png file or jpeg file etc.  IIRC everything on the web is 
designed for use in sRGB color space, so gamma of 2.2?

All I'm thinking is that I know lots of places have certain RGB colour 
values that are assigned for brand colours etc or just used in web sites for 
the "core colours".  These are presumably designed with gamma 2.2 in mind, 
it would just be nice to use those RGB values (and any images already made 
that contain them) directly in POV without any tricks.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
>
> Oh I didn't realise that colours on the web had gamma, I thought that
> 255,128,64 would display the same no matter if it was in HTML color
> statement or png file or jpeg file etc.  IIRC everything on the web is
> designed for use in sRGB color space, so gamma of 2.2?
>
> All I'm thinking is that I know lots of places have certain RGB colour
> values that are assigned for brand colours etc or just used in web sites for
> the "core colours".  These are presumably designed with gamma 2.2 in mind,
> it would just be nice to use those RGB values (and any images already made
> that contain them) directly in POV without any tricks.

Yes I'm pretty sure most the web is sRGB or 2.2, the only format that I know
that allows embedding different gamma/profile is PNG, so it is possible that a
PNG may contain something different.  Of course a person creating something for
sharing should save it with sRGB.

Post a reply to this message