 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> As I've pointed out to Warp about half a dozen of times, it is the
> /input file/ gamma handling that's broken indeed.
If the output of POV-Ray is perfect, then why does POV-Ray produce
*different* results when outputting to TGA or BMP than it does when
outputting to PNG?
You have yet not answered that question (nor the others I have made).
If your answer is something along the lines of the output to other
file formats being broken (which would already contradict what you have
said), then you'll have to explain the purpose of File_Gamma. If PNG
output is the only output format which is not broken, and File_Gamma has
zero net effect on the result when outputting to PNG (any change in the
pixel data is countered by the reverse change in the gamma metadata),
then what exactly is the purpose of File_Gamma?
You will also have to explain why POV-Ray displays on screen an image
which is different from what it writes to the PNG file, even though
Display_Gamma and File_Gamma have been set to the same value. I'm not
getting what I'm seeing. Coincidentally (not), when outputting to some
other image file format, such as TGA, the resulting image is identical
to what POV-Ray showed on screen.
If your answer to this is also that the image preview is broken, then
you'll likewise will have to explain the purpose of Display_Gamma if, in
your opinion, it should have zero effect on what POV-Ray displays on screen.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>> As I've pointed out to Warp about half a dozen of times, it is the
>> /input file/ gamma handling that's broken indeed.
>
> If the output of POV-Ray is perfect, then why does POV-Ray produce
> *different* results when outputting to TGA or BMP than it does when
> outputting to PNG?
>
> You have yet not answered that question (nor the others I have made).
It seems we can't reach common ground where I could actually explain
that to you. I don't know whether it's me or you, but we obviously can't
seem to. I tried to answer those questions half a dozen times if not
even more by now in good faith, only to get responses from you asserting
that I didn't answer anything, so something must be going terribly wrong
with our communication.
Let me try once again:
The whole idea of gamma handling is to get output right: To have the
monitor reproduce exactly (or as exactly as possible) what was
originally recorded in the image file.
Obviously, for non-CGI files, what was originally recorded in an image
file is physical brightness (of R, G and B component). This is what the
monitor must therefore reproduce.
Now one might think that encoding the physical brightness linearly in
the image file would be the most straightforward solution to this.
However, early file formats started out differently.
First thing is that displays were invariably CRT (unless output was
printed), and that display and graphics hardware was simple. Now this
has the following implications:
- In CRT displays, the energy of the electron beam (and therefore the
resulting brightness of the phosphor) is /not/ linear proportional to
the input signal voltage, but roughly square: CRT displays have an
inherent /display gamma/.
(Technically, this means that the output brightness is a function of the
input signal voltage of the form f(x)=x^gamma.)
- Graphics adaptors, however, as soon as they became able to display
more than just two brightness levels (on/off), used more or less
straightforward linear digital-to-analog conversion to convert frame
buffer data to signal voltage levels. Thus, the display system as a
whole exhibited that same inherent gamma as the CRT display that
happened to be connected.
The exact value of that gamma, however, depended (and still depends
today) on the exact combination of display and and graphics adaptor, and
therefore especially in the IBM-PC world differs to this day between
individual computers.
---
This is where POV-Ray's "Display_Gamma" kicks in: It informs POV-Ray
about the display gamma of the system on which the preview window is to
be displayed, so that POV-Ray can pre-correct the image data before
writing it to the frame buffer (or passing them to the operating system
for that purpose).
---
Now when graphics file formats emerged, the first ones in common use
were mere dumps of the display framebuffer; often, files would even
store the data into separate bit planes, just as it was organized in
some display adaptors' framebuffers. Therefore, of course, they implied
a certain display gamma: They were /gamma pre-corrected/.
As the fidelity of graphics displays was still low anyway, nobody cared
about the precise value of the gamma at that time. Virtually nobody was
even aware that it was there.
This is how older file formats like TIF or BMP started out: They relied
on every display having an inherent gamma, and the file data therefore
pre-corrected. However, they did not specify exactly what gamma was to
be expected, and each file would be pre-corrected to match the display
gamma of whoever happened to have created that particular file.
---
This is where POV-Ray's "File_Gamma" kicks in: It informs POV-Ray about
the display gamma of the system on which the file is to be viewed or
post-processed, so that POV-Ray can pre-correct the output file to match
that display.
---
Some file formats, however, have addressed the problem of gamma varying
between different computers, by using linear encoding. To display such a
file, the decoding software must apply gamma correction itself, before
passing the data to the graphics hardware. Of course, in this case the
displaying software must be aware of the system's inherent display gamma.
Other file formats are kind of "logically linear" despite using an
/encoding gamma/ to preserve a higher "depth" at lower brightness. To
display such a file, the decoding software must "un-apply" the encoding
gamma first, then apply any display gamma correction; in practice, this
can be done in one step by applying
f(x)=x^(1/(encoding_gamma*display_gamma))
PNG belongs to this group of file formats, provided that a gAMA chunk is
present.
---
This is where POV-Ray's "File_Gamma" kicks in again, this time in a
slightly different role: It informs POV-Ray about the encoding gamma to
be used, as the PNG format leaves this choice up to the creator of the file.
Or, to be more precise, it informs POV-Ray about the /inverse/ of that
encoding gamma. This has the benefit of being more intuitive, because
the values will be in the same domain as for the parameter's classic role.
There is also a rationale why this parameter isn't just hard-coded into
POV-Ray, and why to use File_Gamma and not yet another parameter:
Sometimes, software handling a PNG file may not be able to process the
gAMA chunk, and will silently assume the file to be encoded with gamma
pre-correction, i.e. encoding_gamma = 1/display_gamma. In that case,
File_Gamma automatically takes back its classical role of specifying the
target system's display gamma.
---
Does this answer your question of what exactly File_Gamma does, and why
it has different effects on different file formats?
> You will also have to explain
I have to explain nothing. (This is exactly the attitude that drives me
berserk. It is not /my/ responsibility to make sure that you're
well-informed.)
> why POV-Ray displays on screen an image
> which is different from what it writes to the PNG file, even though
> Display_Gamma and File_Gamma have been set to the same value.
As I mentioned before, this only happens if you set Display_Gamma wrong:
In that case, POV-Ray will no longer be able to perform proper gamma
correction on the image data it hands to the display hardware, and
therefore what you see on-screen will no longer be what POV-Ray
computed; is it any surprise to you that in that case what ends up in
the file (which is supposed to be what POV-Ray computed) may differ from
what you see in the preview?
Note that when I'm saying things like "what POV-Ray computed", I take
gamma correction to /not/ be part of that computation; it is merely an
additional transformation of the output data required to get the
computed data through the display hardware onto your retina, unpertubed
by the peculiarities of the hardware.
> I'm not
> getting what I'm seeing. Coincidentally (not), when outputting to some
> other image file format, such as TGA, the resulting image is identical
> to what POV-Ray showed on screen.
Not much of a surprise that it looks the same with those file formats:
Whether you fail to perform gamma correction before sending data to the
framebuffer yourself, or fail to apply gamma pre-correction before
writing output to a file format that is silently expected by all image
display software to implicitly include gamma pre-correction, the effect
is the same: Values originally implied to be linear brightness values
will be written directly to the framebuffer without applying proper
gamma correction first.
The fact that both look the same doesn't make any one of them right.
You're welcome of course to try shoving gamma-pre-corrected values into
POV-Ray in the first place and hope that this will make up for the
artificially forced lack of gamma-correction of the output. Be prepared
however for this to not work: The render engine in POV-Ray is designed
to operate on linear brightness values, and you'll end up with math
where all of a sudden 0.5 + 0.5 = 2.3. You may not be able to put your
finger on where exactly the output is wrong, but you may have a much
harder time getting your shot to look realistic. And this is precisely
why POV-Ray does not provide full support for such nonsense.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> The fact that both look the same doesn't make any one of them right.
So you are basically saying that all the other image file formats
except PNG are the broken ones.
OTOH, the only way one can match POV-Ray-generated pixel colors with,
for example, the pixel color in an existing JPEG image or with HTML
colors is to use File_Gamma=1.0 and bypass the "correction" that POV-Ray
is doing, by either rendering to TGA, or removing the gamma information
from the generated PNG file.
As it is now, there exists no official way of matching pixel colors in
such way. It only becomes possible by abusing side-effects (TGA not
having gamma information) or file format editing trickery (removing
gamma info from the PNG).
Most importantly, there exists no official way of making POV-Ray 3.7
generate the exact same PNG image as POV-Ray 3.6 does for the exact same
scene. Even "#version 3.6" won't do that (because 3.7 still writes the
gamma information to the PNG file, making it look different).
Even when the gamma correction of input image files is corrected, this
can still be a nuisance in certain situations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> So you are basically saying that all the other image file formats
> except PNG are the broken ones.
No, what I'm saying is that they're inferior, not that they're broken.
Just like I wouldn't call GIF broken because it can only represent 256
different colors, I wouldn't call some image file format broken just
because it does not explicitly specify the gamma pre-correction that was
applied to its content.
Furthermore, this inferiority doesn't apply to "all the other image file
formats": HDR and OpenEXR are gamma-aware as well (with the latter
mandating strictly linear encoding IIRC).
Even JPEG /could/ be used in a gamma-aware fashion, as it allows to
embed color profiles, which goes even a step further. Unfortunately
POV-Ray doesn't seem to make any use of this feature, neither for output
nor for input.
> OTOH, the only way one can match POV-Ray-generated pixel colors with,
> for example, the pixel color in an existing JPEG image or with HTML
> colors is to use File_Gamma=1.0 and bypass the "correction" that POV-Ray
> is doing, by either rendering to TGA, or removing the gamma information
> from the generated PNG file.
That is wrong: As I have pointed out many times, one can also match
POV-Ray-generated pixel colors with something else by choosing suitable
/input/ values for POV-Ray, and this is in fact the correct way to do it.
And I have also mentioned many times that POV-Ray is /not/ performing
any "correction" on PNG files created with File_Gamma=1.0, but that it's
the display software which (correctly) does this. As a matter of fact,
POV-Ray-generated PNG files with File_Gamma=1.0 are the "most linear"
files you could ever get:
- The brightness values are encoded linearly in the file.
- The gAMA chunk contains the value 1.0, telling any reading software
"don't perform any gamma-correction on this file unless you need to".
Which is exactly what viewing software will do, because it needs to.
Because the hardware has an inherent gamma of roundabout 2.2 which needs
to be compensated for.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
