POV-Ray : Newsgroups : povray.beta-test : PNG output much brighter than preview... Server Time
28 Mar 2024 21:23:58 EDT (-0400)
  PNG output much brighter than preview... (Message 11 to 20 of 22)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
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

From: Warp
Subject: Re: PNG output much brighter than preview...
Date: 15 Jan 2007 15:56:32
Message: <45abea7f@news.povray.org>
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

From: Daniel Nilsson
Subject: Re: PNG output much brighter than preview...
Date: 15 Jan 2007 18:00:09
Message: <45ac0779$1@news.povray.org>
[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

From: Patrick Elliott
Subject: Re: PNG output much brighter than preview...
Date: 16 Jan 2007 22:21:27
Message: <MPG.2017440c7104752e989fd3@news.povray.org>
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

From: Warp
Subject: Re: PNG output much brighter than preview...
Date: 17 Jan 2007 04:11:24
Message: <45ade83b@news.povray.org>
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

From: Ben Chambers
Subject: Re: PNG output much brighter than preview...
Date: 17 Jan 2007 16:19:13
Message: <45ae92d1$1@news.povray.org>
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

From: Warp
Subject: Re: PNG output much brighter than preview...
Date: 18 Jan 2007 03:30:09
Message: <45af3011@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.