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

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

As a followup, the Moz team reported back to me that the gamma was 
stored inccorrectly in the file.  They claimed that the stored gamma was 
2.2, and it should have been 1.0/2.2

I tested this, using PNGCrush to replace the gamma of an image created 
with the 3.7 beta with .4545, and the image displayed correctly in both 
Firefox and the Explorer preview ("Windows Picture and Fax Viewer").

Is this a valid statement, that the 3.7 Beta writes the gamma wrong, or 
is the Mozilla team wrong in their interpretation of the Gamma issue?

...Chambers

Post a reply to this message

Ben Chambers wrote:
> Is this a valid statement, that the 3.7 Beta writes the gamma wrong, or
> is the Mozilla team wrong in their interpretation of the Gamma issue?

This whole thread was about 3.6, at least that is what I thought. You should
not have filed a bug report using a 3.7 beta as reference :-( I don't know
if that is right or not as you may recall there had been changed to gamma
handling in 3.7...

	Thorsten

	Thorsten

Post a reply to this message