Consistent Color Generation

%ents; Red/Green-Blindness"> Blue-Blindness"> ]>

Consistent Color Generation This specification provides a set of algorithms to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All entities adhering to this specification generate the same color for the same string, which provides a consistent user experience across platforms. &LEGALNOTICE; 0392 Experimental Standards Track Standards Council colors &jonaswielicki; 0.4 2017-11-29 jwi

Use different formulas for Color Vision Deficiency correction, as suggested by Marcus Waldvogel.

Update test vectors.

Clarify generation of the angle.

Prioritize nicknames over bare JIDs.

Add rationale for new palette mapping algorithm introduced in 0.3.

0.3 2017-11-13 jwi

Fix wording in angle generation section which did still use CRC32. Rework palette mapping after with implementation experience.

0.2 2017-10-04 jwi

Move to SHA-1 as mixing function; Properly reference BT.601 and include constants in text; Prefer bare JID over roster name when selecting the hash function input; Editing.

0.1 2017-09-27 XEP Editor: jwi

Accepted as Experimental by Council.

0.0.1 2017-09-14 jwi

First draft.

Colors provide a valuable visual cue to recognize shapes. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities, without having to actually read the text.

Clients have been using randomly or deterministically chosen colors for users in multi-user situations for a long time already. However, since there has been no standard for how this is implemented, the experience differs across platforms. The goal of this XEP is to provide a uniform, platform-independent, stateless and easy-to-implement way to map arbitrary bytestrings to colors, as well as give recommendations how this is applied to color names of participants in conversations, roster entries and other pieces of text.

To allow cross-client use, it is important that the color scheme can be adapted to different environments. This specification provides means to adapt colors to different background colors as well as &cvds;.

In no way is the system presented in this specification a replacement for names. It only serves as an additional visual aid.

The color generation mechanism should provide the following features:

Consistent generation of color across all platforms depending solely on the identifier used as input for the algorithm.
The system should be reasonably fast; it must be possible to, for example, apply it to all roster entries even of very large rosters in reasonable amount of time.
It must be able to provide decent contrast on any background.
The implementation should be stateless and not be complex.
A fallback path for users with common types of &cvds; must be provided.
A fallback path for systems which can only use colors from a restricted palette must be provided.

To generate a color from a string of text, the follownig algorithms are applied in order:

Generate an angle in the CbCr plane from the text.
If enabled, apply configured corrections for &cvds;.
If the output device only supports a small palette of colors, map the angle to the closest palette color.
If the output device supports RGB output, Convert the angle to a CbCr pair and convert the CbCr pair to an RGB triple.

Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.

In such cases, the color SHOULD be generated as described in the Generating a color section. The input used SHOULD be, in descending order of preference, (a) the nickname from the conversation, (b) the bare JID.

Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;).

In such cases, auto-generating an avatar SHOULD happen as follows:

Obtain a name for the contact, in descending order of preference, (a) the nickname from the conversation, (b) the bare JID of the contact (not the bare JID of the conference in case of a &xep0045; room).
Generate a color as described in the Generating a color section.
Fill an implementation-defined background shape with that color.
Render the first character of the name in white or black centered on the shape.

Implementations SHOULD allow the user to turn off any colorization completely.
Implementations SHOULD implement the &cvd; profiles and SHOULD allow the user to choose any of these profiles or to disable the correction.
Implementations MUST NOT share the &cvd; correction settings with other entities.

Input: An identifier, encoded as octets of UTF-8 (&rfc3269;).

Output: Angle in the CbCr plane.

Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color.

Run the input through SHA-1 (&rfc3174;).
Treat the output as little endian and extract the last-significant 16 bits. (These are the first two bytes of the output, with the second byte being the most significant one.)
Divide the value by 65536 (use float division) and multiply it by 2π (two Pi).

Input: Angle in the CbCr plane.

Output: Angle in the CbCr plane.

Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;.

Take the angle modulo π.

Note: the same effect can be achieved by forcing the most-significant bit of the angle to zero before converting to a float in Angle generation. This avoids having to perform a floating-point modulo operation.

Subtract π/2 from the angle, take the result modulo π and add π/2.

Note: the same effect can be achieved by setting the most-significant bit of the angle to the inverse of the second-most-significant bit before conversion to floating point in Angle generation. This avoids having to perform a floating-point modulo operation.

Input: Angle in the CbCr plane, from the previous algorithm.

Output: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5.

Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr:

 abs(cb)) {
  factor = 0.5 / abs(cr);
} else {
  factor = 0.5 / abs(cb);
}
cb = cb * factor;
cr = cr * factor;
]]>

Input: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5; Value for Y.

Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.

Note: The recommended value for Y is 0.732. See Gamma Correction for a discussion on the choice of Y.

Calculate r, g and b according to BT.601:
Clip the values of r, g and b to the range from 0 to 1.

See Constants for YCbCr (BT.601) for the values of KR, KG and KB.

Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each.

Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1.

Invert the background color by subtracting the individual channels from 1 each:
Mix the inverted background with the color to adapt, using a mixing factor of 0.2:

Input: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.

Output: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5; Value for Y.

Calculate Y, Cb and Cr according to BT.601:

See Constants for YCbCr (BT.601) for the values of KR, KG and KB.

Input: A set of RGB colors (each component from 0 to 1).

Output: A mapping from angles (from 0 to 2π) to RGB colors.

Note: when the algorithm finishes, the mapping maps angles (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness.

Create an empty mapping M which maps from pairs of CbCr values to quadruples of Y, R, G and B.
For each color R, G, B from the input palette:
1. If the R, G and B values are equal, skip the color and continue with the next.
2. Calculate Y, Cb and Cr from R, G, B as described in RGB to YCbCr.
3. Convert Cb and Cr to an angle:
  0: cr /= magn cb /= magn angle = atan2(cr, cb) % (2*pi) ]]>
  Here, % is the floating point modulo operator. Since atan2 may return negative values, it is used to put the values into the range from 0 to 2π. ** is the exponentiation operator (cb**2 is thus cb squared).
4. Round the angle to two digits behind the decimal point.
5. If the angle is not in the mapping M yet, or if the Y value of the existing entry is farther away from 0.732 than the new Y value, put the Y, R, G, and B values as value for the angle into the mapping.
Strip the Y values from the values of mapping M.
Return M as the result of the algorithm.

Implementations are free to choose a representation for palette colors different from R, G, B triplets. The exact representation does not matter, as long as it can be converted to an angle in the CbCr plane accordingly.

Input: (a) A mapping which maps angles to R, G, B triplets and (b) a color to map to the closest palette color as angle alpha.

Output: A palette color as R, G, B triplet.

Note: See Conversion of an RGB color palette to a CbCr color palette on how to convert an R, G, B triplet or a CbCr pair to an angle.

First, check if alpha rounded to two places behind the decimal point has an exact match in the mapping. If so, return that match immediately.
For each angle beta in the palette, calculate the distance metric: D = min((alpha - beta) % (2*pi), (beta - alpha) % (2*pi)).
Return the R, G, B triplet associated with the angle with the smallest distance metric D.

An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5.

Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations SHOULD instead use the algorithm described in Adapting the Color for specific Background Colors for that.

An implementation which shows the generated colors on a colored background SHOULD apply Adapting the Color for specific Background Colors. If the background is not uniformly colored, it is up to the implementation to determine an appropriate surrogate background color to correct against.

If an implementation shows the generated colors on a grayscale (including white and black) background, it MAY apply the background color correction algorithm. It is RECOMMENDED to always apply the algorithm if the background color is changed dynamically, to avoid discontinuities between grayscale and colored backgrounds.

Implementations SHOULD use the same background color for all generated colors. If this is not feasible, implementations SHOULD use the same background color for all generated colors within the same GUI control (for example, within a conversation and within the roster).

As outlined above, implementations SHOULD offer the &rgblind; and &bblind; corrections as defined in the Corrections for &cvds; section. Users SHOULD be allowed to choose between:

disabling all corrections (skip the Corrections for &cvds; step entirely),
applying one of the &cvd; correction profiles and
disabling colorization altogether.

The last option is useful for users with monochromatic view or who find colors distracting.

Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.

This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those.

Due to the limited set of distinguishable colors and only extracting 16 bits of the hash function output, possible &cvds; and/or use of palettes, entities MUST NOT rely on colors being unique in any context.

This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected.

The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as &BT.601; does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain.

The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain.

Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen.

There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose.

In addition, more state needs to be taken into account, increasing the complexity of choosing a color.

This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, SHA-1 (&rfc3174;) is used.

CRC32 and Adler32 have been considered as faster alternatives. Downsides of these functions:

Bad mixing without additional entropy.
Adler32 is rarely available in standard libraries.
CRC32 is ambiguous: there are multiple polynomials in widespread use (e.g. the Ethernet and the zlib polynomials). Often it is not clear which polynomial is used by a library.

SHA-1 is widely available. From a security point of view, the exact choice of hash function does not matter here, since it is truncated to 16 bits. At this length, any cryptographic hash function is weak.

The palette-mapping algorithm operates on angles only and disregards the Y value except if the angles match. This has the downside that the brightness is not equal over the range of the palette mapped colors.

The alternative would be to require Y to be close to the target Y. This has several issues:

We cannot know if a palette can satisfy the given Y at all.
Many colors from e.g. the "Web Safe" palette (used in 256 color terminals and the test vectors) will not satisfy any given Y, reducing the size of the effective palette drastically.

For the sake of having more colors available, the given algorithm was chosen which prefers many colors with hue conformance over fewer colors with hue and lightness conformance.

This document requires no interaction with &IANA;.

This document requires no interaction with the ®ISTRAR;.

Thanks to Klaus Herberth, Daniel Gultsch, Georg Lukas, Tobias Markmann, Christian Schudt, and Marcus Waldvogel for their input and feedback on this document.

Throughout the document, the constants KR, KG and KB are used. They are defined in &BT.601; as:

This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, the angle in radians, and the Cb, Cr, Red, Green, and Blue values.

The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 210 colors (grayscales are excluded)). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.

Instead of the cb and cr values, the test vectors contain the best_angle as found in the palette.