>  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

Christoph Hormann <chr### [at] gmxde> wrote:

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

Yes indeed. I bought a very nice Samsung LCD monitor last year, mainly for
use with POV-Ray, expecting a much better visual representation of
on-screen colors and contrast...not realizing this difference. Comparing
rendered images on this monitor and on two other CRT monitors I own, I
immediately opted to keep using the CRTs and return the LCD monitor. The
differences in color and contrast were quite striking (and not in a good
sense.) Sure, LCD monitors have their place--but give me a good ol' CRT any
day, for doing computer graphics imagery.

It's interesting to note that many high-end CG special effects companies
continue to use CRT monitors to do their exacting work on.

Ken W.

Post a reply to this message

In article <45afb6f1@news.povray.org>, war### [at] tagpovrayorg says...
> 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.
> 
No they wouldn't. They would only see the ones produced on systems with 
brighter or darker displays that way. Most, since most people are using 
basically the same hardware, don't play games, are not pros when it 
comes to graphics, etc, **never** adjust the brightness of the display, 
so unless the guy sending the image is on a Mac and you are viewing it 
on a PC, no difference is seen at all. Even if this does happen, most 
people chalk it up to the image "looking as intended", even if it isn't, 
they just don't know any different. Its only when two people with 
different systems actually compare notes that it becomes obvious that 
the PC made image or Mac made one is bleached or too dark. If you don't 
know there is a problem, you won't notice the problem, and sadly, since 
most applications do Software gamma, instead of hardware correcting by 
increasing/decreasing the entire output to the display, you can actually 
get "corrected" images that look too dark of bleached, because the 
colors on them "can't" be corrected numerically. How do you make &FEFE60 
"brighter" without making it almost white, or &101000 darker, without 
making it almost black? You can't. You can "hardware correct" the entire 
display to make "everything" brightened or darker, without altering the 
actually values in the image.

Frankly, other than the existing issues, I think there is a more serious 
problem with Gamma. Mainly, to work right you would need a graphics card 
that supported "more" colors than actually possible, in other words, use 
8 bits per channel for the "image", but have 10/12 bits per channel for 
the "card". That way the "image" would reside in the "middle range", but 
color values on the card might range from -15 to 270 per channel 
(forgive me if I did the math wrong). That way, if you need to gamma 
correct you *shift* the values of the image, not the entire display. I 
am 99.9% sure that it doesn't work that way, so you either end up 
adjusting the "values" in the image, which won't work if they are too 
close to the white or black thresholds, *or* you adjust the entire 
display to compensate, which then messes up any windows you are "not" 
viewing the image in.

Anyway, point is, with most formats, unless someone specifically tells 
you that they made the image on a system with a different gamma than 
yours, you a) probably won't know its looks wrong anyway, and b) in many 
cases they intentionally avoid making scene with obviously bright areas 
or obviously dark ones, where detail "will" be lost on a system that has 
the wrong gamma. This however isn't always either practical or possible. 
But I have definitely seen images in lots of place that you can't see 
well without making them brighter, especially on 3D sites.

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