This calculator recomputes a new gamma value using a different gamma due to a variable gamma multiplier (as used in Photoshop Levels and Adjustment - Exposure tools).
This calculation shows the effect of the gamma multiplier on any specific current tonal value you input. If current gamma is specified to be gamma 2.2, and if you specify a gamma multiplier of 1.4, then data values are computed with gamma = 1.4 x 2.2 = gamma 3.08. The calculator shows the expected numerical data output of those multiplier tools.
It matches the Photoshop Levels Tool which has a center slider which is gamma (CTRL L in Photoshop or Elements). This Levels center slider is a very desirable way to brighten or darken your image. It is not only a good and efficient way to change image brightness, but it does it WITHOUT shifting the 0 and 255 end points, so no clipping and no shift of dynamic range (which is Not true of simple Brightness controls, which just scoot the histogram data back or forth). Gamma is used because tonal values [0..255] must be normalized to be [0..1] (fractional) values before computing gamma. Because then, the 0 or 1 end points are still 0 or 1 when raised to any exponent, so the end points are very fixed at 0 and 1.
The Levels center slider default value is marked 1.0, which is a multiplier of your current gamma. If your image is gamma 2.2, then 1.0 x 2.2 is still 2.2, unchanged. But if you wanted to see linear with 1.0 gamma, then (since 1/2.2 is 0.4545), the slider moved right to 0.4545 darkens the image to be gamma 0.4545 x 2.2 = gamma 1.0.
The Photoshop menu Image - Adjustments - Exposure also has the Exposure and Gamma sliders, both of which match these calculator numbers well.
However, the Exposure slider in Adobe Camera Raw, not so much (see previous page).
Here's a calculation that seems interesting, showing histogram gamma values at X stops down from 255 (or from 4095 or 16383). Our image histograms show gamma data.
The menu of bit buttons here affects Linear values, but Gamma there is always 8 bits, like our JPG files, video cards, monitors and our printers. The numbers here are the maximum storage capability of the bits, it does not imply the available data ever completely fills it.
It may seem to appear that gamma data has greater range, but of course, that's just a numerical math conversion, it cannot change the range, which always remains a normalized [0..1]. Gamma does boost the low values to be new higher values, but gamma was converted from linear, and must always be converted back to linear for the human eye to view it. No human eye ever sees gamma data. Gamma Correction was very important to correct the CRT losses, but the LCD monitor simply first reverses gamma 2.2 back to be linear again, and then shows it. Integer linear values below one are of course zero.
But 12 bits can have greater range [0..4095] than 8 bits [0..255]. We hear claims that some cameras have 12 or 14 stops of dynamic range. That maximum theoretical possibility does exist for 12 or 14 bit data. Each additional bit is a theoretical stop of potential range (the actual data present may not fill it). But the 8-bit data that we see is always limited to 8 stops of dynamic range, and in 8 bits, 2^8=256 is the maximum limit. We conceivably could decode the 256 8-bit gamma values into 10 or 12 or 14 bit video space (shown by the bit conversion here), but typically we don't, we use 8-bit video.
Images printed on paper are limited to less than about 3 stops dynamic range, because the white paper is not bright enough, and the black ink is not dark enough, to show more. A typical 15% to 90% reflectance is a range of 2.58 EV. 10% to 90% reflectance is 3.17 EV.
Note that regardless of bit count, 7 stops down is always 0.78% of linear maximum (in linear data, which is all that we look at). Just like 1 stop is defined as always 50%, and half done seven times is 0.78%. And 2^7=128, and 1/128 = 0.78%. Reminds me of being able to fold a piece of paper in half only 7 times. :)
This previous page article is about gamma correction, so to be more complete, and for example of concept, here are 8-bit video LookUp tables (LUT) for gamma 2.2. Both Encode and Decode tables are shown. Simpler CPU chips don't have floating point instructions. Even if they did, instead of computing math millions of times (megapixels, and three times per RGB pixel), a source device (scanner or camera) could read an Encode LUT, and an output device (LCD monitor) could read a Decode LUT. Here is one example of such a LUT chip. These tables use input addresses simply directly reading the corresponding output value. A binary chip would not use decimal notation, it would use hexidecimal [00h..ffh], but decimal seemed better here for humans. A linear display device (LCD monitor) can simply read a Decode LUT to discard gamma (to restore to be linear data to show).
For an example of use, the highlighted value for Encode below has the input address of the linear center value 127, which reads there its 186 gamma output. Then the highlighted Decode value reads input address of gamma value 186 which reads back the center 127 linear for display. Could not be simpler. The idea is that simply reading the table is fast, and prevents the device from having to do the actual math three times for each of millions of pixels. All math was done once in preparation of the chip, and now it works without any additional math in this device (fast and simple). It is just a table LookUp. The decode LookUp procedure is for linear devices, like LCD displays, which don't need or use gamma (as CRT does). They simply just decode the data to be linear values again, and proceed.
Another example below is that Encode address linear 82 is gamma value 152. And then Decode address gamma 152 is linear value 82. But in 8-bits, some of these could be off by one, like 80 is ... 80 encodes to 150.56, and 81 encodes to 151.46, but rounding in 8 bits can only store both as 151. And 151 can only have one output value.
79 -> 150, 150 -> 79
80 -> 151, 151 -> 81
81 -> 151, 151 -> 81
82 -> 152, 152 -> 82
But off by one is not a big deal (and rounding puts it closer), since there are so many other variables anyway. White Balance for one for example, Vivid for another, these skew the camera data. So this is an instance to not sweat the small stuff.
In an 8-bit integer, where could any supposed so called perceptual improvements by gamma even be placed? :) The lowest linear steps (1,2,3,4) are separately distinguished (with numbers 1,2,3,4), perhaps coarsely percentage wise, but in 8-bits, 1,2,3,4 is all they can be called. And of course, they are the exact values we hope to reproduce (however real world video monitors probably cannot show levels that black, which cause is neither gamma nor 8-bits). Notions about the human eye can't help (the eye never sees gamma data). An analog CRT is all that sees any gamma data directly, but the eye notion is the full opposite, imagining gamma is still somehow needed without CRT? Anyway, gamma is obviously not related to the human eyes response in any way.
Except for the 8-bits, the LUT is simply a faster way to do the same math ahead of time. The LUT decode chip can also additionally correct for any other color nonlinearity in this specific device, or provide additional features like contrast or monitor color calibration for example, or just routine corrections. The LUT provides the mechanism to expand it further (if the data is this, then show that). Color correction would require three such tables, for each of red, green and blue. This table is for gamma 2.2, but other tables are quickly created. A 12-bit encode table would need 4096 values, a larger table, but it still reads just as fast.
The lowest linear values, like 4, 5, 6, may seem to be coarse steps (percentage-wise), but they are what they are (still the smallest possible steps of 1), and are what we've got to work with, and are the exact values that we need to reproduce, regardless if we use gamma or if we hypothetically somehow could bypass it. These low values are black tones, and the monitor may not be able to reproduce them well anyway (monitors cannot show the blackest black). And gamma values of less than 15 decode to zero anyway, if in 8-bits.
But gamma is absolutely Not related to the response of the eye, and gamma is obviously NOT done for the eye, and so of course, we don't even need to know anything about the eyes response. Gamma could use any other algorithm, cube root of 1.9, or value / 5, or whatever, and the LCD encode/decode reversal concept would be the same (except of course other values would not match CRT displays then). But the eye never ever sees any gamma data, because gamma is always first completely decoded back to linear. The entire goal is to see an accurate linear reproduction. We couldn't care less what the eye does with it, the eye does whatever it does, but our brain is happiest when shown an exact linear reproduction of the original linear scene, the same as if we were still standing there looking.
Yes, it is 8-bits, and not perfect. However, the results are still good, very acceptable, which is why 8-bit video is our standard. It works. Gamma cannot help 8-bits work, actually instead, gamma is the complication requiring we compute different values then requiring 8-bit round off. Gamma is a part of that problem, not the solution. But it is only a minor problem, necessary for CRT, and today, necessary for compatibility with the worlds images.
Stop and think. It is obvious that gamma is absolutely not related to the response of our eye. This perceptual step business at the low end may be how we might wish the image tones were, but it is Not an option, not in 8-bits. Instead, the numbers are what they actually are, which we hope to reproduce accurately. The superficial "gamma is for the eye" theory falls flat (fails) when we think about it once. If the eye needs gamma, how can the eye see scenes in nature without gamma? And when would the eye ever even see gamma? All data is ALWAYS decoded back to linear before it is ever seen. Gamma is obviously NOT related to the response of the eye. A linear value of 20 would be given to a CRT monitor as gamma value 80, and we expect the CRT losses will leave the corresponding linear 20 visible. A LCD monitor will simply first decode the 80 to 20, and show that. Our eye will always hopefully see this original linear value 20, as best as our monitor can reproduce it. But gamma is certainly Not in any way related to matching the response of our eye.
Gamma has been done for nearly 70 years to allow television CRT displays to show tonal images. CRT are non-linear, and require this correction to be useful. Gamma is very well understood, and the human eye response is NOT any part of that description. The only way our eye is involved is that we hope the decoded data will show a good linear reproduction of the image for the eye to view (but the eye is NOT part of the correction process). Gamma correction is always done, automatically, pretty much invisible to us. We may not use CRT today, but CRT was all there was for many years, and the same gamma is still done automatically on all tonal images (which are digital in computers), for full compatibility with all of the world's images and video systems, and for CRT too (and it is easy to just keep doing it). LCD monitor chips simply easily decode gamma now (the specification 2.2 value does still have to be right). The 8-bit value might be off by one sometimes, but you will never know that. Since all values are affected about this same way, there's little overall effect. More bits could be better, but the consensus is that 8-bits work OK.
I am all for the compatibility of continuing gamma images, but gamma has absolutely nothing to do with the human eye response. Gamma was done so the corrected linear image could be shown on non-linear CRT displays. Gamma is simply just history, of CRT monitors. We still do it today, for compatibility of all images and all video and printer systems, and for CRT too.
We probably should know though, that our histogram data values are gamma encoded. Any data values you see in the histogram is gamma values. But the human eye never sees gamma images.