Switch from custom YCbCrbased algorithm to HSLuv.
+Prioritize bare JIDs over nicknames.
+Write down normalization rules.
+To generate a color from a string of text, the follownig algorithms are applied in order:
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.
+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 bare JID of the user (not the room), (b) the nickname as chosen by the user in the room.
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;).
@@ 126,58 +136,30 @@The algorithms in this document use the &hsluv;⎄ color space. It provides consistent brightness (for a given luminosity) across its entire definition space. There is also widespread library support.
Input: An identifier, encoded as octets of UTF8 (&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.
+Output: Hue angle.
+Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color.
Input: Angle in the CbCr plane.
Output: Angle in the CbCr plane.
+Input: Hue angle.
+Output: Hue angle.
Note: This algorithm will remap 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 mostsignificant bit of the angle to zero before converting to a float in Angle generation. This avoids having to perform a floatingpoint modulo operation.
+Take the angle modulo 180 and subtract 90.
+Note: the same effect can be achieved by forcing the two mostsignificant bits of the angle to be equal to the secondmostsignificant bit before converting to a float in Angle generation. This avoids having to perform a floatingpoint modulo operation.
Subtract π/2 from the angle, take the result modulo π and add π/2.
Note: the same effect can be achieved by setting the mostsignificant bit of the angle to the inverse of the secondmostsignificant bit before conversion to floating point in Angle generation. This avoids having to perform a floatingpoint modulo operation.
+Subtract 90 from the angle, take the result modulo 180.
+Note: the same effect can be achieved by setting the secondmostsignificant bit of the angle to the inverse of the mostsignificant bit and then setting the mostsignificant bit to zero before conversion to floating point in Angle generation. This avoids having to perform a floatingpoint 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.

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.
@@ 194,68 +176,52 @@ gc = 0.2*gb_inv + 0.8*gi; bc = 0.2*bb_inv + 0.8*bi;]]>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.
+Use the HSLuv operation hsluvToRgb to convert the Hue angle to a color. For this, saturation SHOULD be set to 100 and lightness SHOULD be set to 50.
Input: A set of RGB colors (each component from 0 to 1).
Output: A mapping from angles (from 0 to 2π) to RGB colors.
+Output: A mapping from angles (integer, from 0 to 360) 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.
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).
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.
+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 a Hue angle 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.
+Note: See Conversion of an RGB color palette to a Hue palette on how to convert an R, G, B triplet to an angle.
D = min((alpha  beta) % (2*pi), (beta  alpha) % (2*pi))
.D = min((alpha  beta) % 360, (beta  alpha) % 360)
.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.
+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 a Hue angle accordingly.
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.
+Implementations should be aware of Gamma correction and apply it as needed.
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).
When processing JIDs as text input, implementations MUST prepare the JID as it would for comparing it to another JID with a casesensitive comparison function.
+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:
@@ 273,8 +239,8 @@ angle = atan2(cr, cb) % (2*pi)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 versions up to 0.5 of this document used a variant of the YCbCr color space (namely &BT.601;) along with a custom algorithm to convert from angles to CbCr and from there to RGB. The HSLuv color space provides extremely consistent apparent brightness of the colors which cannot be achieved with simple application of YCbCr. In addition, HSLuv has widespread library support.
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.
@@ 303,6 +269,20 @@ angle = atan2(cr, cb) % (2*pi)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.
In &xep0045; conversations (MUCs), there are two viable choices for the hash function input when generating a color for a participant: the nickname as chosen by the participant (or their full JID) and the participants real bare JID. Both options have advantages and disadvantages. The advantages of using the nickname are:
+The advantages of using the bare JID are:
+There is no obvious correct choice to make here; both choices break in different usecases. Specifically, the "nickname" choice breaks when the same entity has different nicknames in different rooms, as well as when two different entities have the same nickname in different rooms. The "bare JID" choice breaks when (semi)anonymous MUCs are involved.
+The choice "bare JID" has the conceptual advantage that it ties as closely as possible to the identity of the entity. It is also forwardcompatible with future protocols where nicknames might not be available or work differently.
+This document requires no interaction with &IANA;.
@@ 313,62 +293,59 @@ angle = atan2(cr, cb) % (2*pi)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 UTF8 as hexadecimal octets, the angle in radians, and the Cb, Cr, Red, Green, and Blue values.
+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 UTF8 as hexadecimal octets, the angle in degrees, the calculated hue in degrees (differs from angle only for CVDcorrected rows), and the 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 socalled "Web Safe" colors.
Instead of the cb and cr values, the test vectors contain the best_angle as found in the palette.
+
+
+