XEP-xxxx: Consistent Color Generation

Abstract:This specification provides an algorithm to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All clients generate the same color, which provides easier recognition of identifiers across clients and user interface elements.
Author:Jonas Wielicki
Copyright:© 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Track
Version:0.0.1
Last Updated:2017-05-04

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Table of Contents


1. Introduction
2. Requirements
3. Algorithms
    3.1. Angle generation
    3.2. Corrections for Color Vision Deficiencies
       3.2.1. Red/Green-blindness
       3.2.2. Blue-blindness
    3.3. CbCr generation
    3.4. CbCr to RGB
    3.5. Adapting the Color for specific Background Colors
4. Use Cases
    4.1. Adding colors to participants of a conversation
    4.2. Auto-Generating Avatars
5. Business Rules
6. Implementation Notes
    6.1. Gamma Correction
7. Accessibility Considerations
8. Security Considerations
9. Design Considerations
    9.1. Other variants of the YCbCr color space
    9.2. Hue-Saturation-Value/Lightness color space
10. IANA Considerations
11. XMPP Registrar Considerations

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

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.

2. Requirements

The color generation mechanism should provide the following features:

3. Algorithms

3.1 Angle generation

Input: An identifier, encoded as octets of UTF-8 (RFC 3269 [1]).

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.

  1. Run the input through CRC32 as defined by zlib (TODO: add citation).
  2. Take the lower 16 bits and XOR them with the upper 16 bits.
  3. Divide the value by 65535 (use float division) and multiply it by 2π (two Pi).

3.2 Corrections for Color Vision Deficiencies

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 Color Vision Deficiencies.

3.2.1 Red/Green-blindness

Divide the angle by two.

3.2.2 Blue-blindness

Divide the angle by two and add π/2 (half Pi).

3.3 CbCr generation

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:

float cr = sin(angle);
float cb = cos(angle);
float factor;
if (abs(cr) > abs(cb)) {
  factor = 0.5 / abs(cr);
} else {
  factor = 0.5 / abs(cb);
}
cb = cb * factor;
cr = cr * factor;

3.4 CbCr to RGB

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.

  1. Calculate r, g and b according to BT.601:

    float r = 2*(1 - KR)*cr + y;
    float b = 2*(1 - KB)*cb + y;
    float g = (y - KR*r - KB*b)/KG;
    
  2. Clip the values of r, g and b to the range from 0 to 1.

3.5 Adapting the Color for specific Background Colors

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.

  1. Invert the background color by subtracting the individual channels from 1 each:

    rb = 1-rb;
    gb = 1-gb;
    bb = 1-bb;
  2. Mix the inverted background with the color to adapt, using a mixing factor of 0.2:

    rc = 0.2*rb + 0.8*ri;
    gc = 0.2*gb + 0.8*gi;
    bc = 0.2*bb + 0.8*bi;

4. Use Cases

4.1 Adding colors to participants of a conversation

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

4.2 Auto-Generating Avatars

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 User Avatar (XEP-0084) [2]).

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. Generate a color as described in the Algorithms section.
  3. Fill a square with that color.
  4. Render the first character of the name in white or black centered on the square.

5. Business Rules

6. Implementation Notes

6.1 Gamma Correction

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.

7. Accessibility Considerations

As outlined above, implementations MUST offer the Red/Green-Blindness and Blue-Blindness corrections as defined in the Corrections for Color Vision Deficiencies section. Users MUST be allowed to choose between:

The last option is important for users with monochromatic view.

8. Security Considerations

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 Best Practices to Prevent JID Mimicking (XEP-0165) [3] for examples) in JIDs, it may add additional protection against attacks based on those.

In the worst case, this specification does not worsen security.

9. Design Considerations

The following alternatives to the YCbCr BT.601 colorspace were considered and eventually rejected:

9.1 Other variants of the YCbCr color space

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.

9.2 Hue-Saturation-Value/Lightness color space

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.

10. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

11. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [5].


Appendices


Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2017-05-04
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: colors
This document in other formats: XML  PDF


Appendix B: Author Information

Jonas Wielicki

Email: jonas@wielicki.name
JabberID: jonas@wielicki.name


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2017 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. RFC 3269: UTF-8, a transformation format of ISO 10646 <http://tools.ietf.org/html/rfc3269>.

2. XEP-0084: User Avatar <https://xmpp.org/extensions/xep-0084.html>.

3. XEP-0165: Best Practices to Prevent JID Mimicking <https://xmpp.org/extensions/xep-0165.html>.

4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

5. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.0.1 (2017-05-04)

First draft.

(jwi)

END