Talk:SRGB

message: Probably the sane thing to do these days, for something like a decent paint program, is to use the sRGB primaries with linear floating-point channels. Then you can use out-of-bounds values as needed to handle colors that sRGB won't normally do. This scheme avoids many of the problems that you'd get from using different primaries. AlbertCahalan 05:05, 5 January 2006 (UTC)
replies: text: That seems roughly like a description of scRGB. Cat5nap (talk) 21:18, 23 October 2021 (UTC)
thread_title:  easy way to do wide gamut stuff 

message: I believe the value of the symbol \gamma is supposed to be 2.4. However it is not clear at all from the article: at first I thought the value was 2.2. Could someone who knows more than me explain this in the article? --Bernard 21:21, 13 October 2006 (UTC)
replies: text: Keep an eye on the article, because people keep screwing this up. The sRGB color space has a "gamma" that consists of two parts. The part near black is linear. (gamma is 1.0) The rest has a 2.4 gamma. The total effect, considering both the 1.0 and 2.4 parts, is similar to a 2.2 gamma. The value 2.2 should not appear as the gamma in any sRGB-related equation. 24.110.145.57 01:38, 14 February 2007 (UTC)
replies: text: That's not quite true.  The gamma changes continuously from 1.0 on the linear segment to something less than 2.4 at the top end; the overall effective gamma is near 2.2.  See gamma correction. Dicklyon 03:07, 14 February 2007 (UTC)
replies: text: To avoid confusions, I suggest to replace expression 1.0/2.4 with 1.0/\gamma and declare \gamma = 2.4 right after a = 0.055. At least, that would make math unambiguous. Also, an explanation is desired, why 'effective gamma' (2.2) is not the same as letter \gamma (2.4). Actually, there is nothing unusual: if you combine gamma=2.4 law with some other transformations, you will get a curve that fits with best some other effective gamma (2.2). Also, note that effective gamma is more important (it does not figure in definition, but it is was the base of the design, see sRGB specification mentioned in article). —The preceding unsigned comment was added by 91.76.89.204 (talk) 21:44, 14 March 2007 (UTC)
replies: text: I don't understand your suggestion, nor what confusion you seek to avoid.  2.4 is not the gamma, it is an unnamed and constant-valued parameter of the formulation of the curve. Dicklyon 07:36, 15 March 2007 (UTC)

text: OK, I think I fixed it to be more like what I intended to mean. Dicklyon 21:59, 23 May 2007 (UTC)
thread_title:  gamma = 2.4? 

message: The sRGB specifies an ENCODING gamma (Tone Response Curve or transfer curve function) that effectively offsets the 2.4 power curve exponent, very closely matching a "pure" gamma curve of 2.2 — the reason for the piecewise with the tiny linear segment was to help with math near black (with a pure 2.2 curve, the slop at 0 in infinite). 
BUT WAIT THERE'S MORE
That piecewise was for image processing purposes. Displays don't care. CRT displays in particular displayed at whatever gamma they ere designed for (somewhere from 1.4 to 2.5ish, depending on system, brand etc. Apple for instance was based around a 1.8 gamma till circa 2008). Most modern displays are about a 2.4 gamma, resulting in a desirable gamma gain for most viewing environments. 
AND: most ICC profiles for sRGB use the simple 2.2 gamma. Even Adobe ships simple 2.2 gamma profiles with AfterEffects. 
And to be clear: that linearized section is in the black area, with code values so small they are indiscernible. And any visible difference mid-curve is barely noticeable side by side. 
The upshot: IF you are going in and out of sRGB space (to linear for instance) it MAY make sense to use the piecewise version. However, using the simple gamma version simplifies code and improves execution speed, which is important if you are doing real-time video processing for instance.
--Myndex (talk) 02:37, 21 October 2020 (UTC)
thread_title:  Gamma & TRC 

message: I don't think that scaling the linear values is part of the specification. If the linear values lie outside [0,1], then the color is simply out of the sRGB gamut. Shoe-horning them back into the gamut may be a solution to the problem for a particular application, but it is not part of the specification and it is not an accurate representation of the color specified by the XYZ values.  PAR 16:38, 23 May 2007 (UTC)
replies: text: OK, I think I fixed it to be more like what I intended to mean. Dicklyon 21:59, 23 May 2007 (UTC)
thread_title:  or needs to be scaled .... 

message: I noticed a discrepancy between the W3C source and the IEC 61966 working draft.  Using the notation of the article, the W3C source specifies the linear cutoff as Clinear ≤ 0.00304, while the IEC 61966 source specifies the linear cutoff as Clinear ≤ 0.0031308, as used in the article.  Does anyone know why the discrepancy exists or why the article author chose the cutoff from the IEC working draft?  Thanks. WakingLili (talk) 19:48, 31 August 2007 (UTC)
replies: text: I don't recall exactly, but I think someone made a mistake in one of the standards.  As the article says (or values in the other domain), "These values are sometimes used for the sRGB specification, although they are not standard."  You could expand that to add the numbers and sources that you are speaking of. Dicklyon 20:17, 31 August 2007 (UTC)
replies: text:  I just compared the W3C spec with the IEC 61966 draft.  They use the same formulas for each part of the piecewise function, the only difference is the cutoff points.  I checked the math, and the IEC draft has the correct intersection point between the linear and geometric curves.  The W3C source is incorrect, which is unfortunate considering more people are likely to read it than the authoritative (but not freely available) IEC standard.  The error is ultimately pretty small, though, restricted to the region near the transition point. --69.232.159.225 19:25, 16 September 2007 (UTC)
replies: text:  Good work!  Please feel free to add that explanation to the article.  --jacobolus (t) 19:50, 16 September 2007 (UTC)

text: Which numbers are you saying are correct?  Do they result in a slope discontinuity at the intersection of the curves, or not? It would be good to say. Dicklyon 20:49, 16 September 2007 (UTC)

text:  Actually, is the IEC 61966-2-1 draft from 1998 different from the IEC 61966-2-1:1999 spec?  Does anyone have access to the spec, who could check this out?  Maybe the current spec was changed after that draft and the W3C is repeating the correct version?? --jacobolus (t) 21:03, 16 September 2007 (UTC)
replies: text: I just noticed the w3c doc is from 1996, before sRGB was standardized.  Looks like they had some better numbers then, but it didn't quite get standardized that way; their value 12.92 was not accurate enough to make the curve continuous, and rather than fix it they changed the threshold to achieve continuity when using exactly 12.92 and 1/2.4; the result is a slope discontinuity, from 12.92 below the corner to 12.7 above, but at least the curve is continuous, almost exactly. Dicklyon 21:35, 16 September 2007 (UTC)

text: It seems to me to make the most sense to do all math at high precision and save the rounding for the last step. What’s the justification for rounding before inverting the matrix? –jacobolus (t) 15:20, 24 August 2010 (UTC)
replies: text:  I don't know the thinking used by the group that wrote the standard.   Their choice has the feature that you can produce the forward transform as published in the standard from knowledge of the reverse transform to the four places specified in the standard.  It has the downside that you get less accurate matrices than if you did everything starting at double precision with the specified monitor primaries and white point.  This same general issue (rounding) seems to be behind differences in the way the cutoff constant is specified as well.  For the transformation matrices, the differences strike me as so small not to be of practical importance, except that having several versions floating around produces confusion. DavidBrainard (talk) 01:54, 25 August 2010 (UTC)
thread_title:  Discrepancy between sources 

message: Does anyone actually use this definition for practical purposes? To me it would appear much more logical to define the effective gamma as the solution for the equation g(K) = K^gamma_eff, which is gamma_eff=log g(K)/log K. I.e., not the slope of the curve, but the slope of the line connecting a curve point to the origin. This function is 1.0 at k->0, 1.46 at k=1/255 and exactly 2.2 at k=0.39, and 2.275 for k->1. Han-Kwang (t) 08:58, 13 October 2007 (UTC)
replies: text: No, the slope is always what's used.  See this book, for example; or this more modern one.  These are in photographic densitometry; in computer/video stuff, the same terms were adopted long ago; see this book on color image processing.  Try some googling yourself and let us know what you find. Dicklyon 16:32, 13 October 2007 (UTC)

text: Usually, to avoid confusing people with the calculus concept of a derivative as a function of level, the gamma is defined as a scalar as the slope of the "straight line portion" of the curve.  Depending on where you take that to be for sRGB, since it's not straight anywhere (and has no shoulder hence no inflection point), you can get any value on the curve shown in blue; but in the middle a value near 2.2.  Some treatments do omit the straight line bit and talk about derivatives, like this one.  Dicklyon 16:41, 13 October 2007 (UTC)
thread_title:  Effective gamma 

message: Could someone please plug the following RGB values, (0.9369,0.5169,0.4710), into the conversion formula? I'm getting strange results (e.g., values returned for XYZ that are greater than 1 or less than 0). SharkD (talk) 07:22, 21 February 2008 (UTC)
replies: text: Multiplying the reverse transformation matrix times the above, I get (0.6562,0.6029,0.5274). PAR (talk) 15:26, 21 February 2008 (UTC)
replies: text: Oops. I was using the forward transformation matrix instead of the reverse. SharkD (talk) 21:05, 21 February 2008 (UTC)
thread_title: Formulae help

message: The link I added to http://www.magnetkern.de/spektrum.html (the visible electromagnetic spectrum displayed in web colors with according wavelengths) was reverted by another user with the reason that a german site is not suitable. The page is bilingual (english and german) and contains references to english sources, so I cannot understand the reasons for deleting the link. See the discussion about the "Wavelength" article. 85.179.9.12 (talk) 11:05, 26 June 2008 (UTC)
thread_title:  sRGB colors approximating monochromatic colors 

message: The article states that sRGB is "well accepted and supported by free software, such as GIMP". Does anyone have anything to back up this statement? From my visual experience, Gimp does not comply with sRGB at all. Sam Hocevar (talk) 22:09, 30 August 2008 (UTC)
replies: text: I removed mention of the GIMP and "free software", as I have been trying for months to set up a usable sRGB workflow on a Linux system and completely failed (I ended up writing my own software). Sam Hocevar (talk) 01:29, 1 September 2008 (UTC)
replies: text: You are right that GIMP is not doing anything special about sRGB. However I don't understand your complaint about Linux, in fact in most cases sRGB is the *only* colorspace supported, and it is difficult/impossible to get a program to work in a color space that is *not* sRGB.  —Preceding unsigned comment added by 72.67.175.177 (talk) 17:12, 16 September 2008 (UTC)
replies: text: Open source developers are too dumb to understand what a color space is. In fact I've been using linux for years and I know of no free software that handles colors properly when doing things such as affine transformations on images. Femmina (talk) 03:22, 6 October 2008 (UTC)
replies: text: Who cares as long as the terminal is black and the text is white? It's not a matter of stupidity, it's just low priority.. .froth. (talk) 00:31, 16 February 2009 (UTC)
thread_title:  sRGB in GIMP ? 

message: I tagged the article NPOV because many of its claims are unsourced and it is so biased it seems to have been written by a Microsoft employee. For example, there is no source that Apple has switched to sRGB. --Mihai cartoaje (talk) 09:06, 30 July 2009 (UTC)
replies: text: I've done my best to keep the article sourced and accurate, and I'm no fan of Microsoft.  And I don't see anything about Apple in the article.  So I reverted the NPOV tag.  If there are problems needing attention, please do point them out here or with more specific tags in the article. Dicklyon (talk) 03:32, 31 July 2009 (UTC)
replies: text: I don't see any of the above mentioned problems, at least not with the current edition.ChillyMD (talk) 18:42, 27 September 2009 (UTC)
thread_title:  NPOV 

message: I just added a tentative timeline context in the article, but I'm not sure it's correct. My addition is based on the date of the proposal in reference #2 ("w3c"), i.e. 1996. But the standard proper is dated 1999 (IEC 61966-2-1:1999). And to make matters worse, the w3c reference makes references to earlier, unnamed versions of the same document (see section "sRGB and ITU-R BT.709 Compatibility" in that document). So, when was the standard created? I strongly feel we should place the article in its proper timeline (something it lacked altogether), but I'm not sure which date we should use. --Gutza T T+ 21:50, 29 September 2009 (UTC)
thread_title:  Timeline 

message: The plot and text contain serious errors and need to be corrected. The gamma makes sense in log spaces only. By definition, gamma = d(log(Lout)) / d(log(Lin)). The sRGB conversion function looks naturally just in log space.
However, according to an existing tradition, we use the inverse value of gamma that relates to encoding. For example, we use conventional value of 2.199 instead of true value of 0.4547 for the aRGB encoding.
The sRGB gamma in the linear space:
{{\gamma }_{sRGB}}=\frac{2.4}{1.055}\cdot \left( 1.055-\frac{0.055}{{{c}^{{1}/{2.4}\;}}} \right),
where c is the input normalized luminance (0.0031308 < c ≤ 1).
The sRGB gamma in the log2 space:
{{\gamma }_{sRGB}}=\frac{2.4}{1.055}\cdot \left( 1.055-\frac{0.055}{{{2}^{{L}/{2.4}\;}}} \right),
where L is the input normalized luminance, expressed in stops (-8.31925 < L ≤ 0).
When c = 1 or L = 0, the value is maximal: (2.4/1.055)(1.055-0.055) = 2.275.
Alex31415 (talk) 22:12, 7 February 2010 (UTC)
thread_title:  Plot of the sRGB 

message: The article states that a "12-bit digital sensor or converter can provide a dynamic range [...] 4096". This is not true, as if the code 0 is really an intensity of 0, then the dynamic range is infinite (a division by zero). The next sentence states that the dynamic range of sRGB is 3000:1; can someone point me to a reference?  To my knowledge, the Amendment 1 to IEC 61966-2-1:1999 defines white and black intensities of 80 cd/m2 and 1 cd/m2, and thus the dynamic range would be 80:1. --FRBoy (talk) 06:01, 1 December 2011 (UTC)
replies: text: Using 12-bits vs. 8-bits doesn’t inherently make any difference to the recordable or representable dynamic range, which depend instead on the properties of the sensor and so on. Obviously though, if you have lots of dynamic range, and not too many bits to store it in, then you end up with some big roundoff error ("posterization"). –jacobolus (t) 16:24, 1 December 2011 (UTC)
thread_title:  Dynamic range 

message: Hi. For a lecture, I created a video that enumerates all the colors in the sRGB gamut (you may have to store it to disk before viewing).
Instead of a diagram showing a certain cut through the gamut, it shows all colors where CIELAB L=const, looping from L=0 to L=100. Of course, the chromaticity corresponding to a given RGB pixel is in the right place in the diagram. The white parts are out-of-gamut colors.
If editors find it useful for this or a different article, I can generate an English version specifically for Wikipedia, maybe encoded in a more desirable way, or just as an animated gif.
Comments and suggestions very welcome.  — Preceding unsigned comment added by Dennis at Empa Media (talk • contribs) 19:36, 30 September 2012 (UTC)
replies: text: Why did you plot it in terms of x/y? –jacobolus (t) 18:53, 1 October 2012 (UTC)
replies: text:  Instead of e.g. CIELAB a/b, you mean? It was simply to shed some more light into the chromaticity diagrams. Can be done differently, of course. Dennis at Empa Media (talk)  —Preceding undated comment added 17:09, 2 October 2012 (UTC)
thread_title:  Enumerating sRGB gamut 

message: Somewhere in the introduction there should be a sentence explaining what 'sRGB" actually stands for. Many computer savvy people can probably figure out the RGB part (though I assert that's assuming more knowledge than many people might have). But what about the "s" part? In general, one should never assume that a reader knows what an acronym expands into. I'd fix it myself, except I don't know what the "s" stands for.  — Preceding unsigned comment added by 173.228.6.187 (talk) 23:09, 27 January 2013 (UTC)
replies: text: The letter s in sRGB is likely to come from "standard", but I could not find any truly reliable sources stating that. All sources that I found that made a statement about it appeared to assume that that's where it must come from, or from "standardized", or even from "small". Well maybe that ambiguity could somehow be expressed in the article. Olli Niemitalo (talk) 23:51, 27 January 2013 (UTC)
thread_title:  Acronym 

message: The illustration, , shows sRGB’s primary red somewhere near 608 nm. Even if we’ll try to determine the dominant wavelength and draw a constant hue segment from any of standard white points through it to the spectral locus, then it will not meet the latter in any waves longer than 614 nm. Spectroscopists classify waves shorter than 620 (or sometimes even 625) nanometres as orange. Is something wrong in some of these data, or monitors manufacturers blatantly fool consumers with the help of the hypocritical standard? 
No, do not say anything about illuminants and adaptations to white points please, standard ones or whatever. A spectral color is either itself or black, everywhere. Under any illuminant. Incnis Mrsi (talk) 16:27, 19 June 2013 (UTC)
replies: text: According to the ISCC–NBS system of color designation, the “R” primary of RGB would be called “vivid reddish orange”. You can see where it plots relative to some other landmark colors in the image to the right, which plots colors in terms of munsell hue/value. Likewise, the “G” primary is a yellowish green, and the “B” primary is on the edge between the “blue” and “purplish blue” categories. None of these primaries is close to the typical representative color for “red”, “green”, or “blue”. But that’s sort of irrelevant, since their purpose is not to match a color name. It would be silly to call it the “reddish orange, yellowish green, purplish blue color model”, or more accurately label the secondary colors as “purple, greenish blue, and greenish yellow”. –jacobolus (t) 23:44, 19 June 2013 (UTC)
replies: text: They're not that terrible, though.  One can wish that Microsoft and HP had defined more extreme colors as the primaries for sRGB, or that monitor manufacturers wouldn't "blatantly fool consumers with the help of the hypocritical standard", but that standard basically just encoded what all the TVs and monitors out there were already doing.  The red primary is accepted as "red" by most people.  Similarly for green and blue.  Probably because it's the reddest red you can get out of the device; etc.  And trying to make a longer-wavelength red primary or a shorter-wavelength blue primary is a very inefficient use of power, since the perceived intensity drops rapidly as you try to move the primaries into those corners.  I think you'll find the red primaries on many LED displays, on phones and such, even more orange for that reason.  Dicklyon (talk) 23:54, 19 June 2013 (UTC)
replies: text:  Yep, exactly. The primaries are just fine considering their purpose, and calling them R, G, and B is relatively unambiguous, even if it occasionally causes confusion like Incnis Mrsi is experiencing. –jacobolus (t) 23:59, 19 June 2013 (UTC)

text:  “Purplish blue” in reference to B is an nonsensical artefact of Munsell notation, or similar ones. This color has the same hue as an actual mix of blue with purple could have, but it is indigo, one of recognized spectral colors. Incnis Mrsi (talk) 09:35, 20 June 2013 (UTC)
replies: text:  I realize it’s probably not intentional, but could you please stop using loaded language like “blatantly fool”, “hypocritical”, “nonsensical artefact”, and similar? It’s obnoxious and makes me want to stop talking to you. “Purplish blue” is the ISCC–NBS category (the ISCC–NBS system is one of the only well-defined, systematic methods of naming colors, is in my opinion quite sensible (was created by a handful of experts working for the US National Bureau of Standards with quite a bit of input/feedback from all the experts in related fields they could find), and is in general more useful than the arbitrary set of “spectral color” names invented by Isaac Newton). In any event, “Indigo” would also be a reasonable name for this color. The point is it’s not particularly close to what would typically be called “blue”. –jacobolus (t) 11:36, 20 June 2013 (UTC)
replies: text:  Well, subtractive-oriented (or pigment-oriented), not nonsensical: an additive-minded expert does not see a sense in defining the set of as many as 8 primary terms (for saturated colors at full lightness) which misses violet. You think ISCC–NBS has more sense than works of Newton, but I think the only Newton's mistake was that he did not specify a quantitative description of his terms. Incnis Mrsi (talk) 17:15, 20 June 2013 (UTC)
replies: text:  Incnis, you’re getting caught here by the amount of color science that you currently don’t understand, and it’s leading you to make statements which don’t make sense to anyone who has studied an introductory color science textbook. You’re stuck in a 19th century mindset about how color vision works. I recommend you read through that handprint.com site, or if you like I can suggest some paper books. –jacobolus (t) 06:39, 22 June 2013 (UTC)
thread_title:  Does red of Microsoft become orange in a spectroscope? 

message: Are there any attempts or proposals to transform sRGB into more recent colour spaces, like e.g. the CIE 1964 10-degrees standard observer? And are there any standard spectra for the R,G,B primaries (like the D65 standard illuminant for the whitepoint), which would be required for such a transformation?--SiriusB (talk) 08:49, 19 August 2013 (UTC)
replies: text: Is the spectrum necessary to locate a colour in the CIE 1964 or similar colour space? Are these spaces not based on the same tristimulus response functions as CIE 1931? Illuminants require the actual spectrum (not only X,Y,Z) because an illuminant maps pigment colours to light colours and such mapping has much more than only 3 degrees of freedom (see metamerism (color) for examples). Neither R,G, or B is not designed to illuminate anything. Incnis Mrsi (talk) 14:53, 19 August 2013 (UTC)
replies: text:  I think instead of spectrum, you might mean spectral power distribution. In any case, primaries are defined in terms of XYZ (or Yxy), so they represent a color sensation, which can be created by any number of spectral power distributions. So the XYZ color sensation is standardized, not the SPD. One of the purposes of XYZ color space is to predict the color sensation produced by mixing two other color sensations. SPD is not necessary for this. But yes, illuminants like D65 are defined by a SPD. Fnordware (talk) 02:12, 20 August 2013 (UTC)

text: The 1964 space does not use the same 3D subspace as the 1931 space, so there is not an exact conversion, in general.  I don't know of attempts to make good approximate conversions, which would indeed need spectra, not just chromaticities.  Spectra of sRGB-device primaries would let one find a conversion, but it would not necessarily be a great one in general.  On the other hand, the differences are small. Dicklyon (talk) 04:51, 20 August 2013 (UTC)
thread_title:  Other colour spaces than CIE 1931 

message: The cutoff point 0.0031308 between the equations for going from C_{linear} to C_{srgb} doesn't seem quite right, since it should be where the curves intersect, which is actually between 0.0031306 and 0.0031307. A value of 0.0031307 would be closer to the actual point at about 0.0031306684425006340328412384159643075781075825647464610857164606110221623262003677722151859371187949498. It might make sense to give the cutoff point for the reverse equations 0.040448236277108191704308800334258853909149966736524277227456671094406337254508751617020202307574830752 with the same number of digits as the other cutoff point, as in, 0.040448. Κσυπ Cyp   16:06, 18 November 2013 (UTC)
replies: text: It would be best to make sure we give exactly the numbers in the standard.  Dicklyon (talk) 22:13, 18 November 2013 (UTC)
replies: text: I agree, just stick with what the standard says, otherwise you are doing original research. If you found a reliable source that points out this discontinuity, you could mention that. But I would point out that the difference is small enough to be meaningless. In the conversion to sRGB, it is off by 0.00000003. For even a 16-bits per channel image, that would still only be 1/50th of a code value. So it would truly not actually make any difference at all. Fnordware (talk) 02:09, 19 November 2013 (UTC)
thread_title: Cutoff point

message: The article mainly focusses on mapping sRGB components in a continuous [0,1] interval, but of course all sRGB images are stored in some sort of digital format and they often end up with 8 bits per component, at some point.
I am curious whether there were any official or commonly accepted guidelines on the discretizing to integers?
It's of course possible that sRGB never specified how to quantise. If it is only an analog display standard, then this is not their problem.
Regarding the inverse process (discrete to continuous) I suppose it is fairly obvious that, e.g., for integers in the [0, 1, ..., 255] range one should simply divide by 255.
That way the endpoint values 0 and 1 are both accessible.
As with codecs, the goal of the digitizing (encoding) process is to produce the best result out of that defined inverse (decoding) process. If so, the rounding technique would depend on which error you want to optimize for. I can think of numerous approaches--
* Multiply by 255 and round. This divides the interval [0,1] into 256 unequal-sized intervals. The first and last are [0,1/510) and [509/510,1] respectively, while all intervals inbetween have length of 1/255.
* Multiply by 256, subtract 0.5, and round. This divides the interval [0,1] into 256 equal-sized intervals. I.e. [0,1/256) maps to 0, [1/256,2/256) maps to 1, etc.
* Round to minimize intensity error. To minimize error after the sRGB->linear conversion, we should be careful that rounding up and rounding down by the same amount in sRGB does not give the same amount of change in intensity. To compensate for this we would tend to round down more often.
* Dithering of sRGB. Some sort of dithering has to be used if one wants to avoid colour banding.
* Intensity dithering. Along those lines, to produce a more accurate intensity on average, we would instead pick an integer randomly from a distribution such that the average intensity corresponds to the desired intensity. The nonlinearity means this is distinct from dithering for desired sRGB. 
* Minimize perceptual error. Given that human perception is nonlinear in intensity, maybe something else.
Is is really true that, as the article says, "the usual technique is to multiply by 255 and round to an integer" ? It's simply stated uncited at the moment, I would hope for something like "the sRGB standard does not specify how to convert this to a digitized integer[cite], but the standard practice for an 8-bit digital medium is to multiply by 255 and round to an integer[cite]". I'm not sure that this is correct, as a google search for sRGB dither uncovers that dithering is used in many applications. --Nanite (talk) 11:50, 23 December 2014 (UTC)
thread_title:  common practice discretizing 

message: I recently made edits to the page to fix a common misconception that the gamma function currently described in the page is supposed to be used for displaying sRGB images on a monitor. This is not the case: the display gamma for sRGB is a 2.2 pure power function. It is different from the encoding gamma function, which is what's currently on the page (with the linear part near black).
When I made this modification, I backed it up using two sources:
* sRGB working draft 4 (which I used as a proxy for the real spec since it's behind a paywall), which clearly states the expected behavior of a reference display on page 7 (§2.1 Reference Display Conditions). It mandates a pure power 2.2 gamma function. Meanwhile, the section about encoding is the one that contains the gamma function with the linear part at the beginning and the 2.4 exponent. This is further confirmed by §3.1 (Introduction to encoding characteristics): "The encoding transformations between 1931 CIEXYZ values and 8 bit RGB values provide unambiguous methods to represent optimum image colorimetry when viewed on the reference display in the reference viewing conditions by the reference observer", which means that the encoded values are meant to be viewed on the reference display, with its pure power 2.2 gamma function.
* Mentions of sRGB EOTF in Poynton's latest book (which I own), which repeatedly states "Its EOCF is a pure 2.2-power function", "It is a mistake to place a linear segment at the bottom of the sRGB EOCF". On page 51-52 there is an even more detailed statement, which reads as follows:
Documentation associated with sRGB makes clear that the fundamental EOCF - the mapping from pixel value to display luminance - is supposed to be a 2.2-power function, followed by the addition of a veiling glare term. The sRGB standard also documents an OECF that is intended to describe a mapping from display luminance to pixel value, suitable to simulate a camera where the inverse power function's infinite slope at black would be a problem. The OECF has a linear segment near black, and has an power function segment with an exponent of 1/2.4. The OECF should not be inverted for use as an EOCF; the linear slope near black is not appropriate for an EOCF.
As many will confirm, Poynton is widely described as one of the foremost experts in the field (especially when it comes to gamma), which makes this a very strong reference.
To be honest, I fell for it as well and was convinced for a long time that the gamma function with the linear part was supposed to be used for display. But upon reading the standard itself, it appears this is completely wrong, and Poynton confirms this assertion. BT.709 has the exact same problem, i.e. the gamma function described in BT.709 is an OECF, not an EOCF - the EOCF was left unspecified until BT.1886 came along and clarified everything.
User:Dicklyon reverted my edit with the following comment: "I'm pretty sure this is nonsense". Since I cite two strong references and he cites none, I am going to reintroduce my changes.
E-t172 (talk) 20:33, 25 December 2014 (UTC)
replies: text: Poynton is a well-known expert, but he is wrong here; his statements on page 12 are not supported by what the sRGB standard says, nor by any other source about sRGB.  The cited draft only mentions 2.2 in the introduction; it is not a part of the standard itself.  The concept doesn't even make sense.  sRGB is an output-referred color space.  The encoding encodes the intended display intensity via the described nonlinear function.  Dicklyon (talk) 20:47, 25 December 2014 (UTC)
replies: text: The cited draft mentions 2.2, along with the explicit pure power function, in section 2.1. Section 2.1 is fully normative. It is certainly not the introduction, which is section 1 (though the introduction also mentions 2.2). So yes, his statements are fully supported by the standard. The concept makes perfect sense because, as Poynton explains, you can't encode sRGB values from a camera with a pure power law for mathematical reasons (instability near black). This is why a slightly different function needs to be used for encoding as opposed to display. But since you were mentioning the introduction, here's what the introduction says: "There are two parts to the proposed standard described in this standard: the encoding transformations and the reference conditions. The encoding transformations provide all of the necessary information to encode an image for optimum display in the reference conditions." Notice "display in the reference conditions". "Reference conditions" is section 2, including the pure power 2.2 gamma function. I therefore rest my case. E-t172 (talk) 21:05, 25 December 2014 (UTC)
replies: text: I see my search failed to find it since they style it as "2,2" and I was searching for "2.2".  I see it now in the reference conditions.  But I still think this is a misinterpretation.  The whole point of an "encoding" is that it is an encoding of "something";  in this case, sRGB values encode the intended output XYZ values.  If the display doesn't use the inverse transform, it will not accurately reproduce the intended values.  I believe that it is saying that a gamma 2.2 is "close enough" and is a reference condition in that sense, not that it is ideal or preferred in any sense, which would make no possible sense.  I've never seen anyone but Poynton make this odd interpretation.  Dicklyon (talk) 23:27, 25 December 2014 (UTC)

text: Saying that the reference conditions are ideal for viewing sRGB implies that a veiling glare of 1 % is ideal. The money says that it is not. People will pay to get a better contrast ratio in a darkened home theater. Olli Niemitalo (talk) 00:12, 26 December 2014 (UTC)
replies: text:  What "people" prefer has no bearing on accuracy. Besides, sRGB is not designed for home theater - it's designed for brightly lit rooms (64 lx reference ambient illuminance level). The reference viewing conditions simply indicate that correct color appearance is achieved by a standard observer looking at a reference monitor under these reference viewing conditions. Whether it is subjectively "ideal" or not is irrelevant - the goal of a colorspace is consistent rendering of color, not looking good. Theoretically, you can use sRGB in an environment with no veiling glare, as long as you compensate for the different viewing conditions using an appropriate color transform (CIECAM, etc.) so that color appearance is preserved. E-t172 (talk) 17:40, 27 December 2014 (UTC)

text: Finding a source that specifically refutes Poynton is hard, of course, but many take the opposite, or normal classical interpretation viewpoint.  For example Maureen Stone, another well-known expert.  Dicklyon (talk) 00:39, 26 December 2014 (UTC)

text: Here's another source about using the usual inverse of the encoding formula to get back to display XYZ:  ; and another ; and another .   Dicklyon (talk) 05:35, 26 December 2014 (UTC)
replies: text:  I see. Well, I guess we have two conflicting interpretations in the wild. I suspect that your interpretation (the one currently on the page) is the widely accepted one, and as a result, it most likely became the de facto standard, regardless of what the spec actually intended. So I'll accept the statu quo for now. E-t172 (talk) 17:40, 27 December 2014 (UTC)
replies: text:  Whichever one is correct officially, an inverted sRGB transfer function makes a lot more sense physically and, at least more recently, pragmatically. Perhaps a 2.2 function made sense with high-contrast CRT's, but the ghastly low contrasts of common modern displays really favor a fast ascent from black. Even on my professional IPS, the few blackest levels are virtually indiscernable when not set to sRGB mode. 128.76.238.18 (talk) 23:45, 2 August 2019 (UTC)
thread_title:  Display gamma versus encoding gamma 

message: A lux meter can buy very cheep.
I measure with my monitor(brightness in monitor is set to 20% and prad test of this monitor say it is around 140 cd/mm2 at full white at default monitor settings and choose 6500 Kelvin.In the gamma testimage in this article, can see it is wrong. measurement is relative to full 79 Lux
show a big box at rgb value 255 and bring the digital multimeter with Lux support Conrad Dt-21 neares to screen and i measure 79 Lux. I use always same place on screen.
with rgb value 128 i measure 34 Lux
/rgb 64 measure 16,5 Lux
/rgb 8 measure 3,1 Lux
/rgb 0 measure 1.0 Lux
I use quickgamma and this article gamma testimage 
Now i measure this LUX values 
/rgb 128 29 Lux
/rgb 64  14,1 Lux
/rgb 8 3.4 Lux
/rgb 0 1.0 Lux
So please can somebody do a more precise diagram that the result values of srgb between 0 and 1 can precise read for at least values 192(0.75), 128(0.5),64 (0.25), 32(0.125), 16, 8 ?
then there need only the result value multiplicate with the lux measure at rgb 255. and if this is identical with the measure Lux, then gamma is ok. 
so no gamma test image is need and it can be much more precise and give not much worser results than color calibration system – — Preceding unsigned comment added by 84.183.119.225 (talk • contribs) 
:There is fairly good plot on the Gamma correction article.  Dicklyon (talk) 20:49, 29 February 2016 (UTC)
thread_title:  please do a precise gamma curve plot or formular that can put in google calculator, so users with a Lux meter can measure easy and see if gamma work correct. so no gamma testimages are need 

message: I think it would be good to mention that 50% absolute intensity is (188, 188, 188). It reinforces to the reader that the scale is non-linear, it aids in checking calculations, and it dispels the common idea that it's (128,128,128). (I know there are more greys that are also interesting, see e.g. Middle gray.) I'm not quite sure what the best place in the article would be though.  — Preceding unsigned comment added by 80.114.146.117 (talk) 18:09, 19 January 2017 (UTC)
replies: text: I totally agree. I'd also like to see more discussion of white point. I assume that if it's reference is D65, then the XYZ value for (255, 255, 255) corresponds to an XYZ value of (95.047, 100.00, 108.883). Is that correct? —Ben FrantzDale (talk) 14:38, 13 November 2017 (UTC)
thread_title:  50% absolute intensity 

message: :Note to address the claims by user 69.172.145.112 aka Deadlythings. on his last revert he made this statement:
::Deadlythings Said: — It's listed in the actual specification as to why "gamma" isn't used anywhere in the specification. Perhaps it makes sense to make it clear that it's an overloaded term that doesn't adequately describe the actual Transfer Function? Remember that EOTFs and OOTFs and OETFs all have a "TF" in them, given that the term "gamma" doesn't adequately describe their nature nor what they achieve
:The IEC document in question has a statement in Annex A that is non-normative opinion regarding the term "gamma" however gamma is the correct terms as used in industry for three quarters of a century, and the term used by all OTHER standards organizations such as the ITU, NAB, SMPTE, SPIE, ICC, etc. Instead, the IEC is avoiding using "gamma" and instead using non-standard terminology that is somewhat obtuse and lacking meaning, using the terms such as  "display characteristic" and "simple power function" and worse "normalised (sic) output luminance as represented by an exponential function" without any consistency, the document is only harder to parse. In these cases using the term "gamma" would have be simpler and well understood, instead of trying to rewrite the language, which is ultimate a fruitless semantic argument. The user "Deadlythings" is all harping here (and elsewhere) about how the term is "transfer function" and even this IEC does not clearly state it as such. 
:And again, it is a SEMANTIC argument and notwithstanding. A transfer function or tone response curve or gamma curve all achieve the same thing, and this is academic. In fact IEC 61966-2-1 states in the intro and in the reference display specifically "simple exponent value of 2.2." not even mentioning the piecewise function, though the piecewise is of course defined under what the IEC calls "Encoding Characteristics". 
:This is only another example of how the IEC 61966-2-1 standard is essentially irrelevant. The primaries and white point are defines in Rec.709, the reference display (based around CRT) has no relevance to modern LCDs particularly in terms of output luminance, and the "viewing conditions" are also no longer relevant in today's world of mobile devices. The IEC itself suggested that the standard only have a lift of ~5 years, and yet has never revised it. Nevertheless, other standards organizations and manufacturers have moved forward with new technology, making the only thing about the IEC 61966-2-1 that is relevant is the tone response curve aka transfer curve, aka what the IEC calles the display characteristic, and what engineers and other standards organizations have very simple referred to as "gamma" since the middle of the last century.
:All this nonsense aside, today I will add a paraphrasing of why the IEC chose to use inconsistent terminology (not even sticking to "TRC" or "transfer function" and tossing in ambiguous terms like "characteristic"). I hope this solves the dilemma of Mr. Deadlythings and puts an end to this edit warring. Thank you for reading. ==Myndex (talk) 20:55, 13 December 2020 (UTC)
replies: text: Well thank you  I tried to explain in detail the problem with these semantic issues below. If the other user is who I think he is, he does have knowledge in related areas, but for some reason has been stuck on this "gamma" thing and not to good effect. As for color: yes, I noticed. I've been trying to spend some of my free time fixing some of these more important color articles as so many have been, eh, degraded for want of a better term. I *have* been using the talk pages to mention what I plan on fixing before I do so, and why, so it's clear I'm not being capricious and specifically to prevent edit warring.--Myndex (talk) 22:37, 13 December 2020 (UTC)
thread_title:  Gamma Gone Gonzo 

message: ::I completed the above section before I saw Mr Deadly's comment (whcih is above that), which I will now address:
::Dear Mr. Deadlythings or should I call you Troy? if you read what the actual IEC 61966-2-1 standard says, you'd see that not only in the introduction to the document, but in the reference display characteristics, it defines the display (in other words the EOTF) as a simple power curve of 2.2 and does not call it a transfer function (except in one tangential spot) typically calling it the "display output characteristic." Again, this is a pointless semantic argument. As I elaborated above, the IEC is not even using the "technically most correct" term of "colour component transfer function" so please stop claiming it is. 
::And moreover the terms EOTF and OETF are ABSOLUTELY NO WHERE IN THAT DOCUMENT AT ALL so stop claiming they are, your arguments in this regard are meritless. As was your previous attack on this article replacing the term "gamma" which was also reverted some time ago. 
::And FYI I did not just remove that clump of non-normative opinion that you cut and pasted in its entirety from the IEC doc. I re-wrote that section to include history and the colloquial use of the term which continues today, for the obvious reasons of brevity. Your reverts dumped what I wrote and replaced it again with the full long winded section from the IEC, a copyright infringement. If you really wanted some of that in there, you need to use only a snippet and give it relevance to the overall sRGB article (as you did in your comment above). As I mention above I am going to do that today since you are so bent out of shape about this. But this is not the world according to Troy. Some of us have been in this business before digital was even a "thing", before you were even born, so don't presume to have some stranglehold on information here because all you are doing is making a meritless semantic argument from an unsupportable position.
::As for "fair use," you cannot just copy and paste a whole section of a document, fair use allows copying a "minimum portion" for comment. Because this is such a big deal to you, I am working on a revision that includes a little more of the IEC's opinion. And to be clear that Annex A is JUST THAT: it is a non-normative opinion.
==== Semantics Shemantics ====
::Mr Deadly Dude, you are spending a lot of time on semantic arguments. You are literally arguing about the use of words and terms and not the function. Everyone in the industry knows what gamma means and what it refers to. It is used by multiple international standards organizations. When I write articles, I am careful to clarify that "transfer curve" is the most technically correct, and that "gamma" in some cases is not a pure power function, but an "effective gamma" to be more accurate. This is easily understood by all in the industry.
::On the other hand, the IEC's term: "Display output characteristic" is bizarre, over-broad, and non-definitive. We should no more replace terms "gamma" or "effective gamma" with "Display output characteristic" than your own personal opinion edits of what you personally think the terms should be. Gamma to refer to the transfer characteristics of a display is a consensus terminology.
::INCLUDING THE CIE. Nice try trying to bring up the CIE's nifty new glossary site to support your point. Read it again, because you missed something pretty important. I'll explain: The CIE entry is for the "colour component transfer function" and if you noticed, they clearly indicate that the term is the most broad and encompassing term, covering not only piecewise functions, BUT ALSO covering log, linear, and ALSO simple power functions, i.e. gamma. Your attempt to claim "scare quotes" is notwithstanding. It's right there for all to see. colour component transfer function refers to ALL FORMS of transfer curve, it is therefore MORE AMBIGUOUS when discussing a specific TYPE of transfer curve. Get it?
::The brief paragraph I wrote (that your wholesale reverts tossed out) specifically addressed WHY in our industry it is IMPORTANT to be MORE DEFINITIVE about the TYPE of curve, as we learned the hard way in the 90s and early 2000s through the emergence of digital to replace chemical imaging. Using the term "Transfer Curve" is LESS definitive, as it applies to even straight-linear (gamma 1.0).
::Do you see now why you are incorrect? Semantic arguments likes this tend to be annoying to other industry professionals, but I'm guessing no one has taken the time to break it down for you. As a side note, adherence to a non-normative blurb in a document that most in the industry consider mostly irrelevant to today's technology is weak support. If you are who I think you are, I've read some of the other things your written, on film emulsions for instance, and that is the only reason I've taken the time to cover this. You do yourself a disservice in credibility by grasping at a tiny straw of support from a 22 year old document that should have been revised long ago, regarding terms that are well established in other standards and in industry. 
::Take this one little bit of advice: if the substance of your argument is nothing more than terminology, look into why that terminology is being used that way, what the history is, if it's embedded, and if there's a compelling reason to change it. I'm dealing with a semantic issue at the moment regarding people using the term "luminosity" when they mean luminance. But I also researched into why, and my position is only to suggest it be changed in documents I'm working on by explaining that luminosity is light over time and luminance is light over area, and why it's important to keep them separate. 
::In your case, you are using the term "transfer function" as if it solely refers to a piecewise function, and as I demonstrated above that's not the case, it's actually more ambiguous than the narrower term of "effective gamma." So do you gain anything by using the more general, encompassing term? I don't think so, and I'll guess the others that have also been reverting your edits don't think so either. Have a nice day. --Myndex (talk) 22:26, 13 December 2020 (UTC)
thread_title:  A Response to Mr Deadly, Part Deux 

message: ::Mr Deadly Dude, you are spending a lot of time on semantic arguments. You are literally arguing about the use of words and terms and not the function. Everyone in the industry knows what gamma means and what it refers to. It is used by multiple international standards organizations. When I write articles, I am careful to clarify that "transfer curve" is the most technically correct, and that "gamma" in some cases is not a pure power function, but an "effective gamma" to be more accurate. This is easily understood by all in the industry.
::On the other hand, the IEC's term: "Display output characteristic" is bizarre, over-broad, and non-definitive. We should no more replace terms "gamma" or "effective gamma" with "Display output characteristic" than your own personal opinion edits of what you personally think the terms should be. Gamma to refer to the transfer characteristics of a display is a consensus terminology.
::INCLUDING THE CIE. Nice try trying to bring up the CIE's nifty new glossary site to support your point. Read it again, because you missed something pretty important. I'll explain: The CIE entry is for the "colour component transfer function" and if you noticed, they clearly indicate that the term is the most broad and encompassing term, covering not only piecewise functions, BUT ALSO covering log, linear, and ALSO simple power functions, i.e. gamma. Your attempt to claim "scare quotes" is notwithstanding. It's right there for all to see. colour component transfer function refers to ALL FORMS of transfer curve, it is therefore MORE AMBIGUOUS when discussing a specific TYPE of transfer curve. Get it?
::The brief paragraph I wrote (that your wholesale reverts tossed out) specifically addressed WHY in our industry it is IMPORTANT to be MORE DEFINITIVE about the TYPE of curve, as we learned the hard way in the 90s and early 2000s through the emergence of digital to replace chemical imaging. Using the term "Transfer Curve" is LESS definitive, as it applies to even straight-linear (gamma 1.0).
::Do you see now why you are incorrect? Semantic arguments likes this tend to be annoying to other industry professionals, but I'm guessing no one has taken the time to break it down for you. As a side note, adherence to a non-normative blurb in a document that most in the industry consider mostly irrelevant to today's technology is weak support. If you are who I think you are, I've read some of the other things your written, on film emulsions for instance, and that is the only reason I've taken the time to cover this. You do yourself a disservice in credibility by grasping at a tiny straw of support from a 22 year old document that should have been revised long ago, regarding terms that are well established in other standards and in industry. 
::Take this one little bit of advice: if the substance of your argument is nothing more than terminology, look into why that terminology is being used that way, what the history is, if it's embedded, and if there's a compelling reason to change it. I'm dealing with a semantic issue at the moment regarding people using the term "luminosity" when they mean luminance. But I also researched into why, and my position is only to suggest it be changed in documents I'm working on by explaining that luminosity is light over time and luminance is light over area, and why it's important to keep them separate. 
::In your case, you are using the term "transfer function" as if it solely refers to a piecewise function, and as I demonstrated above that's not the case, it's actually more ambiguous than the narrower term of "effective gamma." So do you gain anything by using the more general, encompassing term? I don't think so, and I'll guess the others that have also been reverting your edits don't think so either. Have a nice day. --Myndex (talk) 22:26, 13 December 2020 (UTC)
thread_title:  Semantics Shemantics 

message: The text following ‘In IEC 61966-2-1 the IEC does not use the term gamma or effective gamma’ was clearly written by someone who didn't just disagree with the IEC, but who at the time was feeling very emotional about it and therefore in no state to write article text for Wikipedia.  — Preceding unsigned comment added by 77.61.180.106 (talk) 03:33, 28 December 2020 (UTC)
replies: text: I added that paragraph to appease another user who was starting an edit war. Nevertheless, ultimately it is useful to describe the nature of the controversy — one that rages on still today. I discuss this at length immediately above, and if you read the entirety of this talk page, you'll see this issue is a frequent talking point. I stated in the edit history the reasoning for the paragraph. This is not about "disagreeing" with the IEC, and I had initially struck and replaced the references to the "Annex A" material. This is only about presenting the information regarding this, which is entirely a semantics issue. Myndex (talk) 23:21, 28 December 2020 (UTC)

text: Work on your reading comprehension. Your snark notwithstanding, I'm the "Hollywood professional" as are more than a few on here. The averted edit war was with another industry guy, in Vancouver. If you don't like the tone of the description, reword it. And consider making an account instead of hiding behind an anonymous IP address if you are going to be attacking other users.Myndex (talk) 10:07, 5 January 2021 (UTC)
thread_title:  NPOV problem 

message: The entire section was moved to the gamma article, where I subsequently deleted it.  Not that there's nothing good there, but as written it was most unsourced and WP:SYNTH.  Feel free to start with a relative clear slate to say what might make sense in this article or that; but keep it well sourced please. Dicklyon (talk) 23:47, 24 July 2021 (UTC)
thread_title: Start over?

message: They no longer do after this edit. https://en.wikipedia.org/w/index.php?title=SRGB&diff=949593434&oldid=946057212 Or didn't they before? Probably well-meant, but now the citation is a lie...? 91.249.62.203 (talk) 13:42, 23 January 2021 (UTC)
replies: text: No, it perfectly matched IEC 61966-2-1-1999 before the edit, although matrix with 7 decimal points was further defined in Amendment 1 (also not the same as this new one). 109.252.90.66 (talk) 07:41, 1 February 2021 (UTC)
replies: text: Looks like the values are now the ones used in NIF RGB (it was the same as sRGB before correction of discontinuity). http://www.graphcomp.com/info/specs/livepicture/fpx.pdf 109.252.90.66 (talk) 21:46, 7 February 2021 (UTC)
replies: text: This is coming from https://stackoverflow.com/questions/66360637/which-matrix-is-correct-to-map-xyz-to-linear-rgb-for-srgb/66374377#66374377 so I propose we revert that change and add that matrix is rounded and maybe clarify how the unrounded matrix will look like, thanks to Nvidia. https://docs.nvidia.com/cuda/npp/group__rgbtoxyz.html 109.252.90.66 (talk) 14:15, 10 April 2021 (UTC)
replies: text: I fixed it and will add better matrix for sYCC. 2A00:1370:812D:F205:6912:F9FB:801B:3897 (talk) 13:43, 17 April 2021 (UTC)
thread_title:  "The numerical values below match those in the official sRGB specification,[1][3]" 

message: Back in 2013 this section made some sense, as it uses terminology Clinear and Csrgb that at that time was used in the previous section.  But now these terms are floating and meaningless.  I just removed the same meaningless math from the Gamma correction article where it was copied to a few years ago.  Anyone want to work on this?  Dicklyon (talk) 05:57, 13 July 2021 (UTC)
replies: text: Wow, in you edit you use C_sycc, but there after transfer function it is actually C_srgb, it is only YCC after YCbCr transfer, YCC means YCbCr. Valery Zapolodov (talk) 20:25, 8 August 2021 (UTC)
thread_title:  "Theory of the transformation" section 

message: User Valery Zapolodov insists on inserting irrelevant , incorrect, and uncited information into this article.
I have yet to see any proof that  "FlashPix Format" has any relevance what so ever to sRGB. IT DOESN'T nothing about it is relevant.
And it is not relevant if Display P3 happens to use a similar TRC, P3 is not sRGB.
This crap belongs in ColorSpace the general article not here.  — Preceding unsigned comment added by Myndex (talk • contribs) 02:49, 30 October 2021 (UTC)
replies: text: There is no edit war, since there were no 3 reverts from anyone. History of creation must be present in Wikipedia article. I still did not see the documents that derived BT.709 primaries, i.e. CCIR Rec. XA/11 1986-90f, a.k.a. IWP 11/6-2108 (Canada). Display P3 uses THE very same (not similiar) TRC, this is very important since it means no change of transfer happens, only primaries are changing (color managment must still happen on linear light of course, so not that important). Now "LUTs are faster" idea is citation needed since nonlinear math is usually faster without any tables if normal HW accel. is used, only very strange people use LUTs nowadays since it is something of a black box if derived from para curve (but to calibrate real HW 3DLUT is needed, like LG TVs), also as shown by https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-4-final-results LUTs have lower precision than para encoding and even para encoding can be further tuned. FlaxPix specification here http://www.graphcomp.com/info/specs/livepicture/fpx.pdf discusses two main colorspaces back then in 1990-1996: PhotoYCC of PhotoCD and JPEG/JPEG 2000 (NOT used AT all nowadays) and NIF RGB, both supported by Windows 2003. NIF RGB is what sRGB with round errors and no RGB as main space was (indeed IEC mandates that inverted matrices are all pointing to RGB and R'G'B', by increasing precision of those inverts one gets better bitness in R'G'B'). Now, https://github.com/ImageMagick/libfpx/blob/296e4471f9ce5c06381405a981448b24f8675b9b/fpx/buffdesc.cpp#L278 As for Windows code https://github.com/9176324/Win2K3/blob/572f0250d5825e7b80920b6610c22c5b9baaa3aa/NT/printscan/wia/common/jpeglib/jccolor.cpp#L19 17:47, 2 November 2021 (UTC)
replies: text:  Yea it was three over time and you are bringing in things that are not related and inserting your own opinion as unreferenced and unsupported fact. Myndex (talk) 14:59, 4 November 2021 (UTC)

text:  Then you should find a source which clearly explains the history. Synthesizing it out of scattered inferences from miscellaneous documents is not a good fit for Wikipedia. –jacobolus (t) 18:25, 4 November 2021 (UTC)

text:  My understanding (from private communications a decade ago, maybe this has changed since) is that Photoshop internally converts everything to lookup tables. Though if you want to argue that Adobe is filled with "very strange people" I won’t argue too hard. I can agree that the sections about LUTs are not sufficiently sourced. Myndex apparently added them here. Maybe you can find some better sources Myndex? –jacobolus (t) 18:28, 4 November 2021 (UTC)
replies: text:  It is standard practice here in the Hollywood film industry, and image files delivered to DI are most often integer (10bit DPX or 16bit TIF) and to be honest I thought it was "academic enough" to state it. I'm certain I can find additional references, and I'll look. But in short, with a LUT you can remain as an integer (8bit 10 12 whatever) there is a single lookup & assignment, whereas when calculating a piecewise TRC as for sRGB, there is a divide by 255, a comparison, then usually (an exponentiation, a multiply, a subtraction, or the inverse), and possibly a multiply by 255. Compare all of that to: out_int = lut[in_int];  and either iterated three times per pixel. Also hashed tables may be used for more complicated 3D LUTs for greater efficiency. Even if a parametric curve is being used to define a transformation, software that needs speed such as for streaming is typically reducing it to a LUT at run time at the very least..... Myndex (talk) 20:25, 4 November 2021 (UTC)
replies: text: Photoshop uses para if the ICC profile is para. sRGB profile on windows is (as mentioned in this very ARTICLE) is TRC of 1024 1DLUT, not para, since it is v2 ICC profile para is not supported in v2. I think user above was even trying to insinuate that it 1024 1DLUT does not have a linear spline (and that Photoshop is just that dumb to use pure gamma to encode (that will cause bad artificats) and present). That is false of course, it has linear spline if you will visualise the 1DLUT. 109.252.90.119 (talk) 23:59, 4 November 2021 (UTC)
replies: text:  Valery, commenting anonymously from Moscow doesn't help, FYI. Unless you work for Adobe, you don't have access to the source code, therefore you do not know how Photoshop or the Adobe CMM processes any profile. As far as the curves go, I am not insinuating anything. Also, Adobe ships (or did) profiles with a simple gamma curve and refers to those as "Simple sRGB", it's even in their documentation, and I've written a few articles about this, and the IEC specification even states not only the intent of a 2.2 pure gamma, but the functional use of a 2.2 pure gamma (EOTF). This is defined in multiple places in the actual IEC 61966-2-1 standard that says the reference display characteristics (in other words the EOTF) is a simple power curve of 2.2 and does not call it a transfer function (except in one tangential spot) typically calling it the "display output characteristic." And your assertion of "bad artifacts" is utter hogwash.  Myndex (talk) 01:17, 5 November 2021 (UTC)
replies: text: Not using linear spline for encoding (OETF) from linear data will mean some blacks when quantised will be indiscernable and some blacks will be absent. In the EOTF sense the display should use linear spline too, but it will not cause such effect as OETF. I will assure you that chrome and others default to sRGB with actual linear spline NOT to 2.2 pure gamma. Indeed PNG with gAMA chunk of 2.2 will be converted to sRGB with linear spline (there is a bug about it on wikimedia phabricator, read it: https://phabricator.wikimedia.org/T26768). So monitors' 2.2 gAMA is supposed to be having a linear spline like in sRGB, in many cases they do not, alas. P.S. What your comment about me living in Moscow has anything to do with anything? Also, I will remind you that it is against the rules of Wikipedia to attack IP logins of registered users, except for double voting in RfC, see WP:WAE. 109.252.90.119 (talk) 02:24, 5 November 2021 (UTC)

text:  My understanding is that internally Photoshop used to do 1:1 lookup tables for everything (originally all images were 8 bit/channel, so these tables were small). Later when they added higher bit depths, they switched to constructing a highish resolution (12 bits maybe?) lookup table and then linearly interpolating for values between. Including for e.g. the "curves" tool which would otherwise be cubic polynomials. I didn’t ever see the code, and things may also have changed in recent times. On recent CPUs math is now so outrageously cheap compared to moving data around that it often might as well be free. –jacobolus (t) 04:34, 5 November 2021 (UTC)
replies: text:   yes cycles are cheap, and probably less relevant for Photoshop — but data still has to be moved and for streaming media types where you might be adding multiple effects, composites, transforms, etc., processing efficiency is still important as it impacts the limits of real-time playback..  Myndex (talk) 18:16, 5 November 2021 (UTC)
replies: text: Photoshop does not even support 16 bit (which is how png stores images >8 bit, always), it has 15 bit max mode, GIMP is good there. BTW, did you even read the FlashPix spec? It is like you did not even try to open it. Again, that is where the TRC/EOTF came from. The primaries came from the CCIR doc above, I was not able to find it. 2A00:1FA0:4664:8ED4:CC39:8CA2:453B:D575 (talk) 20:58, 7 November 2021 (UTC)
replies: text: The things you are trying to put in and the things you are saying here are NOT RELEVANT, and your attempts to recite history from memory are notwithstanding. For instance, you can't find CCIR because they became the ITU. And again, not relevant. I did read the flash pix and it is not relevant. The fact Photoshop does 15 bit and not 16 internally is also not relevant here. Myndex (talk) 08:19, 9 November 2021 (UTC)
replies: text: It did not become ITU, but ITU-R. It was CCIR that created original primaries for HDTV, not ITU. The fact that UN got control of IP of CCI(R) has nothing to do with anything. And of course it is very relevant for this article, CCIR specification is mentioned in Preamble, but it further links to internal secret documents in ITU-R archives and also to article "Influence of display primaries on the colorimetric characteristics of colour television", that is by Australian broadcasting corporation, report No 136 by B. Powell. There is again no PDF available of this. It is very important to know how HD primaries were derived from SMPTE C. There is only one mention of it in google, in https://search.itu.int/history/HistoryDigitalCollectionDocLibrary/4.282.43.en.1014.pdf Valery Zapolodov (talk) 08:32, 9 November 2021 (UTC)
replies: text:   – these cannot be relied on by Wikipedia articles. Maybe someone involved wrote a retrospective book or journal article or something, explaining the details in public? –jacobolus (t) 23:23, 9 November 2021 (UTC)

text:  The FlashPix spec is not a reliable source for any claim about it made here. It doesn’t mention sRGB, nor does it describe its history/context. Trying to draw inferences based on this as evidence counts as “original research” as far as Wikipedia is concerned. If you want to add a discussion of the relevance of FlashPix to sRGB, then you need to find a better source which describes the relationship explicitly. –jacobolus (t) 23:21, 9 November 2021 (UTC)
replies: text: Code is a RS usually. Either in Windows or ImageMagick... As for other RS, fulltext search through libgen and sci does not show anything relevant, just as I cannot find anything on ABC white paper. P.S. "secret" does not mean it is classified or whatever, just someone would have to scan ITU archives, I suppose. Oh, also NIF RGB is sRGB from the draft, so... 2A00:1370:812D:B532:18D8:2751:E851:1F56 (talk) 09:17, 10 November 2021 (UTC)
thread_title:  Edit War over irellevant information 

message: The article should be more clear / explicit as to what it means to have two different whites. The discussions above help, but we shouldn't have to come to the talk page for this.  — Preceding unsigned comment added by 92.67.227.181 (talk) 06:43, 11 June 2022 (UTC)
replies: text: You mean encoding white? 2A00:1370:8184:6AD9:D044:40FD:8073:258E (talk) 06:36, 11 September 2022 (UTC)
thread_title:  The two whites 

message: I don't think the re-written version is helpful, the previous version seemed more clear to me at least, though this may be it was what I was more used to reading.  The new version, and the use of uppercase  seems less clear to me. Myndex talk   04:23, 3 July 2022 (UTC)
replies: text: This whole thing is quite not verifiable since the source is not available in public or on libgen. I mean it sounds logical and BT.2020 says the same thing about this, solving a pair of equestions...  I mean "Colour Engineering: Achieving Device Independent Colour"  Valery Zapolodov (talk) 01:59, 29 September 2022 (UTC)

text: Meanwhile these authors already wrote a new book! And I still do not know where to find the book Colour Engineering. https://www.wiley.com/en-ie/Fundamentals+and+Applications+of+Colour+Engineering-p-9781119827184 Valery Zapolodov (talk) 15:01, 9 August 2023 (UTC)
thread_title:  "Computing the transfer function"