Notice how in this case 187 is not mid gray anymore because the value erroneusly sent to the monitor is 0.5, which is then converted to 0.25.
The monitor is not aware of this and apply its gamma decode anyway, which means we gamma decode a signal that was not encoded. When we read the texture data we correctly decode it, but then when we send it to the monitor we don't gamma encode it as we should. The third case looks darker, and this is because we decode more times than we encode.
The function used for these operations is always the same \(y=x^\gamma\) and the only thing that changes is the gamma parameter usually for decoding it's set to 2.2, and for encoding it's \(\frac = ~0.5\) (0.7333 is 187 normalized to 255). The operation that we apply to compensate this is called gamma encode or gamma correction. The non linear operation that the display applies to the signal is called gamma decode or gamma expansion. Why we are still interested in this then? We don't use CRT monitors anymore! Well, because of a fortunate coincidence by using that operation we also improve the visual quality of the signal as we happen to allocate more information in the areas where the human eye is more sensitive (darker shades). The transformation function is the non linear operation \(y=x^\gamma\) where \(x\) is our input value, \(y\) is what we see on monitor and \(gamma\) is the correction value that depends on the physical technology used in the CRT. To actually get a linear response so that our 128 looks like a mid gray we need to apply the inverse of the monitor's transformation to the input (intuitively, if 128 is too dark we send in a bigger number to compensate). This means that if we send a value of 128 to the monitor it wouldn't appear 50% the maximum brightness of the monitor but it would be sensibly darker. The technology used by these monitors to light the pixels introduced a non linear conversion from the energy in input to the energy in ouput. The reason why we have gamma correction in the first place goes back to CRT displays. The term gamma is often used in a confusing way as it gets mapped to different concepts, so in this article I will always put a second word with it to provide more context the word gamma itself comes from the exponent of the encode/decode function used by the non-linear operation known as gamma correction. The script was created by at, to solve the tedious “workaround” described earlier.Gamma correction is a characteristic of virtually all modern digital displays and it has some important implications to the way we work with images. The above described process was clearly a “workaround” to meet the client’s request…until I was introduced to an ingenious script called “ Overscan”. Until recently, many well-known studios (including myself) would “achieve” the above mentioned request by first decreasing the original FOV of the camera in order to cover new areas of the 3D scene followed by increasing the original render output size (pixels) many times over in order to compensate for the reduced FOV values. Having said that, that’s often what’s required from most users: To do the impossible. In real technical terms such requirement is impossible to achieve, as it defies the physics of any real camera. almost like extending the borders of a PSD canvas).
When re-rendering an existing camera view, the client may also require users to include more of the 3D scene in the same shot preferably without affecting the perspective (e.g. There will be times when clients will ask users to revisit old projects, with the purpose to redesign and/or re-render an existing camera view.
0 kommentar(er)
