ColorToolDoc.tioga
Last edited by Stone, August 16, 1985 10:57:29 am PDT
Maureen Stone, June 5, 1987 6:59:53 pm PDT
Pier, December 7, 1988 5:01:01 pm PST
Giordano:PARC:Xerox (8*923-4484), June 21, 1990 4:44 pm PDT
COLOR TOOL
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
ColorTool
Maureen Stone
© Copyright 1985, 1986, 1987, 1990 Xerox Corporation. All rights reserved.
Abstract: The ColorTool allows one to manipulate the color of a patch using any or all of a variety of color systems. The ColorTool is valuable for experimenting and learning about the various color schemes and how they interrelate to one another. A client interface is provided so that illustrators might use the ColorTool for color specification by a user.
Created by: Maureen Stone
Maintained by: Maureen Stone <Stone.pa>
Keywords: color, color spaces, color specification
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. Overview
The ColorTool permits a user to interactively manipulate the color of a test patch using a variety of color systems. It is a complete rework of the Cedar 6.1 colortool, and has been split into several modules. At the moment, it has far fewer features than the previous versions. (Re)Developement will be driven by need and interest.
The color systems currently provided are RGB (red, green, blue), CMY (cyan, magenta, yellow), HSV (hue, saturation, value), HSL (hue, saturation, lightness), There is a text window that shows the color names implemented by the NamedColors interface.
2. Color Systems
Continuous Systems
Each continuous color system is implement as three sliders, three text viewers, and a button for setting the color from the text viewers. This set of viewers is actually implemented using the ColorSchemeViewer package (See ColorSchemeViewerDoc for details).
RGB: the red, green, blue monitor primaries.
CMY: the cyan, magenta, yellow printing primaries. In this implementation, we let [C,M,Y] = [R,G,B] - [1,1,1], although the actual relationship between printer and monitor colors is really more complex.
HSL: hue, saturation, lightness. Hue is a continumum from red to purple. Saturation controls the vividness of the color. Lightness controls the darkness-lightness of the color. The fully powered monitor colors are at S=1, L=0.5.
HSV: hue, saturation, value. Hue is the same as in HSL. Saturation and value are similar to HSL, but behave differently at their extremes. The fully powered monitor colors are at S=1, L=1.0.
HSL and HSV are the usual computer graphics systems defined in Foley and Van Dam1.
Color Names
The named colors map an English language description of a color to an RGB triple using the HSL (hue, saturation, lightness) color ordering system as an intermediate form. Seen NamedColorsDoc for more detail.
Registered Colors
This window provides a way to access the registered colors using their hierarchical names. These colors reside in the ColorRegistry, which must be running to make this part of the tool interesting. Everyone should have it running at all times. For registered colors that begin with the string "Xerox/Research", that part of the name can be omitted by the user. See ColorRegistryDoc for the list of valid names.
2. ColorTool.mesa
Client can read and set the color values in the ColorTool using the following procedures
SetRGBValue: PROC[rgb: ImagerColor.RGB, viewer: ViewerClasses.Viewer ← NIL];
GetRGBValue: PROC[viewer: ViewerClasses.Viewer ← NIL] RETURNS [ImagerColor.RGB]
Clients who want to continuously change the color of an object as the colortool changes value, like Gargoyle, should register a NotifyProc using:
RegisterNotifyProc: PROC[id: ATOM, notifyProc: NotifyProc, data: REF, viewer:
 ViewerClasses.Viewer ← NIL];
RemoveProc: PROC[id: ATOM, viewer: ViewerClasses.Viewer ← NIL];
In all these procedures, if the viewer=NIL, the ColorTool implementation will use ViewerOps.FindViewer["ColorTool"] to search for the ColorTool viewer. The effect of this call if there are more than one ColorTool viewers is unpredictable. If the client wishes to link to a specific tool, it should create the viewer using the following procedure and save the returned value to use as the viewer parameter.
Create: PROC RETURNS[ViewerClasses.Viewer];
3. ColorTool Modules
ColorToolPackage: From ColorTool.df, this is the top level BCD for the ColorTool. It exports the ColorTool interface above.
ColorSchemeViewer: From ColorSchemeViewer.df, this creates a viewer class that is a set of viewers suitable for one continous color system (3 sliders, 3 text viewers, a button and a label) with some automatic layout as a function of the total size. It exports ColorSchemeViewer.mesa. Clients who want to use only one system are encouraged to nest a ColorSchemeViewer viewer in their tools.
NamedColors: From NamedColors.df, this implements the color naming system.
ColorPatch: From ColorTool.df, this implements the ColorPatch viewer class. It exports ColorPatch.mesa. This viewer class could also be imbedded in client tools if desired.
4. Colormap Animation
Clients who continuously update a color to follow the colortool, like Gargoyle or the ColorPatch viewer, may want to use colormap animation to provide the necessary performance.
Given an rgb: ImagerColor.RGB, the formula for colormap animation is in a Viewer.PaintProc is:
Get your new rgb off the viewer data
mode: Terminal.ColorMode = Terminal.GetColorMode[Terminal.Current[]];
animationOK: BOOLEAN = self.column=color AND NOT mode.full AND mode.bitsPerPixelChannelA=8; --this only animates in 8 bits/pixel mode
IF NOT animationOK THEN {
Imager.SetColor[context, ImagerColor.ColorFromRGB[rgb]];
Use Imager Mask commands to draw picture
}
ELSE {
patchMapEntry: ImagerColorMap.MapEntry ← [
mapIndex: 101, --[0..256) see note below
red: ToByte[rgb.R],
green: ToByte[rgb.G],
blue: ToByte[rgb.B]];
ImagerColorMap.LoadEntries[vt: Terminal.Current[],
mapEntries: LIST[patchData.patchMapEntry], shared: FALSE];
IF whatChanged=NIL THEN {
Imager.SetColor[context, ImagerDitherContext.MakeSpecialColor[
specialPixel: [patchMapEntry.mapIndex,null],
ordinaryColor: ImagerColor.ColorFromRGB[rgb]]];
Use Imager Mask commands to draw picture
};
};
Each client needs to select a colormap entry (a mapIndex) to use for its application which does not conflict with the regular colormap values used for dithering or with other clients, and is available for the colordisplay mode you are expecting (8 bpp, 4bpp, etc). The informal list of used map entries is kept by Michael Plass. Currently, the ColorPatch viewer uses mapIndex 128.
5. CesColorTool Command
If the tool is started with the command CesColorTool, the following substitutions happen:
1. CIE Lightness, Chroma, and Hue instead of Hue, Saturation, and Lightness;
2. YES Linear instead of Cyan, Magenta, and Yellow;
3. Xerox Hue, Saturation, and Value instead of Research Hue, Saturation, and Value.
Known errors and restrictions:
1. To avoid recompilation of the interface module, if a ColorTool is created by program, then a ColorTool or CesColorTool is created with the same choice as the last creation from a CommandTool.
2. In the L*C*h* color space the gamut is alway clipped in the chroma direction. This is because there is no way to tell which of the three sliders is being moved. It causes the funny behavior that the sliders are not independent when the lightness slider is moved.
3. ColorSchemeViewer contemplates only coordinate values in the interval [0, 1]. Therefore 0.5 is added to the chrominance coordinates in YES, lightness & chroma are divided by 100, and hue angles by 360. Note this means that for chromata > 100, sliders in other color spaces must be used.