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