Talk:sRGB

Neutrality

The debate over sRGB, Adobe RGB and goodness knows what seems to be rather spread out and would benefit from being integrated and tidied up, with a stronger dose of neutrality. This article is still, I think, not neutral (the idea that you can assume sRGB is a little strong, even though I've written software in which that is the default). Notinasnaid 13:16, 31 Aug 2004 (UTC)

You can and should assume sRGB. It's nice to provide an out-of-the-way option for a linear color space that uses the sRGB primaries, and of course anything professional would have to support full ICC profiles. Normal image processing has been greatly simplified by sRGB. The only trouble is that lots of software simultaneously assumes that the data is sRGB (for loading, displaying, and saving) and linear (for painting, scaling, rotation, masking, alpha blending...). This is just buggy though; it wouldn't have been correct prior to the sRGB standard either. 65.34.186.143 17:30, 25 May 2005 (UTC)

A statement like "You can and should assume sRGB" is obviously not neutral. It is telling people what to do, which is not the business of Wikipedia. The article shouldn't say things like that. At the moment, it still does. —Pawnbroker (talk) 03:41, 11 September 2008 (UTC)

??? I don't see anything like that in the article. Dicklyon (talk) 04:40, 11 September 2008 (UTC)

How about this quote from the article: "sRGB should be used for editing and saving all images intended for publication to the WWW"? To me that seems about the same as saying "You can and should assume sRGB". Also there are various unsourced statements in the article about sRGB being used by virtually everything and everyone, and a vague sentence about the standard being "endorsed" by various organizations. The concept of endorsement is not at all clear. For example, does endorsement just mean that an organization has permitted sRGB to be one of the various color spaces that is allowed be indicated as being used in some application, or does it mean that the organization has declared sRGB to be the most wonderful color space ever and said that everyone should use it exclusively? —Pawnbroker (talk) 17:05, 11 September 2008 (UTC)

You can and should assume sRGB. That is entirely correct buddy, as the vast majority of devices on the market use sRGB as default or only color space. sRGB should be used for editing and saving all images intended for publication to the WWW. That is also correct in the sense that you should use english to communicate with as many people as possible. Femmina (talk) 03:41, 6 October 2008 (UTC)

Note: Most people do not speak English [citation needed] ;-) Moreover, at least 80% of people I usually talk with would not understand me if I spoke English...

Therefore I should consider speaking language of those who I want to understand me, not English... Eltwarg (talk) 21:28, 30 November 2011 (UTC)

The article "A Standard Default Color Space for the Internet - sRGB" is normative in the HTML4 specification, thus, all standard conforming web browsers should assume images are sRGB if they do not contain a color profile. CSS can also contain the "rendering-intent" for conversion from image color space to display color space, which by default is "perceptual". This does not mean we should use sRGB on the web, it only means that if we use another profile, it must be embedded in the images. --FRBoy (talk) 05:38, 1 December 2011 (UTC)

Limitations of sRGB

The article says that sRGB is limited, but it doesn't go into detail as to why. I am used to RGB being expressed as a cube with maximum brightness of each element converging at one corner of the cube, producing white. Since white is usually expressed as the combination of all colors, it isn't hard to come to the conclusion that RGB should be able to produce all colors, limited of course by the color resolution, i.e. 4 bits per primary, 8 bits per primary, etc.

The range of colors you can get from a given color space is called its gamut. All RGB colors can be thought of as having a cube, but the cubes are different sizes. Even if you want to think of them as sharing the white corner, that is (but white is not universal! - see white point). So some RGB spaces cannot express colors that are in other cubes. Hope that makes sense; now, as the article says sRGB is frequently criticised by publishing professionals because of its narrow color gamut, which means that some colors that are visible, even some colors that can be reproduced in CMYK cannot be represented by sRGB. Notinasnaid 14:47, 29 October 2005 (UTC)

The problem I seem to be having is that the article doesn't make it clear that the issue isn't the divvying up of the space encompassed by sRGB, but the position and/or number of the three bounding points Hackwrench 17:33, 30 October 2005 (UTC)

It probably could be clearer, but first make sure you read the article on gamut which is crucial to the discussion, and rather too large a subject to repeat in this article. Now, with that knowledge, how can we improve the article beyond just saying its narrow color gamut? Notinasnaid 08:24, 31 October 2005 (UTC)

This text about a limitation is rather odd: designed to match the behavior of the PC equipment commonly in use when the standard was created in 1996. The physics of a CRT have not changed in the interim, and the phosphor chromaticities are those of a standard broadcast monitor, so this off notion of "limited PC equipment" - which seems to crop up all over the Web, often in PC vs. mac discussions - is just incorrect.

On the other hand, the limited color gamut should be better explained - both as a weakness (significant numbers of cannot be represented) and a strength (the narrower gamut assures less banding in commonly occuring colors, when only 8 bits per component are used). --Nantonos 17:16, 20 February 2007 (UTC)

The gamut limitation essentially means that for some images you have a choice of either a) clipping, removing saturation information for very saturated colours or b) making the entire image greyer. This is not a big issue in practice however, because on the one hand our visual system has the tendency to ‘correct’ itself and if the entire image is greyer you stop noticing and on the other hand most real world images fit well enough in the gamut. Photos look a lot better on my LCD screen than in high-quality print. — Preceding unsigned comment added by 82.139.81.0 (talk) 21:50, 23 March 2012 (UTC)

Years and years ago, I remember much of the wrangling that went into the formation sRGB, and among the chief complaints from the high-end color scientists at the time was that sRGB was zero-relative. Even though there are conversion layers that are placed above sRGB, it is still the case that having sRGB able to "float" somewhat would have allowed a great deal of problem solving flexibility with only a minor loss in data efficiency. When I hear most of the complaint arguments around sRGB, I hear the many conversations I've had in the past with such scientists and engineers that predicted many of them.Tgm1024 (talk) 15:50, 25 May 2016 (UTC)

Camera Calibration

This article needs a rational discussion of the problem with RELYING on sRGB as if it proves anything about the content of an image -- it doesn't. It's merely a labelling convention -- and what's more, it doesn't even speak to whether or not the LCD on the camera produced a like response. You can manufacture a camera that labels your image 'sRGB' and yet the LCD is displaying it totally differently, and the label isn't even a lie. A consumer camera labelling an image 'sRGB' is no guarantee that you are actually looking at the images in this colourspace on the camera itself! This causes much, much MUCH confusion when people do not get the results they expect. I don't want it to become a polemic against the standard or anything, but putting an sRGB tag on an image file is not a requirement to change anything whatsoever about how the LCD reads. Calibrating an image from an uncalibrated camera is useless, and most consumer cameras are just that, labelled sRGB or not. This is kind of viewpoint stuff, and I don't really want to inject it into the article, but there is a logical hole into which all this falls, and that hole is: Labelling something in a certain manner does not necessarily make it so. This is the problem with sRGB, but people don't understand this because they think of sRGB as changing the CONTENTS of the file, not just affixing the label. So they think that their cameras are calibrated to show them this colourspace, but they aren't nor are they required to. This basic hole in the system by which we are "standardising" our photographs should be pointed out. I have made an edit to do that in as simple and neutral manner as I could think of. The language I came up with is this (some of this wording is not mine but what inherited from the paragraph I modified): "Due to the use of sRGB on the Internet, many low- to medium-end consumer digital cameras and scanners use sRGB as the default (or only available) working color space and, used in conjunction with an inkjet printer, produces what is often regarded as satisfactory for home use, most of the time. [Most of the time is a very important clause.] However, consumer level camera LCDs are typically uncalibrated, meaning that even though your image is being labelled as sRGB, one can't conclude that this is exactly what we are seeing on the built-in LCD. A manufacturer might simply affix the label sRGB to whatever their camera produces merely by convention because this is what all cameras are supposed to do. In this case, the sRGB label would be meaningless and would not be helpful in achieving colour parity with any other device."--67.70.37.75 01:39, 2 March 2007 (UTC)

I'm not so sure the article needs to go into this, but if so it should say only things that are verifiable, not just your reaction to the fact that not all sRGB devices are well calibrated. The fact that an image is in sRGB space is a spec for how the colors should be interpreted, and no more than that; certainly it's not guarantee of color accuracy, color correction, color balance, or color preference. Why do think people think what you're saying? Have a source? Dicklyon 02:04, 2 March 2007 (UTC)

I'm afraid your understanding of the issue (no offence) is a perfect example of what's wrong with the way people understand sRGB as it relates to cameras. It's not that some devices' LCDs are not "well calibrated". It's that most all digital camera LCDs are UNcalibrated. It's not usual practice. They don't even try. And this is also true of most high end professional cameras, such as the Canon's 30D and Nikon's D70. I only say 'most' because I can't make blanket statements. But I have never actually encountered a digital camera that even claims a calibrated LCD, and I've used and evaluated a lot of them. As far as I know, a "color accurate" camera LCD doesn't exist (except maybe by accident, and not because of any engineering effort whatsoever). But of course Canon and Nikon don't advertise in their materials that they make no attempt to calibrate what you're shown on the camera itself (and that as a result, the sRGB tag is really not of any use to people who take pictures with their cameras). However, this is common knowledge among photography professionals. Obviously 'common knowlege' is not a citable source, but you wouldn't want a wiki article to contradict it without a citable source, right?! I have looked around for something with enough authority, but I couldn't find it. This isn't really discussed in official channels, probably because it's embarrassing to the whole industry, really. But I did find some links to photographers and photography buffs discussing the situation. The scuttlebutt is universal and accords with my experience: no calibration on any camera LCDs, to sRGB or to anything else. Even on $2000 cameras...

From different users with different cameras @ [1]: "I know my D1H calibration is not WSYWIG. I get what I see in my PC ... not on the camera's screen"; (re the EOS 10D) "No, not calibrated and not even particularly accurate"; "No [they] are not, the EOS 10D lcd doesn't display colors correctly thats why many use the histogram".

From [2]: "The only way to be sure is to actually take the shots, process them all consistently, and look at the luminance. Best case would be to shoot a standard target, so you could look at the same color or shade each time. Otherwise, you are guessing about part of your camera that is not calibrated, or intended to use to judge precise exposure."

From [3]: "users should be aware that the view on the LCD is not calibrated to match the recorded file".

On the Minolta Dimage 5 from [4]: "The LCD monitor is also inaccurate in its ability to render colors."

From [5]: "I realize the LCD is not accurate for exposure, so I move to the histogram." (And of course, the histogram is pretty useless for judging things like gamma, so it's no substitute for a viewfinder-accurate colourspace.)

You hear that last kind of offhand remark all the time on photography forums. Camera LCDs aren't calibrated. They all know it. I rest my case with the realisation that my evidence is anecdotal, but to conclude that argument with a "pretend absence of evidence is evidence of absence" argument: you will not find through Google or through any other search engine any product brochure or advertisement that claims any digital camera has a calibrated LCD. There are no LCD accuracy braggarts -- and there should be, if camera LCD calibration existed. Anyway, I'm happy with the modest statement as it now stands in the article just making the distinction between just having an sRGB colourspace tag affixed to an image, and actually knowing that the image has been composed in the sRGB colourspace, because they are two different things.--65.93.92.146 11:00, 4 March 2007 (UTC)

I just noticed the new language. It's better than mine, more succinct and more precise, too. Good job.--65.93.92.146 11:17, 4 March 2007 (UTC)

Thanks. The point is that not being able to trust the LCD is not an sRGB issue, and doesn't make the sRGB irrelevant, so I pruned back your text to what's true. Dicklyon 15:53, 4 March 2007 (UTC)

Whether or not the camera manufacturers do a good job of producing sRGB is not relevant to the discussion of sRGB itself. A camera manufacturer could also do a bad job of producing Adobe Wide Gamut yet label their output as that, and that is not Adobe Wide Gamut's fault. And the fact is that whether they do it on purpose or accident, the output of the camera *approaches* sRGB, since they want it to look "correct" when displayed on users computer screens and printed on the user's printers. sRGB defines this target much better than a subjective analysis of a screen display and thus serves a very important purpose, whether or not it is handled accurately. Spitzak 16:59, 18 April 2007 (UTC)

easy way to do wide gamut stuff

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)

That seems roughly like a description of scRGB. Cat5nap (talk) 21:18, 23 October 2021 (UTC)

gamma = 2.4?

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)

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)

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)

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).

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)

Gamma & TRC

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)

or needs to be scaled ....

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)

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

Formulæ

I can't see how the matrix formulæ can be correct with X, Y, Z. Suppose I choose X = 70.05, Y = 68.79, Z = 7.78 (experimental values to hand for a yellow sample), then there is no way the matrix will generate $C_{\mathrm {linear} }$ values in the range [0, 1]. Sorry if there is something obvious I'm overlooking, but surely the RHS needs to be x, y, and z??? —DIV (128.250.204.118 06:49, 30 July 2007 (UTC)) Amended symbols. 128.250.204.118 01:14, 31 July 2007 (UTC)

The RGB and XYZ ranges should be about the same (both in 0 to 1, or both in 0 to 100, or both in 0 to 255 or whatever). Of course, the RGB values won't always stay in range. The triples that are out of range are out of gamut. Dicklyon 14:39, 30 July 2007 (UTC)

I see what you're saying, but it is not what the article currently says. If you have a look, you will see that the first formula uses X, Y and Z, and immediately below is a 'conversion' to (back-)compute these parameters if you start off with x, y and Y. To me there is only one way of reading this which is that the first formula uses the tristimulus values (X, Y and Z), and not chromaticity co-ordinates (x, y and z) — where the present naming follows the CIE. And, indeed, this is what the article currently says. Yet the article further states just below this that:

"The intermediate parameters $R_{\mathrm {linear} }$, $G_{\mathrm {linear} }$ and $B_{\mathrm {linear} }$ for in-gamut colors are in the range [0,1]",

and at the end of that sub-section that

the "gamma corrected values" obtained by using the formulæ as stated "are in the range 0 to 1".

Chromaticity co-ordinates obviously have a defined range due to the identity $x+y+z=1$. There is no equivalent for the tristimulus values.

A further disquiet I have concerns the implication that the domains scale 'nicely', considering that $x=y=z=1$ is not allowed, whereas $r=g=b=1$ is allowed.***

Dicklyon, your answer sounds like it supports my initial finding. At present, then, the article is incorrect and misleading. If what you say is correct, then the article text and formulæ should be amended to suit. If the matrix formula is supposed to be generic, then you'd be better off writing the two vectors as simply C and S, and then say that when C is such-and-such, S is this, and when C is such-and-such other, then S is that, ....(et cetera)

—DIV (128.250.204.118 01:36, 31 July 2007 (UTC))

***At least, the article implies it's allowed. In contrast, CIE RGB doesn't allow it; explained nicely at the CIE 1931 article. —DIV (128.250.204.118 01:52, 31 July 2007 (UTC))

I added a note to indicate the XYZ scale that is compatible with the rest. The XYZ value example for D65 white is already consistent with the rest. You are right that you can't have x=y=z=1 but can have r=g=b=1 (that's called white). Dicklyon 02:48, 31 July 2007 (UTC)

Why the move from "sRGB color space" to "sRGB"?

What's the benefit? Why was this done with no discussion? Why was it marked a "minor edit"? --jacobolus (t) 00:47, 28 July 2007 (UTC)

Agree, this is inconsistent with the other articles. On the plus side, it avoids conflict over the use of "colour" versus "color" ;-)p

—DIV (128.250.204.118 05:47, 30 July 2007 (UTC))

Discrepancy between sources

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 C_linear ≤ 0.00304, while the IEC 61966 source specifies the linear cutoff as C_linear ≤ 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)

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)

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)

Good work! Please feel free to add that explanation to the article. --jacobolus (t) 19:50, 16 September 2007 (UTC)

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)

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)

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)

I have both the 4th working draft IEC/4WD 61966-2-1 (which is currently available on the web) and the final IEC 61966-2-1:1999 document in front of me. These two sources agree on the numerical values of the transformation and with what is currently (after my edit of 8/22/10) on the wikipedia page in the "Specificaiton of the transformation" section. (The draft version does neglect to mention that when converting numbers in range [0-1] to digital values, one needs to round. This is explicit in the final version.) As described under the "Theory of the transformation" section, the value of K0 in 61966-2-1:1999 differs from value given in ref [2]. In addition, the forward matrix in [2] differs slightly from that in 61966-2-1:1999. The reverse matrix is the same in [2] and 61966-2-1:1999. I don't know what the origin of the difference in the forward matrix values is. I did verify that if one takes the reverse matrix to the four decimal places specified and inverts it (using the inv() function in Matlab) and round to four places, you get the forward matrix in 61966-2-1:1999. It is possible (but pure speculation on my part) that the forward matrix in [2] was obtained by inverting a reverse matrix given to higher precision than published. DavidBrainard (talk) 02:30, 24 August 2010 (UTC)

Following a suggestion by Jacobolus, I computed the reverse transformation from the primary and white point specifications. This matches (to four places) what is in all of the documents. If you invert this matrix without rounding, you get (to four places) the forward transformation matrix of reference 2 (of the sRGB page, it's Stokes et al., 1996) to four places. If instead you round to four places and invert, you get (to four places) the forward transformation matrix of 61966-2-1:1999. So, that is surely the source of the discrepancy in the forward matrix between the two sources. DavidBrainard (talk) 13:49, 24 August 2010 (UTC)

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)

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)

Effective gamma

Plot of the sRGB intensities versus sRGB numerical values (red), and this function's slope in log-log space (blue) which is the effective gamma at each point

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)

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)

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)

Formulae help

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)

Multiplying the reverse transformation matrix times the above, I get (0.6562,0.6029,0.5274). PAR (talk) 15:26, 21 February 2008 (UTC)

Oops. I was using the forward transformation matrix instead of the reverse. SharkD (talk) 21:05, 21 February 2008 (UTC)

sRGB colors approximating monochromatic colors

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) and 85.179.4.11 (talk) 14:02, 1 July 2008 (UTC)

Use areas

The very first sentence of the articles is completely ludicrous. I am of course talking about the use of sRGB "on the Internet". Should sRGB also be used on LANs and maybe even RS-232 connections? --84.250.188.136 (talk) 23:59, 14 August 2008 (UTC)

Sort of ludricous, nevertheless, more meaningful than it might appear, since it refers to both WWW (html page images) and email (image attachment) usage; yes, it would apply to LAN and other inter-computer connections as well. The point is, it's the most common standard for interchanging pictures over networks. Is there a better way to put it? Dicklyon (talk) 00:20, 15 August 2008 (UTC)

To call sRGB a standard for internet is similar to calling it a standard for compact discs and USB sticks. I believe the "LAN" example by the anonymous guy was just a try to provide some even more funny example of the same kind of mistake.

I believe color space is here to define transfromation between what is stored as digital data and what is to be shown in reality (printed or rendered on my screen) or what is to be grabbed from reality (camera, scanner).

Thus mentioning sRGB is a standard for Internet seems absurd and can be seen as an appeal to use sRGB wherever possible because it most probably will "appear" "on internet" at least for several minutes (:-D)

Following your reasoning by "interchange", saying sRGB is a standard for image files would be more correct here (if it is true).

But I am getting e-mails with image attachments that are not in sRGB intentionally and the true reason is just the perfect color information interchange (using calibrated devices in apparel industry).

Also, on Wikipedia (encyklopedia) we should try to distinguish between words like: Internet, WWW, Email, FTP and today also FB, because some younger guys believe Internet IS FaceBook... could be some believe Internet IS Wikipedia :-D)

I definitely think this needs an update including explanation what is meant by word "internet" and why. Otherwise I am going to remove all occurences of word "internet" from the article.

Eltwarg (talk) 22:24, 30 November 2011 (UTC)

Before you get too excited, take a look at the title of the 1996 paper that introduced sRGB (ref. 2 by Stokes). Maybe even read it to see where this is coming from. Dicklyon (talk) 00:55, 1 December 2011 (UTC)

sRGB in GIMP ?

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)

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)

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)

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)

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)

NPOV

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)

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)

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)

Timeline

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)

Plot of the sRGB

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)

Diagram broken?

Is the image at the top (the CIE horseshoe) broken for anybody else, or just me?

It's not "broken" for me, but it's not a very good diagram: its color scheme, text sizes/positions, and line widths make it virtually unreadable, and much of it is dramatically harder to interpret than necessary. Additionally, the coloring inside the horseshoe isn’t my favorite, though this is a problem with no perfect solutions. Finally, it should really use the 1976 (u', v') chromaticity diagram, rather than the 1931 (x, y) diagram. I started working on some better versions of these diagrams at some point, but got distracted. As an immediate step I’d support reverting to some earlier version with readable labels. –jacobolus (t) 01:36, 18 February 2011 (UTC)

For me I am getting a tiny gray rectangle in the page, about the size of the letter 'I'. reloading the image, clearing the Firefox cache do not seem to fix it. Clicking on the gray rectangle leads me to the page showing the full-size image.Spitzak (talk) 02:21, 18 February 2011 (UTC)

There are some other suggestions at Wikipedia:Bypass your cache –jacobolus (t) 02:31, 18 February 2011 (UTC)

Ctrl+Shift+R fixed it, thanks. It was a local problem as I thought...

Still problems with the matrix

The matrix seems still to be either wrong or incompletely documented. Is far as I understand the XYZ vectors corresponding to each R,G,B point must yield R = 1 for the R-point etc. In other words, if the XYZ values for the red point, (0.64, 0.33, 0.03) are applied, then from the multiplication rules of matrices with vectors, it must be for red: 3.2406*0.64-1.5372*0.33-0.4986*0.03=1 (first row for the red value) and correspondingly 0 for the others. But actually the matrix yields R = (1.551940,0.000040,-0.000026). While the small non-zero values may be due to rounded values given in the matrix, the 1.55 times too high red value must be due to some systematic error. The other points G, B have values below 1, so no constant-value adjustment will do Could someone please fix this or, if this mis-scaling is a feature rather than a bug, explain this in detail?--SiriusB (talk) 20:18, 4 September 2011 (UTC)

I think you’re misunderstanding what chromaticity coordinates mean (they aren’t a transformation matrix, for one thing). The numbers and text in this article are fine. –jacobolus (t) 01:06, 5 September 2011 (UTC)

He misunderstands, but his calculations demonstrate that the matrix does the right thing. It maps the xyz of R to a pure red in RGB, etc., to within a part in 10000 or so. The factors like 1.5 are not relevant, since he started with chromaticities (not XYZ), which lack an intensity factor. The real test is to see if the white point in xyz maps to equal values of r, g, and b. Dicklyon (talk) 01:27, 5 September 2011 (UTC)

Then there is a step missing between the matrix calculation and the gamma correction: The values have to be rescaled into the interval [0:1] since this is assumed by the gamma formulae.--SiriusB (talk) 06:59, 5 September 2011 (UTC)

No, you’re still misunderstanding. The chromaticity coordinates tell you where in a chromaticity diagram the three primaries R, G, and B are for a particular RGB color space, but without also knowing the white point they don’t give you enough information to fully transform RGB values to XYZ, because chromaticity coordinates don’t say anything about what the intensity of a light source is (i.e. what Y value to use). For that you should use the transformation matrix in sRGB#The forward transformation (CIE xyY or CIE XYZ to sRGB). –jacobolus (t) 08:26, 5 September 2011 (UTC)

No, you are still misunderstanding me: Using exact this matrix for the given chromaticity values yields R>1. So, *before* proceeding to the next step *after* using the matrix, namely the gamma correction, one has to rescale these values to make sure that they are in range. Note that the gamma formula assumes that all values are within 0 and 1. If not, please clarify this in the article.--SiriusB (talk) 08:34, 5 September 2011 (UTC)

What? If you have measured X, Y, and Z (where you have scaled Y such that a value of 1 is the white point, or sometimes in the case of object colors, is a perfectly diffusing reflector), then when you apply the transformation matrix provided, you’ll get just correct values for (linear) R, G, and B. These can then have a gamma curve applied. If you’re still talking about trying to draw a color temperature diagram, however: Given any chromaticity coordinates (x, y) you can pick any value for Y you like, which means when you convert from xyY to XYZ space, you have free reign to scale the resulting X, Y, and Z by any constant you like without changing chromaticity. –jacobolus (t) 18:25, 5 September 2011 (UTC)

Right, what J said. There will always be X,Y,Z triples that map outside the range [0...1], so some form of clipping is needed. If you interpret an x,y,z as an X,Y,Z, you get such a point in the case of the red chromaticity, but not for the green and blue; it means nothing, since x,y,z is not X,Y,Z. If you want to know what X,Y,Z corresponds to an R,G,B, use the inverse matrix; that will restore the intensity that's missing from chromaticity. Dicklyon (talk) 18:37, 5 September 2011 (UTC)

So far thanks for the replies so far. One additional note: at wrong link Bruce Lindblom's page I have found matrices which may be even more accurate than the ones given in the article. I have tested the ones for sRGB and found that they are accurate in the first six digits, meaning that the zero-coefficients in each direction (xyz to RGB and vice versa) differ from zero no more than 3⋅10^-7. However, as far as I understood the earlier discussions on this the present coefficients are considered "official" (since they were derived from some draft of the official standard) while Lindblom's might be from his original research. Any opinions on that?--SiriusB (talk) 19:16, 6 September 2011 (UTC)

Maybe you intended this link? –jacobolus (t) 19:54, 6 September 2011 (UTC)

Yes, sorry, had the wrong (sub)link in the clipboard. The illuminant subpage is already linked to from Standard illuminant--SiriusB (talk) 09:13, 7 September 2011

Dynamic range

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/m² and 1 cd/m², and thus the dynamic range would be 80:1. --FRBoy (talk) 06:01, 1 December 2011 (UTC)

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)

Enumerating sRGB gamut

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)

Looking at the user feedback for this article, I could also easily generate a 3D representation of the sRGB solid in CIELAB. Dennis at Empa Media (talk) 14:22, 1 October 2012 (UTC)

Why did you plot it in terms of x/y? –jacobolus (t) 18:53, 1 October 2012 (UTC)

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)

Acronym

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)

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)

Color mixing and complementary

If the standard defines a non-linear power response with γ ≈ 2.2, then does it mean that three complementary pairs of the form (0xFF, 0x7F, 0) ↔ (0, 0x7F, 0xFF) in whatever order are blatantly unphysical? Namely, these are:

1. orange ↔ azure
2. lime chartreuse green ↔ violet
3. spring green ↔ rose

Incnis Mrsi (talk) 04:56, 18 June 2013 (UTC)

That is correct. Well, maybe not "blatantly", but it's not right. If you want orange and azure to add up to white you need to use (0xFF, 0xBA, 0) and (0, 0xBA, 0xFF), since (186/255)^2.2 = 0.5. The use of 0x7F or 0x80 for half brightness is a common misconception. You can test this by making color stripes or checkboards of the two colors and looking at from far enough back that you don't resolve the colors. Dicklyon (talk) 05:12, 18 June 2013 (UTC)

So, what we have to do with aforementioned six colors? There are two solutions:

• State that “true” orange, lime, spring green, azure, violet, and rose lie on half brightness, but incompetent coders spoiled their sRGB values;
• Search for definitions independent from (s)RGB and compare chromaticities.

Incnis Mrsi (talk) 05:41, 18 June 2013 (UTC)

There’s no such thing as “true orange”, “true lime”, “true spring green”, etc. The names are arbitrary, and every system of color names is going to attach them to slightly different colors. Though with that said, the X11 / Web color names were chosen extremely poorly, and the colors picked for each name are typically very far from the colors a painter or fashion designer or interior decorator (or a layman) would attach to that name. The biggest problem here is that they tried to choose colors systematically to align with “nice” RGB values, but the colors at the various corners and edges of the sRGB gamut don’t have any special relation to color names in wide use. –jacobolus (t) 07:02, 19 June 2013 (UTC)

Thanks for your reply. I actually expected something like this except for the wide use qualifier. Wide use by whom do you mean? Painters, fashion designers, interior decorators… I would also add printers and pre-press, are they actually so wide? Incnis Mrsi (talk) 16:27, 19 June 2013 (UTC)

I just mean, if you want to name some specific pre-chosen color on your RGB display, it’s likely no one has a name that precisely matches that color. So if you just arbitrarily pick a name sometimes used for similar colors, then at the end you get a big collection of (name, color) pairs that don’t match anyone’s idea of what those names should represent. –jacobolus (t) 23:32, 19 June 2013 (UTC)

Does red of Microsoft become orange in a spectroscope?

The illustration, commons:File:Cie Chart with sRGB gamut by spigget.png, 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)

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)

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)

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)

“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)

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)

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)

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)

Multiply and divide by 255: quick and dirty?

The other day I made what seemed like a minor correction to the section entitled Specification of the transformation. The text said, "If values in the range 0 to 255 are required, e.g. for video display or 8-bit graphics, the usual technique is to multiply by 255 and round to an integer." I changed it to "multiply by 256." Shortly thereafter the edit got reverted, apparently by a Silicon-Valley engineer who has contributed a great deal to Wikipedia articles on computer graphics.

Looking back on it, I can see that my edit wasn't quite correct. It should be been "multiply by 256 and subtract 1." I also forgot to correct the other problem sentence nearby, "(A range of 0 to 255 can simply be divided by 255)" That should be something like "add one, then divide by 256."

This is analogous to the problems one encounters when working with ordinal numbers, when things need to be scooted over by one before multiplying or dividing, then scooted back again.

The method described here is probably close enough that no one would ever notice the difference. I'm reminded of conversations I've had over the years with German engineers who are so particular about doing things correctly. Then they go nuts when they run into an engineer from another country who uses a "quick and dirty" method that's way easier and works every time. Zyxwv99 (talk) 17:20, 22 July 2013 (UTC)

Your edit was obviously not correct, as the nearest integer to 1 × 256 is, surprisingly, 256 (i.e. out of range). So it would be for any input from (⁠511/512⁠,1]. As an alternative we can multiply by 256 and then apply the floor function instead of rounding, but disadvantage of this composition is that it works only on [0,1) and fails when input is exactly equals to 1. Why do not leave Dicklyon’s version in place, indeed? Incnis Mrsi (talk) 17:56, 22 July 2013 (UTC)

The standard approach (universally considered the most "correct", though it's not perfect) is to map the range of floats [0, 1] onto the range [0, 255] and then round to the nearest integer. Multiplying by 256 and subtracting 1 would take 0 to -1, so you'd need to round it up, and you wouldn't have any distinction between 0/256 and 1/256.

To reverse this operation, we just divide by 255.

Note that this sort of thing is the reason that Adobe Photoshop's "16-bit" mode uses the range [0, 32768] instead of [0, 65535]. They then have a precise midpoint, and can do some operations using simple bit shifting instead of multiplication/division. –jacobolus (t) 19:49, 22 July 2013 (UTC)

I believe Zyxwv99 is confused by the conversion of 16 bits to 8, which indeed is better to shift right by 8 and (equivalent to divide by 256 and floor). This is because each of the 256 results has 256 numbers in it. The seemingly more accurate "multiply by 255.0/65535 and round" will not evenly space the values (0 and 255 have about 1/2 the values mapping to them) and this causes errors later on. However this does not apply to floating point, where the correct conversion is "multiply by 255 and round". It is true there are tricks that you can do in IEEE floating point to produce the same result as this using bit-shifts and masking but it is still the same result and such tricks are probably outside this page's scope.Spitzak (talk) 20:28, 22 July 2013 (UTC)

Converting from 16 bits to 8 is a bit tricky, and there's not an obvious “right” way to do it (just making even-width intervals compress down to each points creates problems too, at the ends), with different programs choosing to handle it in different ways. But yeah, the thing to do in floating point is relatively uncontroversial. –jacobolus (t) 05:16, 23 July 2013 (UTC)

The edit I reverted is the opposite of what you're discussing: [6]. But wrong for a similar reason: dividing the max value 255 by 256 would not give you a max of 1.0, which is usually what you want. Dicklyon (talk) 05:53, 23 July 2013 (UTC)

Thanks. I get it now. Zyxwv99 (talk) 15:00, 23 July 2013 (UTC)

Other colour spaces than CIE 1931

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)

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)

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)

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)

@Incnis Mrsi: Yes, I am (almost) sure that the SPD is required since the color-matching functions (CMFs) do differ themselves. The simplest attempt would be to reproduce the primary chromaticities by mixing monochromatic signals with equal-energy white. This is essentially what you get if you interpolate the shifts between monochromatic signals (the border curve of the color wedge) and the whitepoint in use (for E it would be zero since E is always defined as x,y = 1/3,1/3). This can be done with quite loq computational effort. However, the more realistic way would be to fit Gaussian peaks to match the CIE 1931 tristimuli, or better, to use standardized SPDs of common RGB primary phosphors.

@Dicklyon: Sure, one would need a standardisation of RGB primary SPDs since different SPDs like the whitepoint illuminants have been standardizes. At least the letter should definitively adjusted when using CIE 1964 or the Judd+Vos corrections to the 1931 2-deg observer, since otherwhise white would no longer correspond to RGB=(1,1,1) (or #FFFFFF in 24 bit hex notation). Furthermore, even the definition of the correlated color temperature may differ, especially for off-Planckian sources (for Planckian colors one would simply re-tabulate the Planckian locus). On the other hand, the color accuracy of real RGB devices (especially consumer-class displays etc.) may be even lower than this. Maybe there has not yet been a need for a re-definition yet. Howecer, according to the CRVL there are proposed new CMFs for both 2 deg and 10 deg observers, whichs data tables can already be downloaded (or just plotted) there.--SiriusB (talk) 11:18, 20 August 2013 (UTC)

Cutoff point

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)

It would be best to make sure we give exactly the numbers in the standard. Dicklyon (talk) 22:13, 18 November 2013 (UTC)

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)

common practice discretizing

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. [7]
• 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)

Display gamma versus encoding gamma

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)

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)

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)

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)

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)

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)

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)

Here's another source about using the usual inverse of the encoding formula to get back to display XYZ: [8]; and another [9]; and another [10]. Dicklyon (talk) 05:35, 26 December 2014 (UTC)

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)

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)

Just to add to this controversy, Poynton has been quoted as saying he reversed his earlier position regarding the piecewise, now favoring its use, and we have Jack Holm of the IEC saying that the EOTF should be the piecewise... HOWEVER, I don't have context for Dr. Poynton's quote, and Jack Holm is not normative, the standard as voted on and approved is the only normative thing here. The standard states the reference display uses a simple gamma of 2.2, and this is reiterated in the introduction to the published standard that anyone can read for free in the preview here: https://www.techstreet.com/standards/iec-61966-2-1-ed-1-0-b-1999?product_id=748237#jumps

Click on "preview" and on page 11 for english, the last paragraphs states "...The three major factors of this RGB space are the colorimetric RGB definition, the simple exponent value of 2,2, and the well-defined viewing conditions..." emphasis added.

I am a professional in the film and television industry in Hollywood. My opinion is that the piecewise should be used for all image processing operations so that round trips are lossless. But that if the intent is to emulate displays in the wild, or for sending something direct to display and performance is important, the simple exponent is acceptable for a variety of reasons — not the least of which is once in the wild, displays are adjusted by users to preference, and the linear toe is completely obliterated by flare in normal conditions. It is after all under code values about rgb(11,10,11). In other words, the sRGB piecewise does not do a better job of predicting displays in the wild than the simple exponent, and the simple exponent is frequently what is used by industry for performance reasons. One example is Adobe shipping simple exponent versions of ICC profiles with their products.

Relative to this subject here on Wikipedia, both should be shown as technically both are part of the IEC standard, and an explanatory paragraph added mentioning the ambiguity therein.

The IEC standard states the reference display has a gamma of 2.2 with no offset. It later defines the transform into linear XYZ space using the piecewise. --Myndex (talk) 09:39, 6 December 2020 (UTC)

What does "s" stand for?

Does the "s" in sRGB stand for anything? --209.203.125.162 (talk) 22:21, 12 March 2015 (UTC)

Not really. I think the authors thought of it as "standard" RGB. Dicklyon (talk) 06:21, 13 March 2015 (UTC)

+1, I expected this to be in the first few sentences. If there isn't a specific meaning, just say so. I'd add it, but then I'd need to find a source... 142.113.155.49 (talk) 10:23, 16 January 2016 (UTC)

Although the v. 1.10 proposal documentation suggestive of "standard" as the "s-", the consistent omission of direct references to "standard RGB" seems painfully coy in that case. It's possible they were attempting to avoid confusion over the many "standards" involved in the discussion. (I wouldn't be surprised if the language had specifically been edited before publication to replace that specific phrase).

That being said, I wouldn't hastily rule out a non-English origin, since we're talking about the ICC (they publish in English/French & Spanish). It's also quite possible that they specifically avoid referring to it as "standard RGB" for the same reason--i.e., to avoid an Anglocentric label.

Looking at proposal v. 1.10, under the heading "Part 2: Definition of the sRGB Color Space," the spec's reference viewing environments definitions are introduced with the sentence "Reference viewing environments are defined for standard RGB in Table 0.1." (Emphasis mine). I think that is enough to warrant a statement about the "s-" standing for "standard," at least unofficially. Looking at more recent publications would help settle whether sRGB should be referred to as "standard RGB," though.

On that score... You can check the to the 1999 specification and see what you make of it. I see that in French, sRGB is actually given the separate initialism sRVB (V probably for verde), which complicates what I said above: in the French portion, "common standard RGB colour space" is rendered as "espace chromatique RVB normalisé commun." So then, to me, it appears that "s-" in the French "sRVB" doesn't really stand for anything.

I don't know. It seems like a small, but annoyingly Wikipedia-fundamental issue. I'll check back here to see how things play out.

--νημινυλι (talk) 20:37, 29 February 2016 (UTC)

What about actually explaining what the 's' most likely means in the article? I had to do additional searches to find out that the 's' might (more than anything else) stand for 'standard' (surprisingly). The explanations above seem to be a good source to extract one or two sentences in the first paragraph. Leaving it unmentioned in the whole article is needlessly confusing to readers. 79.193.107.140 (talk) 10:55, 22 November 2016 (UTC)

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

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)

is this what you want? Clickit for its description.

There is fairly good plot on the Gamma correction article. Dicklyon (talk) 20:49, 29 February 2016 (UTC)

Rounded vs. Exact

Thanks to the numbers in the matrices being rounded to four decimal places, converting from sRGB to XYZ and back or XYZ to sRGB and back gives a result which differs by a fair amount from the input. For many purposes this doesn't matter, but I've run into a few applications where error from repeated conversions accumulates to an unacceptable level. Also, looking through earlier sections here, there are several questions about the rounding of the matrices and some confusion about why, e.g., XYZ(0.64, 0.33, 0.03) doesn't result in exactly sRGB(r, 0, 0) for some r.

If you take the white-point chromaticities given in the spec (x_w = 0.3127, y_w = 0.3290) as exact, you can calculate exact rational values for the matrices, as per [11]. Using the rational values in double-precision floating point reduces the round-trip error by a factor of 10 billion. (!) This isn't part of the spec, obviously, but it was really helpful to me, and I hope it'll help others who see it here.

XYZ to sRGB matrix:

${\begin{bmatrix}12831/3959&-329/214&-1974/3959\\-851781/878810&1648619/878810&36519/878810\\705/12673&-2585/12673&705/667\end{bmatrix}}$

sRGB to XYZ matrix:

${\begin{bmatrix}506752/1228815&87881/245763&12673/70218\\87098/409605&175762/245763&12673/175545\\7918/409605&87881/737289&1001167/1053270\end{bmatrix}}$

Matrix multiplying these should give the 3-by-3 identity matrix, exactly if you're using rational math, or with very small error if you're using floating point math. Converting to decimal should give matrices close to the ones given by the sRGB spec.

Hussell (talk) 02:46, 6 March 2016 (UTC)

Looking at the "Theory of the Transformation" section, it's fairly easy to calculate the exact values of $K_{0}$ and $\phi$ which join the two segments with no slope discontinuity.

$K_{0}=11/280$ ≈ 0.0392857

$\phi =K_{0}/(132/1477)^{2.4}$ ≈ 12.9232

$K_{0}/\phi =(132/1477)^{2.4}$ ≈ 0.00303993

I'm not sure why preventing a slope discontinuity is important, but if it is, using the exact values is probably a better idea than using rounded values or, worse, rounding one value, recomputing the others from the rounded value, then rounding the recomputed values, as was done for the current(?) version of the spec. This is exactly what was done to the matrices, too, which caused the problems mentioned above.

An exactly parallel analysis of the XYZ to Lab function was written up by Bruce Lindbloom, and led to that spec being updated: [12]. I'm not Bruce Lindbloom, so I have no idea how to even begin getting something like that happening. Help?

Hussell (talk) 14:27, 6 March 2016 (UTC)

XYZ_W according to ASTM E308-01

For:

 xr = 64/100 =  0.64
 yr = 33/100 =  0.33
 xg = 3 /10  =  0.3 
 yg = 6 /10  =  0.6 
 xb = 15/100 =  0.15
 yb = 06/100 =  0.06
 
 XW =  95047/100000 = 0.95047
 YW = 100000/100000 = 1.00000 
 ZW = 108883/100000 = 1.08883

... and using [13] we have:

XYZ to sRGB matrix:

${\begin{bmatrix}{\frac {962828}{2334375}}&{\frac {26710933}{74700000}}&{\frac {336967}{1867500}}\\{\frac {2647777}{12450000}}&{\frac {26710933}{37350000}}&{\frac {336967}{4668750}}\\{\frac {240707}{12450000}}&{\frac {26710933}{224100000}}&{\frac {26620393}{28012500}}\end{bmatrix}}={\begin{bmatrix}0.4124564390896921&0.357576077643909&0.1804374832663989\\0.2126728514056225&0.715152155287818&0.07217499330655958\\0.01933389558232932&0.119192025881303&0.9503040785363677\end{bmatrix}}$

sRGB to XYZ matrix:

${\begin{bmatrix}{\frac {780000}{240707}}&-{\frac {370000}{240707}}&-{\frac {120000}{240707}}\\-{\frac {25890000}{26710933}}&{\frac {50110000}{26710933}}&{\frac {1110000}{26710933}}\\{\frac {18750}{336967}}&-{\frac {68750}{336967}}&{\frac {356250}{336967}}\end{bmatrix}}={\begin{bmatrix}3.240454162114105&-1.537138512797717&-0.4985314095560162\\-0.9692660305051868&1.876010845446694&0.04155601753034984\\0.05564343095911469&-0.2040259135167539&1.057225188223179\end{bmatrix}}$

— Preceding unsigned comment added by 93.87.247.188 (talk) 17:02, 6 January 2017 (UTC)

I ended up doing the same thing, except recomputing X_W and Y_W from the 1nm standard observer from [14]. You seem to have the matrices swapped (XYZ to sRGB is the one with negatives), but other than that we ended up with the same result.

Hussell (talk) 13:44, 31 July 2017 (UTC)

50% absolute intensity

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)

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)

Reproducing perceived color vs. actual color

My understanding is that since sRGB uses D65 white, that means a calibrated screen displaying a field of (255, 255, 255) produces the same XYZ value as an ideal white surface under appropriately bright D65 illumination. Is that correct? In that case, if I measure the XYZ value of an illuminated surface (i.e., weighting Y by the illuminant), using D65 for that, then, a perfect white surface has XYZ=(1.0, 1.0, 1.0) and so sRGB=(255,255,255).

However, suppose I want to use my sRGB monitor to display the same color as a sample I have illuminated by D50 light. How do I do that? The XYZ value of pure white is still (1.0, 1.0, 1.0) since we normalize Y by the illuminant. It seems like either I:

1. Convert from spectrum to XYZ using D50 weighting on the reflectance spectrum but D65 for the normalization or
2. Convert reflectance spectrum to XYZ in the usual way using D50 but then make the display show white as the D50 white by scaling the XYZ value by a white correction.

The alternative, I think, would be to adjust the display to have a D50 white point, at which point it's no longer acting as an sRGB display. Which of these approaches is correct? —Ben FrantzDale (talk) 14:52, 13 November 2017 (UTC)

XYZ of a perfect white surface under D65 is not 1,1,1, it is .95047, 1.00, 1.08883, right?Spitzak (talk) 20:45, 13 November 2017 (UTC)

My mistake. You are correct, D65 is XYZ=(.95047, 1.00, 1.08883) and so when multiplied by the matrix to get linear RGB, it becomes (1, 1, 1).

So, if I want to reproduce on a D65 sRGB display the appearance of a white surface under D50 illumination... I get XYZ=(0.9642, 1.0, 0.8249), which becomes #ffebce in sRGB. Is that right? Up to brightness, would I expect #ffebce to be the same chromaticity as a white object under a D50 illuminant?

For the sake of comparison, if I adjust my monitor so white is D50, then if I wanted to display an image of a sample illuminated under D50, then white would need to display as #ffffff, so if I have the XYZ value under D50 illuminant, I guess I'd scale it by (0.95047/0.9642, 1.00, 1.08883/0.8249) before converting from XYZ to sRGB. Sound right? —Ben FrantzDale (talk) 21:25, 13 November 2017 (UTC)

And I guess if I had a display calibrated to D50, if I wanted it to show a D65 white, I'd take XYZ=(0.95047, 1.00, 1.08883)^2 = (0.90339322, 1. , 1.18555077) and convert that to sRGB to get #defaff. —Ben FrantzDale (talk) 21:30, 13 November 2017 (UTC)

The "Annex A" Comment

There is an edit where someone inserted the Annex A comment verbatim from the IEC sRGB specification. Seriously it does not belong. But before I remove it, I thought it would be good to discuss. I don't want an edit war LOL.

That Annex A comment is pure opinion. I am a full time professional in Hollywood, and I can tell you that the term "gamma" is used unambiguously as the accepted colloquial way to describe image data that is encoded with a power curve (regardless of if it has a tiny piecewise linearization), as opposed to image data that is encoded with a log type curve, or image data that is linear (EXR, i.e. gamma 1.0).

I was dealing with some troll recently who apparently just graduated from "Full Sail" or something and was all "oh you can't call that gamma because..." whataboutism.

Gamma is the term used by professionals in the industry as I described. The Annex A chunk should be removed (it IS a copyright violation as posted) and if anything, could be replaced with a single sentence clarifying the issue. --Myndex (talk) 02:39, 21 October 2020 (UTC)

@Dicklyon: As you can see I brought it up here in talk a couple months ago before doing today's edit. The cited Annex A blurb is part of the IEC un-published draft, and copying it in total is a copyright violation. But moreover, it is irrelevant.

The quote is not withstanding, not a normative part of any standard, and not at all a part of the terminology as used in the professional film and television industries. It does not belong here on Wikipedia. --Myndex (talk) 05:13, 6 December 2020 (UTC)

OK, sorry I missed the discussion. I'll self-revert my revert. Dicklyon (talk) 05:15, 6 December 2020 (UTC)

@Dicklyon: Thank you... I can try to integrate some of that Annex A material if you feel I should, I just did not think that it related to sRGB in any real way. IEC standards are a little odd, as they are "semi-open" and allow for some public comments to sometimes be included. But my concern is that those claims just muddy the water further and to no useful purpose.

If you want to bicker about this, go nuts. I've included the citation to the actual specification's annex, which is also fair use, and is indeed taken from the published specification. You can use "gamma" all you want, and I really don't care. Maybe you might want to go search the termlist at the CIE and see how many times "gamma" shows up in their term lists? Guess what, you'll find that "gamma" is only listed in the annex in the sRGB specification, and in the CIE term list, you'll find it used with scare quotes. The sRGB specification defines an EOTF, which is a transfer function. With specific attention to the specification formula, it is most certainly not a pure power function in the only sane interpretation of "gamma". Most any person involved with colourimetry in the film and television industry is familiar with the term, and it more greatly outlines precisely what it is in fact; a two part transfer function. While I respect Mr. Spitzak's opinion on the matter, I'll still disagree on principle with the specifically incorrect usage within the sRGB specification page at Wikipedia. Deadlythings (talk) 20:20, 13 December 2020 (UTC)

Gamma Gone Gonzo

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)

It looks like we have several experts involved here. The color articles need you folks. There's no hurry to tweak the article to the point of doing it via an edit war vs. having some fun sorting it out on the talk page first. Please do that. Sincerely, North8000 (talk) 21:06, 13 December 2020 (UTC)

Well thank you @North8000: 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)

A Response to Mr Deadly, Part Deux

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)

NPOV problem

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)

@77.61.180.106: 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)

I assume you mean the ‘I know all there is to know about colorimetry because I'm a Hollywood professional’ guy? Even so, if you read the text back now, you can see what I meant, right? Maybe it would have been better to cool down and take some mental distance before writing it. In any case, it isn't appropriate the way it is, as I'm sure you'll agree. — Preceding unsigned comment added by 77.61.180.106 (talk) 04:04, 5 January 2021 (UTC)

@77.61.180.106: 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)

Start over?

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)

"The numerical values below match those in the official sRGB specification,[1][3]"

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)

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)

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)

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)

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)

"Theory of the transformation" section

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)

@Spitzak: Here is the 2019 edit where things got disconnected. Dicklyon (talk) 06:07, 13 July 2021 (UTC)

Please check my fixes. Dicklyon (talk) 17:33, 14 July 2021 (UTC)

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)

Edit War over irellevant information

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)

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) — Preceding unsigned comment added by Valery Zapolodov (talk • contribs)

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)

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)

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)

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)

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)

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)

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)

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)

@Jacobolus: 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)

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)

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)

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)

internal secret documents – 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)

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)

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)

The two whites

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)

You mean encoding white? 2A00:1370:8184:6AD9:D044:40FD:8073:258E (talk) 06:36, 11 September 2022 (UTC)

The image with the squares

Its caption says: ‘On an sRGB display, each solid bar should look as bright as the surrounding striped dither. (Note: must be viewed at original, 100% size)’

The thing is, for the average reader 100% is when the browser says the zoom level is 100%. At this zoom level, the image will display at 104 × 36 ‘CSS pixels’ because that's what the width and height attributes are set to. Since this is the pixel size of the image, that means it will be displayed at 96 DPI. Which means that on a high DPI device, even though the reader has followed the instructions, the image's pixels are interpolated, usually in a way that makes the striped bars appear too dark.

Even if the user thinks to right-click and open the image in a new tab, that won't help. You see, at offset 33 there's a pHYs chunk (00 00 00 09 70 48 59 73 00 00 0e c4 00 00 0e c4 01 95 2b 0e 1b) that says the image resolution is 3780 pixels per metre. This means that a conforming viewer will still end up interpolating the pixels in the same way. And if this chunk is absent, I wouldn't be at all surprised if viewers end up substituting a default DPI of 96 anyway.

I've tested Firefox, Chrome and Edge, all with similar results. Now high DPI displays are becoming increasingly popular, and with the lack of support for the use of device pixels in the wiki software, I think we can no longer display calibration images like this on Wikipedia. The risk of misleading our viewers is already too big, and will only continue to grow in the future. — Preceding unsigned comment added by 92.67.227.181 (talk) 12:29, 26 June 2022 (UTC)

I also think it's sus that the file doesn't contain an sRGB chunk. I'm not sure anyone would notice, but still. — Preceding unsigned comment added by 92.67.227.181 (talk) 13:14, 26 June 2022 (UTC)

Disagree. At default settings retina screens are fine, as they are usually 2:1 or 3:1. And it's useful to have gamma targets on screens, just ideally should be set aside (not in the main table) and with a sentence that indicates how to properly view. It's not sus if the image does not have the sRGB, especially a small image. sRGB is not needed as sRGB is the default for the web, and sRGB is therefore assumed.

What IS needed is for such targets to have the image property set to img{image-rendering: crisp-edges;} and I suspect that is actually the problem you are having in viewing.  Myndex talk   09:47, 27 June 2022 (UTC)

>Disagree.

This is a matter of fact and not an opinion about which you can just ‘disagree’. Using a retina screens is no guarantee of the image rendering correctly, it all depends on how the image ends up being upscaled; most software that is in common use today does it wrong, almost always interpolating pixels in such a way that the striped bars appear too dark. It is not useful to have gamma targets on screen if they are wrong, such as is the case here, in fact it's counterproductive. And the image not having an sRGB chuck is sus, because this article is about sRGB so the image should explicitly contain sRGB values and be clearly tagged as such; not doing so indicates a lack of care and understanding. (Also, note that if a PNG file contains a gAMA chunk but no sRGB chunk, a conforming implementation doesn't assume sRGB but instead uses a plain gamma as specified by the gAMA chunk.)

Setting ‘image-rendering: crisp-edges;’ doesn't always help. For example, one of the more popular DPI settings for desktops and laptops is 144. In that case crisp-edges will result in either the light or dark lines being duplicated compared to the other, resulting in an overall brightness that is way too light or dark. I've checked four different calibrated displays and it only shows up correctly on the oldest one (which is 96 DPI so that was to be expected). — Preceding unsigned comment added by 92.67.227.181 (talk) 17:07, 1 July 2022 (UTC)

No, you are pulling opinion from thin air, you are not reciting facts. Just because YOU can't figure it out does not meat it has no utility or is not useful to others. At most it might require some additional discussion.  Myndex talk   16:25, 2 July 2022 (UTC)

pHYs is seldom applied.

"wouldn't be at all surprised if viewers end up substituting a default DPI of 96 anyway."

I would think it will just use native pixels. Your gAMA comments are correct, Chrome and Firefox both use it instead of sRGB if sRGB chunk is absent. 2A00:1370:8184:6AD9:D044:40FD:8073:258E (talk) 06:41, 11 September 2022 (UTC)

The amendment also recommends a higher-precision XYZ to sRGB matrix using seven decimal points

That is not what the cited reference actually says. It says that you should use the inverted matrix from (F.7) to sufficient precision. (Actual text: ‘enough accuracy decimal points’ – Points? Seriously? This is an official standard, but it reads like a YouTube comment.) It then goes on to say that for 16 bits per channel 7 decimal places should be enough. (Which seems fair given that 16 bits is enough for just under five digits, although at first glance (F.7) itself seems to be rounded to insufficient precision for 16 bits...) Why don't people read the references they cite? 92.67.227.181 (talk) 17:45, 1 July 2022 (UTC)

"seems to be rounded to insufficient precision for 16 bits.."

Seems? Well, check it out with a brute force. Name for decimal point and numbers after it are defined by its insane ammount of its own ISO standards. Valery Zapolodov (talk) 02:02, 29 September 2022 (UTC)

You are saying it as if I am lying. This is from the standard, https://imgur.com/a/1FMB3sO 2A00:1370:8184:6AD9:F9BC:A3B4:30C7:B031 (talk) 04:20, 29 September 2022 (UTC)

Lighten up. We can discuss different interpretations of sources with anyone being interpreted as making accusations of lying. Dicklyon (talk) 04:36, 29 September 2022 (UTC)

"Computing the transfer function"

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)

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)

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)

Contradictory formulas?

The formulas for the $\gamma (u)$ in the section Transfer function ("gamma") do not agree with those in the From CIE XYZ to sRGB section below. It seems that part of the problem is that the formulas in the DRAFT of the standard (public) differ the OFFICIAL standard (paywalled). Would please someone with access to the latter put the correct formulas, with every parameter rounded (or not) exactly as in that document, and get rid of the incorrect ones? In name of the world wide world, thanks... Jorge Stolfi (talk) 21:02, 17 December 2024 (UTC)

Can you explain more clearly which part seems contradictory? The section § Transformation should be correct here. I don't see any contradiction between that and the earlier section § Transfer function ("gamma"). –jacobolus (t) 21:24, 17 December 2024 (UTC)

The contradictions were actually confusion between the historical and current specs of the standard. I revised the whole page, separating the two. Please have a look and let me know if I made any mistakes. --Jorge Stolfi (talk) 10:12, 18 December 2024 (UTC)

I don't have time to check the details right now, but if I remember I'll take a look when I get the chance. Why are we removing the sentence "sRGB essentially codifies the display specifications for the computer monitors in use at that time, which greatly aided its acceptance" from the lead section? It seems like useful basic context for readers. –jacobolus (t) 17:27, 18 December 2024 (UTC)

This looks incorrect to me: "Part of the confusion is due to the value of $\Gamma$ having changed from 2.2 in the initial draft (which is widely available) to 2.4 in the final document (which is paywalled)". If this is referring to Anderson & al. 1996, you can read it directly here at imaging.org. Compare to color.org/sRGB.pdf which should be an accurate summary of the final spec. –jacobolus (t) 17:27, 19 December 2024 (UTC)

If that is the correct paper, it definately says 2.4 in the formula. I agree this is claim is certainly wrong. There was and is confusion between the 2.4 used in the formula and the fact that the closest match pure exponential curve has a gamma of 2.2, but this was never misprinted in any papers imho.Spitzak (talk) 17:13, 20 December 2024 (UTC)

No, 2.2 was never EVER USED IN sRGB. sRGB was originally called NIF RGB. And even back then it was using 0.42 ~~ 1/2.4 gamma (see page 55): http://www.graphcomp.com/info/specs/livepicture/fpx.pdf Valery Zapolodov (talk) 01:42, 25 December 2024 (UTC)

Why "sRGB is assumed"

The artcle said

"If the color space of an image is unknown and the R, G, and B samples are encoded with 8 bits each, the sRGB encoding usually the assumed default, in part because color spaces with a larger gamut need a higher bit depth to maintain a low color error rate (∆E)"

I removed the sentence after "in part" since it is confusing, unsourced, and probably incorrect. First, the sentence is incomprehensible except by readers who already know what it is supposed to say. (What is ∆E?) Maybe it is even conflating "gamut" with "gamma", which are two unrelated concepts. The sRGB encoding is usually assumed by default, when not specified, solely because it is the standard for images intended to be embedded in HTML pages; not for being optimal in some technical sense. (It should be noted, by the way, that the specification of the venerable PNM (PBM/PGM/PPM) image file format specifies BT.709 as the encoding, not sRGB.) Jorge Stolfi (talk) 19:20, 25 December 2024 (UTC)

I would skip the "in part" section of this sentence, and just say that sRGB is the assumed default color space for untagged images, especially on the web. "not for being optimal in some technical sense" – sRGB was designed to be relatively close to existing computer displays when it was first published, and then there was a whole generation of computer displays which were themselves designed to more or less match sRGB (for example iPhones from ~2010–2020 did no color management in software but had displays which were extremely close to matching sRGB). I don't think there's such a thing as a "technically optimal" color space, but sRGB is quite well adapted for its intended purpose. –jacobolus (t) 19:44, 25 December 2024 (UTC)

It does not conflate gamma with gamut. Of course if we have much more complex gamma (well, transfer function, not pure gamma) like PQ we ideally need 10 bit at least to stay at good quality in SDR portion. But of course no one will assume HDR image unless explicitly tagged. WCG images in theory need higher bitdepth to stay at the same spacings between 8 bit codepoints. Yes, since iPhone 7 photos use P3, so it is kinda "did not age well" point. Valery Zapolodov (talk) 01:08, 29 December 2024 (UTC)

Either way, unsourced and handwavy speculation about this point is not really appropriate for Wikipedia. –jacobolus (t) 01:26, 29 December 2024 (UTC)