diff --git a/xep-0392.xml b/xep-0392.xml index 56b25f99..6774dc3a 100644 --- a/xep-0392.xml +++ b/xep-0392.xml @@ -28,6 +28,17 @@ jonas@wielicki.name jonas@wielicki.name + + 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 @@ -43,6 +54,9 @@

Colors provide a valuable visual cue to recognize text. 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.

+

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:

@@ -68,23 +82,23 @@

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 name assigned in the roster, (b) the nickname from the conversation, (c) 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 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:

    -
  1. Obtain a name for the contact, in descending order of preference, (a) from the roster, (b) by using the nickname from the conversation, (c) by using the bare JID.
  2. +
  3. Obtain a name for the contact, in descending order of preference, (a) by using the actual bare JID of the contact (not the bare JID of the conference in case of a XEP-0045 MUC), (b) by using the nickname from the conversation.
  4. Generate a color as described in the Generating a color section.
  5. Fill an implementation-defined background shape with that color.
  6. -
  7. Render the first character of the name in white or black centered on the square.
  8. +
  9. Render the first character of the name in white or black centered on the shape.
@@ -112,7 +126,7 @@

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.

+

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:

-

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.

+

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.

    @@ -137,6 +151,7 @@ float g = (y - KR*r - KB*b)/KG; ]]>
  1. 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.

@@ -144,25 +159,26 @@ float g = (y - KR*r - KB*b)/KG;
  1. Invert the background color by subtracting the individual channels from 1 each:
  2. +rb_inv = 1-rb; +gb_inv = 1-gb; +bb_inv = 1-bb;]]>
  3. Mix the inverted background with the color to adapt, using a mixing factor of 0.2:
  4. +rc = 0.2*rb_inv + 0.8*ri; +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.

+

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).

@@ -190,53 +206,6 @@ cr = (r - y) / (1 - KR) / 2

Note: the distance metric is simply the euclidian distance in the CbCr plane.

- -

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, 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 216 colors). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.

- - - - - - - - - -
-
@@ -245,7 +214,7 @@ text,hextext,angle,cb,cr,r,g,b -

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

+

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: