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

Patrick Elliott wrote:
> 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.

I think you have slightly misunderstood gamma correction. The blackpoint 
and the whitepoint are not affected by gamma, it is only the middle 
range of values that are altered. 0 will be 0 and 255 will be 255 
whatever the gamma, no need for values "out of range". But there is a 
problem with the limited number of discrete values of 8 bit numbers if 
gamma correction is done in software.
To take your examples: FEFE60 gamma corrected to be brighter might end 
up being FEFE72, 101000 might become 090900 (I did the correction 
from/to 1.8 and 2.2). The values close to 00 and FF don't change much at 
all as you see, but there are some error introduced due to rounding. 
That error may show up as color banding.

You use the brightness and contrast knobs on you monitor to adjust the 
blackpoint and the whitepoint but that won't affect the gamma of the 
display. The color value to monitor output function is something like 
this (at least theoretically):
output = (brightness + contrast * value) ^ gamma
 From that formula it should be clear that there is no way to change 
brightness and contrast to compensate for wrong gamma and vice versa.
(A gamma knob on the monitor would be handy, maybe they have that on 
some monitors, I don't know)

-- 
Daniel Nilsson

Post a reply to this message

Warp wrote:
> 
>   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.

Might be right, but what kind of fadings are not possible with alpha
channel?

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

Yes. Usually for the images on the web JPEG is smaller than PNG.

Yes, there's also JPEG-crapped images in the web, which should be in
some other (lossless) format.

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

You should be able to inform the browser the gamma used making the page.
I think *ML is lacking this feature, please correct me if I'm wrong.

> The browser would have to apply the same
> gamma correction to the other elements in the page too 

No. In Perfect Web(tm) the browser should apply the gamma correction
specified in page source for the rest of the page and a object-related
gamma correction for objects which have one.

> (which, if it
> did that, would probably just cause more problems instead of solving
> any).

Indeed.

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

As I said, use the default gamma correction of 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.

Nobody thinks they are gamma-related (well, some do), but the problems
of difference still remain. You know "this works for me" -syndrome in
the clothes of "this images views just right and is readable in *my*
system".

-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> > The browser would have to apply the same
> > gamma correction to the other elements in the page too 

> No. In Perfect Web(tm) the browser should apply the gamma correction
> specified in page source for the rest of the page and a object-related
> gamma correction for objects which have one.

  I think that in a perfect world source colors (such as image pixels
and CSS color definitions) would use a universal standard of being
absolutely linear, and then it's the OS which gamma-corrects everthing
if needed.

  I think that the idea that people generate images so that they look
good on their monitor and then are supposed to put some "gamma info" in
it so that other people looking it with different monitors may use
proper corrections is exactly as stupid as someone posting ascii art
to a newsgroup using a variable-width font and then just putting a
note at the beginning saying "you should use this font to see this ascii
art properly". While it may work, it's cumbersome and stupid.

  The better idea for images is that the image creation program converts
it to the universal linear representation and then every system can just
assume that the input is linear and do the necessary conversions to make
it also look linear in the monitor.

  And if 8 bits is a concern, then use 16 bits.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I think that in a perfect world source colors (such as image pixels
> and CSS color definitions) would use a universal standard of being
> absolutely linear, and then it's the OS which gamma-corrects everthing
> if needed.

That is indeed a better system.  When do you plan on implementing it?

...Chambers

PS Wasn't it Patton who said "A good plan today is better than a perfect 
plan tomorrow?"

Post a reply to this message

"Ben Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:45b3aa07@news.povray.org...
> Warp wrote:
>>   I think that in a perfect world source colors (such as image pixels
>> and CSS color definitions) would use a universal standard of being
>> absolutely linear, and then it's the OS which gamma-corrects everthing
>> if needed.
>
> That is indeed a better system.  When do you plan on implementing it?

it already is implemented in a way, as far as I know.  Both my computers, one 
with an nVidia and one with an ATI videocard, have systemwide gamma-correction 
settings

Post a reply to this message

Zeger Knaepen wrote:
> it already is implemented in a way, as far as I know.  Both my computers, one 
> with an nVidia and one with an ATI videocard, have systemwide gamma-correction 
> settings 
> 
> 

Yes, and mine does too.  However, many people never bother looking for 
such settings, let alone fixing them.

...Chambers

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Chambers wrote:
> Warp wrote:
>>   I think that in a perfect world source colors (such as image pixels
>> and CSS color definitions) would use a universal standard of being
>> absolutely linear, and then it's the OS which gamma-corrects everthing
>> if needed.
> 
> That is indeed a better system.  When do you plan on implementing it?
> 
	It's already in the standards: the HTML specifications states that
color should be given in the sRGB color space. The browser/OS should
make any adjustments required to display them properly.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFs7t0d0kWM4JG3k8RArxbAKCnYxPAl6n8JnfrIzNqCrCRD5Hs1ACdFhUy
ci8UmiBNuGXwmXLeafnhMPs=
=WGuV
-----END PGP SIGNATURE-----

Post a reply to this message

> 	It's already in the standards: the HTML specifications states that
> color should be given in the sRGB color space.

Note that sRGB does not use linear values, but a gamma of 2.2.

Post a reply to this message