Editing Gamma correction (section)

==Simple monitor tests==
[[File:Gamma correction test picture.png|left|frame|Gamma correction test image. Only valid at browser zoom&nbsp;=&nbsp;100%]]

This procedure is useful for making a monitor display images approximately correctly, on systems in which profiles are not used (for example, the Firefox browser prior to version 3.0 and many others) or in systems that assume untagged source images are in the sRGB colorspace.

In the test pattern, the intensity of each solid color bar is intended to be the average of the intensities in the surrounding dotted dither; therefore, ideally, the solid areas and the dithers should appear equally bright in a system properly adjusted to the indicated gamma.

Normally a graphics card has contrast and brightness control and a [[Transflective liquid-crystal display|transmissive LCD]] monitor has contrast, brightness, and [[backlight]] control.  Graphics card and monitor contrast and brightness have an influence on effective gamma, and should not be changed after gamma correction is completed.

The top two bars of the test image help to set correct contrast and brightness values. There are eight three-digit numbers in each bar. A good monitor with proper calibration shows the six numbers on the right in both bars, a cheap monitor shows only four numbers.

Given a desired display-system gamma, if the observer sees the same brightness in the checkered part and in the homogeneous part of every colored area, then the gamma correction is approximately correct.<ref>{{cite web |url=http://www.normankoren.com/makingfineprints1A.html#gammachart |title=Monitor calibration and gamma |last=Koren |first=Norman |access-date=2018-12-10 |quote=The chart below enables you to set the black level (brightness) and estimate display gamma over a range of 1 to 3 with {{sic|nolink=y|precison}} better than 0.1. }}</ref><ref>{{cite web |url=http://www.lagom.nl/lcd-test/gamma_calibration.php |title=Gamma calibration |last=Nienhuys |first=Han-Kwang |date=2008 |access-date=2018-11-30 |quote=The reason for using 48% rather than 50% as a luminance is that many LCD screens have saturation issues in the last 5 percent of their brightness range that would distort the gamma measurement. }}</ref><ref>{{cite web |url=http://www.photoscientia.co.uk/Gamma.htm |title=The Monitor calibration and Gamma assessment page |last=Andrews |first=Peter |access-date=2018-11-30 |quote=the problem is caused by the risetime of most monitor hardware not being sufficiently fast to turn from full black to full white in the space of a single pixel, or even two, in some cases. }}</ref> In many cases the gamma correction values for the primary colors are slightly different.

Setting the [[color temperature]] or [[white point]] is the next step in monitor adjustment.

Before gamma correction the desired gamma and [[color temperature]] should be set using the monitor controls. Using the controls for gamma, contrast and brightness, the gamma correction on an [[Liquid-crystal display|LCD]] can only be done for one specific vertical viewing angle, which implies one specific horizontal line on the monitor, at one specific brightness and contrast level. An [[ICC profile]] allows one to adjust the monitor for several brightness levels. The quality (and price) of the monitor determines how much deviation of this operating point still gives a satisfactory gamma correction. [[Twisted nematic field effect|Twisted nematic]] (TN) displays with 6-bit [[color depth]] per primary color have lowest quality. [[IPS panel|In-plane switching]] (IPS) displays with typically 8-bit color depth are better. Good monitors have 10-bit color depth, have hardware [[color management]] and allow hardware calibration with a [[tristimulus colorimeter]]. Often a 6bit plus [[Frame rate control|FRC]] panel is sold as 8bit and a 8bit plus FRC panel is sold as 10bit. FRC is no true replacement for more bits. The 24-bit and 32-bit color depth formats have 8 bits per primary color.

With Microsoft Windows 7 and above the user can set the gamma correction through the display color calibration tool dccw.exe or other programs.<ref>{{cite web |url=https://support.microsoft.com/en-us/help/14217/windows-8-get-best-display-on-your-monitor |title=Get the best display on your monitor - Calibrate your display |publisher=Microsoft |access-date=2018-12-10 |quote=If you have a display calibration device and software, it's a good idea to use them instead of Display Color Calibration because they'll give you better calibration results. }}</ref><ref>{{cite web |url=https://www.quickgamma.de/indexen.html |title=Quickgamma |last=Werle |first=Eberhard |access-date=2018-12-10 |quote=QuickGamma is a small utility program to calibrate a monitor on the fly without having to buy expensive hardware tools. }}</ref><ref>{{cite web |url=http://www.hex2bit.com/products/product_mcw.html |title=Monitor Calibration Wizard |last=Walters |first=Mike |access-date=2018-12-10 |quote=Easy wizard for creating color profiles for you monitor. }}</ref> These programs create an [[ICC profile]] file and load it as default. This makes [[color management]] easy.<ref>{{cite web |url=https://support.microsoft.com/en-gb/help/4462979/windows-about-color-management |title=About Color Management |publisher=Microsoft |access-date=2018-12-10 |quote=Usually Windows handles this on its own }}</ref> Increase the gamma slider in the dccw program until the last colored area, often the green color, has the same brightness in checkered and homogeneous area. Use the color balance or individual colors gamma correction sliders in the gamma correction programs to adjust the two other colors. Some old graphics card drivers do not load the [[Palette (computing)|color Look Up Table]] correctly after waking up from standby or hibernate mode and show wrong gamma. In this case update the graphics card driver.

On some operating systems running the [[X Window System]], one can set the gamma correction factor (applied to the existing gamma value) by issuing the command <code>xgamma -gamma 0.9</code> for setting gamma correction factor to 0.9, and <code>xgamma</code> for querying current value of that factor (the default is 1.0). In [[macOS]] systems, the gamma and other related screen calibrations are made through the System Preferences.

=== Scaling and blending ===
''Generally,'' operations on pixel values should be performed in "linear light" (gamma 1). Eric Brasseur discusses the issue at length and provides test images.<ref>{{cite web |last1=Brasseur|first1=Eric |title=Gamma error in picture scaling|url=http://www.ericbrasseur.org/gamma.html|access-date=22 March 2020|date=August 2007|quote=Technically speaking, the problem is that "the computations are performed as if the scale of brightnesses was linear while in fact it is a power scale." In mathematical terms: "a gamma of 1.0 is assumed while it is 2.2." Lots of filters, plug-ins and scripts make the same error.}}</ref> They serve to point out a widespread problem: Many programs perform scaling in a color space with gamma, instead of a physically correct linear space. The test images are constructed so as to have a drastically different appearance when downsampled incorrectly. Jonas Berlin has created a "your scaling software sucks/rules" image based on this principle.<ref>{{cite web|last1=Brasseur|first1=Eric|title=Gamma error in picture scaling, Acknowledgements|url=http://www.ericbrasseur.org/gamma.html#acknowledgments|quote=Jonas Berlin sent this image. Scale it down 1:2 with your software...}}</ref>

In addition to scaling, the problem also applies to other forms of [[Resampling (bitmap)|downsampling]] (scaling down), such as [[chroma subsampling]] in [[JPEG]]'s gamma-enabled [[Y′CbCr]].<ref>{{cite journal |last1=Chan |first1=Glenn |title=Toward Better Chroma Subsampling: Recipient of the 2007 SMPTE Student Paper Award |journal=SMPTE Motion Imaging Journal |date=May 2008 |volume=117 |issue=4 |pages=39–45 |doi=10.5594/J15100 |url=http://www.glennchan.info/articles/technical/chroma/chroma1.htm|doi-access=free }}</ref> [[WebP]] solves this problem by calculating the chroma averages in linear space then converting back to a gamma-enabled space; an iterative solution is used for larger images. The same ''sharp YUV'' (formerly ''smart YUV'') code is used in sjpeg<!--[https://github.com/webmproject/sjpeg]?--> and optionally in [[AVIF]]. Kornelski provides a simpler approximation by luma-based weighted average.<ref>{{cite web |title=Gamma-correct chroma subsampling · Issue #193 · mozilla/mozjpeg |url=https://github.com/mozilla/mozjpeg/issues/193 |website=GitHub |language=en}}</ref> [[Alpha compositing]], [[color gradient]]s, and 3D rendering are also affected by this issue.<ref>Archived at [https://ghostarchive.org/varchive/youtube/20211211/LKnqECcg6Gw Ghostarchive]{{cbignore}} and the [https://web.archive.org/web/20150321235204/https://www.youtube.com/watch?v=LKnqECcg6Gw Wayback Machine]{{cbignore}}: {{cite web|url=https://www.youtube.com/watch?v=LKnqECcg6Gw|title=Computer Color is Broken|author=Minute Physics|date=March 20, 2015|website=[[YouTube]]}}{{cbignore}}</ref><ref>{{cite web |title=What every coder should know about gamma |url=https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/ |last=Novak|first=John|date=September 21, 2016}}</ref>

Paradoxically, when upsampling (scaling up) an image, the result processed in a "wrong" (non-physical) gamma color space is often more aesthetically pleasing.<ref>{{cite web|title=Re: Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal...?|author=Nicolas Robidoux|url=https://legacy.imagemagick.org/discourse-server/viewtopic.php?p=89754#p89754|website=ImageMagick discourse server|quote=Generally, the linear light colour spaces (linear RGB and XYZ) produce exaggerated dark halos, and the "perceptual" colour spaces (sRGB, LAB, LUV) produce exaggerated light halos. If you think about it for a minute, this makes complete sense, because the perceptual colour spaces pack lots of bits at the darker end of the intensity spectrum, and "hollow out" the lighter end, so as to mimick the HVS (Human Visual System). So, 1 unit of dark overshoot gets you less "far" in sRGB than in linear RGB, but 1 unit of light overshoot gets you less "far" in linear RGB than sRGB.}}</ref> This is because resampling filters with negative lobes like [[Mitchell-Netravali filters|Mitchell–Netravali]] and [[Lanczos resampling|Lanczos]] create [[ringing artifacts]] linearly even though human perception is non-linear and better approximated by gamma. (Emulating "stepping back," which motivates downsampling in linear light (gamma=1), does not apply when upsampling.) A related method of reducing the visibility of ringing artifacts consists of using a [[Sigmoid function|sigmoidal]] light transfer function as pioneered by [[ImageMagick]] and [[GIMP]]'s LoHalo filter and adapted to video upsampling by [[Video renderer|madVR]], [[AviSynth]] and [[Mpv (media player)|Mpv]].<ref>{{cite web |title=Resizing using a Sigmoidal Colorspace|author=Anthony Thyssen |url=https://imagemagick.org/Usage/resize/#resize_sigmoidal |website=imagemagick.org |language=en |quote=A new technique has been developed in which rather than trying to resize images in a linear color space, the image is resized in a modified colorspace using the Sigmoidal Color Modifier Operator (-sigmoidal-contrast). This can reduce the clipping of extreme halo or Ringing Artefacts that may develop along very sharp edges.}}</ref><ref>{{cite web |title=GNOME/gegl: gegl-sampler-lohalo.c |url=https://github.com/GNOME/gegl/blob/master/gegl/buffer/gegl-sampler-lohalo.c|website=GitHub |language=en |quote=Sigmoidization was invented by N. Robidoux as a method of minimizing the over and undershoots that arise out of filtering with kernel with one more negative lobe. It basically consists of resampling through a colorspace in which gamut extremes are "far" from midtones.}}</ref><ref>{{cite web|title=madVR - high quality video renderer (GPU) assisted)|author=Mathias Rauen|url=https://forum.doom9.org/showthread.php?p=1595323#post1595323|website=forum.doom9.org|language=en|quote=I've now implemented your sigmoid function "stretching" and it seems to work well, from what I can see.}}</ref><ref>{{cite web|title=Dither tools|website=AviSynth wiki|url=http://avisynth.nl/index.php/Dither_tools#Dither_sigmoid_direct.2C_Dither_sigmoid_inverse|language=en|quote=Dither_sigmoid_inverse applies the inverse sigmoid curve to a clip in linear luminance in order to lessen the ringing when resizing it. Dither_sigmoid_direct converts back a clip to linear luminance. The chroma channels remain untouched.}}</ref><ref>{{cite web|title=mpv-player: options.rst|url=https://github.com/mpv-player/mpv/blob/d8c2e33a5d3840045a84cd5fa22c9c601fb1a0ae/DOCS/man/options.rst|website=GitHub|language=en|quote=When upscaling, use a sigmoidal color transform to avoid emphasizing ringing artifacts. Enabled by default. This is incompatible with and replaces --linear-upscaling. (Note that sigmoidization also requires linearization, so the LINEAR rendering step fires in both cases)}}</ref>