Template talk:Infobox color

Color ranges

Adding the International Klein Blue (Pantone 285) I found different values for the CMYK value ([1] [2] and [3]). I suppose that one of the problems is that the color ranges are different. Is the following correct?:

• Hex triplet : 00 - FF
• RGB: 0 - 255
• CMYK: 0 - 255
• HSV: 0-360°, 0-100%, 0-100%

I will convert the CMYK value I've found (0-100) to the correct range (0-255). Please, if I'm wrong please correct the International Klein Blue article. Thanks. --suruena 16:23, 2005 Apr 9 (UTC)

Ranges are part of the problem, but the most important thing is that conversion to CMYK is not standardised. This is why CMYK has no place in these info boxes, except for colors defined by some standard in terms of CMYK. Notinasnaid 10:07, 26 February 2006 (UTC)

Units

I propose to put "units" to the infobox because this would help to identify the ranges:

• HSV (h, s, v) ({{{h}}}°, {{{s}}}%, {{{v}}}%)

--suruena 10:32, 2005 Apr 10 (UTC)

Done. I've also noted the range into which the other units are normalised. I shall do my best to go back and check this. --Phil | Talk 08:38, Apr 11, 2005 (UTC)

Hello again. If the CMYK value is now being normalised to 0-100 I think we should add some % to specify the units (as with the HSV, like above):

• CMYK (c, m, y, k) ({{{c}}}%, {{{m}}}%, {{{y}}}%, {{{k}}}%)

Also, why not use the same range for the RGB values? I know very little about this theme, but IMHO altough nowadays 8bits are used to represent a component of an RGB value probably in the future the number of bits used to represent every component will be increased. So a percentage is an exact solution that assures the "future", and anyway no information is lost because the 24bit RGB value is maintained in the hex triplet. So I propose to change the RGB representation too:

• RGB (r, g, b) ({{{r}}}%, {{{g}}}%, {{{b}}}%)

--surueña 08:25, 2005 May 11 (UTC)

modular/splitting template

I suggest a way to add a line "this color is also a named web color" with its hex triplet and swatch.. Circeus 21:49, Apr 20, 2005 (UTC)

This infobox is big enough for the time being. Also bear in mind that actually very few colors which will have their own article are ikely to be valid web colors. The standard 16 web colors, and the extra added for CSS, are already linked using {{web colors}}. If you want to link to X11 color names from each article linked from there, feel free. Please make a note of what you are doing at WikiProject Color. --Phil | Talk 09:05, Apr 21, 2005 (UTC)

Please think twice

I think the color values you provide here can be misinformation. Has any of you consulted a real color expert before doing this? You cannot send a set of RGB or CMYK values to a printer (I mean a person, not a computer peripheral) and expect him/her to give you your expected color. These color spaces are device-dependant!

You cannot just create a color in Photoshop and get its color values from that program. -- Toytoy 01:47, Apr 29, 2005 (UTC)

I agree. Does anyone else see a major problem with the whole concept of providing these boxes for nonstandardised colors? It is original research, and should be removed. Notinasnaid 10:01, 26 February 2006 (UTC)

Changing to [0-100]

I know what "Normalized to [0-255]" means, but what does "Changing to [0-100]" mean? Lefty 07:20, 11 February 2006 (UTC)

sRGB

I think it should read sRGB instead of RGB. Not only would it be preferable to have an absolute color space in the infobox, but I think that most RGB values in this infobox are already in sRGB as it is. Any comments? Shinobu 02:00, 5 March 2006 (UTC)

It would at least have some meaning. At the moment it is not meaningful except for colors that are defined by some standard in uncalibrated RGB. The CMYK should absolutely be removed in all cases except those that are uncalibrated CMYK in some standard. But there is a far more serious problem with these info boxes: there are no sources, no references. Under Wikipedia rules anything without a source should be removed. If the box is to remain, it needs to indicate according to what standard or reference this is "Red", "Burnt umber" or whatever. I think a significant amount of (forbidden) original research has gone into some of the colors. Notinasnaid 21:01, 6 March 2006 (UTC)

Hear hear. How about defining a field that could contain a) a reference (this color is ... by standard this-and-that), b) a definition (this color is red by definiton of the sRGB color model) or c) a notice like "this is only a sample of what this colour might look like and the values used to..." etc. etc. That way the user would know what the numbers mean. If we want to keep the CMYK colors, we would need to have a properly defined CMYK color space. Shinobu 08:39, 7 March 2006 (UTC)

color vs. colour

I just reverted a change at Orange (colour) where an anon changed all of the instances of "colour" (which was standard within the article) to "color". While I'm sure the edit was made in good faith, I reverted it to "colour" since the article was at "colour", rather than "color", and since guidelines suggest that consistency is important. I realized soon afterwards that I should check for other instances of the word "color" rather than "colour" in the article, and started a quick word search. I noted that each instance of this template used "color". Since this is awkward for articles written with the "colour" spelling, I propose that another parameter be added to this template: spelling. If there were a parameter that let the spelling be set, it would be much easier to standardize articles without automatically favoring the spelling used by this template. Nihiltres 19:29, 7 November 2006 (UTC)

Since nobody's responded, I'm going to try to modify the template myself. I'll add how to use this extra feature to the template documentation once I'm done. Nihiltres 16:56, 13 November 2006 (UTC)

Direct color

I would add Direct color:

The user could specify yes / no. By default direct color name would be set to 'no . See : Template:Shades_of_green, [edit] Shades of green in text. —The preceding unsigned comment was added by Altermike (talk • contribs) 09:33, 18 March 2007 (UTC).

infobox "about" link image

While I think that the addition of the as a link explaining the infobox is quite appropriate, its overlap with the "hex"-parameter-coloured field can be disruptive in some articles, such as Orange (colour), where its blue color in comparison to the one discussed is disruptive or jarring. If someone can figure out a way to change the template so as to avoid this problem, I'm sure that many users will appreciate the small aesthetic improvement. Suggestions? Nihiltres 00:09, 5 April 2007 (UTC)

I can think of a couple possibilities. One is to use an approach similar to textcolor. However that would require alternate versions of the image. Another possibility is to move it to the Color coordinates line. It actually might make more sense to have it there. PaleAqua 00:32, 5 April 2007 (UTC)

It looks much nicer now that you've moved it - I agree that it makes more sense there. Thanks, Nihiltres 02:31, 5 April 2007 (UTC)

suggestion

would it be possible to add an option to have a block of the colour instead of a image? as it can be hard to get an idea of the colour from just the background of the text. I would do it myself but don't have that much experience with template making, and don't want to break anything.--UltraMagnus (talk) 16:10, 1 October 2009 (UTC)

How big a block? I suppose this is doable, although I'm still not convinced it's that useful. Chris Cunningham (not at work) - talk 11:11, 15 October 2009 (UTC)

Automatic conversion

We do have some color conversion templates. I suggest we employ them in this template so there only needs to be one set of RGB specified (probably in percentages) and others, like hash code, 8bit RGB values, HSL, HSV and probably more (not CMYK of course) would be generated automatically. — Christoph Päper 23:46, 10 September 2010 (UTC)

We applied automatic conversion on it.wikipedia (see it:Template:Infobox colore generico and it:Template:Codifica colore). In this way, hex code is used to calculate automatically the following parameters: R, G, B, C, M, Y, K, H, L and V. Wavelenght is used instead to calculate frequency and photon energy. Please let me know if we can use the same principle here. --Daniele Pugliesi (talk) 14:56, 27 January 2020 (UTC)

Adding caption= parameter

Most templates which include images also include the ability to optionally include caption = . Over at Indigo, a caption would be helpful. Can we add the caption parameter as implemented elsewhere? --Lexein (talk) 02:06, 24 August 2011 (UTC)

I was about to post exactly the same message. Is there anyone that could look at this? Formerip (talk) 01:06, 25 July 2012 (UTC)

Why do things the easy way?! I've updated the entire infobox. (dragged kicking and screaming into the modern age).

See Sample. Compare with current version in Red

See code here.

The only option that I couldn't implement is "|nocoords= " but I don't think any instances actually use this option?

Any concerns or objections? (I've done basic testing, and all aspects seem to be working.) If it seems ok, we can throw an (Edit protected) template up, and get an admin to copy it across. Ta. -- Quiddity (talk) 09:37, 25 July 2012 (UTC)

Looks good to me. Might make sense to copy it into the sandbox for the template just before throwing the edit protected up. ( I still think this infobox needs a major rethink, but that's a side discussion, and I've mostly retired from editing Wikipedia ) PaleAqua (talk) 05:45, 26 July 2012 (UTC)

Sandbox (and therefor Template:Infobox color/testcases) Done.

The color variants (at the bottom) don't stretch full width in the new version, but that can be tweaked later if needed. Making the infobox easier to change/update is one of the main benefits of switching to {{infobox}}. I'll put an editprotected up in 12 hours or so. -- Quiddity (talk) 19:55, 26 July 2012 (UTC)

Is "pic=" more standard than "image=" now? Anyways, in Sample I tested the caption= parameter - works! I look forward to this updated template being globally available. --Lexein (talk) 21:36, 26 July 2012 (UTC)

"Image=" is standard, but "pic=" is what this template currently uses, so to change it would require a bot-run to change all existing intances in each article... Or, I could do some convoluted doublecoding and make both options work, and then change all the articles once the new code is in place... I think I'll do that. -- Quiddity (talk) 22:15, 26 July 2012 (UTC)

Please copy the code from Template:Infobox color/sandbox over to Template:Infobox color. Per consensus above, and completed testing. Thanks. -- Quiddity (talk) 22:15, 26 July 2012 (UTC)

I made a slight tweak to the sandbox to fix a bug in variants 3-8, and also added them to the test cases. PaleAqua (talk) 07:50, 27 July 2012 (UTC)

 Done, with a couple of minor tweaks to use Unicode directly for degrees and dashes. Thanks! Chris Cunningham (user:thumperward) (talk) 09:55, 27 July 2012 (UTC)

Thanks! Updated doc for caption= & image= --Lexein (talk) 10:42, 27 July 2012 (UTC)

Thanks for the fixes, corrections, and implementation! I've updated all articles to use "image=" instead of "pic=" . That code to support the old "pic=" can (probably) be removed from the template, at any time. -- Quiddity (talk) 11:42, 31 July 2012 (UTC)

 Done. Chris Cunningham (user:thumperward) (talk) 11:42, 2 August 2012 (UTC)

Once more please, copy the code from Template:Infobox color/sandbox to this template. This change fixes some linewrap problems, using 2 {{nowrap}} templates, and removes some trailing spaces (see the testcases page for before&after examples). Thanks. -- Quiddity (talk) 11:42, 31 July 2012 (UTC)

 Done, with some additional tidying of the title, image and header code. Chris Cunningham (user:thumperward) (talk) 08:08, 1 August 2012 (UTC)

New version of the template breaks ## example values in wavelength and frequency parameters.

Looks like the new version is causing # to be treated as a numbered list when given as part of a parameter for wavelengths and frequencies. Probably not really worth fixing as it is rarely used that way and I fixed the one instance I found. PaleAqua (talk) 00:15, 31 July 2012 (UTC)

Fixing variations so that they are once again full width.

I've updated the sandbox so variations are once again full width. Look okay? (see testcases) PaleAqua (talk) 08:49, 1 August 2012 (UTC)

Aslo per consensus from a while back at the Color project, should we switch the wording to "Some shades of" instead of "Some variations of"? PaleAqua (talk) 08:55, 1 August 2012 (UTC)

Looks good. And I'd support the wording change, based on that consensus (changed in sandbox). -- Quiddity (talk) 09:22, 1 August 2012 (UTC)

Thanks, I tweaked it a little further to put the name of the sample to the left instead of directly above the bock with color. What do you think? I also wonder if the shade samples should be moved up to just below the image with the "shades of" header dropped. PaleAqua (talk) 16:17, 1 August 2012 (UTC)

Half-width blocks looks really good, and does indeed simplify the text-contrast issue.

I don't think moving them up would help, as they're more of a supplemental level of detail, and not core. If a color variant is important(defined), then (at least in the way our articles are currently structured) they tend to have their own subsection and their own infobox (eg Desert sand (color)). Possibly you're thinking along these lines in regard to your earlier comments about needing to rethink the entire thing? (I'd be curious to see details/examples of proposed overhauls :) . -- Quiddity (talk) 20:49, 1 August 2012 (UTC)

This was what I was thinking awhile back Wikipedia talk:WikiProject Color/Archive 7#Discussion about the color boxes. PaleAqua (talk) 21:39, 1 August 2012 (UTC)

Also I think articles generally should only have one infobox color, with pictures and samples as necessary when talking about various shades, tints, and tones. PaleAqua (talk) 21:47, 1 August 2012 (UTC)

Edit request on 1 August 2012

Please copy the latest version of sandbox to the live template. ( I'm wondering if full protection is still necessary for this Infobox. Some of the other color project templates that were protected as highly visible templates have been since become semi-protected. ) PaleAqua (talk) 21:28, 1 August 2012 (UTC)

 Done, with the same entity -> Unicode tweak for degrees and dashes as before. As for unprotection, the usual procedure is to ask the admin who locked the template originally; I agree that this doesn't need more than semiprotection in any case, and personally I'd just drop protection altogether. Chris Cunningham (user:thumperward) (talk) 11:39, 2 August 2012 (UTC)

Thanks, I just asked Wknight94 about unprotection. PaleAqua (talk) 13:23, 2 August 2012 (UTC)

Add ref params

I'd like to add three optional params: |RGBnote=; |HSVnote=; and |CMYKnote=. If present, they will render after the closing parenthesis of the RGB, HSV, and CMYK value groups, respectively. The purpose is to provide cites for the individual coordinate sets, which are currently being inserted by appending them to the last color parameter in the set, creating ugly placement inside the parentheses and before the the final '%' (e.g. at Amaranth (color)). Any objections? —[AlanM1(talk)]— 23:15, 9 October 2013 (UTC)

Those references should really be removed. Most of the coordinates given are Wikipedia:Synthesis. The current over use of color infoboxes implies that the color has an exact one to one representation of color terms to (s)RGB coordinate, which is not true. The references are basically just color coordinate calculators. Also RGB <-> CMYK conversions are dependent on several of factors, include the type of paper and the set of inks, as well as the whole additive vs subtractive thing.. PaleAqua (talk) 00:57, 10 October 2013 (UTC)

Removing symbolism parameter

In August 2013, SiefkinDR (talk · contribs) removed the implementation of the symbolism parameter in 9 of the 11 major color group articles as subjective, unsourced, and better covered in that article text. He/she removed the parameter from the remaining two articles (Green and Pink) about a month later for consistency. As it is unlikely to be used in any of the more specific color articles, should I remove the parameter outright? –LaundryPizza03 (dc̄) 20:11, 31 December 2018 (UTC)

bad titleline

Please watch out: neither color coordinates can be found in this infobox. Only color coordinates would be CIE xy and CIELAB L*a*b*. All are missing from the infobox. ZJ (talk) 16:03, 31 July 2020 (UTC)

A good point. Where is the capacity to include L*a*b coordinates. GraemeLeggett (talk) 21:55, 13 January 2022 (UTC)

I could easily code an automatic conversion to CIELab or CIELCh_ab if there's consensus this information should appear in the infobox. Personally, I'm afraid this may not add much value to the articles about colors (but I might be wrong on this). CIELab is useful for measuring perceptual color contrast, but the coordinates themselves are not very useful for much else, see list of color spaces and their uses. To avoid feature creep (and the possible addition of as many color conversions as one can think of), I think it's best to pick which coordinates are really notable and useful, worthy of an encyclopedia for the general audience. I added CIELCh_uv because it is designed for perceptual uniformity and commonly used in information visualization. Like HSL and HSV, one can look at CIELCh_uv coordinates and have a good idea of what colour they represent, and comparisons between two pairs of such coordinates are meaningful to humans with normal vision: if two colours are perceived as having approximately the same lightness, L will be approximately the same regardless of other aspects; if they're perceived to have approximately the same hue, h will be approximately the same; and if they're approximately as colourful, even if their hues are very distinct, C will be approximately the same. You don't get that with the simpler HSV and HSL spaces, nor CIELab. --Fernando Trebien (talk) 18:46, 17 January 2022 (UTC)

My opinion that the title line must be "dominant wvelength of colour stimulus" in short: dominant wavelength to fill in the title line space of the template. ZJ (talk) 12:28, 16 October 2023 (UTC)

Alignment

May I suggest a parameter to control the alignment of this infobox, as offered, for example, in Infobox_enzyme? This could help the readability of an article where the Infobox template is used within the body, such as Turquoise. Regards, Guffydrawers (talk) 12:52, 3 September 2020 (UTC)

CIE coordinates

For some colors, particularly colors of light rather than colors of objects, such as the "average color of the universe" Cosmic latte, it would make sense to provide the color's CIE coordinates in XYZ, xyY, or in the case of unspecified brightness, just xy. Could those be added as optional fields, to go alongside RGB values when appropriate? — Maggie David P. K. Haynes 2600:1700:C190:4AE0:24B6:2CC0:1A3C:2627 (talk) 21:12, 17 September 2020 (UTC)

 Partly done. The CIE XYZ space isn't very useful per se. I added the CIE LCH_uv (automatically calculated from the hex triplet) because the numbers mean something to humans. --Fernando Trebien (talk) 18:27, 16 January 2022 (UTC)

Please see this table. I arranged as highering hue angle according to the CIELAB. Mainly the hue angle values are bad in infoboxes.

R G B L* C* h_ab

red 255 0 0 53,2 104,5 40,0

orange 255 128 0 67,3 85,4 60,3

yellow 255 255 0 97,1 96,9 102,8

lime 128 255 0 89,9 109,2 128,2

green 0 255 0 87,7 119,8 136,0

dark green 0 255 128 88,5 89,4 148,9

cyan 0 255 255 91,1 50,1 196,4

dark blue 0 128 255 55,0 72,8 284,4

blue 0 0 255 32,3 133,8 306,3

violett 128 0 255 41,0 124,8 311,8

magenta 255 0 255 60,3 115,6 328,2

light red 255 0 128 54,9 84,7 2,4

What happens if you have the LCH but not the hex triplet? An infobox that only takes one parameter and calculates the others from it sounds limited. GraemeLeggett (talk) 20:20, 16 January 2022 (UTC)

Is this a real need? Do you have any colors with LCh values (and a reference to them) that are different from the calculated ones or that are outside the sRGB color space? I first added these fields on Jan 8th (9 days ago), and removed it shortly after I was able to calculate them automatically. --Fernando Trebien (talk) 18:26, 17 January 2022 (UTC)

I don't know. I come at this from the way of thinking in aircraft specs templates where the various values might be in a mix of feet and metres, lb and kg, mph or km/h or knots and the template takes what is given and outputs the missing ones. And I come to this infobox because of NIVO where there is no actual source of the colour just modellers giving their best estimate of paint mixes that look right and an interpretation of that as hex triplet GraemeLeggett (talk) 19:48, 17 January 2022 (UTC)

I see. You're right to question the source for the hex triplet in NIVO. Reference #4 got me here and the NIVO article says it's colour FS:34096 which should be this which is #404735 if you use a colour picker on the base image (or directly on a screenshot of the website). The Source field in the infobox says the current (incorrect) hex was computed from sRGB values and the computation is correct, but the values clearly are not. So I would (1) fix the hex and (2) cite [4] this as the source for the colour in the infobox and in the last paragraph of the text.

I've seen many color catalogues but none ever provides CIELCh coordinates, that's why I don't think it's worth the effort of providing a field for that - at least at the moment. It is possible that the CIELCh field in the infobox will be replaced by something like OKLCH in the future, but that's a very recent development (just added to CSS 4, and competes with HSLuv), while CIELCh is an old, widely used standard. --Fernando Trebien (talk) 23:39, 17 January 2022 (UTC)

I think the standard illuminant must be the D65 as is writtn in sRGBB standard. ZJ (talk) 12:30, 16 October 2023 (UTC)

Relevant comment on Talk:Shades of gray

I've commented on Talk:Shades of gray#Usage of space but I figure it's relevant here as well. — Preceding unsigned comment added by 92.67.227.181 (talk) 20:39, 28 May 2022 (UTC)

Defining a Color "Class"

A constant hassle in this talkpage, in WP:COLOR, and pretty much all color articles, is the assumption that all colors can or should somehow be defined by specific sRGB coordinates. The format of these infoboxes has made it all too easy to find some questionable online source that will define any color term by sRGB, but I'd argue that most colors with an infobox should NOT be defined by a single sRGB coordinate and in many cases, no sRGB coordinates should be given at all.

I started a discussion in WP:COLOR, but it didn't get much traction. Technically, it is more specific to this template anyway. What I suggest(ed), is a way to classify colors based on how they are defined. I recommended the following classes:

• based on a digital definition or defined directly to sRGB (or at least CIEXYZ) coordinates. This would include web colors (e.g. Shades of yellow#Computer web color yellow) and most modern brand colors (e.g. Android green). These infoboxes would stay as-is.
• based on a pigment, defined chemically (e.g. Prussian blue or mummy brown); these do not have a direct relation to CIEXYZ and may not even represent a precise color. I would completely remove sRGB coordinates from this class of colors.

• based on some vague, imprecise natural referent (e.g. sapphire or sky blue), that must be best represented by a range of colors or shades. I'd be inclined to define these qualitatively instead of qualitative, or give an array of example colors, such as is done currently (in a way) with basic color terms like blue, see inset.
• based inextricably on a fixed, "precise" natural referent (e.g. uranian blue), that could be represented by a single color, and could make sense to define as in sRGB.
• a basic color term, (e.g. dark blue) that is vague by definition and can be related to a range of applicable colors, as we see in the inset, but defining dark blue in sRGB is pointless!
• based on a proprietary referent (anything pantone, crayola, RAL, Munsell, etc.) that can mostly be transformed rather reliably to CIEXYZ; I've seen many claim that this is an IP problem, but I don't know enough about how that is handled in WP.

The content of an infobox would therefore differ depending on what class the color term falls into, and of course, there can be several definitions of a color in different color classes, as we already see with most basic colors like blue, which starts with 6 definitions of "blue", spanning several classes. An indication of the class, in the infobox, with a hoverbox defining the class would also be useful. Curran919 (talk) 11:28, 8 January 2023 (UTC)