Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> 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.

  But the problem remains that if all programs followed that "guess a
gamma for a gammaless png" rule, pngs would become completely unusable
in web pages where matching some png color with a css (or whatever other)
color is necessary. The same is probably true for other similar
applications (although perhaps with less impact, given that web pages
are the single most widely viewed things in completely different
architectures).

  I think that an image telling "I want you to use this gamma correction
with me" is the wrong approach. It causes all kinds of problems with
things which do not have that kind of gamma information.

  I think that the gamma problem has been approached from the wrong end.
They try to solve gamma problems by wanting the *images* to have some
gamma correctio info.

  IMO the problem should be solved in the exact opposite way: All pixel
information should be universally the same (ie. for example a value of
128 (in a 8 bits per channel image) means exactly half the brightness,
not more, not less) and the OSes then correct it so that it will look
like that in the target monitor. If the image wants an exactly-half-bright
gray color, then it specifies 128,128,128 for that pixel and the OS then
makes sure when showing that image that it will look half-bright on the
monitor by whatever corrections are necessary to achieve that.

  Currently this problem has been solved in the completely wrong and
retarded way. If in one system "exactly half brightness" means 135,135,135
then the image will be created with that pixel value and a gamma correction
information is put in the file which in practice says "when you find the
value 135 it actually means 'exactly half brightness'". Now if in another
system 'exactly half brightness' means 120,120,120 then it has to convert
the 135s to 120s before showing them. This, of course, causes all kinds
of problems. Some programs will do that, others won't. Some programs
will not even know what is the proper correction to be applied (ie.
they don't know which value 'exactly half brightness' is in that
specific system).

  As I said, IMO "exactly half brightness" (with a 8bpp image) should
mean 128. No more, no less. The target OS can then do whatever
modifications it wants so that it will also *look* exactly half as
bright as the full brightness.

  This way if you specify 128,128,128 as a webpage background color
and you have 128,128,128 used in a png, they will always match. They
will both be corrected in the same way by the OS.

  Currently, with the reversed (and retarded) logic, this is just not
possible.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> 
>   But the problem remains that if all programs followed that "guess a
> gamma for a gammaless png" rule, pngs would become completely unusable
> in web pages where matching some png color with a css (or whatever other)
> color is necessary.

The problem here is that programs apply different 'guessed' gamma 
correction to the css colors and png colors.  It would only make sense 
to guess a gamma correction for none specified when this guess is 
equally used for images and other colors.

>   I think that an image telling "I want you to use this gamma correction
> with me" is the wrong approach. It causes all kinds of problems with
> things which do not have that kind of gamma information.
> 
>   I think that the gamma problem has been approached from the wrong end.
> They try to solve gamma problems by wanting the *images* to have some
> gamma correctio info.
> 
>   IMO the problem should be solved in the exact opposite way: All pixel
> information should be universally the same (ie. for example a value of
> 128 (in a 8 bits per channel image) means exactly half the brightness,
> not more, not less) [...]

The problem about this is that people are so used to specify colors in a 
non-linear color space that a change in this would be very difficult to 
introduce.

It gets even more funny for LCD monitors that do not have the typical 
gamma characteristic of CRTs.  This means colors are sent to the monitor 
in a nonlinear form but then linearized again to be displayed.

Leaving the gamma correction all to the monitor and having the rest run 
with normal linear colors would be technically feasible and would 
simplify all this.  Sadly this will most likely never happen (at least 
not in my lifetime).

-- Christoph

Post a reply to this message

>  IMO the problem should be solved in the exact opposite way: All pixel
> information should be universally the same (ie. for example a value of
> 128 (in a 8 bits per channel image) means exactly half the brightness,
> not more, not less) and the OSes then correct it so that it will look
> like that in the target monitor. If the image wants an exactly-half-bright
> gray color, then it specifies 128,128,128 for that pixel and the OS then
> makes sure when showing that image that it will look half-bright on the
> monitor by whatever corrections are necessary to achieve that.

In theory this is a good idea, but the problem is with only 8 bits and a 
linear scale dark areas will look rubbish.  The eye is much more sensitive 
to differences in dark shades than bright shades, so unless you have a 16+ 
bit or floating point image, it makes quite a lot of sense to use a 
non-linear scale.

IMO it would be better to split "images" into two categories.  One where you 
want the exact pixel value to be shown on the monitor, so 50% in the image 
is 50% brightness, etc.  This would be used for web pngs that have to match 
CSS colours and diagrams that want to exploit "pure red", "pure white" etc 
on a monitor.  The other type would be "photo" type images, where you want 
all viewers to see exactly the same colour.  For this you should use a 
proper physical colour space, like Yuv to specify pixel colours.  It is then 
up to the OS/application how to translate these values into RGB to send to 
the monitor/printer/projector.

Post a reply to this message

> It gets even more funny for LCD monitors that do not have the typical 
> gamma characteristic of CRTs.  This means colors are sent to the monitor 
> in a nonlinear form but then linearized again to be displayed.

Well actually the LC response curve (brightness against voltage) is even 
funnier than the CRT curve, it is an S-shape.  Something like this: 
http://www.kth.se/fakulteter/TFY/kmf/lcd/image11.gif

There is normally a look up table that does the inverse gamma and the LC 
response curve all in one step.

Post a reply to this message

Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> 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.

  Transparency may not always be the answer. Sometimes you may want to
use color fadings which are not possible to achieve with the alpha channel.

> Fortunately for you JPG's are usually far more practical on the web,
> while they take up less space.

  A jpeg takes more space if the image is simple and uses just a few
colors. (Ok, you *can* make it take less space, but then the image will
look like crap.)

> 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.

  IMO it's a bad idea. I understand why they specified it like that,
but I think it's still a mistake, and less problems would have arised
if they would have not.

> > 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.

  Even if all browsers followed the PNG recommendations to the letter,
you still couldn't be sure to get matching colors between the PNG and
other elements in the page. The browser would have to apply the same
gamma correction to the other elements in the page too (which, if it
did that, would probably just cause more problems instead of solving
any).
  Of course funny things may happen if there are two PNGs in the wegpage
with *different* gamma info. (IOW, what should be done to the other
elements in the page?)

> > 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.

  Right, but think about image formats which do not support any gamma info.
No gamma-related problems appear there.

-- 
                                                          - Warp

Post a reply to this message

>  Of course funny things may happen if there are two PNGs in the wegpage
> with *different* gamma info. (IOW, what should be done to the other
> elements in the page?)

The gamma chunk within PNG's  just describes how the image data within
the PNG has to be interpreted and does of course not tell the browser how
to display the other elements of the page.
You can use multiple PNG files with different gamma settings on the same
web page without problems. Firefox (and meanwhile even IE) do work just
fine with this.

>> This certainly is no PNG standardization group's fault, some programs
>> just act wrong.
>
>  Right, but think about image formats which do not support any gamma info.
> No gamma-related problems appear there.

Wrong. The image data within all common 8 bit per sample graphic formats
(tga, bmp, pnm, tiff, jpeg and so on...)  is usually gamma corrected in some
way. (As someone else already mentioned here: the human eye is more
sensitive in the "darker" color range.  To avoid color banding, images
- at least 8bps ones - indeed should use a non linear color response curve).
So, as long the gamma value is not written to the file,  we have always just
a guessing game about the way the image data has to be "seen".
Remember remarks like: "..but the colors look a little bit washed out on
my monitor" or " ...the image appears to dark here...".

There is a good reason why programs like Photoshop include not just
the gamma info but a complete icc profile within image files like jpeg,
tiff and png. Sadly enough that color profiles are almost never used by
other applications (including POV-Ray).

Final note: I think there is no "gamma problem" at all - just the usual
problem that people do not really know what they are doing.

Final final note: back in 1992 (IIRC) I was working with some SGI
graphic workstations. There was no need to even think about
gamma correction because the operating system (together with
graphics card and monitor) did all the gamma stuff properly by
itself.
Sometimes I'm really wondering about the technical progress within
the IT industry.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftcom> wrote:
> Final note: I think there is no "gamma problem" at all - just the usual
> problem that people do not really know what they are doing.

  You can't deny the fact that PNG is the *only* format which has
caused people problem in relation to POV-Ray, and the problems are
always related to the gamma correction data embedded in the PNG.

  This, of course, raises the question of why other formats haven't
caused such problems.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Ive <ive### [at] lilysoftcom> wrote:
>> Final note: I think there is no "gamma problem" at all - just the usual
>> problem that people do not really know what they are doing.
> 
>   You can't deny the fact that PNG is the *only* format which has
> caused people problem in relation to POV-Ray, and the problems are
> always related to the gamma correction data embedded in the PNG.
> 
>   This, of course, raises the question of why other formats haven't
> caused such problems.
> 

I'm sure there are comments to images in p.b.i of the type "It looks 
very dark" or "The colors are a bit washed out", even though it looks 
good on the authors computer.
What do you call these if not gamma problems?
There are, obviously, problems both ways. I've already stated how it 
IMHO should be solved. To make povray not write the gamma info is a 
workaround and not a solution. I have nothing against such an option as 
long as it's not the default.

PS. I meant to post a reply earlier but Christoph and scott already said 
pretty much exactly what I was to say.

-- 
Daniel Nilsson

Post a reply to this message

Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> I'm sure there are comments to images in p.b.i of the type "It looks 
> very dark" or "The colors are a bit washed out", even though it looks 
> good on the authors computer.

  If there were people seeing images like that, then they would see
*all* images eg. on the internet like that. I think they would rather
quickly tune the brightness and contrast of their monitors.

  It's not as if all images in the internet have correct gamma info
in them while povray images don't.

-- 
                                                          - Warp

Post a reply to this message

Ive wrote:
> Final final note: back in 1992 (IIRC) I was working with some SGI
> graphic workstations. There was no need to even think about
> gamma correction because the operating system (together with
> graphics card and monitor) did all the gamma stuff properly by
> itself.
> Sometimes I'm really wondering about the technical progress within
> the IT industry.

Yes, it's the triumph of low-cost commodity hardware designed to be as 
cheap as possible, over high-end workstations held to high standards of 
performance.

Basically, it's the same reason that Walmart is successful.  People 
would rather have cheap trash than valuable quality :(

...Chambers

Post a reply to this message