Ive <"ive### [at] lilysoftorg"> wrote:
> This is the point I really do not understand. The use of the png gamma 
> chunk is well documented in the png specs, the reference library libpng 
> (used by almost everybody) already includes all the code needed and the 
> usage is even as example code available. A programmer can just copy and 
> paste it. Still, the programmers of a lot of browser and other image 
> applications managed it to do it wrong (wrong as in programming a 
> calculator that says 1 + 1 = 3). And as a result the PNG format is 
> blamed for that.

  The problem is that some software out there apply the gamma correction
info properly, other software ignore it, and there is even some software
which apply the gamma correction incorrectly.

  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). You can easily have four or more
different programs, none of which show all PNG images in the same way,
because of gamma correction issues. Yet all the programs will usually
show GIF and JPEG images identically to each other.

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

  Sometimes gamma correction is applied when you don't want it to be
applied, sometimes it's not applied when you want it to be applied, and
sometimes it is applied when you want, but incorrectly.

  Gamma correction = problems.

> Well, ok, do not get me wrong, I really do see your point but my 
> conclusion is different. I would never say gamma correction = problem. 
> Gamma correction is a necessary (and in fact quite simple) concept that 
> has to been known in digital image processing. People who do not know or 
> understand it should not work there as a programmer. But they did and 
> this is the source for most irritation about the gamma subject.

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

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

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

  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.

  This is a bad idea, and only causes problems. It may work fine when you
simply want to *show* the image: First you apply the gamma correction
specified in the file to the pixels, after which the OS/display hardware
applies whatever gamma correction is necessary for the current hardware.
If this is done properly, the image will look the same as in the original
hardware.

  Problems start happening when you want to mix these images together and
with other color settings, eg. in a web page or a rendering software.
Should the gamma correction specified in the image be applied to the
image while reading it or not? If the web page or whatever uses its own
gamma correction, should it *also* be applied to the image or not? If
you want a color value of <.5, .5, .5> to exactly match the equivalent
color in the image, how can you do it? Should the color be gamma-corrected
to match the image? Or should the image be gamma-corrected to match the
color space where the <.5, .5, .5> was specified? How can you even know
which pixel value in the image corresponds visually to <.5, .5, .5>?

  It's a huge mess. Maybe there is no solution to all these problems
because it all has become an unfixable mess.

-- 
                                                          - Warp

Post a reply to this message