Talk:Gamma correction

message: I have photo-editing software which includes Gamma adjustment.  Looks like I can do approximately the same adjustments using the Brightness and Contrast adjustments.
Approximately, but I assume not exactly?  So, what's the Gamma adjustment for?
That's where I'm coming from.  Maybe more than me alone.
This article and everyone participating in it is speaking a different language.  Maybe the answer to my question is buried in the article, somewhere.  So when it comes to Gamma, I don't think Wikipedia is helping the vast majority of users, who need some Usability help with their software.
I recommend before getting into "Hurter–Driffield curves," "slopes of input–output curves in log–log space," and "conversion matrices,"  you begin with a plain English explanation of what those Gamma adjustments are, some possible methods for using them correctly, and how the Gamma adjustment is more than another Brightness and Contrast control.
Then, invite people to follow the more complex image-engineering concepts if they so desire.  Still, assuming that people aren't stupid and you truly care about sharing your explanations with them, then in the more technical, second-half of the discussion, you might be careful to provide guidance to supplement any technical jargon.
Nei1 (talk) 02:40, 25 May 2009 (UTC)
replies: text: The whole article needs to be rewritten.   References to Macs and PCs may seem useful to people who already own Macs and PCs, but if you don't already own one, or a copy of Photoshop (as the case may be), the article appears to wander off into territory that is completely and absolutely worthless.    216.99.219.73 (talk) 07:19, 15 September 2010 (UTC)
replies: text: Why would you need to own a Mac or PC to understand that these systems have different standard or historic gamma values?  If it's worthless to you, skip that part. Dicklyon (talk) 04:15, 17 September 2010 (UTC)
replies: text: I can understand a little about the need for a digital to analog converter, in order to adjust a bit pattern in memory to an output signal sent to a Cathode Ray Tube.   But most of the article seems to worry about why PC computers or Macs don't use the same numbers.   And then they jump to the conclusion that what they see, when a file is displayed, is an accurate representation of the data in a particular file.   My gut feeling is that the editors posting these paragraphs, are having problems with what they are seeing, when they really ought to be ignoring the visual data, and try using a hex dump instead, so they can see the real values of the bytes they are working with.   216.99.219.208 (talk) 04:37, 17 September 2010 (UTC)
replies: text: It's easy enough to use a dump to see the 8-bit values in an image.  But you need a gamma to know what light intensities those numbers represent; a value of 100, for example, represents a brightness much darker than half of what 200 represents; more like 0.5^2.2 typically [≈22%].  Dicklyon (talk) 22:39, 17 September 2010 (UTC)

text: Feel free to be bold and take a stab at it. It’s kind of a technical subject, that frankly isn’t very interesting outside a technical context. –jacobolus (t) 03:41, 14 November 2010 (UTC)
replies: text: It's a technical context that everyone who tries to adjust their computer monitors may need help understanding.  This article is not appropriate for that audience, or it needs a Section 1 inserted into the beginning.  Isn't there someone who can use Plain English to provide the two elements presently missing in this article: 1) Some basic explanation of what Gamma is, and 2) Adjustment instructions -- perhaps three levels of gamma adjustment: a "crude adjustment," "better adjustment," and "perfectly accurate adjustment?" Nei1 (talk) 03:25, 10 April 2011 (UTC)
replies: text:  It's great if people can use Wikipedia articles to answer such questions, but that really isn't their primary purpose. There are several nice links at the bottom of this article to “how to adjust your gamma” tutorials. –jacobolus (t) 03:31, 10 April 2011 (UTC)
thread_title: Newbie

message: The introductory section of this article states that “A gamma value \gamma < 1, is sometimes called an encoding gamma”; while the "Explanation" section discusses the figure which “shows the behavior of a typical display when image signals are sent linearly (γ = 1.0) and gamma-encoded (standard NTSC γ = 2.2).”  Since 2.2 is larger than 1.0, the article's usage of "encoding gamma" seems inconsistent to me.
W.F.Galway (talk) 06:48, 4 June 2009 (UTC)
replies: text: I've attempted a clarification.  Dicklyon (talk) 14:50, 4 June 2009 (UTC)
thread_title:  Inconsistency in use of the phrase "encoding gamma"? 

message: The article reads
:For a computer CRT, γ is about 2.2. By coincidence, this results in the perceptually homogeneous scale as shown in the diagram on the top of this section.
Is it really a coincidence that the computer CRT γ is 2.2 and that produces a perceptually homogenous scale, or is it the result of a deliberate choice made when sRGB was defined, as to match the overall behavior of the then current run of the mill CRT displays? --Gutza T T+ 00:44, 4 October 2009 (UTC)
replies: text: Whether it's coincidental or not, if it's true it was true before sRGB was dreamed up, and not related to that.  Personally, I don't think there's any reliable basis for it, though it's within the range that could be consistent with the Stevens' power law for brightness.  Dicklyon (talk) 03:30, 4 October 2009 (UTC)

text: Having sat around one afternoon discussing this very topic with Charles Poynton, the tentative conclusion was that in one sense it was purely coincidence, but in another sense it probably was not - if the physics had been different and CRT's were linear light response, then the necessity of having an efficient encoding over the limited signal to noise ratio transmission channels would have forced the researchers looking for display technology to have either moved on to some other technology that did have a gamma of about 2.2, or to have gone to the trouble of developing an electronic way of imposing such a power on CRT's.  GWG (talk) 11:37, 2 December 2009 (UTC)
replies: text: For me no coincidence at all. The same laws are valid for a biological light sensor, aka the eye, and a vacuum based light sensor like the early TV cameras. The law was there and waited for someone to find the (average) gamma parameter. AndreAdrian (talk) 12:15, 24 November 2018 (UTC)
thread_title:  Coincidence? 

message: The statement "Gamma values less than 1 are typical of negative film, and values greater than 1 are typical of slide (reversal) film" is incorrect.
In the general case:
gamma > 1 — expanded luminance range;
0 < gamma < 1 — compressed luminance range;
-1 <gamma < 0 — compressed luminance range, negative image; 
gamma < -1 — expanded luminance range, negative image.
Alex31415 (talk) 20:06, 7 February 2010 (UTC)
replies: text: OK, I just tried changing this, but my change is wrong.  First, it is in terms of optical density (absorption), so negatives have a positive slope (gamma), and positives a negative slope.  Reversal (positive) films do tend to have an abs(gamma) greater than one, as people like images this way.  (As long as you fit the dynamic range of the subject into the range of the film.)  Color negative films pretty much always have a gamma of about 0.5.  This gives them a large exposure latitude (compressing the dynamic range), while color printing materials have an appropriately large gamma, to reverse this effect. This mostly came from early use of Kodacolor in simpler cameras, where the dynamic range is needed.  Also, commercial printers use an appropriate analyzer to appropriately set exposure and color balance. Black and white films normally don't have the same low gamma, not quite as large an exposure latitude, but still enough.  Black and white negative films have gammas between about 0.6 and 2.0  For a more usual pictorial film, TMax P3200 with usual development has gamma (contrast index) between about 0.6 and 0.8.  One can adjust contrast at printing with graded or variable contrast paper.  For a reversal (slide) film they don't quote gamma or contrast index, but from the slope on the graph its (absolute) value is greater than one. Gah4 (talk) 10:34, 11 January 2019 (UTC)
thread_title:  Generalized gamma 

message: With my netbook (Acer Aspire One 751h), and its glary screen, I get the best results for this picture, http://en.wikipedia.org/wiki/File:Srgbnonlinearity.png, when I turn my Screen's gamma correction to the minimum.  
69.203.29.76 (talk) 23:55, 21 April 2010 (UTC)
thread_title:  Acer screen 

message: Help!   This article talks about encoding, and later on, reversing the encoding, so as to express the data in some way or other that is "visible."   In that respect, is gamma some kind of characteristic of the data being compressed?   Does plain vanilla ASCII have gamma?   I just read the article, and am confused.  I was wondering how on earth the main page of this article could be improved for someone who is very visually handicapped.   Would a blind person still have been able to make heads and tails of this article?   There has got to be some way of making this article palatable to people who can actually count bits, know what a byte is, but who can't exactly see the pixels involved.   Is the encoding routine really just a simple matter of counting the pixels, and figuring out which kinds of pixels are most common?   And how is it doing so?   I mean, exactly.   Are there 32 bit counters assigned to each of various specific colors, or shades of colors?   The main page of this article appears to assume we are all using either a PC compatible, or a Mac.   What if we aren't?   The main page of this article could be improved vastly by making it platform-independent.   The whole article needs to be rewritten.   216.99.219.73 (talk) 07:11, 15 September 2010 (UTC)
replies: text: Plain vanilla ascii is not an image format. The lead section is pretty explicit that we’re talking about images and video here, and the first paragraph of the article body explicitly talks about the components of an RGB image. Someone who is blind, doesn’t know what a video signal is, doesn’t have enough mathematical experience to understand what it means to be a power law & is unwilling to click the link and find out, and can’t read the formula Vout = Vinγ is going to have a pretty tough time understanding the concept, however we try to explain it. Frankly, the basics of the concept is just that formula alone, and just writing the math is pretty much the easiest and most explicit explanation we can give. If you have some other ideas though, suggest away. –jacobolus (t) 07:57, 15 September 2010 (UTC)
replies: text:  Bytes are bytes.   You can find bytes inside of graphic files, just like you can find bytes inside of text files.    They are wholly interchangeable.   I can't see any reason to treat them otherwise.   Your statement "plain vanilla ascii is not an image format" doesn't make sense to me.    But I think I am reasonably open-minded.  Does it depend on the file system you are using?   Can you show me, somehow, that vanilla ascii is not an "image" format?  (Are you talking about 'IMG' files for an Atari ST running GEM?   How about a file that consists entirely of 1 byte?   What about a file that consists of exactly 2 bytes?  How big must a file be, in order to be subject to gamma correction?   Does a file have to be more than 3 or 4 bytes?   Even if the file is 3 or 4 megs, why would it make a difference what kind of a filetype it is, for it to be gamma correctable?    216.99.219.102 (talk) 01:50, 17 September 2010 (UTC)
replies: text: But bytes are not ASCII.  ASCII is a 7-bit character code, unrelated to anything we're talking about here.  Images are stored usually with 8-bit pixel values, in a format that says how they're organized and encoded.  Gamma has not much to do with file formats, except that most image file formats specify or assume that 8-bit pixel values are gamma compressed, since they wouldn't have much dynamic range of intensity if they were not.  Whether JPEG, PNG, TIFF, GIF, or something else, if you take 8-bit values from an image file and send them to a display system, they will almost always be interpreted as gamma-compressed intensities, with a gamma between 1.5 and 2.4, depending on the system, file type, device, or color profile.  Dicklyon (talk) 04:00, 17 September 2010 (UTC)

text: Also, given how little you know of the topic, you probably shouldn't be improving the article from your own instinctive opinions; I reverted your edit. Dicklyon (talk) 04:13, 17 September 2010 (UTC)
replies: text: Oh, a personal dig, huh?  How clever.   Well, I am not going to get into an edit war with you.   I don't have time for that.   And plain vanilla ASCII is 8 bits wide with my computer.    I can't make use of this article because it appears to require me to go out and get a platform X instead of my platform Y.   216.99.219.208 (talk) 04:28, 17 September 2010 (UTC)
replies: text:  No one is trying to insult you. But this is not about data in general, but instead about the representation of colors numerically. ASCII really has nothing to do with anything, since ASCII is about text, not numbers. You don’t need any particular platform to understand some straightforward mathematics. Maybe start by reading the article on Exponentiation? –jacobolus (t) 12:16, 17 September 2010 (UTC)
thread_title:  Written for a specialized audience, redux 

message: The main page of this article would be improved if a couple paragraphs were added on the history of Gamma correction, and when and how it was arrived at.   Yes, that means that some of you will have to do your homework, and describe what it was in the olden days (before 1990, and earlier), and how it changed as the years went by.   216.99.201.198 (talk) 20:02, 15 September 2010 (UTC)
replies: text: There's a section entitled "Photography" which covers that somewhat. –jacobolus (t) 20:30, 15 September 2010 (UTC)
replies: text:  Do you mean the history behind the inks used for printing color photographs?   Cyan, Magenta, and stuff like that?  How are those related to Gamma correction?  216.99.219.208 (talk) 04:31, 17 September 2010 (UTC)
replies: text:  Did you read the Photography section of the article? No, there’s nothing related to color inks in there. γ was the symbol used for the slope of the straight part of the curve on a log-log plot comparing light exposure to resulting film density. –jacobolus (t) 12:22, 17 September 2010 (UTC)
thread_title: History of Gamma correction

message: The title is a misnomer that sets the wrong context for gamma encoding. At its core, gamma encoding is a form of lossy image compression, similar to mu-law encoding. It's not there to correct anything, any more than encoding as electrical signals is a correction for the fact that the monitor receives the image as electrical signals. If you sent a signal without gamma encoding to a monitor, it would look bad, just as if you sent it to a monitor with the wrong voltage range or polarity. Using the term correction implies that if monitors could have accepted a linear signal back when the standards were being written, we wouldn't be using gamma encoding (at least where signal bandwidth was an issue).
216.188.252.240 (talk) 17:17, 31 October 2010 (UTC)
replies: text: While I have some sympathy for the idea that "gamma correction" is a confusing misnomer, it's a commonly used term.  Gamma compression has mostly been conceptualized as correcting for a CRT display gamma, historically, even though you don't like that idea.  And I disagree that gamma encoding should be thought of as a form of lossy encoding.  It's not necessarily lossy; it just depends on whether you keep enough bits, or what you consider to be "uncompressed" as a reference.  I don't take your implication.  Dicklyon (talk) 22:49, 31 October 2010 (UTC)
replies: text:  "Gamma correction" definitely needs to be mentioned, but 216.188.252.240 might be right that some other term would make a better title. Personally I don’t much care either way. –jacobolus (t) 08:35, 1 November 2010 (UTC)
replies: text: The german wiki entry reads "monitor calibration" and refers to the purpose of the gamma correction value. But as in most cases in engineering: the term is not self-explaning. And gamma correction implies - for me - that there is a gamma, which is not correct and needs correction. Exactly what we do ... AndreAdrian (talk) 12:21, 24 November 2018 (UTC)
replies: text: Correction or not, that is what it is usually called in the case of TV signals. It seems that CRTs have a gamma of about 2.8 for intensity vs. voltage. Instead of putting correction circuits into each TV set, they put such circuits in before transmission.  (Back to the beginning black and white TV days.)  But do they correct for 2.8?  No, they use 2.2.  The result is about 1.3 in the visual image, which partially makes up for contrast loss due to ambient light. Note also, as noted, that slide films have a gamma (absolute value) a little greater than one, and I suspect that photographic prints are commonly printed with overall (negative+print) greater than one. That is the way it looks right to us. In the case of an analog TV signal, coding such as mu-law doesn't apply. Analog TV signals have white at a low voltage, and black at high, which allows for sync signals to be blacker than black, and so not visible. It is not so obvious how analog noise affects the result. I have no idea whether mu-law coding would have been done on digital signals without the analog history. Gah4 (talk) 10:20, 12 December 2019 (UTC)
thread_title:  Misnomer; it's not correcting anything 

message: There are a lot of a graphs on this page, but none of them actually name any of the axes. I suggest "input signal" for the x axis, and "light intensity" or "photon count" (if that is even correct) for the y axis. Bajsejohannes (talk) 10:34, 8 February 2011 (UTC)
thread_title:  Axis labels 

message: The quote is rather silly and doesn't contribute anything to the article. For example, imagine if in a biology article about polymerase chain reactions, a biologist was quoted as saying "7 minutes at 68°F in Buffer X with machine settings Y" represents "normal" to me. I have no idea what the actual effective gamma is, nor do I care. I could consider this degree of development as yielding Gamma = 1.0 or being Development No. 9 or Operation H, or any other symbol I choose. But why should I inject an unnecessary and confusing symbol for a perfectly simple statement of procedure? "Buffer X/ Settings Y/68°F/7minutes" is definite and easily expressed and understood as the means of obtaining my "normal" results.  — Preceding unsigned comment added by 132.183.104.52 (talk) 18:33, 15 May 2012 (UTC)
thread_title:  Removed quote by Ansel Adams 

message: I was surprised not to see much discussion of digitization and signal-to-noise ratio in this article. I've been wondering about the appropriateness of using gamma compression to pack 12- or 16-bit photographs into few bits without meaningful loss of data. By that I mean, if I have an ideal image sensor, it will be subject to Poisson shot noise corresponding to the number of photons that actually land on each pixel. If I record a 16-bit image and my signal corresponds to around 65k photoelectrons, then my SNR will be about 256, so the bottom eight bits are all noise. But if in a different part of the image I have signal of 256 photoelectrons, then there the noise will be on the order of 16 counts, but I certainly could still tell the difference between 256 and 224; if I had dropped the bottom eight bits, I would have completely lost that data.
The problem seems to be that the SNR isn't uniform across the dynamic range even though the quantization error is. However, it seems like if we take the 16-bit signal and gamma-compress it with γ=0.5, we can then represent that as an 8-bit signal and not really loose any information since the quantization error would vary across the dynamic range along with the SNR. Does that sound right? —Ben FrantzDale (talk) 13:13, 18 June 2013 (UTC)
replies: text: In your example the quantization error with gamma 2.0 is on the same order of magnitude as the signal noise. That means you would be adding some noise to the image. To make the quantization error irrelevant you might want to use 9 bits to make it half the noise, or instead start with a 32k photoelectrons sensor. Search for dithering and quantization errors and how much dithering is needed. It's not a hard value, it depends on the errors you can live with, but usually dither noise should be a bit larger than the quantization step. Rnbc (talk) 13:46, 21 April 2019 (UTC)
replies: text: Actually his example is right on, and pretty typical of what's done in camera image processing.  And yes you're right that the quantization noise is on the same order as the shot noise.  With quantization being uniformly distributed between plus and minus a half step, the rms quantization noise is enough less than shot noise that you'll get an excellent 8-bit file this way, and starting with fewer electrons of signal will only make it noisier.  And the shot noise is enough dither; no reason to add more.  More typically, a slightly lower gamma is like 0.45 is used (like in sRGB and other standard representations), so the data will have a bit less quantization noise in the darker areas, that is, optimized for a modest amount of dynamic range compression in the rendering.  An SNR near 100 in the highlights is plenty.  Dicklyon (talk) 14:26, 21 April 2019 (UTC)
thread_title:  Gamma compression/encoding and Poisson shot noise 

message: The series of pictures on the right hand side do not display the correct gamma factors. When you plug the factors displayed in the images into the formula presented at the start of the article, a larger gamma should lead to a larger Vout, or a brighter picture, although the opposite is shown. Maybe the inverse of the gamma factor is displayed under the photographs. — Preceding unsigned comment added by 145.18.169.99 (talk • contribs) 13:09, 18 July 2014
:No, a larger gamma should lead to a smaller V (except for in the white regions), since inputs and outputs (V and V) are in the range 0–1, so the pictures on the right hand side are correct. —Kri (talk) 14:39, 24 July 2015 (UTC)
thread_title:  Pictures show incorrect gamma 

message: Since sRGB deviates from the exact power function, should this only apply to images that are to be gamma encoded, or is the monitor also ideally following this function with a 2.4 exponent and linearity near black? --2.108.128.193 (talk) 13:40, 3 July 2016 (UTC)
replies: text: The sRGB gamma function is supposed to be a pretty good model of what the the typical (old-style CRT) display does, so that the encoded values will be correctly reproduced as the intended intensities.  Dicklyon (talk) 16:10, 3 July 2016 (UTC)
thread_title:  Ideal display gamma 

message: The grey tones are wrong in all of the image's three parts. For instance, the center block of the middle part should be 50% grey but it is 74%, as I find by using the color picker of GIMP.
I submit a corrected image, "Display_test_01.png", keeping the original design but substituting the correct grey tones.
To make the new image easily distinguishable from the incorrect one, I have changed the color of the frame from fluorescent green to light blue. If you prefer the frame black, so that the distinction will be easier to remember, use the file "Display_test_02.png".
Perhaps "Srgbnonlinearity.png" was correct when drawn and then saved with gamma information included but, even if it is so, no such information is recognised by either Firefox (52.0.2) or GIMP (2.8.20), which render an image inappropriate for monitor testing.
File:Srgbnonlinearity.png|The incorrect test image
File:Display_test_01.png|If each grey block appears of the same hue and brightness as its adjacent striped blocks (seen from a large enough distance), then the video monitor is checked as well adjusted
File:Display_test_02.png|If each grey block appears of the same hue and brightness as its adjacent striped blocks (seen from a large enough distance), then the video monitor is checked as well adjusted
— Preceding unsigned comment added by GeKahrim (talk • contribs) 08:16, 17 April 2017 (UTC)
replies: text: That's incorrect - the center block of the middle part of the test image is not supposed to be 50% RGB, but the amount of non-linear-light RGB needed according to the sRGB tone response curve to match the surrounding bars in average relative luminance, so that the surrounding horizontal stripes + gray center look like a homogeneous area (if you slightly squint your eyes). Note that in case of LCD monitors, the correct appearance can only be obtained when driving the panel at its native resolution and the image is viewed at 1:1 scaling (there must not be any interpolation). If your system is calibrated to the sRGB tone response curve (not necessarily the sRGB gamut, as we're dealing with an achromatic image here), which can be achieved by either making the actual response match the sRGB response (e.g. by calibrating the system's 1D videoLUT), or employing color management (which requires an accurate monitor profile if we're dealing with ICC-based color management), the original image looks correct, as intended (if you have an accurate monitor profile, you can get the correct view in GIMP by enabling color management in its options and assigning the sRGB profile to the image). Your modified images on the other hand, do not give the correct appearance, because they are not created with the correct intensities. Fhoech (talk) 12:21, 6 May 2017 (UTC)
thread_title:  In Sec. "Simple monitor tests", image "Srgbnonlinearity.png" is wrong for the purpose 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Gamma correction. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20080704074540/http://ftp2.bmtmicro.com/dlc/Color%20Management.pdf to http://ftp2.bmtmicro.com/dlc/Color%20Management.pdf
*Added archive https://web.archive.org/web/20070701001437/http://www.cgsd.com/papers/gamma.html to http://www.cgsd.com/papers/gamma.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 16:09, 10 October 2017 (UTC)
thread_title:  External links modified 

message: The checkered area has a pattern of 0% and 100% brightness primary color pixels. This integrates to a 50% brightness. The non-checkered area needs a brightness of integrated_brightness ^ (1/Gamma). The test image uses Gamma=2.5 and a non-checkered brightness of 75.8%. To give "high" gamma a value of 2.5 is (a bit) arbitrary. 2.2 or 2.8 are reasonable values, too. Charles Poynton advocates Gamma=2.5 in his GammaFAQ https://poynton.ca/GammaFAQ.html. Please tell me if you can live with the Gamma=2.5 value of mine. AndreAdrian (talk) 21:37, 26 November 2018 (UTC)
thread_title:  Gamma used in Gamma correction test image 

message: The test image in the article can start strobing if users scroll in Firefox 87 and probably other browsers. That isn't safe. 138.88.18.245 (talk) 20:00, 19 April 2021 (UTC)
thread_title:  Test Image Strobing on Scroll 

message: FTA: A notable exception, until the release of Mac OS X 10.6 (Snow Leopard) in September 2009, were Macintosh computers, which encoded with a gamma of 0.55 and decoded with a gamma of 1.8.
This sentence makes it seem like the Mac just happened to use .55 accidentally, but I don't think that's historically accurate. I'm pretty sure the Mac's gamma was set to match print process, given the DTP focus of early Macs. And when you look at modern colour appearance models, their effective power factor seems close to .55 under standard conditions. 77.61.180.106 (talk) 05:43, 26 July 2023 (UTC)
thread_title:  .55 

message: how do we apply an "image-rendering: pixelated;" style/css to the image used for test gamma? Eesn (talk) 22:43, 25 November 2022 (UTC)
thread_title:  gamma test image rendering on high density displays 

message: Je suis KONE Kolot, responsable de l’entreprise 2KB spécialiser dans d'entretien ménager à Québec. Il faut dire que j’ai moi-même travaillé dans ce secteur d’activité comme étant préposé à l’entretien ménager depuis plus de 3 ans. Et vu le besoin croissant de la demande, j’ai donc décidé de lancer mon entreprise qui a aujourd’huit non seulement un ans d’existence amis aussi avec beaucoup de réalisation à son actif. 38.87.11.25 (talk) 12:00, 26 July 2023 (UTC)
thread_title:  rainuré 

message: Indeed, try to open this image in Chrome and Firefox even on android, it will show the pear, not apple https://gitlab.gnome.org/GNOME/gimp/uploads/e764b2029957401b9f99d46e3e1c6203/VhGrd.png Valery Zapolodov (talk) 18:58, 26 July 2023 (UTC)
replies: text: I will add a good test with gAMA chunks. http://www.libpng.org/pub/png/colorcube/colorcube-pngs-gamma16.html Valery Zapolodov (talk) 22:21, 26 July 2023 (UTC)

text: Chrome already supports HDR (last test in https://www.wide-gamut.com/test) in AVIF and WCG in CSS since 2023 (https://css-tricks.com/the-expanding-gamut-of-color-on-the-web/ (tests) and also https://developer.chrome.com/articles/high-definition-css-color-guide/), as per CSS Color Module Level 4. Since Android 10 color managment is automatic too at least in Samsung browser. And they are already doing https://www.w3.org/TR/css-color-5/ it works perfectly on my LG C9 TV, my only monitor, and on my Galaxy S22 Ultra. Valery Zapolodov (talk) 13:38, 27 July 2023 (UTC)

text: There is evidence that gAMA png chunk worked in all browsers besides IE 7 as long as back in 2008. https://habr.com/ru/amp/publications/19163/ Valery Zapolodov (talk) 17:23, 27 July 2023 (UTC)
thread_title:  Browsers support PNG's gAMA chunk 

message: As the article notes, gamma correction goes back to silver halide films in the 1870's and 1880's, and yet indicates that it originated with the CRT. Hurter and Driffield studied the effects on photographic films, and the characteristic curve is now commonly named after them. Gah4 (talk) 07:03, 21 April 2024 (UTC)
thread_title:  [[Hurter and Driffield]]