> You seem rather confused about the subject of gamma correction.

This has ZERO relevance to gamma CORRECTION; I wrote the exact phrase "gamma
HANDLING" specificly to reflect that.

Read the post carefully: loads of graphics software ignores the fact that
graphics is not stored in a linear format(!!!). Standard addition and
multiplication cannot handle unlinear data. Such data must be converted
back/fourth to give accurate results. It's the equivalent of adding two log
graphs together _after_ the log function is applied to both; the result is
inevitably wrong:

Log(X)+Log(X) != Log(X+X)

Likewize:

pow(0.5,1/2.2)+pow(0.5,1/2.2) != pow(0.5+0.5,1/2.2)

In all CCD hardware (digital cameras, scanners, etc) the hardware format is
16-bpp gamma 1.0 (to support accurate image processing) which is then converted
to 8-bpp gamma 2.2 (IEC sRGB). This is also how the RAW format for dslr cameras
works in order to support loss-less and accurate image processing.

Programmers do this common error repeatedly:

Pixel = sin(variable)* 127.5+127.5

Which is TOTALLY WRONG!!! This is the way to do it (assuming gamma 2.2):

Pixel = pow(sin(variable)*0.5+0.5,1/2.2)*255

If anyone have a problem with my statement that graphics is not stored linear
format then please read the sRGB documentation which clearly states this fact.
....Scrap that. I searched the web and unfortunatley found out that the IEC
standards is only available as paperback copy (sigh). No wonder knowledge is
scarse. What red tape eating.. ..gibbons!

The second one admits that image data is not linear one must also accept the
fact that image processing requires import/export convertion.

Post a reply to this message