Talk:RGB color model

Untitled

Adopted orphan redirects for searching: RGB colour model

---

Subject: Psychological Primary Colors

The "red" and "green" that the R and G were named after in RGB are actually more yellow than pure red and pure green, defining such as being neutral on the blue-yellow scale, which are 2 of the 6 psychological primary colors. The psychological primary colors and their RGB coordinates are:

Red = 255 0 128

I just opened up an xterm with that color and it looks sort of pink. If I just use 255, 0, 0, it looks red. Michael Hardy 02:21, 18 Feb 2004 (UTC)

Yellow = 255 255 0 Green = 0 255 128 Blue = 0 0 255 Black = 0 0 0 White = 255 255 255

Of course, gray is 128 128 128; note that it is a mixture of any 2 colors that are complements, such as black and white, blue and yellow, and red and green. How about the secondary colors

Red + Yellow = Orange (255 83 0) Yellow + Green = Lime (83 255 0)

This is ridiculous: orange and lime are disambiguation pages, not pages about colors!! Michael Hardy 02:24, 18 Feb 2004 (UTC)

Green + Blue = Sea Blue (0 172 255) Blue + Red = Purple (172 0 255)

Anything + Black = half the distances between the coordinates and 0 Anything + White = half the distances between the coordinates and 255

See also the messages at Color, Red and Primary Color that also have to do with psychological primary colors.

Why link to Primary Color with a capital "C" when no such page exists, and you could link to primary color with an appropriately lower-case "c", which does exist? (The capitalized page now exists as a redirect page; I just created it.) Please check your links to see if they're working right!! Michael Hardy 02:28, 18 Feb 2004 (UTC)

History of RGB color model - RCA, Edwin Land ...

Would it be possible to include some history of the use of the RGB color scheme - including for example, the RCA standards for color television that were adopted in 1953, Edwin Land's use of an RGB scheme for the Land / Polaroid camera and the introduction - and subsequent adoption by W3C in HTML 3.2 - of color="#rrggbb" as the Internet standard for the presentation of color.

I would also like to offer a link that perhaps might be included in the RGB color model, namely http://www.peace-cubes.net, the home of the Virtual Light and Colour Cubes - defined as virtual entities with dimensions of red, green and blue, in which the color at any point is the sum of the red, green and blue coordinates, where color="#rrggbb" is understood as an arithmetic expression in a three-dimensional mathematics of light and color.

The Virtual Light and Colour Cubes were dedicated as Peace Cubes at the United Nations Peace Bell on March 20, 1997 - see http://habitat.igc.org/peace-cubes/dedicate.htm - and have served as icons for the transition to a digital knowledge-based universe in which we can see the world in transformed and transformative ways, and as a reminder of the existence of one light in all of creation - in the digital world as well as in material realms.

Robert Pollard
Information Ecologist & Digital Artist
ecology2001@mindspring.com
Information Habitat: Where Information Lives - Home of the Virtual Light & Colour Cubes
http://habitat.igc.org/

This looks like a semi advert. I'm at loss whether to delete it or keep it Kim Bruning 16:25, 9 Apr 2004 (UTC)

I'm removing the comic sans font. It makes me want to hurt someone. --jacobolus (t) 03:30, 17 April 2007 (UTC)

Article has a slight POV slant

...in favor of 8 bits per channel. What about methods that represent RGB as floating point proportions (like OpenGL does, IIRC) or that represent RGB in *more* than 8 bits per channel (I'd imagine specialised applications or simply photo editing where that'd be important).

Hmm. Kim Bruning 16:20, 9 Apr 2004 (UTC)

given that (at normal viewing distance and resolution) only four bits are actually needed for green, ~3.5 for red, and 2 for blue, suggesting that more bits bit be useful could be misleading. 8 bits per channel is a convenience (as it means some image processing calculations can be done more simply), and the same is true for using floating-point values, but all those extra bits are a bit of an indulgence :-) mfc

Only 2 bits are needed for blue? What in the world are you talking about? --jacobolus (t) 03:35, 17 April 2007 (UTC)

Who cares about the human visual system?

• Extra bits are useful for more accurate measurements for scientific purposes.
• Natural lighting can have a massive dynamic range.
  • Even if the human eye can only grab a subset of that range, doesn't mean there might not be a reason to record light levels across the entire range (and then later be able to pick out cross-sections from that range to view different parts of our recording).
  • Have you ever noticed how many rendered images look so flat? This is especially true of "outside pictures".It'd help if those rays actually were traced at a higher color-depth. You could then select your viewing pane coordinates in color space* as well as euclidian space. This would be akin to setting the light sensitivity (ISO value && partially also diafragma) on your virtual camera. (Hmm, I'd actually have to look up to see if some renderers don't already do that.)
• When editing in the colorspace of a photo, sometimes I just run out of bits! Arrrgh, bother, time to retake that photo. If the camera had just been able to record at just a little more colordepth , I could have managed. (This is related to my hard-disk always having juust too little space for those images to fit too. :-P )
  • Fortunately, some cameras already have a raw output format at 16 bits per channel. :-) Unfortunately these are almost always proprietary. :-(

Hope this gives a bit of an idea why a larger color-space might be useful. :-) Kim Bruning 18:55, 9 Apr 2004 (UTC)

* in a way that would actually be meaningful.

yes, 8 bits per channel is simply a historical accident, brought about by limited hardware. --jacobolus (t) 03:35, 17 April 2007 (UTC)

0.0...1.0 vs. 0%...100%

There has been a small disagreement on whether we should explain, and if so, how we should explain the difference/conversion between the two representation of a color's intensity, as per the section title.

The initial version of the article read:

• Color science talks about colors in the range 0.0 (minimum) to 1.0 (maximum). Most color formulae take these values. For instance, full intensity red is 1.0, 0.0, 0.0.
• The color values may be written as percentages, from 0% (minimum) to 100% (maximum). To convert from the range 0.0 to 1.0, just multiply by 100. Full intensity red is 100%, 0%, 0%.

The first paragraph never changes throughout the mini-dispute, so I won't repeat it. An edit made by 67.83.133.218 added a percent sign after the "100" you should multiply with. His/her comment in the history: "You multiply by 100%, not 100. 100% == 1, you aren't actually doing anything." The result was:

• The color values may be written as percentages, from 0% (minimum) to 100% (maximum). To convert from the range 0.0 to 1.0, just multiply by 100%. Full intensity red is 100%, 0%, 0%.

Now that looks kind of silly to me, explaining to people they have to multiply by 100%, it looks like we don't know what we're talking about. Moreover, I think people need to take an arithmetic lesson if they want to find out how to "convert" 1.00 to 100%, instead of reading an article about RGB. Taking things to extreme, should we also include information about how to power up their computer in this article, in order to start Photoshop or whatever? Anyway, based on that rationale, I removed the conversion phrase altogether, leaving us with:

• The color values may be written as percentages, from 0% (minimum) to 100% (maximum). Full intensity red is 100%, 0%, 0%.

Notinasnaid however said "I have to disagree: this is a very common cause of total confusion among people working with color. If it's confusing, please rephrase, but the explanation is important, I think.", and after a couple of edits we now have:

• The color values may be written as percentages, from 0% (minimum) to 100% (maximum), or sometimes just 0 to 100 without a percentage sign. To convert from the range 0.0 to 1.0, just multiply by 100. Full intensity red is 100%, 0%, 0% (or just 100, 0, 0).

I have to say I never saw the 0 to 100 range for colors... 0% to 100%, yes, that I have, and 0..255 as well--but 0 to 100, never. For the time being, I'll simply revert to my deleted version. If someone can come up with a situation where 0 to 100 is actually used in a mainstream product to represent 0..100%, please comment here. --Gutza ^{T T+} 09:47, 28 July 2006 (UTC)

I agree – it's quite unnecessary to spell out that 1 × 100 → 100. (And plain 100 would be very unlikely for a numerical value, anyway, it would more probably be 0→99. quota 12:12, 28 July 2006 (UTC)

Hummm... maybe Notinasnaid was right after all... quota, 1.00 is 100%, you don't "convert" between them because they already are the same thing. --Gutza ^{T T+} 12:32, 28 July 2006 (UTC)

As a compromise version, which tries to clarify things without making the editors look bad, I ended up with this version:

• The color values may be written as percentages, from 0% (minimum) to 100% (maximum). To convert from the range 0.0 to 1.0, see percentage. Full intensity red is 100%, 0%, 0%.

--Gutza ^{T T+} 12:40, 28 July 2006 (UTC)

• You write "Moreover, I think people need to take an arithmetic lesson if they want to find out how to "convert" 1.00 to 100%" and I might be inclined to agree, but people really don't understand what they have, and that they are numbers they can do arithmetic with. Let me share with you an exchange I recently witnessed in a discussion forum. Person A: The colours you quote are in the range 0 to 255. [The context] expects colour components to be in the range 0 to 1. So conversion is straightforward.. Person B: Could you please share how you would convert the RGB value of "233, 217, 145" ? I'm just not getting the straightforward part. It would be good if Wikipedia was comprehensible to people without too much background knowledge. What we have now is OK, but maybe a little table explaining how to convert between each representation would not be too far wrong. When something is easy, it's easy to forget how hard some people can find it. Notinasnaid 20:19, 28 July 2006 (UTC)

Please note I didn't comment on converting 0..1 or 0%..100% to/from 0..255. All of this revolved around the conversion between 0..1 and 0%..100%. I think the current version regarding that part is quite clear, especially since the percentage article starts off with a very clear explanation that 0%..100% is actually the same range as 0.0...1.0. --Gutza ^{T T+} 20:53, 28 July 2006 (UTC)

Color vision

somebody said that the eyes can see 3 different colours.. yellow-green, and two others.. can we get a representation of these particular colours?

much of this same info. is at http://wiki.riteme.site/wiki/Cone_cell and does have a source (a 1982 book). Has anyone read that book? [I have not, am just noticing the same info. is there on the other page]

Opirnia 15:37, 27 May 2007 (UTC)

That wouldn't belong in this article, but might belong in color vision. Notinasnaid 07:24, 30 August 2006 (UTC)

The three colors happen to be... drumroll... RED, GREEN, and BLUE! -SharkD 14:13, 22 October 2006 (UTC)

Nevermind. I was wrong. -SharkD 04:53, 18 November 2006 (UTC)

Why is there a discrepancy between the labeling of the eye's three cone types (i.e., yellow, green, violet on this page and blue, red, and green on the cone cell page). Both pages appear to cite the same source. Syntaxapse (talk) 14:25, 10 June 2013 (UTC)

3D rendering of RGB cube

I did a 3D rendering of the RGB cube in POV-Ray. Wasn't sure where to put it, so I'll just put it here instead. -SharkD 14:15, 22 October 2006 (UTC)

Orphaned article

The article that appears at http://wiki.riteme.site/wiki/RGB_color_model is slightly different to that at http://wiki.riteme.site/wiki/RGB. The RGB article claims to redirect to the RGB color space article, yet has its own page with independent content. As an inexperienced user of Wikipedia, I'd like to know why this is, and what can be done about it.

RGB and RGB color model do seem to be the same article. What differences can you see? RGB color space is an entirely different article. This is as it should be, but one of the great challenges is to make it clear why it should be. Notinasnaid 10:40, 23 October 2006 (UTC)

Should RGB color space be added to the navigation table at the bottom of the page? -SharkD 06:32, 25 October 2006 (UTC)

RGBA and camera's

A small section about digital camera's has been added to the RGBA section. This seems to not belong there. Does it even belong on this page? -- Peter 12:50, 13 November 2006 (UTC) do not play around with theses notes. thank you!

24-bit color image?

I have a question, does anyone know where i can find an image containing all 24-bit colors? —The preceding unsigned comment was added by 168.216.109.213 (talk) 18:31, 8 January 2007 (UTC).

Here ya go. Tiff and png versions: http://www.brucelindbloom.com/ Jive Dadson (talk) 12:03, 4 June 2009 (UTC)

24-bit RGB can describe (2^24)^3 = 4.72 * 10^21 different pixel colors. To show the entire color space (at 300 dpi) would require an image about 1600 miles wide. 170.97.67.142 14:23, 9 April 2007 (UTC)

Um… presumably "24-bit colors" refers to 8 bits per channel, for a total of 24 bits/pixel, not to a 72 bit/pixel image (which I've never heard anyone even propose making). At which point it is possible to put all 2^24 possible colors in a 2¹²×2¹² pixel image, which at 300 dpi is a square less than 14 inches on a side. --jacobolus (t) 03:51, 17 April 2007 (UTC)

Thanks for the good cube pic, helped me on my school project.

Questions

I'm not an expert in this, but I guess the image (VEN DIAGRAM kind) should have black in the centre and not white. Sorry if thats too silly. 128.240.229.66 14:26, 21 February 2007 (UTC)

Sorry it was me Wikiality who posted the above message without realising am not logged in. Just to let know where you can find me. Cheers Wikiality 14:29, 21 February 2007 (UTC)

No, white in the middle is right because white light is made up of all colors. My question is, shouldn't the first cube have a white block in the middle instead of grey? ImMAW 01:00, 13 March 2007 (UTC)

The image is of a cube with a corner cut out of it so that you can see inside. SharkD 02:55, 18 April 2007 (UTC)

Back to the original question from Wikiality, that Venn Diagram is correct because that section is about additive color. I think that section could be clarified further by distinguishing additive color from subtractive/reflected color. For instance, in a subtractive model, black would be in the center of the diagram - think about the RGB inks in an inkjet printer mixing to make black. When light of RGB wavelengths mix evenly, we see white. When white light is reflected off a surface where printed RGB inks mix equally, we see black. I don't know if this article is the correct space for a full explanation of this difference - the article is already very convoluted by cross terminology and poor definitions of color spaces - but it might be worth mentioning that since we are talking about additive color, there is also something called subtractive color, and they are distinct. Dirtmcguinness (talk) 19:08, 27 July 2012 (UTC)

There are several other articles that explain the difference between additive and subtractive color reproduction in great detail. –jacobolus (t) 03:13, 28 July 2012 (UTC)

And I just added a sentence to the first titled section, Additive primary colors, putting this distinction (ahem) into the article, in, I believe, more informative and less technish terms than the sole other mention, in the lede:

Color printers, on the other hand are not RGB devices, but subtractive color devices (typically CMYK color model).

which says nothing about the difference between additive and subtractive models.
--Thnidu (talk) 07:17, 14 February 2017 (UTC)

See also #Additive vs. subtractive models, or, How techie can we get? --Thnidu (talk) 08:19, 14 February 2017 (UTC)

stupid disclaimer and long comment about it

I vastly simplified the disclaimer about RBG at the top of the page. Formerly, it said:

: This term anedates many engineering standards dating historically back into early
television and film leading to minor name variations such that it has been perhaps
represented more frequently in literature as RBG, RBG color, RBG color standard,
or RBG color model, etcetera.

I also removed the silly comment that went along with it:

< !--- -------------------------------------------------------------------------------------
----- These additional terms redirect here, so please leave this disclaimer in place.
----- Note a Google test has no relavence. Most printed material antedates both the 
----- internet & in fact, the ability to digitally store records, rendering such a 
----- search and comparison pretty much meaningless. It is entirely likely that many
----- manufacturers cynically went out of their way to not use the same term as RCA/Kodak.
----- -------------------------------------------------------------------------------------
--->

—jacobolus (t) 03:59, 17 April 2007 (UTC)

uniquely distinguishable colors

I just removed this whole block from the article (reformatting the image a bit so it doesn't take up so much room. Aaron hoffmeyer, who added the image and explanation, was apparently reacting to the notion that people can only distinguish "a few hues". Indeed, that statement was completely unreferenced, and very vague.--jacobolus (t) 19:31, 18 May 2007 (UTC)

Three comparisons of RGB purple values. The block to the left contains two blocks whose RGB purple values vary by two right next to one another (rgb(125, 125, 180) and rgb(125, 125, 182)). For the set in the middle, they vary by four (rgb(125, 125, 180) and rgb(125, 125, 184)). For the set on the right, they vary by eight (rgb(125, 125, 180) and rgb(125, 125, 188)). Most people can easily distinguish between the two purple blocks in the set to the right.

However, at the resolution of current screens and at a standard viewing distance people cannot distinguish more than a few hundred hues. (This statement does not appear to be factual. In testing people's ability to distinguish between color values, some people can tell the difference between 24-bit RGB values that vary by two, which means they can distinguish nearly half the RGB values. Many people can distinguish RGB values that vary by four, which means they can distinguish about four million colors. And most people can distinguish colors that vary by eight, which means they can distinguish two million colors. See the image for an example.

quick question

"RGB is a type of component video signal used in the video electronics industry. It consists of three signals—red, green and blue—carried on three separate cables/pins. Extra cables are sometimes needed to carry synchronizing signals. RGB signal formats are often based on modified versions of the RS-170 and RS-343 standards for monochrome video. This type of video signal is widely used in Europe since it is the best quality signal that can be carried on the standard SCART connector. Outside Europe, RGB is not very popular as a video signal format – S-Video takes that spot in most non-European regions. However, almost all computer monitors around the world use RGB."

If I'm reading this correctly, does it mean that if I had a piece of electronics that could output RGB via component cables, I could make a simple component->vga cable and have it display on my CRT monitor? Also, if this is possible, what woul dhappen if you were to output TV signals like 480p or 720p etc to it? Mr toasty 04:13, 25 May 2007 (UTC)

"biological basis" section; merge proposal to primary color

The section about the biological basis for primary colors is not particularly well explained, and it is given no references whatsoever. I can't find any other online sources (in an admittedly very quick google search) that say this, hence the unreferenced tag. While there is obviously a biological basis for the choice of primary colors, I don't think that this section explains it adequately. And there are definitely other biological concerns than simply which points in the spectrum roughly correspond to cone cells, when deciding on primaries. Wherever the section ends up, it should be put on a reasonable scientific footing, be more clearly explained, and be referenced. Also, the same section appears at the primary color article, which is, I believe, a more appropriate place for a discussion of the biological basis for choosing different primaries, hence the merge proposal. --jacobolus (t) 20:28, 23 June 2007 (UTC)

I agree these sections are way screwed up and probably need to be scrapped, or at least rewritten. I wouldn't call it a "merge" though, and the proposal as currently tagged is one-sided, but I'll let that slide. On the primary colors page, it makes no sense at all, since it's not placed within either the additive or the subtractive framework. On the RGB page it's in an additive context, but the content is still all wrong for that. There has been a lot done on choices of additive primaries, pure spectral and otherwise, and these sections include none of it. I'll see if I can find a good source; probably Hunt will have a good section to draw on. In the mean time, why not just delete it from the color primaries article, and work on the one in RGB? Dicklyon 05:11, 24 June 2007 (UTC)

RTFL: Read The Fine Links? :-P First link is to Cone cell. Second reference on Cone cell contains the 3 frequencies, and lists as a reference: ^ Wyszecki, Günther; Stiles, W.S. (1982). Color Science: Concepts and Methods, Quantitative Data and Formulae, 2nd ed., New York: Wiley Series in Pure and Applied Optics. ISBN 0-471-02106-7.

--Kim Bruning 20:43, 24 June 2007 (UTC)

So? Those cone wavelengths have little relationship to choices of additive color primaries. Besides, what's needed are actual sources, and a wikipedia article can never be treated as a source. Dicklyon 20:46, 24 June 2007 (UTC)

Hmmm, I do see what you mean. I can't actually find an article linking cone reception to actual R,G and B percepts, and most literature just blindly works using R,G and B percepts, which is interesting. Can you provide a reference for your statement?

I've been reading up, and finding all kinds of things. There are certainly links from how the cones work to the constraints on what makes good color primaries. But I the asserted connections are either pretty thin or pretty indirect. What clear from man sources is that if you used the peak wavelengths of cone responses as your color primaries you'd have a pretty awful colorspace; they don't come out and say that, though. Dicklyon 03:28, 25 June 2007 (UTC)

As an aside, note that I didn't use a different wikipedia article as a reference, but rather I just errr, dereferenced it (please excuse the pun ;-) ), by which in this case, I mean I used it to look up a valid reference, and provided that valid reference here.. --Kim Bruning 23:17, 24 June 2007 (UTC)

Yes, I see. Dicklyon 03:28, 25 June 2007 (UTC)

Yes, this is exactly why I had a problem with the "biological basis" section before. It just asserted that RGB were good primaries, without any explanation of that. I'm sure it has to do with which color filters and light sources are easy to produce, with human perception of color, with the opponent process, and with producing the widest gamut possible for the least energy, etc. But I don't really understand all those factors, and this article doesn't explain them. Just saying that "because we have three cones, RGB is good" (basically what it said) is a cop-out. --jacobolus (t) 22:43, 25 June 2007 (UTC)

Alternative plan – How about we fix the RGB primaries to be more sensible in support of this topic, which is all about trichromacy and additivity, and fix the primary colors article's section to be about the distinctions between tri-, bi-, and tetra-chromacy? Split rather than merge. Dicklyon 21:18, 25 June 2007 (UTC)

Yes, that's fine. The point of the "merge" proposal was just to point out that the same information was duplicated, and that some good place should be found for it, and then a link provided in the other place. My thought was that at the primary color article, there could be some biological/psychological argument given about both RGB and CMY as choices of color primaries (and maybe even old artists' RYB, etc.), and then links to that could be put in the articles about RGB and CMY color. But I'd be happy with any solution that a) clearly explains the reasons for choosing those primaries, and b) doesn't duplicate large chunks of text instead of linking. I'm happy with summary + "main article" links, if that's the best way to handle things, but having nearly identical 3-4 paragraph chunks in two places, without any links between them, seems wrong. --jacobolus (t) 23:02, 25 June 2007 (UTC)

Cone cells

Note that green doesn't become "bluish" until well below 540 nm, and that 570 nm is right in the yellow

The description of M and L cone peak sensitivities and bluish-green and yellowish-green doesn't make much sense; they are really right in the green and yellow respectively. But probably we should try to find some sources instead of arguing, or just leave it out as it's pretty irrelevant. Dicklyon 18:09, 25 June 2007 (UTC)

Also, Hunt gives longer wavelength numbers, per Estevez, putting them more squarely into green and yellow. Might as well go with that simpler description if we feel a need to label cones by the color of their peak wavelength (which is a bit nonsensical, as I hope I said before). Dicklyon 00:16, 26 June 2007 (UTC)

QUESTION: i read in this page that cone cells respond to the wavelenghts of red/blue/yellow, this is not correct. they respond to red/blue/green and this is the classification. please not come here to say something like "blabla is not correct write only one color for cone-type, i kow what i'm saying :) so some more expert remove that "yellow" that It is an obvious biasis due to RYB — Preceding unsigned comment added by 87.14.104.44 (talk) 15:41, 14 October 2015 (UTC)

About 24-bit RGB and 0.5 midpoint

As "old friends" we are, we meet again here. It is the second chance you (Dicklyon) request for a source for simple maths: 255×0.5 = 127.5 . "255" is the highest positive value within 8-bits (Do you need a source for this?); "127.5" is the arithmetic half, but bytes do not hold fractional values. Simple enough, you see.

You removed the original paragraph due to "irrelevant"... This a true unsourced statement! ;-) You know, I programmed frequently in digital image processing along years (see my user page), and I still. Perhaps what it is "irrelevant" to you has some importance to others. When programming, lets say, a other_color_model-to-RGB routine, the mid point issue should be taken into account. When we are talking about percentages, for example, the 0% to 100% range encompasses 101 integer elements (due the range is not 1% to 100%, a hundred integer elements) and so it has a perfect midpoint at 50%. Due to lack of a true 0.5 mid point, the 256 levels per component are always asymetrical around the 127 or 128 value, whatever you choose as 0.5 surrogate. Well, it can be irrelevant to you, but it leads to a little roundoff error in conversions. For example, the original Independent JPEG Group (IJG) source code (in which 99.9% actual JPEG code relies; as far as I know, up to date only Adobe has its own JPEG encoder) converts 24-bit RGB to YCbCr internally when encoding, following the JFIF format. At decoding, it reverts YCbCr to RGB, but original (255,255,255) white becomes (254,254,254) or lesser triplet. Not noticeable at eye on screen, but when printed, many printers output pure white (no ink) only at (255,255,255) and do halftoning on the (254,254,254) value, which is noticeable even at nak'd eye. Some good written JPEG decoders (as mine, but it is not a commercial available one) take into account this issue and they can back the (255,255,255) original value. Who matters for this? Every press agency! :-D

This kind of round-off errors result in the professional use of the 48-bit RGB, 16-bit/65,536 levels per component, to ensure the best transformations.

In every case, I rewrote the paragraph to avoid the "curiosity" parlance. The whole article is already tagged as "sources needed", so in this case a "citation needed" tag would be more polite. See you. -Ricardo Cancho Niemietz (talk) 11:17, 25 February 2008 (UTC)

I understand about roundoff error, It still seems to me that the mid-point is nothing special. Your personal experience or trivial mathematical deduction is not a good reason to add it. Please find a source or take it out. Dicklyon (talk) 16:25, 25 February 2008 (UTC)

Reference added. The personal experience I told about is just a practical example of the issue; the fact that I cited it doesn't imply that I mention the midpoint in the article as a result of it. "Irrelevant", "nothing special", "trivial"... you're still judging what is or not is valid... to you. By sighting your user page, I agree with the fact you're an expert in opticals, but I can't see there anything about digital color experience from a programmer's point of view. Do you have the authority to judge based on your own experience and not on that of the others? You'll be more polited if you put "citation needed" tags instead of simply deletion of those paragraphs that you're unhappy with; if there are errors, correct them, but if not, keep them as is or improve them. In the "24-bit representation" section, we're talking about digital binary (quantized) levels, and the midpoint is an issue to take into account. I suppose that many readers will take note of that, and I notice it. Yours. Ricardo Cancho Niemietz (talk) 18:16, 25 February 2008 (UTC)-

Thanks for the source. My point of the mid point is that it does not correspond to 50% intensity, nor any other special intensity, and in fact corresponds to different values depending on the gamma of the colorspace. It is not a "special" point in any way that I'm aware of, so when you speak of it as special, e.g. by saying "perfect gray (50%, 50%, 50%)", that's misleading, and, in my opinion, nonsense. So, since you found a source pointing out that 127.5 is not an integer, I won't object to that being mentioned. But don't go overboard and add personal misleading interpretations of that tiny factoid. Dicklyon (talk) 18:50, 25 February 2008 (UTC)

Where it is said the word "intensity"? And where the word "special"? I didn't use them. The word "perfect" was typesetted in italics, to denote a remarked use of this word, not its nominal meaning. I know by far that RGB is a relative color space, not absolute. The "perfect" was the "50%", not the "gray", and it was noted as an "example". Do we talk the same English? If my parlance and/or spelling is not absolutely correct, sorry. But many times you act as a censor, not as people who merely correct mistakes; your attitude seems to me this way, sorry again, I think you already know what I mean. And, *please*, use the discussion page first to exchange points of view instead of deleting anything. No comments about the need to demonstrate with references that 127.5 is not an integer number... Ricardo Cancho Niemietz (talk) 19:24, 25 February 2008 (UTC)

Sorry I didn't notice this comment (due to wrong indentation) before I reverted you again. You've added an unsourced statement about the "rule" that 127.5 be rounded up to 128. I am not familiar with such a rule, and consider it highly irrelevant if it exists. You persist in giving special treatment to 127.5; why? And an RGB color space can be absolute, but that changes nothing in the matter of this little dispute. I just want added assertions to have some basis in sources. Dicklyon (talk) 04:02, 26 February 2008 (UTC)

Our discussions are so long, that I don't indent & indent & indent up to infinity. I alternate indentation. You only must to read my adds. Again, once more time you dispatch the issue with "not familiar", "highly irrelevant", and yet by deleting. I explained here (read this section from its start) that the inherent asymmetry around 127 or 128 value in lack of a true midpoint 127.5 leads to roundoff errors in conversions, and I provide experience, practical examples and external references. But it is not sufficient enough to you. But, Who are you to decide? You persistently ask for sources. And Yours? Where is the source that says that the 8-bit midpoint issue is irrelevant in every context, etc? What is your experience in this field (image processing programming) to delete if "not familiar"? I insist again that I don't want to start a "war of editions", but you always delete first, then ask, even after changes to improve neutral parlance and longer explanations. I quote from Wiki the principle page Wikipedia:Staying_cool_when_the_editing_gets_hot, point 7:

«Try to avoid deleting things as a matter of principle. When you amend and edit, it is remarkable how you might see something useful in what you might be about to remove. Almost everyone – including you – has something useful to say. Deletion upsets people and makes them feel they have wasted their time; at the very least leave some indication of your rationale in an edit summary, if not in an entry on a Talk page or in a message to a user or users you think might be perturbed by your action.»

So you don't follow the Wiki polite rules. We are not discussing vandalism, original research or the like. I talk about attitudes: I write, you delete, I rewrite again, you delete again... systematically. When I made cleanup in this article, I rearrange, expand, clarify, add a more logical structure, remove redundance, simplify, add images and links... only compare this article's revisions dated february 18, 2008 (before my edits) and last edition of february 22, 2008 (my cleanup). But I didn't remove any bit of info. The whole article was tagged as "citations needed", and it keeps. Again, add cn tags if you want, but P-L-E-A-S-E don't delete my words!

Finally, if you persist in your attitude (i.e. by deleting), I'll start the next step 6 and beyond in the dispute resolution process (you give me no truce). And remember, I live in Madrid, Spain, Europe, so we are time biased. You start the day when I ended it, so be patient. Try to solve our disputes by talking, not by deleting (in absence of errors). This is extensible to all the other pages we are discussing in ("List of palettes" and the like). See you here tomorrow. Yours. -Ricardo Cancho Niemietz (talk) 10:14, 26 February 2008 (UTC)

OK, I read you talk, but didn't find much relevant to the point of contention. Why don't you stick to discuss article contents, and refrain from discussing me, so we can make progress? I'll look at what you did and see whether it needs work... Dicklyon (talk) 15:42, 26 February 2008 (UTC)

I was sticked from the first time (I myself created this section). Then you started to delete... Ricardo Cancho Niemietz (talk) 17:35, 27 February 2008 (UTC)

There, I found a ref about the effect of potential rounding accumulation in colorspace transformations, and rewrote it a bit, removing the focus on the irrelevant mid-gray number that was sourced to another unsourced wikipedia article you wrote. See if that sufficiently representts the point you were trying to get across. Dicklyon (talk) 15:56, 26 February 2008 (UTC)

Sorry, I can't undestand you (missing words?) Ricardo Cancho Niemietz (talk) 17:35, 27 February 2008 (UTC)

I will rephrase. First, please discuss the article topic; do not discuss me; I am irrelevant. Second, I did find, and add a citation to, a source about rounding of 8-bit color values. It didn't mention the midpoint, which is no surprise, since there is nothing special about the value 127.5. It is not in the "middle" in any very important sense. You had added a link to another article as a source; wikipedia is never a source, but espeicially so when the article you use is unsourced itself. Dicklyon (talk) 00:12, 28 February 2008 (UTC)

I already understood the first part, only the second was a bit mangled. I my previous editing, I did reference to a Microsoft's technical article which stands that in the Windows default palette, the (128,128,128) RGB triplet is called "medium gray" by Microsoft itself, and you removed it. Where is the reference to another Wiki article? Did you mean the link to the palette sample? If so, this was not a *reference*, but simple link. And you did it again: P-L-E-A-S-E, discuss first, reach an agreement and finaly edit, and not in reverse! Up to date, there was no errors nor inaccuracy in my previous editions, so you have no rigth to delete anything: improving is not simply deleting. Well, see you here the next time you'll delete my edition (in a few hours, I fear...) - Ricardo Cancho Niemietz (talk) 08:32, 28 February 2008 (UTC)

Sorry, I appear to have missed the microsoft reference. Anyway, the fact that they call [128, 128, 128] "medium gray" is still pretty irrelevant to the point of contention. It's a choice that Microsoft made; there's no evidence that it comes from rounding up 127.5, nor that 126 or 127 or some other number might be any less appropriate as a mediium gray. They chose from among the available integers; that does not imply that 127.5 should be rounded up, or is usually rounded up. Your assertion that "The rounded value 128 it is used instead as a rule" is still unsupported. So, I'll take it out again. And you're getting personal again when you say "you have no right to delete anything: improving is not simply deleting;" as an editor, I have a right to make and explain improvements; if that involves removing unsupportable claims, that's what I do. But let's talk about those claims, not about my behavior. Dicklyon (talk) 15:13, 28 February 2008 (UTC)

OK, I made a careful edit, leaving all the points and info except the "rule". I have no objection to this rule other than that it is unsourced. If you can find a reliable source to back it up, please do put it in. Lacking a source, please do not. Dicklyon (talk) 15:21, 28 February 2008 (UTC)

Maybe the word "rule" was so strong in English in this context. In Spanish, the word, along with the sense of "mandatory", "law", "normative" also means "general", "guideline". I was not talking about any intended standard; most likely, there is no more "rule" than that of round-up. But for your info, to programmers is more useful the value 128 than 127 as the component midpoint, because is more easy to ignore a non-existent "level 256" that deal with a non-used "level 255" when the midpoint 127 is chosen. I actually ignore if there are literature addressing specifically the "127 or 128 best midpoint" issue; if there are and I'll find it, no doubt I'll put here! ;-) Finally, I agree with your last edit, although I think that it departs from the original sense I intended for it; believe it or not, the lack of a true arithmetical midpoint in 24-bit RGB is a topic the programmers deal with, and the current edition seems to me not sufficient warning enough. -Ricardo Cancho Niemietz (talk) 16:08, 28 February 2008 (UTC)

As a programmer, I understand that choosing 256 as the limit makes it easy to represent 0.5, 0.25, etc. But as a color scientist I also understand that those values have no special significance, especially in a gamma-encoded RGB space, and statements that try to endow them with such are misleading. When do programmers need to deal with this special midpoint issue? I've done many years of image processing, and never needed to think about it. Dicklyon (talk) 16:14, 28 February 2008 (UTC)

It wasn't my intention to continuing the discussion, but the gamma has nothing to do, because if you want to output a gamma-mapped given input as a "perfect" 0.5, the problem is the same. But leaving gamma appart, take a look to the following "RGB to YCbCr" formula used in JFIF JPEG (here's the reference:):

JPEG-YCbCr (601) from "digital 8-bit RGB"
========================================================================
Y =        + 0.299    * R + 0.587    * G + 0.114    * B
Cb = 128   - 0.168736 * R - 0.331264 * G + 0.5      * B
Cr = 128   + 0.5      * R - 0.418688 * G - 0.081312 * B
........................................................................
R, G, B   in {0...255}
Y, Cb, Cr in {0...255}

As you can see, in the Cb and Cr lines there are a "0.5*B" and a "0.5*R". While performing floating point operations is more precise, it is also more slow, so faster implementations use integer arithmetic. So then, "0.5*B" when B is 255 can be either 128 rounded-up or 127 truncated. Well, in this case the programmer must select an appropiate value. Which? and Why? I cited you the Independent JPEG group source code as an actual example of failing in do so (at least, their original code; I don't actually know if it is fixed in more recent revisions). Well, I know you won't change your mind about the midpoint topic, and I already agreed with your last edit, but I hope you'll think about different fields of experience over the same subject gives different points of view. -Ricardo Cancho Niemietz (talk) 16:48, 28 February 2008 (UTC)

The problem is the same, as you say; in the sense that you need to have a rounding strategy. In the example of conversion to YCbCr, you would not usually pick a strategy that independently rounds the terms, but even if you did, the midpoint and max point are nothing special. Dicklyon (talk) 17:33, 28 February 2008 (UTC)

And I'm all for including different points of view, but they need to be sourced. Your personal experience an insights can guide you in what to write, but can't be what you rely on instead of sources. Dicklyon (talk) 17:35, 28 February 2008 (UTC)

Hum, you've been "personal" this time, and you contradict yourself when saying that mid and maxpoint are "irrelevant", but you found sources addressing roundoff errors in conversions. Well, I finish the question here. Bye. -Ricardo Cancho Niemietz (talk) 17:47, 28 February 2008 (UTC)

Damn, I hate it when I get personal like that; oh, well, maybe I'm human, too. But I don't see the contradiction that you speak of. Roundoff is relevant at all values, not at particular special values. Dicklyon (talk) 22:57, 28 February 2008 (UTC)

Wow. What a brouhaha. :-) FWIW, the Munsell system defines a gray that is at the mid-point in terms of human perception, namely N5/. That's 122,122,122 when rendered in sRGB with D65 illuminant. —Preceding unsigned comment added by Jive Dadson (talk • contribs) 12:14, 4 June 2009 (UTC)

Ricardo's massive edits

Ricardo, you've made huge changes, with lots of problem. In your most recent, you've mixed RGB and CMYK into device-independent and device-dependent, which totally confuses the picture. In your first, you said "No matter the range and precision employed, linear scale is assumed when dealing with abstact RGB colors" which, following on the description of 8-bit integer encoding is at least misleading and maybe very false, since 8-bit RGB values are never linear. And it's full of language problems that someone needs to help fix. And your rewrite of the noninearity section, focused on devices, missed the point, which is that standard RGB encodings are standardly nonlinear, and that one should not expect an encoded value near 50% to make anywhere near 50% of max intensity; instead of making this more clear you've made it more obscure. I don't mind helping with this, but I'd rather take it a step at a time, rather than try to repair such a huge series of edits. Anyone else have a good idea how to proceed, or want to volunteer to fix it? Or should I revert it all and let's start over incrementally, at a pace where we can move along with Ricardo? Dicklyon (talk) 15:29, 5 March 2008 (UTC)

No major misleadings, maybe spelling and parlance can be enhanced. There are "device dependent RGB" and "device independent RGB" terms out there. If you wish, you can survey the Appendix E of "Digital Newsphoto Parameter Record" (http://www.iptc.org/std/IIM/4.1/specification/dnprv4.zip) of the "Information Interchange Model" (IIM) file format from the Comité International des Télécommunications de Presse-Newspaper Association of America (IPTC-NAA) [1] used worldwide in press agencies as an encapsulted format to universal media file exchange. This file format can especify what color space is used with the encapsulted image file. Among other values, there are "RGB SMPTE", "sRGB" and "device dependent RGB", literally. In this context, "device dependent RGB" is that in which only raw image data is provided (an optional calibration matix can be specified, but it is not mandatory), so the final result is, in effect, device dependent. Along with the color space, there are a "Quantisation method" tag, in which values as "Linear reflectance/transmittance" and "Linear density" coexist with "Gamma Compensated" and so on. Yes, there was a linear-vs-nonlinear, dependent-vs-independent wars out there. We can talk once you have studied the papers provided, Dick. There are very technical, accurate and (overall) reliable sources, as you like. Yours. -Ricardo Cancho Niemietz (talk) 18:49, 5 March 2008 (UTC)

Ricardo, I'm quite familiar with the IPTC specs and the theory and practice of RGB image encoding. Notice that they specify a "Newsphoto Common Parameter Set" that is gamma compensated for a gamma of 2.22. This is very close to sRGB, and effectively interchangable with it. Most 8-bit RGB encodings can be assumed to be about like that unless otherwise specified. Linear encoding is rare, to the point of being largely irrelevant except internally in processing programs. And I'm very familiar with device-dependent versus device-independent color, which is why I'm distressed by some of your edits, such as this one. Dicklyon (talk) 19:04, 5 March 2008 (UTC)

Well, I can't see why. Devices which must be calibrated in the production process are mainly RGB ones: scanners, video cameras, computer screens, etc., and we're talking about RGB. CMYK is always a device dependent color space (the IPTC doesn't recognize a "CMYK device independent" color space, only a "CMYK device dependent one"), and is mainly the target color space for color printing. About linearity: for example, when you change the "brightness" to a digital photo with your favourite software (from Adobe, etc.), the program merely adds or substacts a given value for all pixel's components. Yes, simply arithmetic. It doesn't take into account the nonlinearity. If your monitor is calibrated by hardware, you effectively has changed a 50% for a 75% intensity if you add a 25% of brightness. It is the calibration, not the pixel values themselves, which achieves the effect. So "in abstract", the range is managed as lineal, and to output, not. Better this way you're familiar with IPTC, me too; along 9 years I was official provider for the Agencia EFE, the main Spanish international press agency, and the first in Spanish language over the world. Also 2 more years in a Spanish company that is listed in the IPTC document I refer. So both of us are specialists. -Ricardo Cancho Niemietz (talk) 19:22, 5 March 2008 (UTC)

You don't see why? All devices in the chain need to be calibrated, not just RGB devices; certainly the CMYK printers are a big part of that. As for photoshop changing the "brightness" by adding a constant, I'm unclear on what Photoshop operator you imagine does that, but it's certainly not the way to change what we would usually call brightness; it is closer to what the "brightness" control on a TV does, which is to displace the black level. Your comments about "lineal" make no sense. It's true that many editing operations are done without regard for the nonlinearity, and that's sometimes OK and sometimes not; but let's don't confuse the issue with that question. Dicklyon (talk) 03:47, 6 March 2008 (UTC)

OK, I fixed the worst of it. Please let us know here if you think that anything I've said about gamma is untrue or misleading. Dicklyon (talk) 04:17, 6 March 2008 (UTC)

Many issues:

• The "professional calibration" section it is not focused on RGB. It is very vague and general, and it doesn't cite any color space. As is, it fits better in the "color calibration" article as a summary, than here. I simply tried to focus on RGB, and by citing CMYK as a common example (not the unique) of device-dependent color transformation. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

But adding RGB and CMYK as you did changed the meaning to make it too narrow to be correct. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Surely, my English parlance wasn't accurate enough, but that's was the idea. We should to find a way to focus the section on RGB in an environment about general color calibration. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

• The brightness in image editors, as Photoshop, was only a very simple example. If you wish to do the experiment by yourself (with Photoshop): a) Create a new RGB image; b) Select (128,128,128) as background color; c) Select all, and delete; d) Show info panel, with RGB pixel values—every pixel is (128,128,128). e) Go to Image menu → Adjust → Brightness/Contrast. f) Set brightness value, lets say, to +20. When you point with the mouse to any part of the image, the info panel says "128/148" for every RGB component. Try other values: -20 gives you "128/108", and so on. If you choose OK, evey pixel has the new value. Except for output and color space transformations, every adjustment, filter, layout effect, etc. is done linearly. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

OK, to humor you, I did the experiment, but I did it with more different values than 128. It is very clear that you're wrong. Now it's your turn to do with numbers other than 128 and see that it's not just an addition or subtraction. But it's a stupid point, so I don't mind if you ignore it. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

I chose 128 because is a value from which is easy to add or to substract other values. I would swear that the experiment is right, either with 128 or with any other value. PS version? Incorrect explanation? Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

CS 3. Did you try it with other numbers? Because the "brightness" is really a multiplicative change, not additive. But I don't remember how we got onto this irrelevant side track. Dicklyon (talk) 07:45, 7 March 2008 (UTC)

I moved this question to private field. Check your e-mail. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

• Why did you remove the 16.7 millions of colors information? It was in the better place to say that. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Because it's such pointless numerology, thrown into the middle of a discussion about color. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

But it was in the 24-bit representation, so 256³=16.7 million figure should be cited (also it is cited some paragraphs above, but I think it is at incorrect or worst place). Perhaps better "16.7M combinations" instead of "16.7M colors"; but 16-bit Highcolor section says how many combinations they provides. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

With 16 bits it make make sense to talk about how many, though many of those will be indistinguishable. With 24-bit color, the number is so high as to be pretty meaningless. What is the point of computing and stating such a number? There is none. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

There are "millions of colors" parlance out there to refer to 24-RGB truecolor. Why not put the figure? Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Why not use the "parlance" that's out there? They call it "millions" because the number is irrelevant (and misleading, in my opinion). Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Do you like "... it provides more that 16 millions of combinations..." or similar? Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

• Why did you remove the hexadecimal notations? For the 8-bit case, it was there before my edits, and it was not mine. I simply put it with its decimal counterpart, not as isolate one. Hex notations are in spread use (e.g. HTML colors, etc), so they sholud be cited here. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Again, distraction from the point of the discussion at that point. If you want a section on notations, add one. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

0-to-1, percentages, 8-bit... all of them are both representations and notations. The mere lines about hex in their respective points, talking about computing, are natural and logical, and they allow to introduce "HTML color notation", widely used. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

I disagree. Range of numbers make sense as part of an RGB color model. Notations for making text strings out of them don't fit in that same class. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Hum, it is at least debatable due to when talking of bits per component (8 or 16) we are talking about computers, and the hexa notation is in widesprad use (the HTML colors again as common example). Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

I thought you were the one objecting to making the content too particular to computers. Dicklyon (talk) 17:52, 7 March 2008 (UTC)

• Why did you remove the 16-bit per component red color example (65535,0,0)? Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

That must have been a slip. But it is pretty silly to keep repeating such things. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

All or none! Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Why do you say that? Dicklyon (talk) 22:47, 7 March 2008 (UTC)

To be consistent. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

See [2]. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Ha, ha... Well: I propose you to include a table with all possible variants of the red example (excluding hexa if you prefer). This way, the red examples were not inserted and repeated in text, but as figures apart. Do you agree? Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

• An almost incredible thing: you said to me that there is no such thing as to obtain 50% output from 50% input, but you reverted the whole "nonlinearity" section, which actually says that "(0.5, 0.5, 0.5) achieves about 22% instead of 50%"! Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Why are you saying that's a slip? In a gamma=2.2 gamma-corrected system, such as essentially all RGB representations stored in image files or transmitted as NTSC signals, an encoded value at 50% of the range represents 22% of full scale intensity. Maybe it need to be made more clear? Dicklyon (talk) 22:47, 7 March 2008 (UTC)

But this is *exactly* what my edit said! Why revert it? And the current edition says "computer display", when gamma is not only for computer displays, but also TV sets, TV cameras, etc. I think we must to break the current gamma-and-computer link, due to it can be misleaded as "gamma is only for computers". Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

I must not have understood your edit, then. I took out the too-narrow restriction to computer, as that's a valid point. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Well, I must to practice my English yet... but this was my intention, anyway. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

• You removed my little explanation about the origins of gamma issue. You shouldn't assume previous knowledge by the reader. The origin of the gamma nonlinearity is TV CRT screen behaviour (do you can deny this?). If RGB is so widespread today is thanks to TV, the first electronic RGB device. Other different RGB devices with different technologies, as scanners, are nonlineal too, but not always due to gamma, and I think all of this should be noted. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

The origins of the gamma issue are discussed (iirc) in the gamma correction article. For the RGB color model, what's important is that gamma is part of the model for encoding. If you'd like to add a section on device origin and device variations in gamma, that would be OK, but don't let it get confused with what the model and standard encodings are, which are not device dependent. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

But you assume that a casual reader should alredy know about what gamma is, or from where it comes. My explanation wasn't very extent; of course, further details in the main gamma article. I think my paragraph clarified this (up to a point). Also, you insist in that gamma-correction is part of the RGB model per se, but I think that really is part of a given application of the RGB model, beyond merely mix R+G+B values. When artists use RGB colors in graphic apps (no only photo: illustration, web design, video, etc.) they don't care about gamma when selecting numeric RGB values, but assume their equipment is gamma-calibrated (today, typically done by hardware). They freely select values in the range 0-255 for every component, without gamma in mind; that is, they think linearly. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

I believe you very much misunderstand gamma. When as an artist you select colors by number, you are selecting in a nonlinear gamma-compressed space; you don't need to know that, but it is an error to say that it is linear. It really doesn't matter whether you equipment is correctly calibrated or not. If you think linearly, that won't bother me, but don't let that error creep into the description. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Well, it is "linear" in the sense the artist choose the 128 value as 50% intensity component value, 64 for 25% intensity, etc. within the 8-bit range 0-255, and with that selected value pixels' component are filled. Maybe the problem is the word "linear", but when you said "a nonlinear gamma-compressed space" you are in fact "linearizing" it. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

Would it perhaps be more useful to help the artist understand that choosing 128 gives about 22% intensity (on a PC gamma=2.2 system) or 29% (on an old-standard Mac or a gamma 1.8 system)? This is what nonlinear means. Maybe the artist doesn't have reason to care about the actual intensity, but let's not mislead anyone into thinking that it is linearly related to the 8-bit RGB numbers. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Well, I'm actually dislike the linearity paragraph in the "numeric representations" section, but even I don't think that it should be sticked to the 8-bit per channel (that only you included it, remember) representation. When I did my "massive" edit, I only rewrote a previous paragraph which cited nonlinearity in order to respect the original idea (but possibly messing up the things more yet... :-). I really think that nonlinearity should be noted only in its correspondent section, but neither in the "numeric" nor "digital" representation sections. And about artists, they presume calibrated environments (at least, if they want to get money from their works :-), so even if artists understood the gamma question, they won't think about it anymore. Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

In order to do not start a "war of editions", please comment every point, as we can reach an agreement. Yours. -Ricardo Cancho Niemietz (talk) 10:47, 6 March 2008 (UTC)

Good. Dicklyon (talk) 15:42, 6 March 2008 (UTC)

See you. Ricardo Cancho Niemietz (talk) 19:19, 6 March 2008 (UTC)

Greetings again. Ricardo Cancho Niemietz (talk) 16:34, 7 March 2008 (UTC)

Soon again. Ricardo Cancho Niemietz (talk) 16:34, 7 March 2008 (UTC)

This discussion is impossible to follow, given its formatting, so I'm not going to try. Either of you want to summarize any decisions you've made? --jacobolus (t) 21:48, 7 March 2008 (UTC)c

Sorry, I should have signed my replies. I'll go back and do that. I'd say in summary that I can't understand Ricardo's point half the time, so I'm going to focus on the article contents instead of the talk. Dicklyon (talk) 22:47, 7 March 2008 (UTC)

Well, I signed my posts too. As I said, in order to avoid a "war of editions", I put and discuss every issue. Some points we have reach an agreement, but not the others yet. I made not only complains but also many proposals, some of them not answered by Dick yet. Follow every point of discuss. I hope a 3O can help us to unlock the points. The main of my POV is that the current edit assumes previous knowledge by the reader of many related topics (gamma, calibration, use of hex notations, linear use of the RGB numeric space, etc.) and much of Dick's POV about his experience on RGB that is not shared by many actual uses of the "RGB model" (which is not the same that a given specific "RGB color space"; he mainly assumes NTSC usage of RGB as if it were "universal"). Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)

I'm fairly happy with the way you two are working things out. Let me know if there are any sticking points where my input would be helpful. I agree that perhaps the article isn't as self-contained as it could be, or as well organized, and that the introduction could be greatly improved. In particular, I think the introduction should explain what the applications are of RGB (i.e. what kinds of output devices use it). Then the first section after that should be a summary of Additive color. Subsequent sections can dive into more detail about the history of RGB, specifics for different displays, and all the other things that are currently there. --jacobolus (t) 22:33, 10 March 2008 (UTC)

(as an unrelated example about what I mean by “self-contained”, take a look at the Comet (programming) article I wrote a few months ago, which devotes at least 500 words in the first section to merely providing the context for the rest of the article. --jacobolus (t) 22:38, 10 March 2008 (UTC))

I already added your suggestions. Take a look and enjoy them! I hope Dick will aid to give the article a bit more proffesional spelling. Yours. -Ricardo Cancho Niemietz (talk) 12:05, 11 March 2008 (UTC)

References

Expanded article

Hi. I did again. This time, I hope, with no controversial points. Mainly, rearranging of sections, and a basic missing one added: how RGB are combined to produce colors. I'll try to put references next days. Sorry in advance for typos and copyedit work that can be needed. Yours. Ricardo Cancho Niemietz (talk) 20:52, 10 March 2008 (UTC)

I'm traveling, with limited net access, so I'll have to let someone else look at it. Dicklyon (talk) 09:43, 11 March 2008 (UTC)

I expanded the article even more, following some of the suggestions Jacobolus made in the previous section. I tried my best to avoid conflicting points, but surely you'll want to do some cuttings... Please, read carefully before acting. This article now is focused in many aspects of RGB color mode practical usage, not only theory. I think this way it can serve as the main root for the many RGB related articles found in the Wikipedia. See you. Ricardo Cancho Niemietz (talk) 12:17, 11 March 2008 (UTC)

Ricardo: The changes here from today w.r.t. gamma encoding of images seem to me like POV-pushing, and I am going to revert them unless a very good reason is given not to, since removing the passages about gamma encoding makes the article noticeably less accurate for readers. Provide some sources please. --jacobolus (t) 22:14, 17 March 2008 (UTC)

Sorry, I'm not sure you are talking about. In part 'cos I'm not an native English speaker and your lines are a bit obscure to me, and part because I can't understand you when talk about "removing passages". What passages?Ricardo Cancho Niemietz (talk) 15:27, 18 March 2008 (UTC)

I have incorporated Ricardo's point that 8-bit linear is sometimes used even if it's not considered sufficient, and lots of other corrections, but I've also taken out a lot of junk like the amateur history in the lead, which was all wrong with respect to early color photography, which was initially RGB. This wasn't something to go so much into in the lead, and we already have a history section that's better. I added a source about "additive" after surveying many possible ones. Dicklyon (talk) 04:19, 18 March 2008 (UTC)

In my previous lead, it stated that RGB was only used in early photograph, not modern, so it was not wrong. You add references to a very obscure, for technical, definition of "additive color". Not incorrect, only obscure. And in subtractive color models, you "add" ink to "subtract" intensity, so this opposition should be noted, as in my previous edit, I think. Also, you reverted to a previous edit by Mfc which says "This article does not discuss about RGBA..." while my edit said "Not to be confused (RGB) with RGBA...". Then you wonder why the article talks about RGBA... Please, read carefully anything you want to revert massively. Also, a couple of good points are missing after your revertion. Read or compare versions, please. Ricardo Cancho Niemietz (talk) 15:27, 18 March 2008 (UTC)

I see your point on the RGBA; I think I'll just take it out of the lead; I was reacting to your use of a fragment where a sentence would be more appropriate. As to the history bit that I removed from the lead, I don't know who wrote it, but it mixed up some not quite right hsitory fragments and some non-RGB commentary in a confusing way; what it said was "...but it was not widely used until then. Modern color photography and color films rely on sensible emulsions for more or other than red, green and blue light, so they are not RGB proper. The first commercial application of the RGB was in color TV. With dawning of the computer age and digital equipment, RGB was not only employed to capture and display, but also to store, manage and manipulate color images, both still and in motion. Color print relies on pigments using subtractive color models, which are not RGB related." Dicklyon (talk) 17:42, 18 March 2008 (UTC)

Well, perhaps a bit disordered, but there are no lies there. Some of you can rewrite it better than me, for sure. But I dislike your new "CMYK color printers" cite in the lead: some devices (as those of Kodak and Canon) employ true photographic paper which is impressed with RGB lights, and they are "printers" too. Still the "additive" definition remains obscure. Perhaps we can cite the "wavelenght" after to explain "the higher the component intensities the higher the resultant color intensity" or the like. Remember: subtractive color model "adds" ink to "subtract" light intensity. It should be noted. Also, the nonlinearity phrases in the 0-255 and 0-65535 numeric ranges sound redundant with the following paragraph. I vote to remove them (also the 0-to-1 range is nonlinear in some transformations, and it is not remarked), leaving only the paragraph, which is not "digital-dependent": it can be applied also to voltages. Also, the last luma-chroma section still lacks my edits (which were not untrue) that you removed. See you. Ricardo Cancho Niemietz (talk) 19:35, 18 March 2008 (UTC)

Certainly nobody is accusing anyone of lying, just don't need extra amateur history in the lead when we have a good section on it. As to the printers, even those that expose photographic paper with RGB lights are CMY processes, just like the modern color films, in terms of how the actual colors are reproduced by colorants, wouldn't you agree? Dicklyon (talk) 19:41, 18 March 2008 (UTC)

Hum, positive photograpic paper is subtractive, no doubt, but I'm not sure that it is actually pure CMY. I remember that photographic film & paper have more than three layers (up to five or six). Hum, maybe better do not mess up things: any on-paper media is subtractive and period. No citing CMYK, CMY or the like would be better. And what about my other claims? Ricardo Cancho Niemietz (talk) 19:50, 18 March 2008 (UTC)

Sorry, I've lost track of "other claims". I fixed the CMYK. Dicklyon (talk) 21:28, 18 March 2008 (UTC)

Pseudocolor in Pure and Applied Mathematics, a Free on-Line e-Book with Source Code

Please see my Talk page for this insertion. Doug youvan (talk) 05:07, 26 May 2008 (UTC)

Wrongly misdirected to RGB

I wanted to learn about RGBI, a kind of color generating hardware system, where red, green, blue, and intensity contribute to a kind of color) but somehow got misdirected, and ended up at RGB instead.

What is the difference between RGBI when it comes to graphics cards, and RGBA? I have been told that CGA graphics cards come close to producing the kind of signal you find in RGBI.

The article could be improved by talking more about RGBI, especially in terms of graphics chips like the 8563 that was once available in the Commodore 128. 198.177.27.16 (talk) 01:43, 26 January 2009 (UTC)

RGBI seems like a rare variant term for the IBM 5153 interface. I don't find it in books. It's a 4-bit palette interface; see: A. Kumar (2002). Encyclopaedia of Management of Computer Hardware. Anmol Publications. p. 1050. ISBN 9788126110308.. (I added this citation to the color graphics adapter article) Dicklyon (talk) 02:12, 26 January 2009 (UTC)

(94.182.13.101 (talk) 12:15, 2 October 2009 (UTC))

Question

I've got a question...you know, light helps us see the color of objects, right? as it was said, the main lights are Blue,Red and Green. and the main colors are Blue, Red and Yellow. I was wondering why they are not the same? why we've got Green for light and Yellow for color? I just feel they should be the same...maybe this is non-sense...but can anybody explain it to me plz?

email me plz : foojan.hoodeh@gmail.com

Apparently we need more "see also" links or other links to RYB color model and opponent color to help you find what you need. Dicklyon (talk) 16:08, 2 October 2009 (UTC)

That's not all we needed. See #Additive vs. subtractive models, or, How techie can we get?. --Thnidu (talk) 08:18, 14 February 2017 (UTC)

RGB is a device-dependent color space?

One of the introductory paragraphs states

RGB is a device-dependent color space: different devices detect or reproduce a given RGB value differently, since the color elements (such as phosphors or dyes) and their response to the individual R, G, and B levels vary from manufacturer to manufacturer, or even in the same device over time. Thus an RGB value does not define the same color across devices without some kind of color management.

Can we make such a blanket statement? I mean, yes, different devices do reproduce color differently and so on, and yes, one does need color management in order to achieve good results – but that doesn't mean sRGB or Adobe RGB are device-dependent color spaces. Speaking of which, this article is about the model, not about the space, so why even bother? Of course we could mention device dependency of the native RGB color space of all devices, but that should be placed in the proper context – most modern devices tend to support color profiling (at least in theory, even consumer-grade P&S cameras output sRGB).

Or am I interpreting all this upside down? --Gutza ^{T T+} 20:56, 2 October 2009 (UTC)

Merger proposal: Truecolor and Deep Color

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result was Merge.

---

Hi. Everyone I'm here to suggest Truecolor and Deep Color articles to be merged into this article, respectively into "The 24-bit RGB representation" and "Beyond the 24-bit RGB" section due to their overall small length and similarity of context:

• Truecolor, apart from being relatively small, covers exactly the 24-Bit RGB representation as it defines Truecolor as:

Truecolor is a method of representing and storing graphical image information [~snip~] in an RGB color space [~snip~]. Usually, truecolor is defined to mean at least 256 shades of red, green, and blue, for a total of at least 16,777,216 color variations.

• Deep Color on the other hand, attempts to cover its subject as term that describes wide gamut in RGB, xvYCC and YCbCr color spaces but ultimately fails. It has one or two sentences that is worth being merged into this article. The rest can be deleted, or merged into xvYCC and YCbCr articles.

I'd like to know your opinion on this matter. Please cast your votes too.

Regards, Fleet Command (talk) 18:23, 31 October 2009 (UTC)

Support the merge proposal. There is insufficient material for "deep color" to retain its own article. Ditto on Truecolor. N2e (talk) 00:34, 10 March 2010 (UTC)

Support +1 As HDMI is expanding & Window 7 is supporting higher colour depths it is not going to be a separate topic, just one more variant. 60.242.97.120 (talk) 21:50, 20 March 2010 (UTC)

They should be merged into color depth instead, though some of the information can go here too. –jacobolus (t) 23:31, 20 March 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I don't know color name

I don't know English name of the color RGB 136 71 75. 121.102.47.215 (talk) 06:23, 17 April 2010 (UTC)

I don't know English name of the color RGB 207 172 132. 121.102.47.215 (talk) 06:32, 17 April 2010 (UTC)

Color naming is pretty much arbitrary. Personally, I’d call the first one   “brown”, and the second one   “tan”. –jacobolus (t) 15:24, 19 April 2010 (UTC)

TrueColor isn't complete.

The article says: "The human eye is popularly believed to be capable of discriminating among as many as ten million colors." Subtext: truecolor is good enough.

But when I look at a color gradient 1, I can clearly see color banding in the green and gray bar. I can't believe we have gone 20 years without upgrading to deep color. It's just ridiculous. Can someone find a ref that truecolor isn't perfect?--71.194.190.179 (talk) 04:30, 2 November 2010 (UTC)

(1) I don’t think the “subtext” that you are reading in here is implied by that sentence at all. (2) Your linked GIF image is not “true color”. GIFs are palletized and limited to 256 colors per file. –jacobolus (t) 17:44, 2 November 2010 (UTC)

I removed that sentence though. I agree with you that it’s out of place here. –jacobolus (t) 17:51, 2 November 2010 (UTC)

Okay, but look at the png. It is truecolor and you can clearly see banding in it.--71.194.190.179 (talk) 22:59, 2 November 2010 (UTC)

Here’s Mark Fairchild on “how many colors there are in the world”: “They have shown that we can see about 1000 levels of light-dark, 100 levels of red-green, and 100 levels of yellow-blue for a single viewing condition in a laboratory.[...] Since [...] the variety of viewing conditions and observers is endless, [...] the only truly correct answer is infinity.” [3] I’m not sure what you’re getting at, but computer displays obviously can’t reproduce the visual experience of the world. –jacobolus (t) 00:26, 3 November 2010 (UTC)

Hey RaptorHunter, the problem is that the way the sentence about TrueColor you keep putting back are worded, the statement is somewhere between oversimplified and misleading. It is true that the human eye can distinguish more colors than any displays today can produce, but the main reason is lack of dynamic range and color gamut (esp. in a normally lit room), not because they’re quantized into 256 bits/channel per se. It’s quite possible to make an image that has a very very smooth looking gray gradient (to an extent that you won’t be able to distinguish any transitions) by allowing the {R, G, B} components to have slightly different values than each-other, and by dithering. Unless you have a reliable source (by a real color vision expert, not just any old published book) which talks about specifically the limits of TrueColor relative to human vision, I’d really rather leave the section out, because it’s not directly relevant to the scope of that section. Better would be to have a section by itself about the differences between human perception and RGB, in gamut, dynamic range, etc. etc., but that would take some real research to write, and I don’t plan to write it. Cheers. –jacobolus (t) 07:59, 16 November 2010 (UTC) [Update: bolded key section.]

That sounds great. You obviously know a lot about this so go ahead and add that section.--RaptorHunter (talk) 08:18, 16 November 2010 (UTC)

Split proposal

The digital representations section is not really about the RGB color model, and would be much better suited in the color depth article, yes? Dicklyon (talk) 04:41, 11 January 2011 (UTC)

Not sure color depth is quite the right place, but I agree with you that it’s definitely out of scope here. –jacobolus (t) 11:27, 11 January 2011 (UTC)

Colour!

I've noticed that colour is misspelt color 284 times. — Preceding unsigned comment added by Babysabre (talk • contribs) 05:19, 4 March 2011 (UTC)

In case you're not being facetious, please note that Wikipedia is American. I'm British, but I do understand American - it's one of the easiest languages to learn! (now I'm being facetious) nagualdesign (talk) 21:07, 23 March 2011 (UTC)

True colour

User 174.1.97.241 has made a long list of changes today, some minor, some incomprehensible (I don't think he or she meant any malice), but it has raised a question: Is it Truecolor, truecolor, True color or true color? The article - in fact the whole of Wikipedia - now uses them all interchangeably. Surely there should be some consensus on this before anyone takes it upon themself to make blanket changes (perhaps there was?), which introduce multiple 'errors'. nagualdesign (talk) 20:58, 23 March 2011 (UTC)

Yes, it's a mess. I think we need to revert it all, as it goes the wrong direction, away from spitting this material out to a sensible place; and masssive change sequences with zero edit summaries are anti-collaborative anyway. As for truecolor, when it had its own article, it referenced Poynton, who used the term as one-word, non-capitalized; whoever did the merge did it incompetently, and dropped the references. So there's work to do. Dicklyon (talk) 21:24, 23 March 2011 (UTC)

Removed section

Here is material than can be merged to color depth if anything is not already well enough represented there:

An example of bit groupings in the most common layout of a 24 bit pixel

Pixel samples in a common 24 bit pixel

As usual in computing, the sample values can be represented either in decimal and in hexadecimal notation as well, as is the case of HTML colors text-encoding convention.
The universal RGBAX notation can be used to describe the particular assignment of bit groups in a pixel to a particular channel sample.

Truecolor

Truecolor is a method of representing and storing graphical image information that allows a very large number of colors, shades, and hues to be displayed in an image, such as in high quality photographic images or complex graphics.
Truecolor defines 256 (2⁸) shades of red, green, and blue for each pixel of the digital picture, which ultimately results in 256³ or 16,777,216 (approximately 16.7 million) color variations for each pixel.

Truecolor RGB display mode does not need a color look-up table.

The 24-bit RGB representation

In the 24-bit RGB representation of the truecolor, color values for each pixel encoded in a 24 bits per pixel fashion in which three 8-bit unsigned integer (0 through 255) represent the intensities of red, green, and blue.

A typical sample layout of a 24 bit Truecolor pixel (in RGBAX notation)

Pixel samples in a common 24 bit pixel

This representation is the common color interchange format in image file formats such as BMP, JPEG, TGA or TIFF.

The following image shows the three "fully saturated" faces of a 24-bit per pixel RGB cube, unfolded into a plane:

(0, 0, 0) is black (255, 255, 255) is white (255, 0, 0) is red (0, 255, 0) is green (0, 0, 255) is blue (255, 255, 0) is yellow (0, 255, 255) is cyan (255, 0, 255) is magenta	yellow (255,255,0)	green (0,255,0)	cyan (0,255,255)
	red (255,0,0)		blue (0,0,255)
		red (255,0,0)	magenta (255,0,255)

The 256 levels of a primary usually do not represent equally spaced intensities, due to gamma correction.

This representation cannot offer the exact mid point 127.5, nor other non-integer values, as bytes do not hold fractional values, so these need to be rounded or truncated to a nearby integer value. For example, Microsoft considers the color "medium gray" to be the (128,128,128) RGB triplet in its default palette. The effect of such quantization (for every value, not only the midpoint) is usually not noticeable, but may build up in repeated editing operations or colorspace conversions.

Typically, RGB for digital video is not full range. Instead, video RGB uses a convention with scaling and offsets such that (16, 16, 16) is black, (235, 235, 235) is white, etc. For example, these scalings and offsets are used for the digital RGB definition in the CCIR 601 standard.

The 32-bit RGB representation

Example of a truecolor image with semi-transparent and transparent portions, displayed on a checker background

Apart from the 24-bit representation of Truecolor, there are 32-bit RGB representations, all of which still represent 16,777,216 colors. (These 32-bit representations should not be mistaken or confused with Deep Color schemes explained further below.)

In some graphic cards, the so-called 32 bit per pixel display graphic mode is identical in precision to the 24 bit per pixel mode; there are still only eight bits per component, and the eight extra bits are often not used at all. The reason for the existence of such 32 bit representation is the higher speed at which most modern 32-bit (and better) hardware can access data that is aligned to the 32-bit-long word addresses, compared to data not so aligned.

A sample layout of a 32 bit pixel in some graphic cards (in RGBAX notation)

Pixel samples in a common 32 bit pixel

Some graphics hardware allow the unused byte of the 32-bit mode to be used to display an overlay picture, such as mouse cursor, on the main image, without altering the image itself. In this mode, the overlay forms an 8-bit paletted picture. A certain value (often 0 or 255) is designated as being transparent: Where the overlay pixel value is this value, nothing is drawn on the truecolor image. Otherwise the overlay value is looked up in the palette and used. This feature was often found on graphics hardware for Unix workstations in the 90s and later on some PC graphics cards (most notably those by Matrox). However, PC graphics cards (and the systems they are used in) now have plentiful memory to use as a backing store and this feature has mostly disappeared.

However, with the need for compositing images came a variant of 24-bit RGB which adds an extra 8-bit channel for transparency, thus resulting also in a 32-bit pixel format. The transparency channel is commonly known as the alpha channel, so the format is named RGBA. Note again that since it does not change anything in the RGB model, RGBA is not a distinct color model, it is only a representation that integrates transparency information along with the color information.
This extra channel allows for blending of the image with another, and is a feature of the PNG format and modern BMP file format.

A sample layout of a 32 bit pixel with Alpha channel (in RGBAX notation)

Pixel samples in a 32 bit pixel with Alpha

Beyond truecolor: deep color

See also: Color depth § Beyond truecolor

Deep color is a term that refers to a gamut comprising more than 16.7 millions of colors. Deep color not only involves producing/displaying more shades of color (gamut), but also storing colors at a higher accuracy (bit depth). In the former sense, wide gamuts such as xvYCC, scRGB and Wide Gamut RGB color space fall within the purview of deep color. In the latter sense, there are multiple representations of deep color in RGB color model.

In 30-bit Integer RGB color representation, colors are stored in three 10-bit channels, resulting in 30 bits of color data per pixel.

A sample layout of a 30 bits of color data in a 32 bit pixel (in RGBAX notation)

30 bit color samples in a 32 bit pixel

This representation may be employed to store 2¹⁰ or 1024 different values per channel, which enables the storage of 2³⁰ or 1,073,741,824 (approximately one billion) distinct colors.

In 48-bit Integer RGB color representation, high-precision colors are stored in three 16-bit channels, resulting in 48 bits of color data per pixel.

Sample layout of a 48 bit pixel (in RGBAX notation)

sample layout in a 48 bit pixel

This makes it possible to represent 65,536 tones of each color component instead of 256, hence resulting a total or 2⁴⁸ or 281,474,976,710,656 (approximately 281 trillion) colors.

These representations, however, are not the only RGB representations of deep color. For instance, JPEG XR defines numerous other RGB representations, including some schemes which allow storage of floating point values instead of integers, thus enabling the storage of color data outside the visible range.

Adobe Photoshop supports creating and editing of images of up to 32 bits per channel (96 bits per pixel). This allows maintaining greater precision when a sequence of more than one image filtering algorithm is used on the image. With only 8 bits per component, rounding errors accumulate more quickly with each filtering algorithm that is employed, degrading the end result.

Limited representations below 24-bit RGB

16-bit RGB (Highcolor)

A 16-bit pixel format known as Highcolor, in which there are either 5 bits per color, called 555 mode which in actuality is a 15-bit color mode (32,768 total colors)

Sample layout of a 15 bit color data in a 16 bit pixel (in RGBAX notation)

Sample layout of a 15 bit color data in a 16 bit pixel

The same pixel format with an extra bit for green (because the green component contributes most to the brightness of a color in the human eye), called 565 mode is a true 16-bit color mode (65,535 colors).
Sample layout of real 16 bit color data in a 16 bit pixel (in RGBAX notation)

Sample layout of a 15 bit color data in a 16 bit pixel

(In general, a good RGB representation needs 1 more bit for Red than Blue and 1 more bit for Green, but this can not be fully achieved within a 16-bit word.) This was the high-end for some display adapters for personal computers during the 1990s, but today is considered slightly obsolete in favour of the 24 or 32 bpp graphic modes. It is still in use in many low memory devices with color screens as cell phones, digital cameras, personal digital assistants (PDA) and portable videogame consoles.

RGB arrangements for 8-bit indexed color

Mosaic of image thumbnails rendered with a single shared master palette of 6×8×5 RGB levels plus 16 additional grays.

Display adapters and image file formats using indexed-color techniques limit the simultaneously available colors per image up to 256, 8 bits per pixel. The selected colors are arranged into a palette, and the actual image pixels values do not represent RGB triplets, but mere indices into the palette, which in turn stores the 24-bit RGB triplets for every color in the image, so colors are addressed indirectly.

Every image can have its own color selection (or adaptive palette) when indexed color is employed. But this scheme has the inconvenience that two or more indexed-color images with incompatible palettes cannot be properly displayed simultaneously where the 256-color limitation is imposed by the system's hardware.

One solution is to use an intermediate master palette which comprises a full RGB selection with limited levels to the red, green, and blue components, in order to fit it at all within 256 color entries.

Usual limited RGB repertoires include 6.6.6.0.6 format with 216 combinations (the Web colors case), 6.7.6.0.5 format with 252 combinations, 6.8.5.0.5 format with 240 combinations and 8.8.4.0.4 format with the full 256 combinations (see RGB arrangements for samples).

3-bit RGB

The minimum RGB binary representation is 3-bit RGB, one bit per component. Typical for early color terminals in the 1970s, it is still used today with the Teletext TV retrieval service.

References

nm

I was wondering what the exact wavelengths were that are produced by LCD displays, assuming that they align with our eyeballs. the article says:

The normal three kinds of light-sensitive photoreceptor cells in the human eye (cone cells) respond most to yellow (long wavelength or L), green (medium or M), and violet (short or S) light (peak wavelengths near 570 nm, 540 nm and 440 nm, respectively[3])

But Colors and materials seems to indicate 570nm is on the green end of yellow. Should it read 670nm (red)? I don't have the book to check and found no other data sources today. Raskalnickoff (talk) 09:52, 1 September 2011 (UTC)

First, I’m not sure what you mean by “assuming they align with our eyeballs”. Light sources (like, say, the backlight behind an LCD) produces light of many different wavelengths (there are some spectral power distribution charts for various light sources floating around the internet). Colors and wavelengths of light are not directly relatable, and the color of an object or light depends on not only the distribution of wavelengths emitted or reflected by it, but also on the human observer's eyes’ current state of adaptation, and on the colors of surrounding objects. It’s misleading to directly label L, M, and S cones with “yellow”, “green”, and “violet”. Second, I’m not sure what common LED colors have to do with the light emitted by generic LCDs. –jacobolus (t) 03:00, 2 September 2011 (UTC)

bad external link.

I did a check using Google Safe Search and the website listed in external links is quite full of Malware. Should it be removed and replaced with an alternative for user Security? Tnu1138 (talk) 16:46, 4 November 2011 (UTC)

Yes, immediately, and the site should be WP:Spam blacklisted if that's the case. Dicklyon (talk) 19:33, 4 November 2011 (UTC)

Which site are we talking about? http://www.cs.rit.edu/~ncs/color/a_spaces.html is not “full of malware” as far as I can tell, but it does include a Java applet. There’s nothing inherently suspicious about that. –jacobolus (t) 01:02, 5 November 2011 (UTC)

Primary colours

Are not the primary colours red, blue and yellow rather than red, blue and green? Yellow cannot be created by any mixture of red, blue and green as yellow is a primary colour, like red and blue. Green on the other hand are created by mixing blue and yellow. --Oddeivind (talk) 21:15, 23 March 2012 (UTC)

Not in an RGB device. I believe primary color has some discussion of this point. –jacobolus (t) 21:54, 23 March 2012 (UTC)

Red, blue, and yellow are the primary reflective colours - when you are viewing an object that is lit by light reflecting on it from another source (such as a lamp or the sun). This applies to almost everything, such as a photo, painting, landscape, contents of the room you're in, a person) because almost everything is not a light source itself. Red, blue, and yellow are the primary emitted colours - where the light source itself is generating the colour, such as a CRT or LED screen. -- hulmem (talk) 22:51, 23 March 2012 (UTC)

Are there any article explaining this in more detail? I am not sure if I understood that very well. When I see the colours i can clearly see that green has both blue and yellow in it, but as far as I can tell you cannot create yellow by combining any colours. --Oddeivind (talk) 09:56, 24 March 2012 (UTC)

I just took at look at the article about primary colours andit says:"Any choice of primary colors is essentially arbitrary". Arbitrary? I thought red, blue and yellow were primary colours because they cannot be made by combining any other colour. For instance you cannot create blue by combining e.g. green with red or yellow. --Oddeivind (talk) 10:12, 24 March 2012 (UTC)

I just noticed in my paint programme that it is possible to make yellow by combining an eual amount of red and green. How can this be explained? I thought yellow was a pure colour that could not be made by combining any other colour. Is my understanding of primary colours wrong? --Oddeivind (talk) 13:48, 24 March 2012 (UTC)

Yes, your understanding is wrong. Additive color and subtractive color might be helpful. For a longer explanation, see Handprint.com’s “do primary colors exist?” One key sentence there: ‘There is no historical source prior to the 18th century that starts with three "primary" or "primitive" colors and explains how to mix all other colors from them.’ Basically, the red-yellow-blue-primary-color idea is one that arose in the 18th century, stuck around through the 19th century, and was shown to be inadequate by late-19th-/early-20th-century scientists and researchers. If you want to mix the broadest possible set of colors from three paint pigments or dyes, your best bet is to choose CMY: “cyan” (greenish blue), “magenta” (purple–red), and yellow. If you want to mix the broadest set of colors from three lights, your best bet is to choose RGB: “red” (orangish red), “green” (yellowish green), and “blue” (blue–violet). But if you’re painting, you’re really better off starting with at least 6 or so “primary” pigments, or depending on your subject and style, maybe more like 8 or 10 or more. –jacobolus (t) 21:19, 24 March 2012 (UTC)

My high school's stage lights were incandescent, with glass filters giving essentially red, yellow, and blue! (along with incandescent white, perhaps). Ignorance actually made this happen! Trying to create green light by mixing yellow and blue simply did not work. (The lighting was installed probably about 1947 or so; dimmers were Autrastats, if that gives a clue.) At the time, we lived in a cultural backwater.

Art teachers are probably still telling their students that red, yellow, and blue are the primary colors. I dream of showing up at an art class with cyan, magenta, and yellow paints...

Nevertheless, mixing blue and yellow watercolors as a child gave a decent green. I suspect that spectral reflectance curves of those pigments, allowing for the illuminant spectrum, metamerism (maybe), and human eye colorimetry would explain why that happened. I've read that centuries ago, these were the best-available pigment colors.

I spent quite a bit of time trying to select felt-tip pens and liquid watercolors (dropper bottles), attempting to purchase yellow, magenta, and cyan. Laying down yellow on paper and overlaying with magenta (for me) creates a lovely red; yellow followed by cyan creates a nice green. (I'm having lots of trouble convincing myself that cyan is not a "light" variety of blue!) The pens I chose were Marvy 1500 series, No. 22, lemon yellow; No. 9, pink; and No 74, aquamarine. liquids were Dr. Ph. Martin's No. 1, lemon yellow; No.7A, moss rose; and 51D, ice blue. These make nice refills for the pens; vehicles seem quite compatible. Hope I'm not veering too far off-topic! Nikevich 19:06, 13 June 2012 (UTC)

The definitions of all of these terms are fuzzy. In a computer monitor, what get called “red”, “green”, and “blue” are really more like “orangish red”, “yellowish green”, and “blue–violet”. The cyan used in a 4-color printing process could be called “greenish blue” – it’s much more blue than green. –jacobolus (t) 20:55, 13 June 2012 (UTC)

@Nikevich, Jacobolus, and Hulmem: See #Additive vs. subtractive models, or, How techie can we get?. (Nice explanation there, Hulmem, maybe some of it should be added into mine?) --Thnidu (talk) 08:25, 14 February 2017 (UTC)

Request for expansion in section "History of RGB color model theory and usage"

Would it be possible to include a category about Art & Design in the section "History of RGB color model theory and usage"? There is the RGB project by Milan based art design duo Carnovsky that works on the interaction between additive colors (RGB color changing lights) and subtractive colors (printed CMYK or hand dyed fibers). The pieces are made up by the superimposition of images in subtractive colors. Under normal/white light, all the layers are visible at the same time giving life to unexpected and disorienting worlds where the colors mix up and the lines and shapes entwine becoming oneiric and not completely clear. When viewed through a Red, Green or Blue colored light the individual layers can be shown or hidden revealing the elements of the composition. With this technique they have done RGB wallpapers, RGB limited editions (prints, foulards, furniture) and installations around the world (Milan 2010/2011/2013 http://www.yatzer.com/RGB-Wallpapers-by-Carnovsky-for-Jannelli-e-Volpi , Berlin 2010 http://www.designboom.com/design/carnovsky-rgb-exhibition-at-johanssen-gallery/ , London 2011/2012 http://www.dezeen.com/2011/08/28/rgb-by-carnovsky-at-dreambags-jaguarshoes/ winning the wallpaper magazine design awards 2011, Tokyo 2011, Toronto 2011, Paris 2012/2013, Melbourne 2012, Portland (ME) 2012, Lille 2012, Amsterdam 2013 and Helsinki 2013 between others)

Reliable sources:

Arizona state University School of Art Core Program http://artcore.pbworks.com/w/file/fetch/55762430/Additive%20and%20Subtractive%20Color%20Michaelsen.pdf Artist to reference Carnovsky, Olafur Eliasson, Bruce Munro, Dan Flavin

Simon Fraser University of Canada, paper on Human color perception by Neuroscience Dr. Kathleen A. Akins http://www.sfu.ca/~kathleea/Colour%20Project.html http://www.sfu.ca/~kathleea/docs/B&W&C.FINAL.pdf Carnovsky’s RGB work is used to explain Luminance vision and Chromatic processing (from page 11)

Smithsonian Magazine September 2013 Color Issue http://www.smithsonianmag.com/arts-culture/the-art-that-is-hidden-in-plain-sight-750047/?no-ist This is the online preview, complete article in the printed magazine or http://www.scribd.com/doc/172066759/Smithsonian-September-2013-k page 14

Washington Post Article http://www.washingtonpost.com/blogs/innovations/post/carnovsky-paper-wallpaper-that-changes-with-the-light/2011/08/28/gIQAdgQ8lJ_blog.html

Forbes Article http://www.forbes.com/sites/haydnshaughnessy/2011/08/28/bringing-design-thinking-home-a-must-see-innovation/

Article in The Creators project from Vice magazine http://thecreatorsproject.vice.com/blog/carnovskys-rgb-landscapes-add-color-to-milan-design-week connects it to digichromatography (Prokudin-Gorsky photopgraphic work)

Color Association research RGB http://causnow.colorassociation.com/topic/profile/rgb/ Changing Landscapes

http://id-beta.fh-mainz.de/rgb-filtered-wallpaper/

Most read article on creative review http://www.creativereview.co.uk/cr-blog/2010/november/carnovsky-rgb-wallpaper-new-show

http://bldgblog.blogspot.it/2010/11/stationary-cinema.html

Articles in printed media http://www.carnovsky.com/press.htm

Lots of articles in online magazines and blogs just by clicking Carnovsky RGB on google or any search engine

Books

Graphics Alive 2 (2010) http://www.victionary.com/book/ga2.html ISBN 978-988-17327-0-5

Basics Interior Architecture 05: Texture + Materials (2011) http://my.safaribooksonline.com/book/design/9782940411535 ISBN 978-2-940411-53-5

Palette 02: Multicolour (2012) http://www.victionary.com/frameset%20multicolour.html ISBN 978-988-19439-0-3

Colour in the Making (2013) http://blackdogonline.com/all-books/colour-in-the-making.html ISBN13: 978 1 907317 95 8

New Graphic Design: The 100 Best Contemporary Graphic Designers (2013) http://www.amazon.com/New-Graphic-Design-Contemporary-Designers/dp/1847960448 ISBN-13: 978-1847960443

Installation Art Now (2013) http://www.sandupublishing.com/design360en/publicationshow_en.php?id=102 ISBN-13: 978-1584235149

Carnovsky is a Milan based art/design duo formed by Silvia Quintanilla and Francesco Rugi

Carnovsky's official RGB page http://www.carnovsky.com/RGB.htm

JackieB Capsaicin (talk) 16:23, 4 March 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on RGB color model. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20090306171954/http://www.ieee.org/portal/cms_docs_iportals/iportals/aboutus/history_center/publications/entertainment/Chapter2.pdf to http://www.ieee.org/portal/cms_docs_iportals/iportals/aboutus/history_center/publications/entertainment/Chapter2.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 12:33, 27 August 2015 (UTC)

Additive vs. subtractive models, or, How techie can we get?

See #Questions and #Question and #Primary colours. I cannot believe that in the nearly seventeen-year history of this article NOBODY seems to have mentioned the distinction between additive and subtractive models of color except the barely-relevant (to most readers of an encyclopedia) mention in the lede. --Thnidu (talk) 07:48, 14 February 2017 (UTC)

references on talk page

@Ricardo Cancho Niemietz and Dicklyon

After adding the above section, I of course looked at the page to check my edit, and found a whole bunch of references under it— twelve, to be exact. (Diff) So I tracked them down and inserted {{talkref}} at the end of the two sections that had them: mostly #Removed section (unsigned, though at the time it would've been clear enough), plus one in #Ricardo's massive edits. Sheesh! --Thnidu (talk) 08:15, 14 February 2017 (UTC)

RGB in television

What this article lacks is actual use of RGB in what a TV (not computer!) monitor is able to digest properly upon input, rather than 4:4:4 YUV (note: this is different from Y'UV, color subsampling, and wire crosstalk, none of which have to do with YUV itself). Yes, the display's decoding everything to RGB internally, but that doesn't make it an "RGB TV" as such that it displays it right if you're feeding it raw RGB rather than 4:4:4 YUV. In reality, only very, very few professional broadcast TVs exist that can actually properly read and display an RGB signal fed externally into them as most TVs on earth are actually made to interpret YUV signals, as well as very, very few professional broadcast RGB cameras existed (prior to the advent of HDV) that generated or output RGB rather than 4:4:4 YUV. So basically, what I'd like to see in the article is a reflection of this fact there's hardly any TVs (not computer monitors!) that can properly interpret an RGB signal fed into them, and very few video cameras, (video) disk-based or tape-based media that can generate, store, and output an actual RGB signal, rather than a 4:4:4 YUV signal.

This issue comes up especially with gamers who are so proud of claiming that they're "gaming in RGB" on their consoles particularly via SCART when in fact their TVs are only interpreting a 4:4:4 YUV signal sent via the same connection and pins, TV decoding it into RGB, and they believe that "YUV", other than their fake "RGB", would be identical to color subsampling, wire crosstalk, Y/C, and component, mainly because their TV input sockets are labeled "component", "Y/C aka S-video", and, falsely, "RGB". --79.242.203.134 (talk) 02:12, 6 July 2017 (UTC)

Image of spotlights on wall

Old

New

I have rendered a new 3D image of three spotlights shining on a wall. Would the new version be preferable to the old? ➧datumizer  ☎  00:34, 29 May 2019 (UTC)

I think the old one looks better. I actually thought it was a photo, while yours looks more obviously faked. Dicklyon (talk) 03:35, 29 May 2019 (UTC)

One, from the all, finest colors - amber. (Pitch, then rosin.)

Why ? 176.59.210.175 (talk) 18:54, 5 July 2020 (UTC)

RGB color model mixture guide

The RGB color model is an additive color model and, therefore, is used on a  White surface in a dark area.

Primary colors

 Red

 Green

 Blue

Secondary colors/Mixing primary colors

 Cyan

 Magenta

 Yellow

Mixtures:

 Green +  Blue =  Cyan

 Blue +  Red =  Magenta

 Red +  Green =  Yellow

Tertiary colors

Cyan shades

 Spring

 Azure

Mixtures:

 Green +  Cyan =  Spring

 Blue +  Cyan =  Azure

Magenta shades

 Violet

 Rose

Mixtures:

 Blue +  Magenta =  Violet

 Red +  Magenta =  Rose

Yellow shades

 Orange

 Chartreuse

Mixtures:

 Red +  Yellow =  Orange

 Green +  Yellow =  Chartreuse

Mixing secondary colors

Mixtures:

 Magenta +  Yellow =  Light Red

 Yellow +  Cyan =  Light Green

 Cyan +  Magenta =  Light Blue

All hues mixed

 White

Mixtures:

 Red +  Green +  Blue =  White

Color mixture between hues

 Red - 1 red

 Orange-Red - 7 parts red and 1 part green

 Orange - 3 parts red and 1 part green

 Orange-Yellow - 5 parts red and 3 parts green

 Yellow - 1 part red and 1 part green

 Chartreuse-Yellow - 3 parts red and 5 parts green

 Chartreuse - 1 part red and 3 parts green

 Chartreuse-Green - 1 part red and 7 parts green

 Green - 1 part green

 Spring-Green - 7 parts green and 1 part blue

 Spring - 3 parts green and 1 part blue

 Spring-Cyan - 5 parts green and 3 parts blue

 Cyan - 1 part green and 1 part blue

 Azure-Cyan - 3 parts green and 5 parts blue

 Azure - 1 part green and 3 parts blue

 Azure-Blue - 1 part red and 7 parts blue

 Blue - 1 part blue

 Violet-Blue - 7 parts blue and 1 part red

 Violet - 3 parts blue and 1 part red

 Violet-Magenta - 5 parts blue and 3 parts red

 Magenta - 1 part blue and 1 part red

 Rose-Magenta - 3 parts blue and 5 parts red

 Rose - 1 part blue and 3 parts red

 Rose-Red - 1 part blue and 7 parts red

Mixing a primary color with its complementary color

 Very Light Red

 Very Light Green

 Very Light Blue

Red and Cyan

 Red +  Cyan =  Very Light Red

Needs:

2×  Red

1×  Green and 1×  Blue to make 2×  Cyan

A total of 4 parts (2×  Red and 2×  Cyan)

Demonstration:

1×  Red + 1×  Green + 1×  Blue = 3×  White

1×  Red (remaining) + 1×  White (from the created mixture) = 2×  Light Red

2×  Light Red + 2×  White (remaining from the created mixture) = 4×  Very Light Red

Green and Magenta

 Green +  Magenta =  Very Light Green

Needs:

2×  Green

1×  Blue and 1×  Red to make 2×  Magenta

A total of 4 parts (2×  Green and 2×  Magenta)

Demonstration:

1×  Green + 1×  Blue + 1×  Red = 3×  White

1×  Green (remaining) + 1×  White (from the created mixture) = 2×  Light Green

2×  Very Light Green + 2×  White (remaining from the created mixture) = 4×  Very Light Green

Blue and Yellow

 Blue +  Yellow =  Very Light Blue

Needs:

2×  Blue

1×  Red and 1×  Green to make 2×  Yellow

A total of 4 parts (2×  Blue and 2×  Yellow)

Demonstration:

1×  Blue + 1×  Red + 1×  Green = 3×  White

1×  Blue (remaining) + 1×  White (from the created mixture) = 2×  Light Blue

2×  Light Blue + 2×  White (remaining from the created mixture) = 4×  Very Light Blue

colour not color

as stated in https://wiki.riteme.site/wiki/Wikipedia:FAQ/Contributing#Should_I_use_American_English_or_British_English?, "The official policy is to use British spelling when writing about British topics, and American for topics relating to the United States." as can be found out with a quick google search, RGB was created in London, England. Therefore we use British English — Preceding unsigned comment added by Germany FranceUK Australia Russia Latvia (talk • contribs) 02:01, 8 November 2021 (UTC)

That is for topics closely associated with one country or the other (we would use British English in the article about the Queen's biography). This article does not meet that standard. For example, Isaac Newton is English, but the article on gravity uses American spelling. See the full guidelines on this at WP:ENGVAR, which supersedes that FAQ you linked. In particular, see MOS:RETAIN. There are no strong national ties here, so the spellings should be left as they are. - MrOllie (talk) 02:09, 8 November 2021 (UTC)

Sorry for the late response, but can you please explain why we should use the spelling of one specific country and not the standard version used by every other country. Or is it just you aren't aware that not everyone is american and revert useage of non-american spelling because you can't agknologe other cultures. 11:19, 10 November 2021 (UTC)Germany FranceUK Australia Russia Latvia (talk)

Wikipedia had a large amount of edit warring and argument about this earlier in its history, and the compromise that was reached (defined in MOS:RETAIN) is that whatever spelling style was used when the article was first written would be kept, barring some very limited exceptions. The Americans are getting RGB color model, the Brits are getting Aluminium, etc. - MrOllie (talk) 12:56, 10 November 2021 (UTC)

Well I don't entirely think that's fair i think the system is fair where some version of english get each thing but i think that brazil can get football australia can get colour new zealand can get labour america can get eraser etc. i think that is more fair that each country is represented as much as each other and not america gets 90% — Preceding unsigned comment added by Germany FranceUK Australia Russia Latvia (talk • contribs)

Wikipedia is not a nationalistic contest. The goal is making an encyclopedia, not proving whose spelling dialect is superior. Other projects have other criteria for deciding on spelling, but MOS:RETAIN was settled on here as the most effective for writing a global encyclopedia by a pseudonymous/anonymous crew of volunteers. If you have problems with it please start by reading MOS:RETAIN, MOS:ENGVAR, and MOS:SPELL. If you have further concerns please take them up at WT:MOS, not here. –jacobolus (t) 07:15, 11 November 2021 (UTC)

انور

البنات ال ونبقى. — Preceding unsigned comment added by 78.181.157.103 (talk) 10:12, 2 October 2022 (UTC)