In article <45abea7f@news.povray.org>, war### [at] tagpovrayorg says...
>   In my personal experience the least problematic course of action is
> to not to include any gamma info in the png file. While that will not
> guarantee anything (some programs may start "guessing" a gamma info
> for it even if you don't want it to), I think most programs will then
> just take the pixels as they are, in the same way is with any other
> image format.
> 
Actually.. A real good, if only slightly related, issue that can 
demonstrate the problem is games like Myst. This is where the, "looks as 
it should, not the color I said", issue becomes a *major* issue. Myst 
was originally made on the Mac, it was then ported to Windows. Due to 
the way the displays handled color, the only way to **see** every detail 
was to either increase the graphics card gamma (not available at the 
time) **or** increase the brightness of the display. Its even part of 
the standard install for some such games that you have a "settings" 
page, where you adjust the brightness up to compensate for the fact that 
the displays default, which looks good for ***Everything else***, will 
show all the color detail for the game. Gamma on the card works to, but 
can be useless, depending on how the card does it, because some cards 
don't increase the outputs, they just bleach the images by increasing 
the color values.

Nearly all games use Gamma now *period*, generally through the card, 
because the system they "started on" didn't use the same display gamma 
as the final machine they end up on. That can be due to everything from 
the type of display, the OS, the graphics card, or just how someone had 
to compensate for a game that didn't use it, do that *that* game would 
appear as intended. And for some like the Myst series, just seeing a 
switch or a critical object in a dark tunnel **requires** that the 
display is accurate to what the production machine used to make them 
are. Now.. For 90% of us, still images are not a problem. We don't do 
dark rooms with lots of subtle details. If a tiny bit gets blured into 
the background, we don't care. But.. There have been cases in 
*professional* business where someone has sent an image in the wrong 
Gamma, only to have the client reject it, because they couldn't *see* 
the details on their system. Gamma is supposed to correct this. If done 
right, its supposed to correct it via hardware, so that colors don't 
bleach in the high end, or blur into the dark areas, for lower intensity 
colors. Unfortunately... Most application don't use hardware gamma, 
so... And the ones that do use Gamma at all get people mad, because they 
don't bother getting the settings right on their end in the first place, 
so the image comes out wrong in the first place.

Imho, two things are really needed to correct this. 1. Proper use of 
Gamma in all applications. 2. Displays that can ID their "current" 
gamma, so that the software can correct for what the display is actually 
showing, not what some tech either a) failed to set correctly, or b) set 
wrong. The closest they have right now is color correction data, like 
for mine, which "assume" that you are using the display in its factory 
defaults for color intensity and that the software is *asking* the OS 
what the color profile is for that display, so that corrections can be 
made, in theory, for not just the brightness, but also for difference in 
actual color values. I have yet to see any example of that happening 
though.

Basically, its a great idea, if people @$$@#$ used it right, the 
hardware was smarter and you could find some way to take idi... people 
out of the equation. lol


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