Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> Fact remains that if all programs followed the standard's rules 
> regarding gamma (unwise or not), any given png-image would look the same 
> regardless of the target system.

  But the problem remains that if all programs followed that "guess a
gamma for a gammaless png" rule, pngs would become completely unusable
in web pages where matching some png color with a css (or whatever other)
color is necessary. The same is probably true for other similar
applications (although perhaps with less impact, given that web pages
are the single most widely viewed things in completely different
architectures).

  I think that an image telling "I want you to use this gamma correction
with me" is the wrong approach. It causes all kinds of problems with
things which do not have that kind of gamma information.

  I think that the gamma problem has been approached from the wrong end.
They try to solve gamma problems by wanting the *images* to have some
gamma correctio info.

  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.

  Currently this problem has been solved in the completely wrong and
retarded way. If in one system "exactly half brightness" means 135,135,135
then the image will be created with that pixel value and a gamma correction
information is put in the file which in practice says "when you find the
value 135 it actually means 'exactly half brightness'". Now if in another
system 'exactly half brightness' means 120,120,120 then it has to convert
the 135s to 120s before showing them. This, of course, causes all kinds
of problems. Some programs will do that, others won't. Some programs
will not even know what is the proper correction to be applied (ie.
they don't know which value 'exactly half brightness' is in that
specific system).

  As I said, IMO "exactly half brightness" (with a 8bpp image) should
mean 128. No more, no less. The target OS can then do whatever
modifications it wants so that it will also *look* exactly half as
bright as the full brightness.

  This way if you specify 128,128,128 as a webpage background color
and you have 128,128,128 used in a png, they will always match. They
will both be corrected in the same way by the OS.

  Currently, with the reversed (and retarded) logic, this is just not
possible.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> 
>   But the problem remains that if all programs followed that "guess a
> gamma for a gammaless png" rule, pngs would become completely unusable
> in web pages where matching some png color with a css (or whatever other)
> color is necessary.

The problem here is that programs apply different 'guessed' gamma 
correction to the css colors and png colors.  It would only make sense 
to guess a gamma correction for none specified when this guess is 
equally used for images and other colors.

>   I think that an image telling "I want you to use this gamma correction
> with me" is the wrong approach. It causes all kinds of problems with
> things which do not have that kind of gamma information.
> 
>   I think that the gamma problem has been approached from the wrong end.
> They try to solve gamma problems by wanting the *images* to have some
> gamma correctio info.
> 
>   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) [...]

The problem about this is that people are so used to specify colors in a 
non-linear color space that a change in this would be very difficult to 
introduce.

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.

Leaving the gamma correction all to the monitor and having the rest run 
with normal linear colors would be technically feasible and would 
simplify all this.  Sadly this will most likely never happen (at least 
not in my lifetime).

-- Christoph

Post a reply to this message

>  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 () {
  If Schrödingers_cat is alive  
    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

"Jérôme M. Berger"  wrote in message <45b3bb75@news.povray.org>:
> 	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:
> "Jérôme M. Berger"  wrote in message <45b3bb75@news.povray.org>:
>> 	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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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