> 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