Warp wrote:

>   The biggest and most usual problems happen when the PNG does *not*
> have any gamma correction info. Some software out there will *assume*
> some gamma (eg. 2.2), others will assume linear color space (or whatever
> they are using for GIF and JPEG).

IIRC there was indeed a fault in the first draft of the PNG 
specification saying if no gamma chunk is present the application should 
not assume any gamma correction (meaning the image is in linear color 
space). But this was soon revised and happened more than 10 years ago.


>> The POV programmer (whoever this was) did it right, at least.
> 
>   Yet you can still suffer from gamma correction issues. For example,
> specify a surface color like <.5, .5, .5> to an object and apply a PNG
> as an image map to another object, expecting a color value of 128, 128, 128
> in the PNG to look exactly the same as the <.5, .5, .5>, and that might
> just not be the case.
>

well, I never had any problem doing exactly this with PNG files - with 
the PNG files I do use and do know they include a correct gamma chunk.
But this does NOT work with GIF/JPEG/TGA files and assumed_gamma = 1.0 
(what I always do - and if you have forgotten why reread my post about 
bump/specular/transparency maps and look at the antialiasing pictures in 
p.b.i). Changing the default behavior of POV (by assuming these files 
to be in sRGB color space instead of linear) would break the usage of 
them as bump etc. maps - something that does currently work as expected.


>   I think that the underlying problem is that gamma correction is applied
> improperly, and different programs and systems use different approaches
> at applying it, many of them erroneous. 

Agreed.


> Or perhaps not erroneous per se.
> Perhaps there is *no* way of taking gamma into account in a way which
> would work in all possible situations. The whole thing is a mess.
>

When you search this newsgroups for "gamma" and read all the posts (what 
I just did) the whole thing obviously IS a mess. But I guess I mean it 
for a different reason you did ;)


>   I believe that the problem could be solved (or at least greatly
> alleviated) if there was a unified universal standard which stated that
> *all* image formats must use a strictly linear color space for *everything*,
> and that the *only* place where gamma correction is applied is when showing
> the image *on screen* (or printed on paper, or whatever visual media).
>   This way you don't need to add any gamma correction information to any
> image because every single software out there would assume that it's
> already in a strictly linear color space, and every system knows how
> it should convert that linear color space when it sends it to the monitor
> (in other words, the only place where you fine-tune gamma correction is
> in the the OS).
> 

This is no solution at all and another common misconception. There is a 
good reason that 8bit/sample image formats are not linear because the 
human visual system is more sensitive in the dark areas and to avoid 
"color bands" it makes sense to use more bits in the dark area -> no
linear color space -> gamma correction. In times of low computer power 
it was merely a lucky coincidence that a common CRT also had a similar 
non linear response curve and we could send the image data directly to 
the display controller - without processing the data through lookup tables.
To avoid this you'll have to switch to 16bit/sample. But this means a 
much worse compression ratio (because the "noise" introduced into the 
low bits) and (just an educated guess) about 5x the filesize for a DCT 
or DWT compressed file format only to achieve the same visual quality 
for an average photographic image.
What is the point in doing this?


>   Saving gamma correction information on the image file is not needed
> because when eg. the image manipulation program uses the strict linear
> color space but the OS *shows* the window of the image manipulation
> program gamma-corrected for that specific system, it automatically means
> that the created image will look the same in other systems as well (as long
> as the gamma correction has been set up correctly in those systems).
>

B.T.W. with contemporary computer power nowadays EVERY image 
manipulation program should internal use a linear color space. This is 
one of the reasons I use Photoshop (and Windows for that matter - even 
if I dislike the business attitude of both companies behind them). Do 
not get me wrong, I'm not trolling about Gimp, if you like it, fine, but 
it simply does not do what I expect. (And I do not know about the 
current development status of CinePaint, last time I tried it on a linux 
box it just crashed unpredictable.)


>   In other words, every single program out there would use the exact same
> color space, and it's only up to the OS/display driver to show the colors
> properly gamma-corrected *on screen* (and no "correction" is performed
> anywhere else).
> 
>   However, things have got completely messed up because different programs
> use *different* color spaces and do not agree on a single common one. Some
> programs (I'm looking at you, Photoshop) want to gamma-correct the pixel
> values being edited, rather than leaving the gamma correction to the the
> OS/display drivers. Then they want to store the gamma value they used in
> the file, and expect every other program to read this info and perform the
> conversion to the pixel values.
> 

Just because I feel a little picky. A color space does also define what 
colors red, green and blue *are*. And there are good reasons to use 
different color spaces and embed colorimetric information into an image 
file (like e.g. using ICC profiles). But I do not want to open another 
can of worms ;)


>   It's a huge mess. Maybe there is no solution to all these problems
> because it all has become an unfixable mess.
> 
Ok. So finally we have the point again I meanwhile tend to agree ;)


-Ive

Post a reply to this message