Gamma correction question

[Mike Engles]

That's quite an explanation Mike. I dont follow your curves, but the
difference of 0.45/0.4 = 1.125 does darken the image somewhat, less boost,
less expansion of the dark values, which seems to hurt more than help (this
dark expansion being the reported goal, to space the dark points wider).
Then the CRT decode will make it even darker. Frankly this reduced effect
doesnt seem to aid perceiving dark data steps.

But yes, I must agree that it is a remaining effect, however which Poynton
explains differently, the dim room also being related to why movie/slide
film has exaggarated contrast. To me, this effect doesnt seem to be
presented as a player in the dark end 8 bit problem. It would also affect 16
bit data coded to 2.2, which doesnt need it.

Poynton addresses the 8 bit 1% situation as entirely being a dark end
problem (which he applies to Luminance, not to Lightness as you do).

The 8 bit solution is a good story, and reading it sounds real good, until I
realize that the data is decoded by the CRT before humans ever see it. So
I'm wondering what actually is the remaining effect of encoding and then
decoding the 8 bit data that helps the eye better perceive the dark end of
8 bit data? And of course, why doesnt it work on my old CRT? <g>

Hello


The bottom curve is the gamma of a CRT.
2.5, very non linear

The next curve is the interaction of the scanned gamma(.45) and the CRT
gamma 2.5,
so 2.5 x .45= 1.13, just below linear

The next curve is the interaction of the CRT gamma(2.5) and its
inverse(.4),
so 2.5 X .4 = 1.0 which is linear.

The next curve is the interaction of our perceptual gamma(.3) and the
CRT gamma(2.5),
so .33 X 2.5= .83, just above linear.

The next curve is our supposed perseptual gamma(.33)

There ia one curve I omitted to to include.
That is the interaction of our perceptual gamma(.33), the CRT gamma(2,5)
and the scanned gamma(.45). In this instant the total effective gamma is
..33x.45x2.5=.37. This means that even codes 25 and 26 are not within the
perceptual limit. This curve will lie just below the.33 one.

The final curve is one that shows the interaction of our perceptual
gamma(.33) the CRT gamma (2.5) and the gamma that Chris Cox stated in
this thread was needed, even if we were using 16 bit images and a linear
display. He says gamma 2.0, I assume he means the inverse which is (.5).
If not I have misunderstood,

so .33 X 2.5 X.5 = .17. This means that some lower codes are brought
within the perceptual ratio,but at the expense of destroying all codes
above 217 and many below.

You are quite right when you say that the CRT will decode the scanned
gamma, even when we are not looking at it. It will produce measurable
linearity when the scanned gamma is the inverse of the CRT gamma.

In a sense it really does not matter what our perceptual gamma is.
All our perception requires is measurable linearity.

I used it to show up Mr Poynton's own logic against him.
When you look at the total transcaction you realise that Mr Poynton is
totally wrong. 8 bits linear is just perceptual with the limit of the
1.01 ratio.

If we said we had 9 bits or 512 levels, it will only effect those codes
outside the limit. So 12 bits would improve our perception, only if we
remain in 12 bits.

What 12 bits does give us is better dynamic range and HEADROOM for
processing. If we use curves heavily, we will rearrange the codes. Some
could fall outside the perceptual limit and may be noticable, but will
fall within when we go to 8 bits.

That is why Timo Autiokari has been right all along.
Inverse scanned gamma to the image compromises the mid tones and
highlights and reduces the headroom for processing. That is why haloing
is so noticable when using unsharp mask.

Inverse gamma is to correct for a CRT and not for reasons of perception.
Perception will take care of itself as long as it perceives linearity.

The same can be said for our hearing. Our hearing has a non linear
response. It is very insensitive to low frequencies at low pressure
levels. This flattens out as the sound pressure increases. Our ears are
tuned to a narrow band of frequencies, they have evolved like that.

If we make our reproduction systems linear, then our hearing perception
will interpret that as necessary. In audio that is what we do.
We should do the same for light.

I would go with your gut reaction. Inverse gamma was used in TV to
correct for the non linear response of a CRT. It was easier to apply it
to the picture rather than the receiver, for reasons of economy.
It made the image perceptable on a CRT.

Mike Engles

 

[Wayne Fulton]

In a sense it really does not matter what our perceptual gamma is.
All our perception requires is measurable linearity.

I used it to show up Mr Poynton's own logic against him.
When you look at the total transcaction you realise that Mr Poynton is
totally wrong. 8 bits linear is just perceptual with the limit of the
1.01 ratio.

I cannot see that it matters either (regarding gamma encoding improving
perceptual response of 8 bit data). My ultimate goal would be to believe
Poynton fully, but I need someone to help me understand how the encode
followed by the decode can leave any perceptual improvment for 8 bit data.

If we consider 8 bit luminosity values 5, 128, and 255, and encode it as:
5 = ((5/255)^0.45) x 255 = 43
128 = ((128/255)^0.45) x 255 = 187
225 = ((255/255)^0.45) x 255 = 255

Then we can save those 43, 187, 255 8-bit values for the CRT to decode.
And we do this today, without exception, the CRT response requires it.
We are told the CRT applies inverse decoding, which is the point.

Or we can save the unmodified 5, 128, 255 8-bit values in a similar 8 bit
linear file for a linear display (perhaps imaginary due to todays standards
always expecting gamma).

Then I fail to imagine any difference when the eye perceives either the
decoded values or the original values (on the appropriate matching display
screen). 8 bits holds the full range of this data comfortably either way,
and 8 bits is not an issue in that respect. 16 bits could be better, but
that is not this subject. The encoded data may be coincidently similar to
the eyes response, but we are going to decode it before the eye sees it. The
eye will see final representations of the same original 5, 128, 255 linear
intensity values either way on the display screens. Then the eye will do
whatever the eye has gotta do with it, which doesnt matter for this data,
which seems the same either way to me.

The CRT may be slightly darker if we did undercompensate it for use in a dim
room, so I assume the linear display will need a similar darker adjustment
for the same reason, assuming that reason is necessary or helpful.

That is why Timo Autiokari has been right all along.

I dont want to go there, but it's not what I said.

Gamma is obviously required for the CRT, and required for our standards for
those CRT. We must do gamma.

But I can imagine some future time that may not be so.

 

[Mike Engles]

I cannot see that it matters either (regarding gamma encoding improving
perceptual response of 8 bit data). My ultimate goal would be to believe
Poynton fully, but I need someone to help me understand how the encode
followed by the decode can leave any perceptual improvment for 8 bit data.

If we consider 8 bit luminosity values 5, 128, and 255, and encode it as:
5 = ((5/255)^0.45) x 255 = 43
128 = ((128/255)^0.45) x 255 = 187
225 = ((255/255)^0.45) x 255 = 255

Then we can save those 43, 187, 255 8-bit values for the CRT to decode.
And we do this today, without exception, the CRT response requires it.
We are told the CRT applies inverse decoding, which is the point.

Or we can save the unmodified 5, 128, 255 8-bit values in a similar 8 bit
linear file for a linear display (perhaps imaginary due to todays standards
always expecting gamma).

Then I fail to imagine any difference when the eye perceives either the
decoded values or the original values (on the appropriate matching display
screen). 8 bits holds the full range of this data comfortably either way,
and 8 bits is not an issue in that respect. 16 bits could be better, but
that is not this subject. The encoded data may be coincidently similar to
the eyes response, but we are going to decode it before the eye sees it. The
eye will see final representations of the same original 5, 128, 255 linear
intensity values either way on the display screens. Then the eye will do
whatever the eye has gotta do with it, which doesnt matter for this data,
which seems the same either way to me.

The CRT may be slightly darker if we did undercompensate it for use in a dim
room, so I assume the linear display will need a similar darker adjustment
for the same reason, assuming that reason is necessary or helpful.


I dont want to go there, but it's not what I said.

Gamma is obviously required for the CRT, and required for our standards for
those CRT. We must do gamma.

But I can imagine some future time that may not be so.

Hello

I cannot agree more. If encode has value X and decode has value 1/X, the
result is 1. Charles Poynton has built a whole edifice on illogical
thinking. We can apply inverse gamma directly to a CRT to linearise
it,or to the image, but in the end the voltages to the CRT are the same.
They are both in a perceptual space, whatever that gamma might be,
because we are looking at. The one difference is that a gammaed image
has less headroom for processing than a ungammaed one. Processing
headroom is the whole point in digital processing.

The only problem is that we are stuck with the way it is. Linear
displays will be made non linear to fit the status quo.


Mike Engles

 

[Wayne Fulton]

I really didnt want to be a non-believer, it just became necessary. <g>
It was a good story, but since the results continue to be the same if
true or false, it may be Occam's Razor again.

Maybe someone will come along yet to explain how it can work, and
I'd like that, but I'm not expecting it.

 

[Timo Autiokari]

Maybe someone will come along yet to explain how it can
work, and I'd like that, but I'm not expecting it.

Most of Mr. Poynton's writings are false, they are intentionally
devised lies. Your thoughts seem to revolve around his heresy:

Mr. Poynton writes in his so called gamma faq, section 15:
-->Eight bits, nonlinearly coded according to Rec. 709, is sufficient
--> for broadcast-quality digital television at a contrast ratio of
--> about 50:1.

The truth is that by gamma compressing 8-bit image data you get
nothing else but severe damages.

As you have now correctly concluded gamma compression (into gamma
space 2.5) must be done in order that the image data is viewable on
CRT. Also printers are natively non-linear. So e.g. for Web publishing
the main question is then: Do you want to take that damage before the
post-processing or after it?

Non-linear image encoding *for the purpose of image storage* can have
a small benefit but not for 8-bit data and it also always gives severe
disadvantages/damages.

8-bit/c storage and 8-bit/c editing is *always* damaging for digital
imaging no matter if the image encoding is linear or non-linear, you
just get different kind of problems. Non-linear editing is *always*
bad for image quality no matter what the bit-depth is.

Now, you will get some gamma benefit into the deep dark end in the
following way:

1) The imaging sensor (CCD or CMOS) *must* be of *very* good quality,
good enough to provide better than 256:1 usable dynamic range, in
other words it has to have better than 8 stop dynamic range. Some of
the best scanners and best digital cameras can reach almost 10 stops.

2) The sensor signal is then digitized by an ADC (Analog to Digital
Converter) that is deeper than 8 bit. Typically 10-bit, 12-bit and
14-bit ADCs are used. Here you need to understand that the bit-depth
of the ADC does not tell *anything* about the dynamic range of the
device, the dynamic range of the device is solely defined by the
imaging sensor, the sensor has a luminance range that it is able to
record and that does not change at all even if you would use a
1000000-bit ADC.

3) The digital data from the ADC is then gamma compressed using the
native bith-depth of the ADC.

4) Finally the result is truncated/rounded to 8-bit.

Now you have 8-bit image data in a non-linear space that has some
gamma infiltrated image detail in the deep dark end that 8-bit linear
can not hold. Simultaneously the gamma compression removes a lot of
image detail from all the other areas (than from the deep dark end).

Do not jump into conclusions yet, the gamma 2.2 and 2.5 spaces are
severely damaging. E.g. In the bright end of the digital code range
the enormously steep gamma space 2.2 can hold image detail that is
less what a 6-bit digitalization produce.

So, in case:

1) you have a very good acquire device that is capable to capture 10
stops of useful range

2) and for a reason or another you need to truncate that data to
8-bit/c code range

then this two stops over the 8-bit linear can be encoded into 8-bit
data range using a *far* lesser gamma space than the steep 2.2 or 2.5.
The lesser gamma space is far less damaging. Saving the data in higher
bit-dept linear would introduce no damage but there is the requirement
to save the image data using 8-bit data range.

Gamma space 1.25 will compress 10 bits (10 stop range), gamma space
1.5 will compress 12 bits (12 stop range) and gamma space 1.75 will
compress 14 bits (14 stop range). The enormously steep gamma space 2.2
will compress 17.6 bits (17.6 stop range). So for the 10 stop device
you can preserve the detail better in the dark end using 8-bit gamma
space 1.25, any steeper gamma space gives no benefit at all, just
additional damage.And this gamma space 1.25 will remove image
information from the upper 3/4 portion of the 10 stop range (in order
to give the benefit to the darkest 1/4 of that range).

But image editing in non-linear space is always severely damaging, the
gamma compression will reduce a lot of image information that would be
needed for high quality editing and you get the gamma induced errors
from editing non-linear image data.

Gamma compression makes the tonal range non-linear so you need to
linearize the image data in order to apply high quality image editing
operation over it. For example I explain the reason for the white halo
from the USM.

USM like the other sharpening filters do their "magic" by enhancing
the edges in the image. USM scans the image, pixel by pixel, and
detects edges by looking for rapid change in the visual appearance
from pixel to a neighboring pixel, from this visual difference it
calculates how strongly it will affect to such a pixel-pair that
comprise the edge at that location. USM then cause the edge to appear
more sharp by making the darker pixel visually more dark and making
the brighter pixel visually equally more bright. However in a highly
non-linear space it does not happen so, firstly the USM algorithm has
major problems in finding the edges properly and where it finds an
edge the algorithm changes the level values of the darker pixel but
that change has very minimal visual effect in a highly non-linear
codespace and the algorithm changes the level values of the brighter
pixel accordingly but there the visual effect is huge so we do not
perceive that the image would be more sharp, instead it gets the white
halo.

To conclude, sensible usage of non-linear 8-bit/c coding for digital
imaging would require a moderate gamma space like 1.25 to 1.5. In
these days ICC color management does easily support such a workflow
also but similarly the storage space of our HDDs and backup medias now
easily support 16-bit/c linear images too (that are no larger in byte
size than 2x) so there is absolutely no reasons to suffer from any
amount of gamma damage. Linear workflow is also the most efficient and
ICC profiling will result the best accuracy for linear image data.

Why then do we have a lot of scanners digital cameras, printers etc
that code the JPEG images into the steep gamma 2.5 (or 2.2) space?

It is simply because:

1) the CRT is the dominating device to view the digital pictures.

2) general public does not even know what ICC or color-managment means
not to mention that they would want to use it.

3) the general public do not usually edit the images so the gamma
induced errors are not engaged.

4) and the industry just care about the income.

There are scanners and digital cameras that provide an option for the
linear acquire (or linear conversion), those devices are for the
highest quality work, not for general public. Why would manufacturers
like Canon, Nikon etc provide such a linear mode in their high end
devices if it is not good at all and if no-one are using it? Well,
there is a business segment who absolutely demand it, those who do
high quality imaging.

But the general public is happy with the strongly damaged JPEGs that
"look good" on the CRT without any additional steps, straight from the
camera or scanner. And that is all what counts especially here on the
usenet. The industry will eventually find more people like Mr. Poynton
who will preach the "benefits" of steep gamma 2.5 (or 2.2) space,
backing it up with century old research that has nothing to do with
the issue in hand and using even more virtuosic word-twisting than
what Mr. Poynton is ever able to (even if is a word-class magician in
that department).

Timo Autiokari

 

[Wayne Fulton]

Hi Timo,

You have a different argument than I care to debate.

Your view is that images should not be routinely encoded to 2.2 gamma.
I am aware that you have debated this on Usenet for several years, but
my own view is that 2.2 gamma is the obvious real world requirement for
our devices (none were linear until recently), and of course is also
required by our standards. That's good enough for me.

I do however think that the appearance of linear devices, faster
computers, and 64 bit operating systems (to let one computer word hold
16 bit RGB data), will someday change this situation and the present
standards. And that will be good, but that is not yet today.

I think the digital cameras providing RAW output is only due to their 8
bit Bayer pattern, making it more necessary to save what was sampled
before interpolation. Which is what scanners do anyway, so RAW was never
perceived important at the consumer level for 24 bit scanner images.

My question is about this next part:

2) and for a reason or another you need to truncate that data to
8-bit/c code range

then this two stops over the 8-bit linear can be encoded into 8-bit
data range using a *far* lesser gamma space than the steep 2.2 or 2.5.

Less should work if we had such CRT, but either way, my puzzlement how
is this important at all? HOW can additional range can be preserved by
gamma encoding to 8 bit data? After it has been decoded for viewing,
how did either gamma encoding enhance preceived 10 bit range in 8 bit
storage?

16 to 8 bit conversion (truncation) can cause an error of up to the next
adjacent rounded 8 bit value in some cases, if one insists on thinking
of it that way. I dont - it seems much better that truncation precisely
divides the 65356 values into 256 equal groups. But if we call it an
error, this is not a one bit error, but just the next adjacent value,
off by 1 half of the time. Over much of the range, our eyes cannot
perceive this "off by 1" error anyway.

Gamma encoding is a new value computation to be stored as an integer,
and so it can can cause error up to the next adjacent value, off by 1.
Gamma operating on 16 bit data should eliminate that, leaving only any 8
bit deviation from original 16 bit value, at most off by 1.

Perhaps we might quibble over the significance (not significant to me),
but this is the only difference I can predict. Otherwise the original
values map directly to the gamma values, that is, one for one exactly by
formula, at least before the integer 8 bit truncation. These values can
be converted back to linear by the reciprocal operation, and the CRT
tube does this before we see it. These original (or nearly so) linar
values are then are the only values presented to the CRT phosphor.
After the CRT tube decodes it, the CRT phosphor sees the original 256
linear steps, or values. They would be the same 8 bit values there
regardless if we did gamma or not. If there were some change, I suspect
we would not like it. <g>

I see no greater range or perception preserved by gamma. How can that
work? What is the actual mechanism that accomplishes this?

 

[Chris Cox]

Hello

Would that not make the already linear display and linear image
impossibly bright,or do we now apply a gamma to the linear display to
emulate a CRT?

Your question makes no sense.
The image gamma encoding has NOTHING to do with the display.
You always have to adjust the image when displaying it.

Chris

 

[Chris Cox]

If you are interested I can post information that will track these
changes, in a table. By the way Timo Autiokarai has some good
experiments about the perceptual ratio.

No, Timo has nothing but misinformation.
That has been proven over and over again for several years....

Chris

 

[Chris Cox]

I cannot agree more. If encode has value X and decode has value 1/X, the
result is 1. Charles Poynton has built a whole edifice on illogical
thinking.

No, he built his statements on the work of many other vision
researchers. There is nothing illogical about Mr. Poynton's work.
There is good reason that he is one of the recognized authorities on
video and image encoding.

We can apply inverse gamma directly to a CRT to linearise
it,or to the image, but in the end the voltages to the CRT are the same.

But with a limited number of bits to represent the image (and possibly
the CRT linearization circuitry), the result would NOT be the same.

And storing an image iin a linear encoding is known to be a really bad
idea (too many codes to highlights you can't see, not enough codes to
the shadows you can see).

Why do you keep insisting that gamma encoding has something to do with
the CRT when all the experts are telling you otherwise?

The one difference is that a gammaed image
has less headroom for processing than a ungammaed one.

No, that makes no sense.

The only problem is that we are stuck with the way it is. Linear
displays will be made non linear to fit the status quo.

No, linear displays exist.
And the images for them are gamma encoded so that they won't need more
bits (and thus more storage => more cost) to represent the same image
quality. The image then gets adjusted right before being displayed,
same as for your CRT.


Chris

 

[Chris Cox]

Most of Mr. Poynton's writings are false, they are intentionally
devised lies. Your thoughts seem to revolve around his heresy:

Timo, please quit lying.
We're really tired of it.

Chris

 

[Wayne Fulton]

But with a limited number of bits to represent the image (and possibly
the CRT linearization circuitry), the result would NOT be the same.

Then specifically what is the difference Chris? What are the specific
details of how this 8 bit gamma encoding followed by decoding can possibly
leave a perceptual advantage? (other than to correct the response of the
CRT of course, that part is a given).

Poyntons explanation applies to the state while gamma encoded. We dont
view that. Then after it is decoded back to linear for presentation and
viewing by humans, then specifically what perceptual effect remains? And
how is that accomplished? If this is real, just say the words to make me
into a believer.

 

[Timo Autiokari]

my own view is that 2.2 gamma is the obvious real world requirement for
our devices (none were linear until recently), and of course is also
required by our standards.

Hi Wayne, high end scanners have always been linear and high end
cameras have always provided the linear acquire mode.

Gamma 2.2 (or more accurately gamma 2.5) space is an obvious real
world requirement *only* at the publishing phase (when publishing to
the Web or for viewing with a normal office or home PC). It is
perfectly and easily possible to work in linear and just publish from
there.

HOW can additional range can be preserved by gamma encoding to 8 bit data?
After it has been decoded for viewing, how did either gamma encoding enhance
preceived 10 bit range in 8 bit storage?

I already explained this but I try in another way:

Consider 8-bit data from an imaging device, this data is linear. Now
when you convert that data to gamma space 2.2 you will notice that
what was level 1 in linear will be level 21 in the gamma 2.2 space.
After this conversion you have no image information sitting on the
levels 1... 20 of the deep gamma 2.2 space so the gamma compression
cause enormous expansion there in the deep dark end. Also note that
what was level 241 and level 242 and level 243 all become level 249
and what was level 71 and level 72 both become level 143 so gamma
compression will remove image detail there. Note that you need to
disable the 'Use Dither' -option in the
ColorSettings/Advanced/ConversionOptions in order to reliably inspect
the level values. If you inspect the conversion more closely you will
find that there is varying amount of expansion in the levels range
about 0 ... 63 and varying amount of compression in the levels range
about 64 ... 255.

Now, if you had 10-bit linear data instead of the 8-bit linear data,
and you would convert that 10-bit data to gamma space 2.2 and then
truncate the data to 8-bit then you would have some image detail
sitting there in the levels range 0...20 in the gamma 2.2 space,
namely the levels 11, 15 and 18 would hold image detail. When you then
show this data on a display that applies gamma 2.2 (CRT monitors apply
gamma 2.5) then it will show luminance levels that are comparable to
linear levels 0.25 and 0.50 and 0.75 respectively, but in the linear
8-bit space there are no such fractional levels available so that
image detail is represented either by level 0 or level 1 there.

So, for a high quality device there is gamma benefit in the dark end
*and* gamma damage for all other image information *when* using 8-bit
storage range. Practically the gamma benefit is only experienced at
the most dark levels (levels 0 ...3 in linear). When using 16-bit/c
storage range (or the Photoshop 15-bit/c storage range) there is
absolutely no benefit at all from any non-linear coding.

You seem to totally ignore the large adverse effects that you get when
you edit non-linearly coded image data, I call them as the Gamma
Induced Errors. To store image data in the best possible way is one
issue, to edit image data the best possible way is another issue. With
8-bit/c the use of gamma space 1.25 to 1.5 will preserve the image
data the best possible way, but in order to edit the image data the
best possible way you need to apply the editing operations on linear
image data. When using 16-bit/c the best possible storage space is
linear because the image is readily editable there in the best
possible way.

ICC color-management provide us total freedom from what you call as
"the obvious real world requirement". Linear workflow is very similar
to a non-linear workflow, you just use a different RGB working-space
profile and if you are afraid about the deep dark end you will use the
16-bit/c mode. But if you want the best possible quality you would use
the 16-bit/c mode no matter if you work in linear or in non-linear
space. So the general ICC color-managed workflow is:

1) Open or acquire the image, if it is 8-bit/c data then convert it to
16-bit/c mode
2) Assign the device profile
3) Convert it to the RGB working-space profile
3) Edit the image then save it as the finalized original
4) Duplicate the image for publishing
5) Convert the duplicate to the publishing space (e.g. for the Web use
the nativePC -profile or the sadRGB -profile if you wish).

So the only difference is that in the step 3 you select the best
possible working-space, a linear space with large enough gamut.

I repeat that 8-bit/c is always damaging for digital imaging. If you
use 8-bit linear then the most deep dark end of the range will be a
little coarse, this very rarely cause any problems with photographs
but can be seen very easily with graphic work. If you use 8-bit gamma
compressed space you will get highly reduced gradation in the 3/4 of
the range and you get the Gamma Induced Errors (or you must limit your
editing operation to a very very mild effects only). You will get the
gamma benefit only with the most high quality acquire devices, most of
the commercial grade devices do not provide any useful image data that
the gamma compression could preserve.

Timo Autiokari

 

[Mike Engles]

Your question makes no sense.
The image gamma encoding has NOTHING to do with the display.
You always have to adjust the image when displaying it.

Chris

Hello
You would agree that a gamma of .45 would brighten a normal looking
image by redistributing the levels. When displaying this on a CRT with a
gamma of .4,the CRT darkens the image that had gamma.45 applied.

So if the display did NOT darken the image that had gamma.45 applied,
the result would look very bright. So what do you do to make the image
look normal?


Mike Engles

Mike Engles

 

[Kennedy McEwen]

Then specifically what is the difference Chris? What are the specific
details of how this 8 bit gamma encoding followed by decoding can possibly
leave a perceptual advantage? (other than to correct the response of the
CRT of course, that part is a given).

Wayne,
since I got back off an extended business trip I have been talking with
Mike Engles off-line on this topic. I hope that Mike doesn't mind me
using some of the same comparisons publicly here, because they were
prompted by some of his comments from his own field.

Basically gamma is *very* similar to the use of companders in audio,
such as Dolby. In its simplest form, a compander begins by compressing
the audio signal - amplifying the quiet sounds more than the loud
sounds. This compresses the audio into a reduced dynamic range, one
which fits into the dynamic range of the audio recording tape (remember,
in the old days, before CDs ;-) ). When the audio is replayed it is fed
to an expander, where the louder sounds are amplified more than the
quieter ones. The overall effect on the audio of this companding system
is nominally nothing at all, the expander completely counteracts the
effect of the compressor. In practice these never quite matched due to
limitations on the accuracy of analogue components, but the same process
can be implemented digitally with exactness.

So if the compander does nothing at all to the audio then why was Dolby,
which was nothing more complicated than a frequency dependent compander,
so popular? Because of the effect the process had on the tape noise! By
compressing the input audio to fit into the dynamic range of the audio
tape, the expansion part of the cycle no only restored the audio to its
linear form but reduced the random noise of the tape. The overall
effect was to increase the dynamic range of the audio *representation*
system.

Now, irrespective of the properties of the CRT, we know that the human
eye has a non-adapted dynamic range well in excess of what can be
encoded linearly by 8-bit data - indeed, it is about 3-4x greater than
what can be linearly encoded by 16-bit data. So what we need is some
form of companding system that reduces the effect of what is now
quantisation noise on our images - definitely in 8-bit images,
marginally so in 16-bit images.

It is exceedingly fortunate that the response of a CRT actually turned
out to be of the correct form for that display device to operate as the
expanding half of the compander system - the highlights have a contrast
per bit which is much greater than the shadows. Not only that, but it
works out that it just about matches the response of the eye, so that
the apparent distribution of the levels produced by that 8-bit digital
input is *almost* even throughout the brightness range. If the CRT
never existed and we only had linear displays then we would have to
design an analogue video expander instead - a circuit which produced
more contrast per bit at the top of the data range than the contrast per
bit at the bottom of the range.

After that, what is needed to complete the process is a compressor
stage, so that the low level signal (the shadows) are boosted above the
quantisation noise of the 8-bit data that the video is represented by.
That is simply the gamma compensation stage. The overall effect is to
reduce the quantisation noise by a factor which is the gamma that is
used.

If you compute the dynamic range of a linear 8-bit system, as
20log(2^8), you find it is only about 48dB - which is inadequate for
imaging purposes. You can see the posterised shadows - and no amount of
hand waving from Timo on this matter will change that. Shadow
posterisation on an 8-bit linear display is real and *very*
objectionable. You don't see posterised highlights because you have
more levels in that region with linear 8-bit coding than you need. You
can easily overcome this posterisation in the linear display, of course
- turn up the brightness! The problem is that now, of course, you have
no representation of blacks at all, because 8-bits linearly only
represents a Dmax of 2.4, so it isn't really a solution at all.

With gamma of 2.2 however, the dynamic range of the completely companded
video system is now 106dB - the effect of posterised shadows has gone
because you now have many more codes dedicated to representing those
shadows and correspondingly fewer to represent the highlights where the
difference between them was imperceptible in the linear system.

By comparison, the dynamic range of a linear 16-bit system would only be
96dB - still 10dB short of what can currently be achieved by gamma
encoding 8-bit video. To recover this same amount of headroom, you
would need to encode-decode 16-bit video with a gamma of around 1.1,
however in practice the same solution as suggested above would probably
more than suffice - turn up the brightness. On a 16-bit scale, lifting
the brightness by a few tenths of a percentage point would not even be
necessary with the limited contrast range of today's linear display
technologies - LCD & plasma. However such limitations should not be
considered in determining the video system of the future, so it is
reasonable to assume that future high quality high bit video will still
require gamma - possibly not as much as compensates a CRT - but enough
to lift the limited dynamic range of the data above the dynamic range of
the eye with enough headroom in between to permit the data to be
manipulated by profiles of a colour management system.

 

[Wayne Fulton]

I did understand most of what you said, but I still fail to see any reason
for a perceptual advantage of gamma encoding 8 bit data. On this subject, I
alwys get lost during the part about "then magic happens". <g> The 106db
dynamic range must not come from the fact that 255 is still the maximum
possible value in the file. But you are saying gamma has perceptual
advantage for 8 bit data, as others say too, but I always miss the part
about specifically how this can happen?

I understand tape noise and Dolby, but 8 bit files dont have tape noise.
They might have CCD noise, but my assumption is that gamma encoding tries
to be the reciprocal operation as the CRT decoding, and done for that
purpose, not to a different final result as is the Dolby intent. But this
may be philosophical, so lets get to some simple numbers instead.

Quantization noise has a maximum of half of the least significant bit, that
is, half the values might randomly be off by 1.

Let's assume a worst case, say 16 bit value 25727, which /256 = 100.49
(selected for this 0.49) which truncates to 100 as 8 bit. This 0.49
difference from 100 is the 8 bit quantization noise, worst case.

"8 bit to gamma" formula is (value/255)^0.45)x255, so 100 is 167.

"16 bit to 8 bit gamma" is (value/65535)^0.45)x255
so this 25727 is 167.42, which is 167.

So regardless if we encoded from 8 bits or 16 bits, we get 167. Which
seems right. This is just one case, but it is a selected worst case.
However yes, half all possible values of either method might be off by 1.
That is how digital is. 0.49 is small compared to 167, 0.3% is less than
the eye is said to perceive, and 0.42 is hardly better. (yes, using value
25 makes this worse, or 250 makes it better). But I think it is not a
given, as regardless of quantization, this one worst case value is 167
either way. So it doesnt seem a major factor, and it doesnt seem gamma can
affect it much. This trial done for low numbers is hardly different.


Agreed the gamma curve and the eyes perception curve are very similar. So?
Because the eye does not view the gamma encoded data. The data is decoded
back to linear before the eye sees it. If there is some remaining
difference, then what is that difference, and how is it created?

This 100 above, goes to 167 gamma in the 8 bit file, regardless of the two
sources. Then the very next thing that happens is that the CRT decodes it
reciprocally so that the CRT phosphor intensity matches the original 100
value, that is, it displays as 100/255 of max intensity. No, the video
phosphor is not 8 bit, it is not digital, it might even have the capability
of equivalent 16 bit response. But the data was binary, and this 100 value
is all there is to work with. It can never be 100.4 again.

More specifically, and most significantly (to me anyway), it is the same
100 value we would store in an unencoded 8 bit linear file, however then we
would need a linear video system to use it. Assuming we had it, then again
we should see 100/255 of max intensity, in proper relationship to
neighboring values. Gamma didnt help it. So the data source or method
seems not to matter at all in these three situations. The final value is
100 all three ways. And it should be. If all three files map to 100/255
intensity, what was the specific advantage or difference added by gamma?

If we showed the original 16 bit file, we should see 25727/65535 intensity,
which is 39.257% compared to 100/255 being 39.216% intensity, which is the
difference previously mentioned, but not due to gamma.

And it really doesnt matter which test number we use here. We could pick
dark low values, and we might wax poetic about impressive larger gamma
numbers, perhaps they even have mystic properties somehow, but it doesnt
seem to change anything, as they still decode back to the original dark low
values before humans can view them. If the value 25 goes to X and comes
back as 25, and the value 26 goes to Y and comes back as 26, then the
perceived difference between them is still the same too. Any mystic
properties of X and Y seem lost when decoded.

A reason the decode might have a slightly different value result is the
intentionally slightly undercompensated 2.2 gamma. This makes dark things
darker, harder to perceive, and is for other reasons, not for this subject.
I think the CRT does not have the small linear segment at 0, but this is
insignificant overall. These dont seem to be factors in the grand plan.

My question is still, how are the decoded values perceptually different?
There must be some mechanism to which we can assign numbers and see it?

I really dont mind believing, but any perceptual advantage for 8 bit data
doesnt seem workable to me, primarily because that data is decoded before
it is viewed. What I am missing?

 

[Wayne Fulton]

Now, if you had 10-bit linear data instead of the 8-bit linear data,
and you would convert that 10-bit data to gamma space 2.2 and then
truncate the data to 8-bit then you would have some image detail
sitting there in the levels range 0...20 in the gamma 2.2 space,
namely the levels 11, 15 and 18 would hold image detail. When you then
show this data on a display that applies gamma 2.2 (CRT monitors apply
gamma 2.5) then it will show luminance levels that are comparable to
linear levels 0.25 and 0.50 and 0.75 respectively, but in the linear
8-bit space there are no such fractional levels available so that
image detail is represented either by level 0 or level 1 there.

I am seeing that now Timo, thanks for the very clear explanation. I sure wish
I'd read this one first. <g> But yes, I can see the 8 bit gamma perceptual
advantage now. I just couldnt get started right I suppose, I was approaching
it from the wrong end. All that mumbo-jumbo about the eyes response was a
false trail too, I knew it couldnt be that, the eye never sees it. It is
only about these simple numbers you point out here.

Given 10 bit linear data containing each value from 0..30, then:

10 bit linear data converted to 8 bits with 0.45 gamma encoding,
gives the same 8 bit result values as the
corresponding 10 bit gamma data truncated to 8 bits,
and both have 8 bit gamma values of 0, 11, 15, 18, 21, etc.

2.2 gamma decoding does convert these unique 8 bit values back to
values 0.0, 0.3, 0.5, 0.7, 1.0, 1.3, etc,
but these still remain unique values, because they are analog on the CRT
screen, not binary values then. In this way, the 8 bit data could be the
carrier between two sets of analog data, but I wasnt seeing this before.

I dont know how a LCD video driver might treat these values like 0.3. I dont
know its internal mechanism, but at minimum, its driver could round off the
gamma computation, which would be some advantage.

But 10 bit liner data truncated to 8 bits (divide by 4) has every four values
repeated intead of unique (mod 4), so first 4 values are 0, next 4 are 1,
next four are 2, etc, not unique, which is a less acceptable plan.
Gamma encoding this result then creates first four are 0, next four are 21,
etc, also not so acceptable. The fifth value is the same 21 value, but less
unique values. So truncating linear files is not a good plan, gamma really
is better for the 8 bit data.

8 bit linear data containing the same 0, 1, 2, 3, etc, would be a much better
start than the truncated linear data, and gamma encoding would then also
allow each value to contain a unique gamma value. However it isnt so clear
what the source of this 8 bit linear data might be. A graphic editor
perhaps.

Do I have a technical out here, maybe it is just about truncating the linear
file instead of about the 8 bit file? <g>

Just kidding, yes, I do get it now, thanks much Timo. The gamma encoded 8
bit data does contain more unique values in this way, which is a perceptual
advantage, even if the human eye response curve is not a factor. It is
indeed extremely convenient that the CRT does need this gamma correction
anyway.

 

[Wayne Fulton]

Kennedy, best to just ignore my last post here, because Timo has explained it
to me, and I do get it now.. See posts in this thread.

 

[Kennedy McEwen]

I did understand most of what you said, but I still fail to see any reason
for a perceptual advantage of gamma encoding 8 bit data. On this subject, I
alwys get lost during the part about "then magic happens". <g> The 106db
dynamic range must not come from the fact that 255 is still the maximum
possible value in the file.

Yes it does, but it is no longer linearly encoded - so the ratio of the
lowest level possible to the highest is no longer 1/256th, but
(1/256)^gamma. In this case gamma is 2.2, so that gives a ratio of
1/198668, or a dynamic range of 20log((256)^2.2), which is 105.96dB.

But you are saying gamma has perceptual
advantage for 8 bit data, as others say too, but I always miss the part
about specifically how this can happen?

The perceptual advantage *is* this companding - significantly increasing
the dynamic range available from the limited number of bits without
introducing visible posterisation.

I understand tape noise and Dolby, but 8 bit files dont have tape noise.
They might have CCD noise,

Much more significantly, they have quantisation noise! Your CCD noise
is a small fraction of the quantisation noise on an 8-bit signal. Just
like Dolby reduces the effect of tape noise, gamma encode-decode reduces
the effect of that quantisation noise, by pre-emphasising the low level
signals to be greater than the noise and then de-emphasising both the
signal and the quantisation noise at the display.

but my assumption is that gamma encoding tries
to be the reciprocal operation as the CRT decoding, and done for that
purpose, not to a different final result as is the Dolby intent.

No, it does both. Gamma was originally introduced to compensate for the
CRT response. However it would have been needed in any case if we
continued to use 8-bit video because we need a companding system for
8-bits to work. In fact we need a companding system for 16-bits to
work, but we would probably get by without it due to the limited
contrast available from displays.

But this
may be philosophical, so lets get to some simple numbers instead.

Quantization noise has a maximum of half of the least significant bit, that
is, half the values might randomly be off by 1.

That isn't strictly true, because the "error" is the difference between
the encoded signal and the original. For all possible signals in the
range with equal probability, this error is equally weighted for all
values ranging from -1/2LSB to +1/2LSB. In other words, the maximum
error is +/- half the lsb, but the noise is the average error, not the
maximum. If you go through some more arithmetic to take account of the
fact that all errors within this range can occur, you actually get a
quantisation noise which is the square root of twelve less than the lsb.

Nevertheless, lets work with your figures, since they represent the
worst case...

Let's assume a worst case, say 16 bit value 25727, which /256 = 100.49
(selected for this 0.49) which truncates to 100 as 8 bit. This 0.49
difference from 100 is the 8 bit quantization noise, worst case.

"8 bit to gamma" formula is (value/255)^0.45)x255, so 100 is 167.

Woah right there! This is pre-emphasis *after* truncation! However
what you are trying to do is achieve the maximum precision in the gamma
encoding *prior* to truncation. So you apply 2.2 gamma to the 25727
data in the 16 bit range *first* and then truncate the result to 8-bits.

"16 bit to 8 bit gamma" is (value/65535)^0.45)x255
so this 25727 is 167.42, which is 167.

So regardless if we encoded from 8 bits or 16 bits, we get 167. Which
seems right.

And is right... in this specific instance. Try repeating that with
16-bit data of 194, for example. On an 8-bit scale that is either 0 or
1 depending on how you round it, which becomes *either* 0 or 21 after
gamma compensation. Done properly, in the correct sequence, it becomes
18 or 19 depending on the rounding method. The appearance of these
additional codes is *part* of the perceptual advantage of gamma
pre-emphasis. The other part is their appearance on the luminance
output of the CRT and how that response also de-emphasises the
quantisation noise of the 8-bits. If you pre-emphasise (ie. apply gamma
compensation) after the truncation to 8 bits then the perceptual
advantage of gamma is lost completely.

This is just one case, but it is a selected worst case.

Apparently not - it turns out to be close to a best case, as the other
example above demonstrates. ;-)

However yes, half all possible values of either method might be off by 1.

No, as you can see from the other example, they can be off by a lot more
than just one.

That is how digital is.

Or isn't, when a non-linear transform is implemented. ;-)

Agreed the gamma curve and the eyes perception curve are very similar. So?
Because the eye does not view the gamma encoded data. The data is decoded
back to linear before the eye sees it. If there is some remaining
difference, then what is that difference, and how is it created?

Whilst the eye does not view the gamma encoded data it *does* view the
gamma de-emphasised quantisation. The posterisation in the shadows is
significantly reduced if the density range of the display is set to the
full range.

This 100 above, goes to 167 gamma in the 8 bit file, regardless of the two
sources. Then the very next thing that happens is that the CRT decodes it
reciprocally so that the CRT phosphor intensity matches the original 100
value, that is, it displays as 100/255 of max intensity. No, the video
phosphor is not 8 bit, it is not digital, it might even have the capability
of equivalent 16 bit response. But the data was binary, and this 100 value
is all there is to work with. It can never be 100.4 again.

Aha, but it can (almost) - and that is the perceptual advantage! Look
at the example in the shadow data, with original value of 194. This
becomes an 8-bit value of 18 or 19 depending on the rounding, lets call
it 18 for simplicity. However when displayed on the CRT this gives a
luminance on the screen that is (18/255)^2.2, which is 2.93% of the peak
white level. On a 16-bit scale, this is 192. Using the backwards
method of noise then pre-emphasis then de-emphasis, you just get 0 or
256 on the 16-bit luminance scale, with nothing in between! This added
precision, more levels, in the shadows *is* the perceptual advantage of
the gamma encode/decode scheme.

It works because the gamma of the CRT is almost the same as the
perception response of the eye. If we use more gamma, which we could by
applying a suitable non-linear preamp to the CRT input, then we would
get insufficient codes in the highlights to properly display them,
resulting in posterisation in those parts of the image. In other words,
"it is a remarkable coincidence that the gamma of the CRT is almost the
inverse of the perceptual response of the eye". ;-)

And it really doesnt matter which test number we use here.

Yes it does. ;-)

We could pick
dark low values,

Which is why I did. ;-)

and we might wax poetic about impressive larger gamma
numbers, perhaps they even have mystic properties somehow, but it doesnt
seem to change anything, as they still decode back to the original dark low
values before humans can view them. If the value 25 goes to X and comes
back as 25, and the value 26 goes to Y and comes back as 26, then the
perceived difference between them is still the same too. Any mystic
properties of X and Y seem lost when decoded.

Wayne, try doing this on an Excel spreadsheet with *all* the 16-bit
numbers - that will show you exactly how much data is lost when you
implement the coding wrongly.

My question is still, how are the decoded values perceptually different?

More detail in the shadows.

There must be some mechanism to which we can assign numbers and see it?

Yes, more of the 8-bit codes are assigned to the shadows, where the
perceptual response of the eye needs them.

I really dont mind believing, but any perceptual advantage for 8 bit data
doesnt seem workable to me, primarily because that data is decoded before
it is viewed. What I am missing?

The data is encoded from a higher precision source - either an analogue
one, in the case of standard TV and photomultiplier drum scans (Timo's
assertion that all high performance scanning systems have always encoded
linearly is a complete and utter lie in this respect, and seriously
calls into question his basic knowledge of any facts in this area), or
from a higher resolution digital source, such as a 12, 14, or 16-bit
linearly coded CCD output.

 

[Timo Autiokari]

why was Dolby, which was nothing more complicated than a frequency
dependent compander, so popular? Because of the effect the process
had on the tape noise!

That has no relevance in digital imaging what so ever. It does have
relevance with analog TV broadcast where that analog transmission path
(the transmitter, the antenna circuits at both ends and the receiver)
add noise to the information, just similarly like the analog audio
tape and the analog video tape adds noise to the information. We do
not have such a noise source in digital imaging (nor with digital TV
nor digital audio).

Now, irrespective of the properties of the CRT, we know that the human
eye has a non-adapted dynamic range well in excess of what can be
encoded linearly by 8-bit data - indeed, it is about 3-4x greater than
what can be linearly encoded by 16-bit data.

Vision *always* adapts, there is no such thing like "non-adapted
dynamic range". At a given adaptation level (when looking at a scene
where the illumination level does not change) the vision can detect
about 200:1 dynamic range . Light(ness) adaptation is the very
property that makes it possible for the vision to be functional over a
huge range of illumination levels, from less than starlight to more
than bright sunny summer day, that range is something like 100000000:1
or more. But at any given adaptation level we only detect a tiny 200:1
range.

8-bits linearly only represents a Dmax of 2.4

No, the level 0 represents the Dmax of the device in concern and it is
the very same Dmax no matter if the codespace is linear or non-linear.

With gamma of 2.2 however, the dynamic range of the
completely companded video system is now 106dB

There are no devices that provide such an enormously large dynamic
range 198668:1 or 17.6 stops so such coding is highly lossy. The very
best devices give you just 10 stops range so 7.6 stops are useless in
gamma 2,2, codespace.

Timo Autiokari

 

[Timo Autiokari]

Hi Wayne,

so far so good, but you are still drawing conclusion way too hastily.

But 10 bit liner data truncated to 8 bits (divide by 4) has every four values
repeated intead of unique (mod 4), so first 4 values are 0, next 4 are 1,
next four are 2, etc, not unique, which is a less acceptable plan.

Please do the same analysis in the highlights also where the 8-bit
gamma 2.2 space will remove more than 4 bits from that original 10-bit
image information, so divide by 16 (or 18).

So truncating linear files is not a good plan, gamma really is better
for the 8 bit data.

Gamma 2.2 space is not better for any bit depth. As you examined you
self the linear 10-bit data in the dark end of the gamma 2.2. space is
spaced *very* sparsely 0, 11, 15, 18, 21. All those empty code
levels are taken from the range of midtones to highlights where the
gamma does the compression.

So the 8-bit/c gamma 2.2 space will remove eat a lot of editing
headroom, you only have less than 6-bit (linear) data there in the
highlights.

The best non-linearity for 8-bit/c image information is a kind of
exponential function for the codebase where level 0 is Dmax and level
255 is Dmin. But for historic reasons we only have been using the
gamma function. When restricted to use the gamma function the optimal
8-.bit/c non-linearity would be something in the range gamma 1.25
space to gamma 1.5 space.

The gamma encoded 8 bit data does contain more unique values in
this way,

No, it does so only in the very very deep dark end. Elsewhere the
gamma compress the level system.

which is a perceptual advantage,

Compared to the best possible coding system for saving/storing image
information using 8-bit/c codebase the gamma 2.2 space is about
equally damaging than linear space. You simply get different kind of
problems.

even if the human eye response curve is not a factor.

When examining the best possible coding system for saving/storing
image information using 8-bit/c codebase you need to take the whole
chain into consideration:

1) the dynamic range of the sensor
2) the bit-depth of the ADC
3) the contrast sensitivity of the vision *in* the very situation
where the vision is put into when it is looking at a natural scene.
4) the bit-depth and the non-linearity of the display or an other
output device.

The result will be that gamma compression is always very bad no matter
what gamma value is used. When forced to use the gamma function the
optimal value is between 1.25 to 1.5.

It is indeed extremely convenient that the CRT does
need this gamma correction anyway.

No, gamma 2.5 is not. The native gamma space of the CRT tubes is 2.5
and that is horribly steep. E.g. the banding that can be seen in many
images that have large area of bright blue sky is due to the extreme
compression that gamma space 2.5 cause in the high portion of the
range.

A related matter btw is the sadRGB gamma space that is an
approximation of the gamma 2.2 space. When you calibrate the CRT
monitor that is in gamma 2.5 space (using AdobeGamma or other such
tool) into gamma 2.2 space then the code system is further reduced,
this calibration happens in 8-bit codespace.

And the fact remains that for high quality results you must apply
image editing operations only in linear space. Colorimetricly the
vision is bullet straight linear and all the image editing
applications are using algorithms that expect linear data. The
contrast sensitivity of the vision, when it is adapted to natural
scene, is slightly non-linear due to the various spatial functions
that the vision has but you can forget that completely when working in
16-bit/c mode. If you need to work with 8-bit/c space and you only
have the gamma for bith-depth compression then your optimum choice is
a moderate gamma space like in the range from 1.25 to 1.5 and you will
still get the Gamma Induced Errors there when you edit the images.

Timo Autiokari