Talk:RGB color model
From Wikipedia, the free encyclopedia
 |
This article is supported by the Color WikiProject, a project that provides a central approach to Color-related subjects on Wikipedia. Help us improve articles to good and 1.0 standards; visit the wikiproject page for more details. | ||
| B | This article has been rated as B-Class on the quality scale. | ||
| High | This article has been rated as high-importance on the importance scale. | ||
|
|||
Adopted orphan redirects for searching: RGB colour model
[edit] 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)
[edit] 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)
[edit] 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
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)
[edit] 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)
[edit] 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://en.wikipedia.org/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)
[edit] 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)
[edit] Orphaned article
The article that appears at http://en.wikipedia.org/wiki/RGB_color_model is slightly different to that at http://en.wikipedia.org/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)
[edit] 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!
[edit] 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).
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 212×212 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.
[edit] 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)
- 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)
[edit] 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)
[edit] 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)
- 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.
[edit] 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)
[edit] "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)
[edit] Cone cells
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)
[edit] 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)
-
-
-
- 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)
- 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)
-
-
-
-
-
-
-
-
-
- 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:[1]):
-
-
-
-
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)
-
-
-
-
-
-
-
-
-
-
- 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)
-
-
-
-
[edit] 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)
-
-
-
-
- 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)
-
-
-
-
-
-
- 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)
- 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)
-
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
- But it was in the 24-bit representation, so 2563=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)
-
-
-
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
-
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
-
-
- 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)
-
-
-
-
-
-
- All or none! Ricardo Cancho Niemietz (talk) 10:06, 10 March 2008 (UTC)
-
-
-
-
-
-
-
-
-
- To be consistent. Ricardo Cancho Niemietz (talk) 10:06, 10 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)
-
-
-
-
-
-
-
-
-
- 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)
- Good. Dicklyon (talk) 15:42, 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)
-
-
[edit] 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)
-
-
-
-
-
-
[edit] 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)
