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

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

Nicolas George wrote:

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

	"linear" doesn't mean anything. You should be more precise: "linear
with relation to xxx", where xxx could be one of:
 - Radiant intensity;
 - Luminous intensity;
 - Human perception.

	When you say that there is a gamma of 2.2, that is between sRGB and
luminous intensity, but that is absurd as a light measure: radiant
intensity makes sense as a pure physical value, luminous intensity
is computed from radiant intensity by taking into account some
characteristics of human perception but not all!

	sRGB is actually pretty close to being linear with relation to
human perception, which makes the most sense for use by people who
are not color specialists...

		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)

iD8DBQFFs8KId0kWM4JG3k8RAtJHAKC1z+K8F71+nNRr7x371c45oAosiQCgqUcY
Xl/xB8bF+W1rRfmVYIL3WHY=
=8zl/
-----END PGP SIGNATURE-----

Post a reply to this message

In article <45b1defa@news.povray.org>, pov### [at] daniel-nilssoncom says...
> Patrick Elliott wrote:
> 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)
> 
Umm. Ok... But, from a purely practical standpoint, even if changing the 
brightness doesn't "correct" the colors properly, it does make the parts 
of an image that where not previously visible so you can see them. This 
*can* produce a bleaching effect, since the adjustment isn't "correct", 
but its still far better than the result you get with software, simply 
because software can't adjust things past the effective limits of the 
"bandwidth" of the colors available in a 24/32-bit color system. In 
effect, you get clipping, instead of correctly adjusted colors. Its like 
adjusting the volume of a raw audio file format, instead of turning up 
your speakers. If "any" part of the sound is low enough to fall below a 
certain threshold and you adjust down, or it goes above a certain 
threshold and you adjust up... it ends up eating part of the *actually* 
waveform. Same with Gamma and software based solutions to it. That is 
what I was getting at.


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