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

In article <45b3b51b$1@news.povray.org>, ben### [at] pacificwebguycom says...
> Zeger Knaepen wrote:
> > it already is implemented in a way, as far as I know.  Both my computer
s, one 
> > with an nVidia and one with an ATI videocard, have systemwide gamma-cor
rection 
> > settings 
> > 
> > 
> 
> Yes, and mine does too.  However, many people never bother looking for 
> such settings, let alone fixing them.
> 
Nor do they help you one bit, if the image is *still* not right for the 
gamma you are dealing with, corrected or not.

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

BTW. Sorry for the post delay. Stupid client isn't smart enough to send 
them "as they are made", which can be nice, except it can send them 
before you want them to be too (based on timed rechecks), nor is it 
smart enough to bloody send, never mind ask, *before* closing. :p

-- 
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 in message
<MPG.201c800845c4c970989fd5@news.povray.org>:
> Umm. Ok... But, from a purely practical standpoint, even if changing the 
> 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.

You are wrong. As someone already pointed, the gamma does not affect the
black and white points. It is a one-to-one mapping between the minimum and
maximum intensity level. It stretches the dark values, and compresses the
light ones, but there is no clipping whatsoever.

What there is, on the other hand, is loss of precision in the part that gets
compressed. For a gamma of 2.2, for example, value 0.5 becomes 0.73, which
means that, on the discrete scale, the two lower bits of the light colors
are lost.

Post a reply to this message

In article <45b8f419$1@news.povray.org>, nicolas$george@salle-s.org 
says...
> Patrick Elliott  wrote in message
> <MPG.201c800845c4c970989fd5@news.povray.org>:
> > Umm. Ok... But, from a purely practical standpoint, even if changing th
e 
> > effect, you get clipping, instead of correctly adjusted colors. Its lik
e 
> > 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.
> 
> You are wrong. As someone already pointed, the gamma does not affect the
> black and white points. It is a one-to-one mapping between the minimum an
d
> maximum intensity level. It stretches the dark values, and compresses the
> light ones, but there is no clipping whatsoever.
> 
> What there is, on the other hand, is loss of precision in the part that g
ets
> compressed. For a gamma of 2.2, for example, value 0.5 becomes 0.73, whic
h
> means that, on the discrete scale, the two lower bits of the light colors
> are lost.
> 
Sigh.. How about "blending" or "blurring" then, since the problem is 
that, basically, if you have a fine gradient that you "need" to have 
stay that way for the detail to be obvious, its going to screw things 
up. You lose data "period". It doesn't matter if it "technically" isn't 
messing up the white or black points, if it never the less has the 
unfortunate side effect of making it "look" like its doing so, by losing 
colors that *should* remain the same, just brighter or darker. Its what 
the perception is, not what may or may not actually be happening. And in 
90% of cases, people attempt to use Gamma to correct for how "bright" 
the image is, not if green looks 0.01% more blue on Fred's display than 
on Ralph's.

-- 
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 in message
<MPG.20243ea770f89bec989fd8@news.povray.org>:
> Sigh.. How about "blending" or "blurring" then, since the problem is 
> that, basically, if you have a fine gradient that you "need" to have 
> stay that way for the detail to be obvious, its going to screw things 
> up. You lose data "period". It doesn't matter if it "technically" isn't 
> messing up the white or black points, if it never the less has the 
> unfortunate side effect of making it "look" like its doing so, by losing 
> colors that *should* remain the same, just brighter or darker. Its what 
> the perception is, not what may or may not actually be happening. And in 
> 90% of cases, people attempt to use Gamma to correct for how "bright" 
> the image is, not if green looks 0.01% more blue on Fred's display than 
> on Ralph's.

Well, with discrete bounded color values, it is not possible to losslessly
increase the brightness. It is the pigeonhole principle.

Now, not being able to see the dark areas because there is not enough
contrast is a loss too. So the question is not loss / no loss, but between
different forms of loss. It is a matter of compromise. And under the
circumstances, a light gamma correction is a very good compromise.

Post a reply to this message

In article <45bc6ebb$1@news.povray.org>, nicolas$george@salle-s.org 
says...
> Patrick Elliott  wrote in message
> <MPG.20243ea770f89bec989fd8@news.povray.org>:
> > Sigh.. How about "blending" or "blurring" then, since the problem is 
> > that, basically, if you have a fine gradient that you "need" to have 
> > stay that way for the detail to be obvious, its going to screw things
 
> > up. You lose data "period". It doesn't matter if it "technically" isn't
 
> > messing up the white or black points, if it never the less has the 
> > unfortunate side effect of making it "look" like its doing so, by losin
g 
> > colors that *should* remain the same, just brighter or darker. Its what
 
> > the perception is, not what may or may not actually be happening. And i
n 
> > 90% of cases, people attempt to use Gamma to correct for how "bright"
 
> > the image is, not if green looks 0.01% more blue on Fred's display than
 
> > on Ralph's.
> 
> Well, with discrete bounded color values, it is not possible to losslessl
y
> increase the brightness. It is the pigeonhole principle.
> 
> Now, not being able to see the dark areas because there is not enough
> contrast is a loss too. So the question is not loss / no loss, but betwee
n
> different forms of loss. It is a matter of compromise. And under the
> circumstances, a light gamma correction is a very good compromise.
> 
Not if the quality of the image is "dependent" on those fine details, 
then its a bad compromise, since the hardware can't adjust "some" areas, 
instead of all of them, nor can software do it at all, since its 
constrained to those limited color ranges. The only workable solution 
would be if someone came up with a 64-bit color range, then set normal 
white and normal black at some higher number than 0. In other words, 
increase the color space, so that you can adjust it in a range that 
allows for changes due to both the color variations "and" the brightness 
differences that some systems have. The issue between MAC and PC with 
some games and images is not that the colors themselves "look" wrong, 
its that the entire spectrum is "darker" on most PCs than it is on a 
MAC. Adjusting the brightness of the display fixes this, usually, but 
can have unintended consequences to the colors. Gamma.. Tries to correct 
the ranges, but loses the fine detail you couldn't see in the first 
place, just on the opposite end from what ever you are adjusting from. 
Two dark means fine high end detail gets the most screwed, too bright 
and you lose detail in the dark areas. In cases where the problem is 
already not being "able" to see those areas, you need some way to adjust 
the "entire" image, not approximate it. Currently, cards don't seem to 
be able to do something like:

Gamma_Region(100,100,500,400,1.0)

Just:

Gamma_Everything(1.0)

This means if you don't want the "correct" hardware method, or you don't 
have it, you end up with an approximation, which can turn out to be 
*far* worse than just leaving it the way it is, in some cases.

-- 
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:
> The only workable solution
> would be if someone came up with a 64-bit color range, then set normal 
> white and normal black at some higher number than 0.

Just out of curiosity, but doesn't the HDRI format allow this?

And the newer video cards support single precision float values for each 
color value, so this shouldn't be a problem on them, either.

IOW, the problem is being fixed :)

...Chambers

Post a reply to this message

FWIW, I just filed a bug report for Firefox that it doesn't handle PNG 
gamma correctly :)

...Chambers

Post a reply to this message