Talk:SRGB

From Wikipedia, the free encyclopedia

	This article is supported by the Color WikiProject, a project that provides a central approach to Color-related subjects on Wikipedia. Help us improve articles to good and 1.0 standards; visit the wikiproject page for more details.
Start	This article has been rated as start-Class on the quality scale.
High	This article has been rated as high-importance on the importance scale.
Article Grading: The article has been rated for quality and/or importance but has no comments yet. If appropriate, please review the article and then leave comments here to identify the strengths and weaknesses of the article and what work it will need.

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] gamma = 2.4?

I believe the value of the symbol γ 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/γ and declare γ = 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 γ (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)

[edit] 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)

[edit] 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_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_linear, G_linear and B_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)

[edit] 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))

[edit] 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)

[edit] 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)

[edit] 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)