two renderings of the same scene. Both rendered in 3.7,

chextest-36 has #version 3.6 defined, chextest-37 does not.

No matter how hard I try with lighting, I cannot get the 3.7 version to 
look anything other than "Washed-out"

This is with the Display_Gamma setting set at 2.2
Setting Display_Gamma changes how the image looks POV-Ray's render 
window, but does nothing to correct the image.

It doesn't matter what my monitor is set to, even properly calibrated 
(with a colorimeter) it loses plenty saturation, and looks washed out.

-- 
~Mike

Post a reply to this message

Attachments:
Download 'chextest-37.jpg' (9 KB) Download 'chextest-36.jpg' (10 KB)

Preview of image 'chextest-37.jpg'

Preview of image 'chextest-36.jpg'

Mike Raiford wrote:
> Setting Display_Gamma changes how the image looks POV-Ray's render
> window, but does nothing to correct the image.

  Did you try setting File_Gamma and then rendering to an image format
other than PNG (ie. one which has no gamma metadata)? Or, alternatively,
did you try to remove the gamma metadata from the PNG to see how it
affects it?

Post a reply to this message

Warp wrote:
> Mike Raiford wrote:
>> Setting Display_Gamma changes how the image looks POV-Ray's render
>> window, but does nothing to correct the image.
> 
>   Did you try setting File_Gamma and then rendering to an image format
> other than PNG (ie. one which has no gamma metadata)? Or, alternatively,
> did you try to remove the gamma metadata from the PNG to see how it
> affects it?

No, I didn't ... I'll play with this later on.

Post a reply to this message

Mike Raiford wrote:
> Warp wrote:
>> Mike Raiford wrote:
>>> Setting Display_Gamma changes how the image looks POV-Ray's render
>>> window, but does nothing to correct the image.
>>
>>   Did you try setting File_Gamma and then rendering to an image format
>> other than PNG (ie. one which has no gamma metadata)? Or, alternatively,
>> did you try to remove the gamma metadata from the PNG to see how it
>> affects it?
> 
> No, I didn't ... I'll play with this later on.

Ok, so it does work with .bmp, but not .png

I can't find anything that will remove the gamma setting of a png image.

Post a reply to this message

Guys, you're still on the wrong track!

As I've pointed out to Warp about half a dozen of times, it is the 
/input file/ gamma handling that's broken indeed.

Your image looks washed out because the texture /is/ washed out (from 
the render engine's point of view).

Convert the texture file to PNG using IC for instance (to make sure it 
has a gAMA chunk, too), and you should be perfectly fine.

Post a reply to this message

> Guys, you're still on the wrong track!
>
> As I've pointed out to Warp about half a dozen of times, it is the /input 
> file/ gamma handling that's broken indeed.
>
> Your image looks washed out because the texture /is/ washed out (from the 
> render engine's point of view).

Exactly.  POV assumes all input files and colour literals are in linear 
colour space.  Images and colours that you see on your monitor (eg in 
picture viewer, colour picker, or on the web) are not in linear colour 
space, they have already been gamma corrected.  Unless you "undo" the gamma 
correction before handing them to POV, your output file is going to look 
very washed out as essentially they have been gamma corrected twice.  This 
is very obvious if you pick colours in Windows and then try to use them in 
POV, without undoing the gamma correction first they can be very obviously 
wrong!

> Convert the texture file to PNG using IC for instance (to make sure it has 
> a gAMA chunk, too), and you should be perfectly fine.

Or alternatively you can use a paint program to undo the gamma correction 
and save as bmp or jpeg.  I think someone also posted some SDL code here to 
do the conversion within POV.

Post a reply to this message

scott wrote:

> Exactly.  POV assumes all input files and colour literals are in linear 
> colour space.  Images and colours that you see on your monitor (eg in 
> picture viewer, colour picker, or on the web) are not in linear colour 
> space, they have already been gamma corrected.  Unless you "undo" the 
> gamma correction before handing them to POV, your output file is going 
> to look very washed out as essentially they have been gamma corrected 
> twice.  This is very obvious if you pick colours in Windows and then try 
> to use them in POV, without undoing the gamma correction first they can 
> be very obviously wrong!

Isn't this counterintuitive? Heck, even Photoshop, which has a very 
sophisticated color correction system will give you the colors you 
expect. e.g. If I give a 50% gray on input, I get in the output a 50% gray.

>> Convert the texture file to PNG using IC for instance (to make sure it 
>> has a gAMA chunk, too), and you should be perfectly fine.
> 
> Or alternatively you can use a paint program to undo the gamma 
> correction and save as bmp or jpeg.  I think someone also posted some 
> SDL code here to do the conversion within POV.
> 

In fact a gamma of 0.46 works well to "uncorrect" the gamma setting in 
the image, but this does cause a loss of color fidelity in the 
highlights, because the highlight area is being stretched over a larger 
range of colors, this could potentially cause posterization and banding 
in gradients.


With the following scene, what would you expect the output color to be?

global_settings
{
     max_trace_level 20
}

camera
{
     location <0, 0.2, -5>
     look_at 0


}

box
{
   -1,1

   pigment { color rgb .5 } // intuitively: 50% gray!

   finish { ambient 1 }
}

Sampled with irfanview, the box samples as 186,186,186 (not 128,128,128 
gray as you would expect!)

If your monitor is calibrated to a 2.2 gamma, this will be too bright, 
My colorimiter doesn't allow me to select a gamma higher than 2.4. With 
the monitor calibrated to the same gamma as a Macintosh it is way to 
bright. There is no calibration where the colors will look right.

Post a reply to this message

Attachments:
Download 'gamma.png' (2 KB) Download 'gamma_ps.png' (4 KB)

Preview of image 'gamma.png'

Preview of image 'gamma_ps.png'

> Isn't this counterintuitive?

Maybe, but I can see why POV was written the way it was.  If you specify rgb 
0.5 that means you want 50% physical brightness compared to rgb 1.0.  Note 
however, that if you are looking at an image in paint, RGB 128,128,128 is 
*not* 50% brightness on a normal monitor.

There have been several discussions here about adding a new keyword to POV 
so that you can specify gamma-corrected colours and images in SDL.

> In fact a gamma of 0.46 works well to "uncorrect" the gamma setting in
> the image, but this does cause a loss of color fidelity in the
> highlights, because the highlight area is being stretched over a larger
> range of colors, this could potentially cause posterization and banding
> in gradients.

That's totally the wrong thing to do.  You *must* set POV's output gamma 
correction to match your monitor (or just to 2.2 as it's a kind of standard 
nowadays anyway) to get anywhere near realistic scenes.  Then you need to 
make sure any colours or images you are giving to POV as *inputs* are in 
linear colour space (ie they have not already been gamma corrected).

> With the following scene, what would you expect the output color to be?
<snip>
>   pigment { color rgb .5 } // intuitively: 50% gray!
>   finish { ambient 1 }

With an output gamma correction of 2.2, I would expect the colour to be 
0.5^(1/2.2) * 255 = 186,186,186

> If your monitor is calibrated to a 2.2 gamma, this will be too bright,

No, I make it correct.  (186/255)^2.2 = 0.5, so on a monitor with 2.2 gamma, 
186 should be half as bright as 255.

The problem with *inputs* to POV is that a user sees a pixel of (255,186,0) 
on their desktop (ie 100% brightness red, 50% brightness green, and 0% 
brightness blue) and inputs this to POV:

pigment { color rgb <255,186,0>/255 }
finish{ ambient 1 }

Then renders and checks the pixel value in a paint program.  It gives 
<255,221,0> a totally different colour (and washed out).  The only way to 
get around this currently is to apply some inverse gamma to the colour you 
want out before you give it to POV.  Of course you need to do this for 
images too.

Post a reply to this message

scott schrieb:
> Images and colours that you see on your monitor (eg in 
> picture viewer, colour picker, or on the web) are not in linear colour 
> space, they have already been gamma corrected. 

(Well, to be /exact/, they /are/ in linear color space (or should be), 
because the display hardware's gamma and the gamma pre-correction cancel 
out; after all, that's what the pre-correction is for ;-))

Post a reply to this message

>> Images and colours that you see on your monitor (eg in picture viewer, 
>> colour picker, or on the web) are not in linear colour space, they have 
>> already been gamma corrected.
>
> (Well, to be /exact/, they /are/ in linear color space (or should be), 
> because the display hardware's gamma and the gamma pre-correction cancel 
> out; after all, that's what the pre-correction is for ;-))

I meant the actual image and colour data itself, like what is stored in a 
jpeg file, or when you set the fill colour to (220,120,64) in a graphics 
program.  All those values you are used to seeing and probably "knowing" 
have already had gamma correction applied to them, you cannot just use them 
directly in POV without undoing the implied gamma correction first.

Post a reply to this message