Gamma Correction and Shadow Detail bit allocation

Question

I'm having slight difficulties understanding how a gamma correction increases details in the shadows(where our eyes are more sensitive). Once the bits have been been reallocated to the shadows after applying an INVERSE GAMMA/GAMMA CORRECTION in the camera wouldn't all that detail just be lost as the monitor would apply a GAMMA to counter the inverse gamma thus bringing the image luminance back to a linear function. Or are the code values saved after gamma correction and only the brightness is brought down.

I'll use an example I took from the video "Diving into dynamic range" from Filmmaker IQ on youtube.

From what I understood, in his example he uses an 8 STOP(the triangles represent the stops) camera with an 8 bit depth(Not exactly sure about this I got abit confused here. Please correct me If I'm wrong)

Basically once the GAMMA of the screen is applied to the above OETF GAMMA curve and it goes back to the LINEAR one why wouldn't we loose all the details in the shadow again??

​

Here's the link to the video just in case: https://www.youtube.com/watch?v=2sshGdMgJxQ

Perhaps I didn't explain my problem clearly allow me to retry from the start.

So, whenever we have a purely linear function we lose too much detail in the shadows as the majority of the values are assigned to the highlights(which we as humans can't discern as well). As shown in(1st image below)

Therefore this is why the camera applies an inverse gamma(e.g ^1/2.2)which allows more values to be reallocated to the shadows. As shown in (2nd image below)

Now my question is once this OETF Gamma is fed to the monitor, wouldn't the display just apply its own Gamma(e.g ^2.2) to the OETF curve and thus make it linear and bring us back to step 1 where we have lost all our values in the shadows again?? Or would it as Rawshooter say "Save the coded values" and we'd end up with something like below(3rd image below)

I'm basically asking that once the coded values for the tonal shades are redistributed in a gamma encoded curve do they stay that way even though the gamma encoded curve will be decoded to display a linear function in the final image(4th image below)

Answer 1

You have to distinguish between several basic sources of gamma-transformation:

1. Gamma-compression to store digital images in a certain (non-linear) colorspace, such as sRGB.

2. Gamma-decompression to retrieve the actual linear value of light intensity from a gamma-compressed value.

3. Gamma-correction or adjustment to change the appearance of an image.

Basically ## 1 and 2 cancel each other out, are handled by your software and hardware, and as a beginner you need not be concerned about them. Nor need you worry about #3 jangling with #2, because they are totally independent. The technical operations of comporession and decompression are designed to match each other, their only purpose efficient storage of raster images. You can safely forget about them as a potential source of tonal distoriton and focus on the gamma-correction and other curves transformatios in your raster editor.

The simple answer to your question is that the gamma encoding and decoding are fixed, and match and cancel each other our, so that your own gamma-adjustments do stay there and are preserved, and you may test yourself by the following experiment:

1. open an image in a raster editor,
2. make a gamma adjustments using the Curves tool its analog,
3. save the result in a different file,
4. visually compare the original and ajusted files in an image viewer.

Answer 2

Now my question is once this OETF Gamma is fed to the monitor, wouldn't the display just apply its own Gamma(e.g ^2.2) to the OETF curve and thus make it linear and bring us back to step 1 where we have lost all our values in the shadows again??

You are mixing image encoding and image editing. Image encoding is modifying binary image data and image decoding is reconstructing source image from that modified data.

Now my question is once this OETF Gamma is fed to the monitor, wouldn't the display just apply its own Gamma(e.g ^2.2) to the OETF curve and thus make it linear

99% of the time it's not just the display which applies the gamma to the image, it combination of software and display, and of course the combination of all those operations should result in source image being correctly reconstructed.

---

In my opinion it's very misleading for beginners to say that gamma enconding allocates details differently. "Detail" is a spatial contrast transition in the image and I see no reason to transfer that term to brightness values.

Unfortunately, the video you linked does not seem to state the most important part clearly: if you would set up a light source with adjustable brightness in front of a human then you would find out that you can split the brightness range into just noticeable intervals of brightness changes. If you then plot the size of those intervals against luminosity (power) you will get something roughly like this:

which would mean that any absolute change of luminosity is more noticeable when it occurs to a dark light source.

Consumer-oriented image formats have limited brightness values per pixel. After truncating image data to discrete values each discrete value then corresponds to some interval of brightness.

When you apply Gamma encoding, you change the brightness intervals which correspond to same discrete value, so that it allows to represent more just noticeable differences of brightness and if it happens so that precision does not allow to have different discrete values for all just noticeable brightness differences then whole brightness range is affected uniformly. That's the true reason behind gamma encoding.

If you plot 1/derivative of the gamma function $$1/f'(x)$$ you will get roughly the same graph as above because this formula represents the interval size each discrete value gets (with a slight approximation).

There would be zero reason to use Gamma encoding if the image file size was not limited. The actual task the gamma encoding solves is optimizing image data when image file size is limited (and also reduces processing of image data in consumer devices because LCD link bandwidth is also optimized with Gamma encoding).