|
|
|
|
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: PNG output much brighter than preview...
Date: 15 Jan 2007 11:40:57
Message: <45abae99$1@news.povray.org>
|
|
|
| |
| |
|
|
Warp wrote:
> Then why do all other image formats look the same with the viewer
> programs as how povray shows them?
For TIFF it is a missing feature (in POV-Ray) that gamma settings are not
written to file. The other formats are just so old they don't support it.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Daniel Nilsson
Subject: Re: PNG output much brighter than preview...
Date: 15 Jan 2007 13:09:24
Message: <45abc354@news.povray.org>
|
|
|
| |
| |
|
|
Warp wrote:
>
> Then why do all other image formats look the same with the viewer
> programs as how povray shows them? Why is PNG the only format that
> makes a difference? Why can't povray create the PNG in the same way
> as it creates the other, non-problematic image formats (IOW. without
> gamma info stored in it)?
>
> Why does the PNG need the gamma info? The other formats don't, and
> they work just ok. PNG is the only one which presents problems when
> the gamma info *is* included. How about not including it at all?
>
After reading a fair bit about gamma on the web during the years I think
I have a good grasp of it and can answer some questions.
First answering Warp:
If you create an image in windows (gamma 2.2) and save it as JPEG and
PNG and send whose to your friend who owns a mac (gamma 1.8) the JPEG
will look wrong while the PNG will look exactly as you intended (thanks
to the stored gamma info). This assumes that both systems use programs
that use gamma information as they should and that both system are
configured correctly.
More general discussion about gamma:
Gamma is a way to compensate for the non-linearity of the monitor (due
to the properties of the phosphor and electron gun). To get black you
output the value 0.0 (0) and to get white you output 1.0 (255), so far
so good. But to get something which look like 50% gray you don't output
0.5 (128), you output 0.73 (187) which is 0.5^(1/2.2), that is the gamma
correction. The non-linear transfer function of the monitor is
brightness = value ^ 2.2
and that takes the value 0.73 back to 50% gray as expected.
The above paragraph assumes gamma 2.2.
To make the whole thing more complicated, calculations on color values
(such as ray-tracing, filtering, image transformation with
anti-aliasing) should be done in linear color space (gamma 1.0) or
errors such as hue shifts will occur. That is why povray uses gamma 1.0
in all calculation and does the correction when it saves the image to a
file (or rather, I hope that's what 3.7 does, I does right?).
To see why calculations should be done in gamma 1.0 consider the task of
averaging two pixels, one black and one white, in a gamma 2.2 color space:
(0.0 + 1.0) / 2 = 0.5
If you just send this to the monitor you get a pixel that looks 22% gray
(0.5^2.2) and not 50% gray as you would expect. If the pixels are
colored it gets even worse, say one medium red (50% red) and one yellow
(100% red and green):
50% red in gamma 2.2 is 0.73
red: (0.73 + 1.0) / 2 = 0.86
green: (0.0 + 1.0) / 2 = 0.5
blue: (0.0 + 0.0) / 2 = 0.0
If you send that to the monitor it will look like 73% red, 22% green, 0%
blue. The expected values are 75% red, 50% green, 0% blue. The gamma 2.2
calculation yields a too dark color with a hue that is too much red.
In short:
For correctly configured systems, do calculation in gamma 1.0 and save
with any gamma in a file format that store the gamma (such as PNG). This
will always look as intended as long as the viewing program uses the
gamma information (this is how it should be in a perfect world).
For systems that may have programs that don't do gamma right, do
calculation in gamma 1.0 and save with the gamma of your target audience
in a format that *don't* store gamma. This will look right only if the
user viewing the image has a system with the gamma you used else it will
look wrong.
I hope this was understandable and that it answered a few question
people have about gamma.
--
Daniel Nilsson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> If you create an image in windows (gamma 2.2) and save it as JPEG and
> PNG and send whose to your friend who owns a mac (gamma 1.8) the JPEG
> will look wrong while the PNG will look exactly as you intended (thanks
> to the stored gamma info). This assumes that both systems use programs
> that use gamma information as they should and that both system are
> configured correctly.
I know the theory. The problem is that in practice gamma correction
only causes more problems than it's worth.
There's only one thing for which PNG is criticized by the industry
as a whole, and it's related to... surprise surprise, gamma correction.
Gamma correction in PNG causes lots of problems. For instance, if
you want to make a web page with a certain backtround color and add
a PNG image which uses that exact same color, you can blame gamma
correction for the fact that often you won't. While you can do that
with any other image format, and the image will match the background
color in the web page perfect, with PNG it often won't. It depends on
the browser. Some browsers read the gamma correction, others don't.
If there's no gamma correction, some browsers will guess a gamma
correction (screwing up the colors) while others will take the pixels
unmodified.
Other image formats simply don't have these problems. If you use
a certain color in a gif or jpg or whatever, you will get that certain
color, and it will perfectly match the same color used in the background
of the web page. With png you might or might not get the color you want.
In one browser it may look good, in another it may not.
The PNG standardization organization screwed up. They gave unwise
rules on what to do when a png file has no gamma information. Some
programs follow this rule, others don't. What is worse, if there *is*
gamma info, some programs will read it, others won't. Thus you might
get even 4 different results depending on the gamma info and the
program.
In my personal experience the least problematic course of action is
to not to include any gamma info in the png file. While that will not
guarantee anything (some programs may start "guessing" a gamma info
for it even if you don't want it to), I think most programs will then
just take the pixels as they are, in the same way is with any other
image format.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[Followup-To set to povray.general as this isn't really about the 3.7
beta anymore]
Take this as my vision of a future, prefect, gamma corrected world and
not so much of a solution for today's gamma problems ;)
Warp wrote:
> Gamma correction in PNG causes lots of problems. For instance, if
> you want to make a web page with a certain backtround color and add
> a PNG image which uses that exact same color, you can blame gamma
> correction for the fact that often you won't. While you can do that
> with any other image format, and the image will match the background
> color in the web page perfect, with PNG it often won't. It depends on
> the browser. Some browsers read the gamma correction, others don't.
> If there's no gamma correction, some browsers will guess a gamma
> correction (screwing up the colors) while others will take the pixels
> unmodified.
This may be true, I have not experienced it myself, though. In theory I
don't think it should be a problem if browsers implemented gamma
correction correctly. What I mean by that is that they should correct
both images and colors specified in css (assuming they are specified in
sRBG I guess, which seem to be the de facto standard). In practice
browsers don't do this of course and and I doubt that css (or any other
w3 standard) defines any gamma correction, so they probably never will.
You still need embedded gamma information (or standardized gamma) if you
want an image to look the same regardless of the target system's gamma.
I believe that is an important thing for CG-art.
> Other image formats simply don't have these problems. If you use
> a certain color in a gif or jpg or whatever, you will get that certain
> color, and it will perfectly match the same color used in the background
> of the web page. With png you might or might not get the color you want.
> In one browser it may look good, in another it may not.
With gif (or others) you get the pixel value you want, with png (with
embedded gamma) you get the perceived color you want. In web pages the
former is more important (because browsers don't gamma correct css
colors) and when showing the image to others the way it's supposed to
look the latter is more important. It all depends on what the image's
purpose is.
> The PNG standardization organization screwed up. They gave unwise
> rules on what to do when a png file has no gamma information. Some
> programs follow this rule, others don't. What is worse, if there *is*
> gamma info, some programs will read it, others won't. Thus you might
> get even 4 different results depending on the gamma info and the
> program.
(I have not studied the PNG-standard closely so IIUC...)
Fact remains that if all programs followed the standard's rules
regarding gamma (unwise or not), any given png-image would look the same
regardless of the target system. As I see it the problem is that
programs don't follow the standard. In practice you can't (easily, if at
all) fix the programs so you have to find some workaround. I don't have
any solution but it is not a good idea to remove gamma support from
programs that have it (e.g. povray).
> In my personal experience the least problematic course of action is
> to not to include any gamma info in the png file. While that will not
> guarantee anything (some programs may start "guessing" a gamma info
> for it even if you don't want it to), I think most programs will then
> just take the pixels as they are, in the same way is with any other
> image format.
As you can see from my posts I am sort of a fan of gamma correction, but
I'm more of a theoretical guy, not doing much raytracing and image
related work right now. I once started writing my own raytracer and that
was when I encountered gamma first. After reading many articles on the
web I understand how it works and why it is needed. I think it's a
necessary evil, in a perfect world we would only use gamma 1.0 with
floating point values. It's non-linear hardware and the limited dynamic
range of 8-bit values that force us to use gamma correction and the fact
that different manufacturers chose different factors that make it a
PITA, IMHO.
--
Daniel Nilsson
Post a reply to this message
|
|
| |
| |
|
|
From: Eero Ahonen
Subject: Re: PNG output much brighter than preview...
Date: 16 Jan 2007 14:37:58
Message: <45ad2996@news.povray.org>
|
|
|
| |
| |
|
|
[Followed Daniel, by setting follow-ups to .general]
Warp wrote:
> Gamma correction in PNG causes lots of problems. For instance, if
> you want to make a web page with a certain backtround color and add
> a PNG image which uses that exact same color, you can blame gamma
> correction for the fact that often you won't.
Possibly surprisingly that's handness of the web developer. PNG supports
transparency, so there actually should be no real need to get the same
background color as at the page.
Fortunately for you JPG's are usually far more practical on the web,
while they take up less space.
> If there's no gamma correction, some browsers will guess a gamma
> correction (screwing up the colors) while others will take the pixels
> unmodified.
I quickly checked the PNG specs and seems the specified way is to guess
the gamma. I'm not sure if it's a good idea.
> In one browser it may look good, in another it may not.
That's pretty common on webpages these days. :(
> The PNG standardization organization screwed up. They gave unwise
> rules on what to do when a png file has no gamma information.
Yes, but...
> Some programs follow this rule, others don't.
...it's still specsed, so every program should follow the rule. The
final colors would vary less.
> What is worse, if there *is* gamma info, some programs will read it, others won't.
This certainly is no PNG standardization group's fault, some programs
just act wrong.
> Thus you might
> get even 4 different results depending on the gamma info and the
> program.
No, there's 3 choices, since not reading the gamma info and missing the
gamma info should result the same:
1) Gamma is correct (gamma is presented and used)
2) Gamma is guessed (gamma is missing or hasn't been checked)
3) Gamma is forgotten (gamma is missing or hasn't been checked)
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethiszbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <45abea7f@news.povray.org>, war### [at] tagpovrayorg says...
> In my personal experience the least problematic course of action is
> to not to include any gamma info in the png file. While that will not
> guarantee anything (some programs may start "guessing" a gamma info
> for it even if you don't want it to), I think most programs will then
> just take the pixels as they are, in the same way is with any other
> image format.
>
Actually.. A real good, if only slightly related, issue that can
demonstrate the problem is games like Myst. This is where the, "looks as
it should, not the color I said", issue becomes a *major* issue. Myst
was originally made on the Mac, it was then ported to Windows. Due to
the way the displays handled color, the only way to **see** every detail
was to either increase the graphics card gamma (not available at the
time) **or** increase the brightness of the display. Its even part of
the standard install for some such games that you have a "settings"
page, where you adjust the brightness up to compensate for the fact that
the displays default, which looks good for ***Everything else***, will
show all the color detail for the game. Gamma on the card works to, but
can be useless, depending on how the card does it, because some cards
don't increase the outputs, they just bleach the images by increasing
the color values.
Nearly all games use Gamma now *period*, generally through the card,
because the system they "started on" didn't use the same display gamma
as the final machine they end up on. That can be due to everything from
the type of display, the OS, the graphics card, or just how someone had
to compensate for a game that didn't use it, do that *that* game would
appear as intended. And for some like the Myst series, just seeing a
switch or a critical object in a dark tunnel **requires** that the
display is accurate to what the production machine used to make them
are. Now.. For 90% of us, still images are not a problem. We don't do
dark rooms with lots of subtle details. If a tiny bit gets blured into
the background, we don't care. But.. There have been cases in
*professional* business where someone has sent an image in the wrong
Gamma, only to have the client reject it, because they couldn't *see*
the details on their system. Gamma is supposed to correct this. If done
right, its supposed to correct it via hardware, so that colors don't
bleach in the high end, or blur into the dark areas, for lower intensity
colors. Unfortunately... Most application don't use hardware gamma,
so... And the ones that do use Gamma at all get people mad, because they
don't bother getting the settings right on their end in the first place,
so the image comes out wrong in the first place.
Imho, two things are really needed to correct this. 1. Proper use of
Gamma in all applications. 2. Displays that can ID their "current"
gamma, so that the software can correct for what the display is actually
showing, not what some tech either a) failed to set correctly, or b) set
wrong. The closest they have right now is color correction data, like
for mine, which "assume" that you are using the display in its factory
defaults for color intensity and that the software is *asking* the OS
what the color profile is for that display, so that corrections can be
made, in theory, for not just the brightness, but also for difference in
actual color values. I have yet to see any example of that happening
though.
Basically, its a great idea, if people @$$@#$ used it right, the
hardware was smarter and you could find some way to take idi... people
out of the equation. lol
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> 2. Displays that can ID their "current"
> gamma, so that the software can correct for what the display is actually
> showing
That's actually a good point. Given that different displays will have
different brightness curves, it seems really odd that the displays don't
tell the computer what this curve is so that the computer can act
accordingly. At most you get a floppy with the monitor which contains
this info and it might, just might, get used by the OS for *something*.
It usually doesn't seem enough, though.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: PNG output much brighter than preview...
Date: 17 Jan 2007 04:49:26
Message: <45adf126@news.povray.org>
|
|
|
| |
| |
|
|
Warp wrote:
> That's actually a good point. Given that different displays will have
> different brightness curves, it seems really odd that the displays don't
> tell the computer what this curve is so that the computer can act
> accordingly.
Many cheap ones won't, but they actually could, via DDC, which by far most
displays do support. Slightly more expensive displays do offer gamma control
in conjunction with graphics cards this way.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'd just like to add my input to this discussion and say that POV-Ray,
in correctly following the spec, is doing what it should. Rather than
make POV adjust for bad programs, we should complain to the authors of
those other programs...
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> I'd just like to add my input to this discussion and say that POV-Ray,
> in correctly following the spec, is doing what it should. Rather than
> make POV adjust for bad programs, we should complain to the authors of
> those other programs...
But that doesn't help too much, does it?
IMO there should be at least a way to turn gamma correction completely
off in POV-Ray.
After all, sometimes people might want *exact* pixel values in the
resulting image file. Not everything people do with POV-Ray is photographic
in nature.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|