home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-08-27 | 137.6 KB | 4,839 lines |
- \&
- .sp 1
- .ce 3
- \s+1\fBChapter 6\fP\s-1
-
- \s+1\fBColor Management Functions\fP\s-1
- .sp 2
- .nr H1 6
- .nr H2 0
- .nr H3 0
- .nr H4 0
- .nr H5 0
- .na
- .LP
- .XS
- Chapter 6: Color Management Functions
- .XE
- Each X window always has an associated colormap that
- provides a level of indirection between pixel values and colors displayed
- on the screen.
- Xlib provides functions that you can use to manipulate a colormap.
- The X protocol defines colors using values in the RGB color space.
- The RGB color space is device-dependent;
- rendering an RGB value on differing output devices typically results
- in different colors.
- Xlib also provides a means for clients to specify color using
- device-independent color spaces,
- for consistent results across devices.
- Xlib supports device-independent color spaces derivable from the CIE XYZ
- color space.
- This includes the CIE XYZ, xyY, L*u*v*, and L*a*b* color spaces as well as
- the TekHVC color space.
- .LP
- This chapter discusses how to:
- .IP \(bu 5
- Create, copy, and destroy a colormap
- .IP \(bu 5
- Specify colors by name or value
- .IP \(bu 5
- Allocate, modify, and free color cells
- .IP \(bu 5
- Read entries in a colormap
- .IP \(bu 5
- Convert between color spaces
- .IP \(bu 5
- Control aspects of color conversion
- .IP \(bu 5
- Query the color gamut of a screen
- .IP \(bu 5
- Add new color spaces
- .LP
- All functions, types, and symbols in this chapter with the prefix "Xcms"
- are defined in
- .Pn < X11/Xcms.h >.
- The remaining functions and types are defined in
- .Pn < X11/Xlib.h >.
- .LP
- Functions in this chapter manipulate the representation of color on the
- screen.
- For each possible value that a pixel can take in a window,
- there is a color cell in the colormap.
- For example,
- if a window is 4 bits deep, pixel values 0 through 15 are defined.
- A colormap is a collection of color cells.
- A color cell consists of a triple of red, green, and blue values.
- The hardware imposes limits on the number of significant
- bits in these values.
- As each pixel is read out of display memory, the pixel
- is looked up in a colormap.
- The RGB value of the cell determines what color is displayed on the screen.
- On a grayscale display with a black-and-white monitor
- the values are combined to determine the brightness on the screen.
- .LP
- Typically, an application allocates color cells or sets of color cells
- to obtain the desired colors.
- The client can allocate read-only cells,
- in which case the pixel values for these colors can be shared
- among multiple applications, and the RGB value of the cell cannot be changed.
- If the client allocates read/write cells,
- they are exclusively owned by the client,
- and the color associated with the pixel value may be changed at will.
- Cells must be allocated (and, if read/write, initialized with an RGB value)
- by a client to obtain desired colors; use of pixel value for an
- unallocated cell results in an undefined color.
- .LP
- Because colormaps are associated with windows, X supports displays
- with multiple colormaps and, indeed, different types of colormaps.
- If there are not sufficient colormap resources in the display,
- some windows will display in their true colors, and others
- will display with incorrect colors.
- A window manager usually controls which windows are displayed
- in their true colors if more than one colormap is required for
- the color resources the applications are using.
- At any time, there is a set of \fIinstalled\fP colormaps for a screen.
- Windows using one of the installed colormaps display with true colors, and
- windows using other colormaps generally display with incorrect colors.
- The set of installed colormaps is controlled using
- .PN XInstallColormap
- and
- .PN XUninstallColormap .
- .LP
- Colormaps are local to a particular screen.
- Screens always have a default colormap,
- and programs typically allocate cells out of this colormap.
- You should not in general write applications that monopolize
- color resources.
- Although some hardware supports multiple colormaps installed at one time,
- many of the hardware displays
- built today support only a single installed colormap, so the primitives
- are written to encourage sharing of colormap entries between applications.
- .LP
- The
- .PN DefaultColormap
- macro returns the default colormap.
- The
- .PN DefaultVisual
- macro
- returns the default visual type for the specified screen.
- .IN "Color map"
- Possible visual types are
- .PN StaticGray ,
- .PN GrayScale ,
- .PN StaticColor ,
- .PN PseudoColor ,
- .PN TrueColor ,
- or
- .PN DirectColor
- (see section 3.1).
- .NH 2
- Color Structures
- .XS
- \*(SN Color Structures
- .XE
- .LP
- Functions which operate only on RGB color space values use an
- .PN XColor
- structure, which contains:
- .LP
- .IN "XColor" "" "@DEF@"
- .\" Start marker code here
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- unsigned long pixel; /* pixel value */
- unsigned short red, green, blue; /* rgb values */
- char flags; /* DoRed, DoGreen, DoBlue */
- char pad;
- } XColor;
- .De
- .\" End marker code here
- .LP
- The red, green, and blue values are always in the range 0 to 65535
- inclusive, independent of the number of bits actually used in the
- display hardware.
- The server scales these values down to the range used by the hardware.
- Black is represented by (0,0,0), white is represented by (65535,65535,65535).
- .IN "Color"
- In some functions,
- the flags member controls which of the red, green, and blue members is used
- and can be the inclusive OR of zero or more of
- .PN DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue .
- .LP
- .sp
- Functions which operate on all color space values use an
- .PN XcmsColor
- structure.
- This structure contains a union of substructures,
- each supporting color specification encoding for a particular color space.
- Like the
- .PN XColor
- structure, the
- .PN XcmsColor
- structure contains pixel
- and color specification information (the spec member in the
- .PN XcmsColor
- structure).
- .IN "XcmsColor" "" "@DEF@"
- .\" Start marker code here
- .LP
- .Ds 0
- .TA .5i 1i 2.5i
- .ta .5i 1i 2.5i
- typedef unsigned long XcmsColorFormat; /* Color Specification Format */
-
- typedef struct {
- union {
- XcmsRGB RGB;
- XcmsRGBi RGBi;
- XcmsCIEXYZ CIEXYZ;
- XcmsCIEuvY CIEuvY;
- XcmsCIExyY CIExyY;
- XcmsCIELab CIELab;
- XcmsCIELuv CIELuv;
- XcmsTekHVC TekHVC;
- XcmsPad Pad;
- } spec;
- XcmsColorFormat format;
- unsigned long pixel;
- } XcmsColor; /* Xcms Color Structure */
- .De
- .\" End marker code here
- .LP
- Because the color specification can be encoded for the various color spaces,
- encoding for the spec member is identified by the format member,
- which is of type
- .PN XcmsColorFormat .
- The following macros define standard formats.
- .\" Start marker code here
- .TS
- lw(.4i) lw(1.5i) lw(1.5i) lw(1.5i).
- T{
- #define
- T} T{
- .PN XcmsUndefinedFormat
- T} T{
- 0x00000000
- T}
- T{
- #define
- T} T{
- .PN XcmsCIEXYZFormat
- T} T{
- 0x00000001
- T} T{
- /* CIE XYZ */
- T}
- T{
- #define
- T} T{
- .PN XcmsCIEuvYFormat
- T} T{
- 0x00000002
- T} T{
- /* CIE u'v'Y */
- T}
- T{
- #define
- T} T{
- .PN XcmsCIExyYFormat
- T} T{
- 0x00000003
- T} T{
- /* CIE xyY */
- T}
- T{
- #define
- T} T{
- .PN XcmsCIELabFormat
- T} T{
- 0x00000004
- T} T{
- /* CIE L*a*b* */
- T}
- T{
- #define
- T} T{
- .PN XcmsCIELuvFormat
- T} T{
- 0x00000005
- T} T{
- /* CIE L*u*v* */
- T}
- T{
- #define
- T} T{
- .PN XcmsTekHVCFormat
- T} T{
- 0x00000006
- T} T{
- /* TekHVC */
- T}
- T{
- #define
- T} T{
- .PN XcmsRGBFormat
- T} T{
- 0x80000000
- T} T{
- /* RGB Device */
- T}
- T{
- #define
- T} T{
- .PN XcmsRGBiFormat
- T} T{
- 0x80000001
- T} T{
- /* RGB Intensity */
- T}
- .TE
- .\" End marker code here
- .LP
- Note that formats for device-independent color spaces are
- distinguishable from those for device-dependent spaces by the 32nd bit.
- If this bit is set,
- it indicates that the color specification is in a device-dependent form;
- otherwise, it is in a device-independent form.
- If the 31st bit is set,
- this indicates that the color space has been added to Xlib at run-time
- (see section 6.12.4).
- The format value for a color space added at run-time may be different each
- time the program is executed.
- If references to such a color space must be made outside the client
- (for example, storing a color specification in a file),
- then reference should be made by color space string prefix
- (see
- .PN XcmsFormatOfPrefix
- and
- .PN XcmsPrefixOfFormat ).
- .LP
- Data types that describe the color specification encoding for the various
- color spaces are defined as follows:
- .\" Start marker code here
- .IN "XcmsRGB" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef double XcmsFloat;
-
- typedef struct {
- unsigned short red; /* 0x0000 to 0xffff */
- unsigned short green; /* 0x0000 to 0xffff */
- unsigned short blue; /* 0x0000 to 0xffff */
- } XcmsRGB; /* RGB Device */
- .De
- .IN "XcmsRGBi" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat red; /* 0.0 to 1.0 */
- XcmsFloat green; /* 0.0 to 1.0 */
- XcmsFloat blue; /* 0.0 to 1.0 */
- } XcmsRGBi; /* RGB Intensity */
- .De
- .IN "XcmsCIEXYZ" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat X;
- XcmsFloat Y; /* 0.0 to 1.0 */
- XcmsFloat Z;
- } XcmsCIEXYZ; /* CIE XYZ */
- .De
- .IN "XcmsCIEuvY" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat u_prime; /* 0.0 to ~0.6 */
- XcmsFloat v_prime; /* 0.0 to ~0.6 */
- XcmsFloat Y; /* 0.0 to 1.0 */
- } XcmsCIEuvY; /* CIE u'v'Y */
- .De
- .IN "XcmsCIExyY" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat x; /* 0.0 to ~.75 */
- XcmsFloat y; /* 0.0 to ~.85 */
- XcmsFloat Y; /* 0.0 to 1.0 */
- } XcmsCIExyY; /* CIE xyY */
- .De
- .IN "XcmsCIELab" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat L_star; /* 0.0 to 100.0 */
- XcmsFloat a_star;
- XcmsFloat b_star;
- } XcmsCIELab; /* CIE L*a*b* */
- .De
- .IN "XcmsCIELuv" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat L_star; /* 0.0 to 100.0 */
- XcmsFloat u_star;
- XcmsFloat v_star;
- } XcmsCIELuv; /* CIE L*u*v* */
- .De
- .IN "XcmsTekHVC" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat H; /* 0.0 to 360.0 */
- XcmsFloat V; /* 0.0 to 100.0 */
- XcmsFloat C; /* 0.0 to 100.0 */
- } XcmsTekHVC; /* TekHVC */
- .De
- .IN "XcmsPad" "" "@DEF@"
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct {
- XcmsFloat pad0;
- XcmsFloat pad1;
- XcmsFloat pad2;
- XcmsFloat pad3;
- } XcmsPad; /* four doubles */
- .De
- .\" End marker code here
- .LP
- The device-dependent formats provided allow color specification in:
- .IP \(bu 5
- RGB Intensity
- .Pn ( XcmsRGBi )
- .IP
- Red, green, and blue linear intensity values,
- floating point values from 0.0 to 1.0,
- where 1.0 indicates full intensity, 0.5 half intensity, and so on.
- .IP \(bu 5
- RGB Device
- .Pn ( XcmsRGB )
- .IP
- Red, green, and blue values appropriate for the specified output device.
- .PN XcmsRGB
- values are of type unsigned short,
- scaled from 0 to 65535 inclusive,
- and are interchangeable with values
- the red, green, and blue values in an
- .PN XColor
- structure.
- .LP
- It is important to note that RGB Intensity values are not gamma corrected
- values.
- In contrast,
- RGB Device values generated as a result of converting color specifications
- are always gamma corrected, and
- RGB Device values acquired as a result of querying a colormap
- or passed in by the client are assumed by Xlib to be gamma corrected.
- The term ``RGB value'' in this manual always refers to an RGB Device value.
- .NH 2
- Color Strings
- .XS
- \*(SN Color Strings
- .XE
- .LP
- Xlib provides a mechanism for using string names for colors.
- A color string may either contain an abstract color name
- or a numerical color specification.
- Color strings are case-insensitive.
- .LP
- Color strings are used in the following functions:
- .IP \(bu 5
- .PN XAllocNamedColor
- .IP \(bu 5
- .PN XcmsAllocNamedColor
- .IP \(bu 5
- .PN XLookupColor
- .IP \(bu 5
- .PN XcmsLookupColor
- .IP \(bu 5
- .PN XParseColor
- .IP \(bu 5
- .PN XStoreNamedColor
- .LP
- Xlib supports the use of abstract color names, for example, "red", "blue".
- A value for this abstract name is obtained by searching one or more color
- name databases.
- Xlib first searches zero or more client-side databases;
- the number, location, and content of these databases is
- implementation dependent, and might depend on the current locale.
- If the name is not found, Xlib then looks for the color in the
- X server's database.
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- .LP
- A numerical color specification
- consists of a color space name and a set of values in the following syntax:
- .LP
- .Ds 0
- \fI<color_space_name>\fP:\fI<value>/.../<value>\fP
- .De
- .LP
- The following are examples of valid color strings.
- .LP
- .Ds 0
- "CIEXYZ:0.3227/0.28133/0.2493"
- "RGBi:1.0/0.0/0.0"
- "rgb:00/ff/00"
- "CIELuv:50.0/0.0/0.0"
- .De
- The syntax and semantics of numerical specifications are given
- for each standard color space in sections below.
- .NH 3
- RGB Device String Specification
- .XS
- \*(SN RGB Device String Specification
- .XE
- .LP
- An RGB Device specification is identified by
- the prefix "rgb:" and conforms to the following syntax:
- .LP
- .\" Start marker code here
- .Ds 0
- rgb:\fI<red>/<green>/<blue>\fP
-
- \fI<red>\fP, \fI<green>\fP, \fI<blue>\fP := \fIh\fP | \fIhh\fP | \fIhhh\fP | \fIhhhh\fP
- \fIh\fP := single hexadecimal digits (case insignificant)
- .De
- .\" End marker code here
- .LP
- Note that \fIh\fP indicates the value scaled in 4 bits,
- \fIhh\fP the value scaled in 8 bits,
- \fIhhh\fP the value scaled in 12 bits,
- and \fIhhhh\fP the value scaled in 16 bits, respectively.
- .LP
- Typical examples are "rgb:ea/75/52" and "rgb:ccc/320/320",
- but mixed numbers of hex digits ("rgb:ff/a5/0" and "rgb:ccc/32/0")
- are also allowed.
- .LP
- For backward compatibility, an older syntax for RGB Device is
- supported, but its continued use is not encouraged.
- The syntax is an initial sharp sign character followed by
- a numeric specification, in one of the following formats:
- .LP
- .Ds 0
- .TA 2i
- .ta 2i
- #RGB (4 bits each)
- #RRGGBB (8 bits each)
- #RRRGGGBBB (12 bits each)
- #RRRRGGGGBBBB (16 bits each)
- .De
- .LP
- The R, G, and B represent single hexadecimal digits.
- When fewer than 16 bits each are specified,
- they represent the most-significant bits of the value
- (unlike the "rgb:" syntax, in which values are scaled).
- For example, #3a7 is the same as #3000a0007000.
- .NH 3
- RGB Intensity String Specification
- .XS
- \*(SN RGB Intensity String Specification
- .XE
- .LP
- An RGB intensity specification is identified
- by the prefix "rgbi:" and conforms to the following syntax:
- .LP
- .\" Start marker code here
- .Ds 0
- rgbi:\fI<red>/<green>/<blue>\fP
- .De
- .\" End marker code here
- .LP
- Note that red, green, and blue are floating point values
- between 0.0 and 1.0, inclusive.
- The input format for these values is an optional sign,
- a string of numbers possibly containing a decimal point,
- and an optional exponent field containing an E or e
- followed by a possibly signed integer string.
- .NH 3
- Device-Independent String Specifications
- .XS
- \*(SN Device-Independent String Specifications
- .XE
- .LP
- The standard device-independent string specifications have
- the following syntax:
- .LP
- .Ds 0
- CIEXYZ:\fI<X>/<Y>/<Z>\fP
- CIEuvY:\fI<u>/<v>/<Y>\fP
- CIExyY:\fI<x>/<y>/<Y>\fP
- CIELab:\fI<L>/<a>/<b>\fP
- CIELuv:\fI<L>/<u>/<v>\fP
- TekHVC:\fI<H>/<V>/<C>\fP
- .De
- .LP
- All of the values (C, H, V, X, Y, Z, a, b, u, v, y, x) are
- floating point values.
- The syntax for these values is an optional '+' or '-' sign,
- a string of digits possibly containing a decimal point,
- and an optional exponent field consisting of an 'E' or 'e'
- followed by an optional '+' or '-' followed by a string of digits.
- .NH 2
- Color Conversion Contexts and Gamut Mapping
- .XS
- \*(SN Color Conversion Contexts and Gamut Mapping
- .XE
- .LP
- When Xlib converts device-independent color specifications
- into device-dependent specifications and vice-versa,
- it uses knowledge about the color limitations of the screen hardware.
- This information, typically called the device profile,
- .IN "device profile"
- is available in a Color Conversion Context
- (hereafter referred to as the CCC).
- .IN "Color Conversion Context"
- .IN "CCC"
- .LP
- Because a specified color may be outside the color gamut of the target screen
- and the white point associated with the color specification may differ
- from the white point inherent to the screen,
- Xlib applies gamut mapping when certain conditions are encountered:
- .IN "white point"
- .IP \(bu 5
- Gamut compression when conversion of device-independent color specifications
- to device-dependent
- color specification results in a color out of the target screen's gamut.
- .IP \(bu 5
- White adjustment when the inherent white point of the screen
- differs from the white point assumed by the client.
- .LP
- Gamut handling methods are stored as callbacks in the CCC,
- which, in turn, are used by the color space conversion routines.
- Client data is also stored in the CCC for each callback.
- The CCC also contains the white point the client assumes to be
- associated with color specifications (that is, the Client White Point).
- .IN "Client White Point"
- .IN "gamut compression"
- .IN "gamut handling"
- .IN "white point adjustment"
- The client can specify the gamut handling callbacks and client data,
- as well the Client White Point.
- Note that Xlib does not preclude the X client from performing other
- forms of gamut handling (for example, gamut expansion);
- however, direct support for gamut handling other than white adjustment
- and gamut compression is not provided by Xlib.
- .LP
- Associated with each colormap is an initial CCC transparently generated by
- Xlib.
- .IN "Color Conversion Context" "creation"
- Therefore,
- when you specify a colormap as an argument to an Xlib function,
- you are indirectly specifying a CCC.
- .IN "CCC" "of colormap"
- .IN "Color Conversion Context" "of colormap"
- There is a default CCC associated with each screen.
- Newly created CCCs inherit attributes from the default CCC,
- so the default CCC attributes can be modified to affect new CCCs.
- .IN "CCC" "default"
- .IN "Color Conversion Context" "default"
- .LP
- Xcms functions in which gamut mapping can occur return
- .PN Status ,
- and have specific status values defined for them:
- .IP \(bu 5
- .PN XcmsFailure
- indicates that the function failed.
- .IP \(bu 5
- .PN XcmsSuccess
- indicates that the function succeeded.
- In addition,
- if the function performed any color conversion,
- the color (or colors) did not need to be compressed.
- .IP \(bu 5
- .PN XcmsSuccessWithCompression
- indicates the function performed color conversion,
- and at least one of the colors needed to be compressed.
- The gamut compression method is determined by the gamut compression
- procedure in the CCC that is specified directly as a function argument,
- or in the CCC indirectly specified by means of the colormap argument.
- .NH 2
- Creating, Copying, and Destroying Colormaps
- .XS
- \*(SN Creating, Copying, and Destroying Colormaps
- .XE
- .LP
- To create a colormap for a screen, use
- .PN XCreateColormap .
- .IN "XCreateColormap" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XCreateCmap.f,v 1.1 88/02/26 09:59:15 mento Exp $
- Colormap XCreateColormap\^(\^\fIdisplay\fP, \fIw\fP\^, \fIvisual\fP\^, \fIalloc\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Window \fIw\fP\^;
- .br
- Visual *\fIvisual\fP\^;
- .br
- int \fIalloc\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .ds Wi on whose screen you want to create a colormap
- .\" $Header: w_gen.a,v 1.4 88/08/04 11:21:56 mento Exp $
- .IP \fIw\fP 1i
- Specifies the window \*(Wi.
- .\" $Header: visual1.a,v 1.3 88/05/09 05:55:50 mento Exp $
- .IP \fIvisual\fP 1i
- Specifies a visual type supported on the screen.
- If the visual type is not one supported by the screen,
- a
- .PN BadMatch
- error results.
- .\" $Header: alloc.a,v 1.3 88/05/09 13:32:50 mento Exp $
- .IP \fIalloc\fP 1i
- Specifies the colormap entries to be allocated.
- You can pass
- .PN AllocNone
- or
- .PN AllocAll .
- .\" End marker code here
- .LP
- .\" $Header: XCreateCmap.d,v 1.5 88/08/18 07:31:05 mento Exp $
- The
- .PN XCreateColormap
- function creates a colormap of the specified visual type for the screen
- on which the specified window resides and returns the colormap ID
- associated with it.
- Note that the specified window is only used to determine the screen.
- .LP
- The initial values of the colormap entries are undefined for the
- visual classes
- .PN GrayScale ,
- .PN PseudoColor ,
- and
- .PN DirectColor .
- For
- .PN StaticGray ,
- .PN StaticColor ,
- and
- .PN TrueColor ,
- the entries have defined values,
- but those values are specific to the visual and are not defined by X.
- For
- .PN StaticGray ,
- .PN StaticColor ,
- and
- .PN TrueColor ,
- alloc must be
- .PN AllocNone ,
- or a
- .PN BadMatch
- error results.
- For the other visual classes,
- if alloc is
- .PN AllocNone ,
- the colormap initially has no allocated entries,
- and clients can allocate them.
- For information about the visual types,
- see section 3.1.
- .LP
- If alloc is
- .PN AllocAll ,
- the entire colormap is allocated writable.
- The initial values of all allocated entries are undefined.
- For
- .PN GrayScale
- and
- .PN PseudoColor ,
- the effect is as if an
- .PN XAllocColorCells
- call returned all pixel values from zero to N \- 1,
- where N is the colormap entries value in the specified visual.
- For
- .PN DirectColor ,
- the effect is as if an
- .PN XAllocColorPlanes
- call returned a pixel value of zero and red_mask, green_mask,
- and blue_mask values containing the same bits as the corresponding
- masks in the specified visual.
- However, in all cases,
- none of these entries can be freed by using
- .PN XFreeColors .
- .LP
- .PN XCreateColormap
- can generate
- .PN BadAlloc ,
- .PN BadMatch ,
- .PN BadValue ,
- and
- .PN BadWindow
- errors.
- .LP
- .sp
- To create a new colormap when the allocation out of a previously
- shared colormap has failed because of resource exhaustion, use
- .PN XCopyColormapAndFree .
- .IN "XCopyColormapAndFree" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XCopyCmapFr.f,v 1.2 88/05/09 06:38:00 mento Exp $
- Colormap XCopyColormapAndFree\^(\^\fIdisplay\fP, \fIcolormap\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" End marker code here
- .LP
- .\" $Header: XCopyCmapFr.d,v 1.3 88/06/11 07:49:27 mento Exp $
- The
- .PN XCopyColormapAndFree
- function creates a colormap of the same visual type and for the same screen
- as the specified colormap and returns the new colormap ID.
- It also moves all of the client's existing allocation from the specified
- colormap to the new colormap with their color values intact
- and their read-only or writable characteristics intact and frees those entries
- in the specified colormap.
- Color values in other entries in the new colormap are undefined.
- If the specified colormap was created by the client with alloc set to
- .PN AllocAll ,
- the new colormap is also created with
- .PN AllocAll ,
- all color values for all entries are copied from the specified colormap,
- and then all entries in the specified colormap are freed.
- If the specified colormap was not created by the client with
- .PN AllocAll ,
- the allocations to be moved are all those pixels and planes
- that have been allocated by the client using
- .PN XAllocColor ,
- .PN XAllocNamedColor ,
- .PN XAllocColorCells ,
- or
- .PN XAllocColorPlanes
- and that have not been freed since they were allocated.
- .LP
- .PN XCopyColormapAndFree
- can generate
- .PN BadAlloc
- and
- .PN BadColor
- errors.
- .LP
- .sp
- To destroy a colormap, use
- .PN XFreeColormap .
- .IN "XFreeColormap" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XFreeCmap.f,v 1.2 88/05/09 07:01:35 mento Exp $
- XFreeColormap\^(\^\fIdisplay\fP, \fIcolormap\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .ds Cm that you want to destroy
- .\" $Header: cmap_gen.a,v 1.2 88/08/04 11:07:18 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap \*(Cm.
- .\" End marker code here
- .LP
- .\" $Header: XFreeCmap.d,v 1.4 88/06/11 07:50:44 mento Exp $
- The
- .PN XFreeColormap
- function deletes the association between the colormap resource ID
- and the colormap and frees the colormap storage.
- However, this function has no effect on the default colormap for a screen.
- If the specified colormap is an installed map for a screen,
- it is uninstalled (see
- .PN XUninstallColormap ).
- If the specified colormap is defined as the colormap for a window (by
- .PN XCreateWindow ,
- .PN XSetWindowColormap ,
- or
- .PN XChangeWindowAttributes ),
- .PN XFreeColormap
- changes the colormap associated with the window to
- .PN None
- and generates a
- .PN ColormapNotify
- event.
- X does not define the colors displayed for a window with a colormap of
- .PN None .
- .LP
- .PN XFreeColormap
- can generate a
- .PN BadColor
- error.
- .NH 2
- Mapping Color Names to Values
- .XS
- \*(SN Mapping Color Names to Values
- .XE
- .LP
- .sp
- To map a color name to an RGB value, use
- .PN XLookupColor .
- .IN "color" "naming"
- .IN "XLookupColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XLookupColor\^(\^\fIdisplay\fP, \fIcolormap\fP, \fIcolor_name\fP, \
- \fIexact_def_return\fP\^, \fIscreen_def_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\fIcolor_name\fP\^;
- .br
- XColor *\fIexact_def_return\fP\^, *\fIscreen_def_return\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: colorname.a,v 1.2 88/05/09 07:14:45 mento Exp $
- .IP \fIcolor_name\fP 1i
- Specifies the color name string (for example, red) whose color
- definition structure you want returned.
- .\" $Header: exact_def.a,v 1.1 88/02/26 10:26:55 mento Exp $
- .IP \fIexact_def_return\fP 1i
- Returns the exact RGB values.
- .\" $Header: hard_def.a,v 1.2 88/04/23 08:59:18 mento Exp $
- .IP \fIscreen_def_return\fP 1i
- Returns the closest RGB values provided by the hardware.
- .\" End marker code here
- .LP
- .\" $Header: XLkUpColor.d,v 1.3 88/06/11 07:51:53 mento Exp $
- The
- .PN XLookupColor
- function looks up the string name of a color with respect to the screen
- associated with the specified colormap.
- It returns both the exact color values and
- the closest values provided by the screen
- with respect to the visual type of the specified colormap.
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- .PN XLookupColor
- returns nonzero if the name is resolved,
- otherwise it returns zero.
- .LP
- .PN XLookupColor
- can generate a
- .PN BadColor
- error.
- .LP
- .sp
- To map a color name to just the exact RGB value, use
- .PN XParseColor .
- .IN "color" "naming"
- .IN "XParseColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XParseColor.f,v 1.2 88/05/20 05:14:03 mento Exp $
- Status XParseColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \^\fIspec\fP\^, \fIexact_def_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\fIspec\fP\^;
- .br
- XColor *\fIexact_def_return\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: spec.a,v 1.4 88/07/10 12:59:48 mento Exp $
- .IP \fIspec\fP 1i
- Specifies the color name string;
- case is ignored.
- .\" $Header: def.a,v 1.2 88/04/07 16:52:05 mento Exp $
- .IP \fIexact_def_return\fP 1i
- Returns the exact color value for later use and sets the
- .PN DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue
- flags.
- .\" End marker code here
- .LP
- .\" $Header: XParseColor.d,v 1.4 88/08/23 15:05:59 mento Exp $
- The
- .PN XParseColor
- function looks up the string name of a color with respect to the screen
- associated with the specified colormap.
- It returns the exact color value.
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- .PN XParseColor
- returns nonzero if the name is resolved,
- otherwise it returns zero.
- .LP
- .PN XParseColor
- can generate a
- .PN BadColor
- error.
- .LP
- .sp
- To map a color name to a value in an arbitrary color space, use
- .PN XcmsLookupColor .
- .IN "color" "naming"
- .IN "XcmsLookupColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsLookupColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor_string\fP\^, \fIcolor_exact_return\fP\^, \fIcolor_screen_return\fP\^,
- .br
- \fIresult_format\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\fIcolor_string\fP\^;
- .br
- XcmsColor *\fIcolor_exact_return\fP\^, *\fIcolor_screen_return\fP\^;
- .br
- XcmsColorFormat \fIresult_format\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .ds St
- .\" $Header$
- .IP \fIcolor_string\fP 1i
- Specifies the color string\*(St.
- .\" $Header$
- .IP \fIcolor_exact_return\fP 1i
- Returns the color specification parsed from the color string
- or parsed from the corresponding string found in a color name database.
- .IP \fIcolor_screen_return\fP 1i
- Returns the color that can be reproduced on the
- .PN Screen .
- .\" $Header$
- .IP \fIresult_format\fP 1i
- Specifies the color format for the returned color
- specifications (color_screen_return and color_exact_return arguments).
- If format is
- .PN XcmsUndefinedFormat
- and the color string contains a
- numerical color specification,
- the specification is returned in the format used in that numerical
- color specification.
- If format is
- .PN XcmsUndefinedFormat
- and the color string contains a color name,
- the specification is returned in the format used
- to store the color in the database.
- .\" End marker code here
- .LP
- The
- .PN XcmsLookupColor
- function looks up the string name of a color with respect to the screen
- associated with the specified colormap.
- It returns both the exact color values and
- the closest values provided by the screen
- with respect to the visual type of the specified colormap.
- The values are returned in the format specified by result_format.
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- .PN XcmsLookupColor
- returns
- .PN XcmsSuccess
- or
- .PN XcmsSuccessWithCompression
- if the name is resolved, otherwise it returns
- .PN XcmsFailure .
- If
- .PN XcmsSuccessWithCompression
- is resturned, then the color specification
- in \fIcolor_screen_return\fP is the result of gamut compression.
- .NH 2
- Allocating and Freeing Color Cells
- .XS
- \*(SN Allocating and Freeing Color Cells
- .XE
- .LP
- There are two ways of allocating color cells:
- explicitly as read-only entries, one pixel value at a time,
- or read/write,
- where you can allocate a number of color cells and planes simultaneously.
- .IN "read-only colormap cells"
- A read-only cell has its RGB value set by the server.
- .IN "read/write colormap cells"
- Read/write cells do not have defined colors initially;
- functions described in the next section must be used to store values into them.
- Although it is possible for any client to store values into a read/write
- cell allocated by another client,
- read/write cells normally should be considered private to the client
- that allocated them.
- .LP
- Read-only colormap cells are shared among clients.
- The server counts each allocation and free of the cell by clients.
- When the last client frees a shared cell, the cell is finally deallocated.
- Note that if a single client allocates the same read-only cell multiple
- times, the server counts each such allocation, not just the first one.
- .LP
- .sp
- To allocate a read-only color cell with an RGB value, use
- .PN XAllocColor .
- .IN "Allocation" "read-only colormap cells"
- .IN "read-only colormap cells" "allocating"
- .IN "color" "allocation"
- .IN "XAllocColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XGetHardClr.f,v 1.2 88/05/09 07:09:13 mento Exp $
- Status XAllocColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIscreen_in_out\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XColor *\fIscreen_in_out\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: def_io.a,v 1.3 88/05/10 05:17:05 mento Exp $
- .IP \fIscreen_in_out\fP 1i
- Specifies and returns the values actually used in the colormap.
- .\" End marker code here
- .LP
- .\" $Header: XGetHardClr.d,v 1.4 88/06/11 07:51:02 mento Exp $
- The
- .PN XAllocColor
- function allocates a read-only colormap entry corresponding to the closest
- RGB value supported by the hardware.
- .PN XAllocColor
- returns the pixel value of the color closest to the specified
- RGB elements supported by the hardware
- and returns the RGB value actually used.
- The corresponding colormap cell is read-only.
- In addition,
- .PN XAllocColor
- returns nonzero if it succeeded or zero if it failed.
- .IN "Color map"
- .IN "Color" "allocation"
- .IN "Allocation" "colormap"
- .IN "read-only colormap cells"
- Multiple clients that request the same effective RGB value can be assigned
- the same read-only entry, thus allowing entries to be shared.
- When the last client deallocates a shared cell, it is deallocated.
- .PN XAllocColor
- does not use or affect the flags in the
- .PN XColor
- structure.
- .LP
- .PN XAllocColor
- can generate a
- .PN BadColor
- error.
- .EQ
- delim %%
- .EN
- .LP
- .sp
- To allocate a read-only color cell with a color in arbitrary format, use
- .PN XcmsAllocColor .
- .IN "allocation" "read-only colormap cells"
- .IN "read-only colormap cells" "allocating"
- .IN "color" "allocation"
- .IN "XcmsAllocColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsAllocColor\^(\^\fIdisplay\fP\^, \fIcolormap\fP\^, \fIcolor_in_out\fP\^, \fIresult_format\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsColor *\fIcolor_in_out\fP\^;
- .br
- XcmsColorFormat \fIresult_format\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header$
- .IP \fIcolor_in_out\fP 1i
- Specifies the color to allocate and returns the pixel and color
- that is actually used in the colormap.
- .\" $Header$
- .IP \fIresult_format\fP 1i
- Specifies the color format for the returned color specification.
- .\" End marker code here
- .LP
- The
- .PN XcmsAllocColor
- function is similar to
- .PN XAllocColor
- except the color can be specified in any format.
- The
- .PN XcmsAllocColor
- function ultimately calls
- .PN XAllocColor
- to allocate a read-only color cell (colormap entry) with the specified color.
- .PN XcmsAllocColor
- first converts the color specified
- to an RGB value and then passes this to
- .PN XAllocColor .
- .PN XcmsAllocColor
- returns the pixel value of the color cell and the color specification
- actually allocated.
- This returned color specification is the result of converting the RGB value
- returned by
- .PN XAllocColor
- into the format specified with the result_format argument.
- If there is no interest in a returned color specification,
- unnecessary computation can be bypassed if result_format is set to
- .PN XcmsRGBFormat .
- The corresponding colormap cell is read-only.
- If this routine returns
- .PN XcmsFailure ,
- the color_in_out color specification is left unchanged.
- .LP
- .PN XcmsAllocColor
- can generate a
- .PN BadColor
- error.
- .LP
- .sp
- To allocate a read-only color cell using a color name, and return the closest
- color supported by the hardware in RGB format, use
- .PN XAllocNamedColor .
- .IN "allocation" "read-only colormap cells"
- .IN "read-only colormap cells" "allocating"
- .IN "color" "naming"
- .IN "color" "allocation"
- .IN "XAllocNamedColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XGetColor.f,v 1.5 88/05/09 07:13:26 mento Exp $
- Status XAllocNamedColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \
- \fIcolor_name\fP\^, \fIscreen_def_return\fP\^, \fIexact_def_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\fIcolor_name\fP\^;
- .br
- XColor *\fIscreen_def_return\fP\^, *\fIexact_def_return\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: colorname.a,v 1.2 88/05/09 07:14:45 mento Exp $
- .IP \fIcolor_name\fP 1i
- Specifies the color name string (for example, red) whose color
- definition structure you want returned.
- .\" $Header: hard_def.a,v 1.2 88/04/23 08:59:18 mento Exp $
- .IP \fIscreen_def_return\fP 1i
- Returns the closest RGB values provided by the hardware.
- .\" $Header: exact_def.a,v 1.1 88/02/26 10:26:55 mento Exp $
- .IP \fIexact_def_return\fP 1i
- Returns the exact RGB values.
- .\" End marker code here
- .LP
- .\" $Header: XGetColor.d,v 1.3 88/06/11 07:50:59 mento Exp $
- The
- .PN XAllocNamedColor
- function looks up the named color with respect to the screen that is
- associated with the specified colormap.
- It returns both the exact database definition and
- the closest color supported by the screen.
- The allocated color cell is read-only.
- The pixel value is returned in screen_def_return.
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- .PN XLookupColor
- returns nonzero if a cell is allocated,
- otherwise it returns zero.
- .LP
- .PN XAllocNamedColor
- can generate a
- .PN BadColor
- error.
- .LP
- .sp
- To allocate a read-only color cell using a color name, and return the closest
- color supported by the hardware in an arbitrary format, use
- .PN XcmsAllocNamedColor .
- .IN "allocation" "read-only colormap cells"
- .IN "read-only colormap cells" "allocating"
- .IN "color" "naming"
- .IN "color" "allocation"
- .IN "XcmsAllocNamedColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsAllocNamedColor\^(\^\fIdisplay\fP\^, \fIcolormap\fP\^, \fIcolor_string\fP\^, \fIresult_format\fP\^, \fIcolor_screen_return\fP\^,
- .br
- \fIcolor_exact_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\fIcolor_string\fP\^;
- .br
- XcmsColorFormat \fIresult_format\fP\^;
- .br
- XcmsColor *\fIcolor_screen_return\fP\^;
- .br
- XcmsColor *\fIcolor_exact_return\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .ds St \ whose color definition structure is to be returned
- .\" $Header$
- .IP \fIcolor_string\fP 1i
- Specifies the color string\*(St.
- .\" $Header$
- .IP \fIresult_format\fP 1i
- Specifies the color format for the returned color
- specifications (color_screen_return and color_exact_return arguments).
- If format is
- .PN XcmsUndefinedFormat
- and the color string contains a
- numerical color specification,
- the specification is returned in the format used in that numerical
- color specification.
- If format is
- .PN XcmsUndefinedFormat
- and the color string contains a color name,
- the specification is returned in the format used
- to store the color in the database.
- .\" $Header$
- .IP \fIcolor_screen_return\fP 1i
- Returns the pixel value of the color cell and color specification
- that actually is stored for that cell.
- .\" $Header$
- .IP \fIcolor_exact_return\fP 1i
- Returns the color specification parsed from the color string
- or parsed from the corresponding string found in a color name database.
- .\" End marker code here
- .LP
- The
- .PN XcmsAllocNamedColor
- function is similar to
- .PN XAllocNamedColor
- except the color returned can be in any format specified.
- This function
- ultimately calls
- .PN XAllocColor
- to allocate a read-only color cell with
- the color specified by a color string.
- The color string is parsed into an
- .PN XcmsColor
- structure (see
- .PN XcmsLookupColor ),
- converted
- to an RGB value, then finally passed to the
- .PN XAllocColor .
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- .LP
- This function returns both the color specification as a result
- of parsing (exact specification) and the actual color specification
- stored (screen specification).
- This screen specification is the result of converting the RGB value
- returned by
- .PN XAllocColor
- into the format specified in result_format.
- If there is no interest in a returned color specification,
- unnecessary computation can be bypassed if result_format is set to
- .PN XcmsRGBFormat .
- .LP
- .PN XcmsAllocNamedColor
- can generate a
- .PN BadColor
- error.
- .LP
- .sp
- To allocate read/write color cell and color plane combinations for a
- .PN PseudoColor
- model, use
- .PN XAllocColorCells .
- .IN "read/write colormap cells" "allocating"
- .IN "allocation" "read/write colormap cells"
- .IN "color" "allocation"
- .IN "XAllocColorCells" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XAllocCells.f,v 1.3 88/07/10 10:24:51 mento Exp $
- Status XAllocColorCells\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcontig\fP\^, \
- \fIplane_masks_return\fP\^, \fInplanes\fP\^,
- .br
- \fIpixels_return\fP\^, \fInpixels\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- Bool \fIcontig\fP\^;
- .br
- unsigned long \fIplane_masks_return\fP[\^]\^;
- .br
- unsigned int \fInplanes\fP\^;
- .br
- unsigned long \fIpixels_return\fP[\^]\^;
- .br
- unsigned int \fInpixels\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: contig.a,v 1.4 88/05/09 07:26:02 mento Exp $
- .IP \fIcontig\fP 1i
- Specifies a Boolean value that indicates whether the planes must be contiguous.
- .\" $Header: plane_masks.a,v 1.1 88/02/26 10:30:29 mento Exp $
- .IP \fIplane_mask_return\fP 1i
- Returns an array of plane masks.
- .\" *** JIM: NEED MORE INFO FOR THIS. ***
- .\" $Header: nplanes.a,v 1.1 88/02/26 10:29:45 mento Exp $
- .IP \fInplanes\fP 1i
- Specifies the number of plane masks that are to be returned in the plane masks
- array.
- .\" $Header: pixels.a,v 1.1 88/02/26 10:30:24 mento Exp $
- .IP \fIpixels_return\fP 1i
- Returns an array of pixel values.
- .\" $Header: npixels1.a,v 1.1 88/07/10 10:22:06 mento Exp $
- .IP \fInpixels\fP 1i
- Specifies the number of pixel values that are to be returned in the
- pixels_return array.
- .\" End marker code here
- .LP
- .\" $Header: XAllocCells.d,v 1.4 88/08/18 07:35:58 mento Exp $
- .EQ
- delim %%
- .EN
- The
- .PN XAllocColorCells
- function allocates read/write color cells.
- The number of colors must be positive and the number of planes nonnegative,
- or a
- .PN BadValue
- error results.
- If ncolors and nplanes are requested,
- then ncolors pixels
- and nplane plane masks are returned.
- No mask will have any bits set to 1 in common with
- any other mask or with any of the pixels.
- By ORing together each pixel with zero or more masks,
- ncolors * %2 sup nplanes% distinct pixels can be produced.
- All of these are
- allocated writable by the request.
- For
- .PN GrayScale
- or
- .PN PseudoColor ,
- each mask has exactly one bit set to 1.
- For
- .PN DirectColor ,
- each has exactly three bits set to 1.
- If contig is
- .PN True
- and if all masks are ORed
- together, a single contiguous set of bits set to 1 will be formed for
- .PN GrayScale
- or
- .PN PseudoColor
- and three contiguous sets of bits set to 1 (one within each
- pixel subfield) for
- .PN DirectColor .
- The RGB values of the allocated
- entries are undefined.
- .PN XAllocColorCells
- returns nonzero if it succeeded or zero if it failed.
- .LP
- .PN XAllocColorCells
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To allocate read/write color resources for a
- .PN DirectColor
- model, use
- .PN XAllocColorPlanes .
- .IN "read/write colormap planes" "allocating"
- .IN "allocation" "read/write colormap planes"
- .IN "color" "allocation"
- .IN "XAllocColorPlanes" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XAllocPlanes.f,v 1.2 88/05/09 07:36:19 mento Exp $
- Status XAllocColorPlanes\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcontig\fP\^, \fIpixels_return\fP\^, \fIncolors\fP\^, \fInreds\fP\^, \fIngreens\fP\^,
- .br
- \fInblues\fP\^, \fIrmask_return\fP\^, \fIgmask_return\fP\^, \fIbmask_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- Bool \fIcontig\fP\^;
- .br
- unsigned long \fIpixels_return\fP[\^]\^;
- .br
- int \fIncolors\fP\^;
- .br
- int \fInreds\fP\^, \fIngreens\fP\^, \fInblues\fP\^;
- .br
- unsigned long *\fIrmask_return\fP\^, *\fIgmask_return\fP\^, *\fIbmask_return\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: contig.a,v 1.4 88/05/09 07:26:02 mento Exp $
- .IP \fIcontig\fP 1i
- Specifies a Boolean value that indicates whether the planes must be contiguous.
- .\" $Header: pixels.a,v 1.1 88/02/26 10:30:24 mento Exp $
- .IP \fIpixels_return\fP 1i
- Returns an array of pixel values.
- .PN XAllocColorPlanes
- returns the pixel values in this array.
- .\" $Header: ncolors1.a,v 1.1 88/02/26 10:29:29 mento Exp $
- .IP \fIncolors\fP 1i
- Specifies the number of pixel values that are to be returned in the
- pixels_return array.
- .\" $Header: nredgrbl.a,v 1.3 88/05/09 07:37:51 mento Exp $
- .IP \fInreds\fP 1i
- .br
- .ns
- .IP \fIngreens\fP 1i
- .br
- .ns
- .IP \fInblues\fP 1i
- .br
- .ns
- Specify the number of red, green, and blue planes.
- The value you pass must be nonnegative.
- .\" $Header: rgbmask.a,v 1.1 88/02/26 10:31:01 mento Exp $
- .IP \fIrmask_return\fP 1i
- .br
- .ns
- .IP \fIgmask_return\fP 1i
- .br
- .ns
- .IP \fIbmask_return\fP 1i
- Return bit masks for the red, green, and blue planes.
- .\" End marker code here
- .LP
- .\" $Header: XAllocPlanes.d,v 1.3 88/08/18 07:38:01 mento Exp $
- .EQ
- delim %%
- .EN
- The specified ncolors must be positive;
- and nreds, ngreens, and nblues must be nonnegative,
- or a
- .PN BadValue
- error results.
- If ncolors colors, nreds reds, ngreens greens, and nblues blues are requested,
- ncolors pixels are returned; and the masks have nreds, ngreens, and
- nblues bits set to 1, respectively.
- If contig is
- .PN True ,
- each mask will have
- a contiguous set of bits set to 1.
- No mask will have any bits set to 1 in common with
- any other mask or with any of the pixels.
- For
- .PN DirectColor ,
- each mask
- will lie within the corresponding pixel subfield.
- By ORing together
- subsets of masks with each pixel value,
- ncolors * %2 sup (nreds+ngreens+nblues)% distinct pixel values can be produced.
- All of these are allocated by the request.
- However, in the
- colormap, there are only ncolors * %2 sup nreds% independent red entries,
- ncolors * %2 sup ngreens% independent green entries,
- and ncolors * %2 sup nblues% independent blue entries.
- This is true even for
- .PN PseudoColor .
- When the colormap entry of a pixel
- value is changed (using
- .PN XStoreColors ,
- .PN XStoreColor ,
- or
- .PN XStoreNamedColor ),
- the pixel is decomposed according to the masks,
- and the corresponding independent entries are updated.
- .PN XAllocColorPlanes
- returns nonzero if it succeeded or zero if it failed.
- .LP
- .PN XAllocColorPlanes
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .LP
- .sp
- .IN "Freeing" "colors"
- To free colormap cells, use
- .PN XFreeColors .
- .IN "XFreeColors" "" "@DEF@"
- .IN "color" "deallocation"
- .\" Start marker code here
- .FD 0
- .\" $Header: XFreeColors.f,v 1.3 88/05/09 09:12:36 mento Exp $
- XFreeColors\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIpixels\fP\^, \fInpixels\fP\^, \fIplanes\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- unsigned long \fIpixels\fP\^[\^];
- .br
- int \fInpixels\fP\^;
- .br
- unsigned long \fIplanes\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .ds Pi that map to the cells in the specified colormap
- .\" $Header: pixels_gen.a,v 1.2 88/08/04 11:18:34 mento Exp $
- .IP \fIpixels\fP 1i
- Specifies an array of pixel values \*(Pi.
- .\" $Header: npixels.a,v 1.1 88/02/26 10:29:44 mento Exp $
- .IP \fInpixels\fP 1i
- Specifies the number of pixels.
- .\" $Header: planes.a,v 1.1 88/02/26 10:30:29 mento Exp $
- .IP \fIplanes\fP 1i
- Specifies the planes you want to free.
- .\" End marker code here
- .LP
- .\" $Header: XFreeColors.d,v 1.2 88/06/11 07:50:45 mento Exp $
- The
- .PN XFreeColors
- function frees the cells represented by pixels whose values are in the
- pixels array.
- The planes argument should not have any bits set to 1 in common with any of the
- pixels.
- The set of all pixels is produced by ORing together subsets of
- the planes argument with the pixels.
- The request frees all of these pixels that
- were allocated by the client (using
- .IN XAllocColor
- .IN XAllocNamedColor
- .IN XAllocColorCells
- .IN XAllocColorPlanes
- .PN XAllocColor ,
- .PN XAllocNamedColor ,
- .PN XAllocColorCells ,
- and
- .PN XAllocColorPlanes ).
- Note that freeing an
- individual pixel obtained from
- .PN XAllocColorPlanes
- may not actually allow
- it to be reused until all of its related pixels are also freed.
- Similarly,
- a read-only entry is not actually freed until it has been freed by all clients,
- and if a client allocates the same read-only entry multiple times,
- it must free the entry that many times before the entry is actually freed.
- .LP
- All specified pixels that are allocated by the client in the colormap are
- freed, even if one or more pixels produce an error.
- If a specified pixel is not a valid index into the colormap, a
- .PN BadValue
- error results.
- If a specified pixel is not allocated by the
- client (that is, is unallocated or is only allocated by another client),
- or if the colormap was created with all entries writable (by passing
- .PN AllocAll
- to
- .PN XCreateColormap ),
- a
- .PN BadAccess
- error results.
- If more than one pixel is in error,
- the one that gets reported is arbitrary.
- .LP
- .PN XFreeColors
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- and
- .PN BadValue
- errors.
- .NH 2
- Modifying and Querying Colormap Cells
- .XS
- \*(SN Modifying and Querying Colormap Cells
- .XE
- .LP
- .sp
- To store an RGB value in a single colormap cell, use
- .PN XStoreColor .
- .IN "color" "storing"
- .IN "XStoreColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XStoreColor.f,v 1.2 88/05/09 07:46:50 mento Exp $
- XStoreColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XColor *\fIcolor\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIcolor\fP 1i
- Specifies the pixel and RGB values.
- .\" End marker code here
- .LP
- .\" $Header: XStoreColor.d,v 1.3 88/08/18 07:39:08 mento Exp $
- The
- .PN XStoreColor
- function changes the colormap entry of the pixel value specified in the
- pixel member of the
- .PN XColor
- structure.
- You specified this value in the
- pixel member of the
- .PN XColor
- structure.
- This pixel value must be a read/write cell and a valid index into the colormap.
- If a specified pixel is not a valid index into the colormap,
- a
- .PN BadValue
- error results.
- .PN XStoreColor
- also changes the red, green, and/or blue color components.
- You specify which color components are to be changed by setting
- .PN DoRed ,
- .PN DoGreen ,
- and/or
- .PN DoBlue
- in the flags member of the
- .PN XColor
- structure.
- If the colormap is an installed map for its screen,
- the changes are visible immediately.
- .LP
- .PN XStoreColor
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To store multiple RGB values into multiple colormap cells, use
- .PN XStoreColors .
- .IN "color" "storing"
- .IN "XStoreColors" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XStoreColors.f,v 1.2 88/05/09 07:41:37 mento Exp $
- XStoreColors\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor\fP\^, \fIncolors\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XColor \fIcolor\fP\^[\^]\^;
- .br
- int \fIncolors\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: defs.a,v 1.1 88/02/26 10:06:27 mento Exp $
- .IP \fIcolor\fP 1i
- Specifies an array of color definition structures to be stored.
- .\" $Header: ncolors.a,v 1.1 88/02/26 10:29:17 mento Exp $
- .IP \fIncolors\fP 1i
- .\"Specifies the number of color definition structures.
- Specifies the number of
- .PN XColor
- structures in the color definition array.
- .\" End marker code here
- .LP
- .\" $Header: XStoreColors.d,v 1.3 88/06/11 07:53:50 mento Exp $
- The
- .PN XStoreColors
- function changes the colormap entries of the pixel values
- specified in the pixel members of the
- .PN XColor
- structures.
- You specify which color components are to be changed by setting
- .PN DoRed ,
- .PN DoGreen ,
- and/or
- .PN DoBlue
- in the flags member of the
- .PN XColor
- structures.
- If the colormap is an installed map for its screen, the
- changes are visible immediately.
- .PN XStoreColors
- changes the specified pixels if they are allocated writable in the colormap
- by any client, even if one or more pixels generates an error.
- If a specified pixel is not a valid index into the colormap, a
- .PN BadValue
- error results.
- If a specified pixel either is unallocated or is allocated read-only, a
- .PN BadAccess
- error results.
- If more than one pixel is in error,
- the one that gets reported is arbitrary.
- .LP
- .PN XStoreColors
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To store a color of arbitrary format in a single colormap cell, use
- .PN XcmsStoreColor .
- .IN "color" "storing"
- .IN "XcmsStoreColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsStoreColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsColor *\fIcolor\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIcolor\fP 1i
- Specifies the color cell and the color to store.
- Values specified in this
- .PN XcmsColor
- structure remain unchanged upon return.
- .\" End marker code here
- .LP
- The
- .PN XcmsStoreColor
- function converts the color specified in the
- .PN XcmsColor
- structure into RGB values and then uses this RGB specification in an
- .PN XColor
- structure, whose three flags
- .Pn ( DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue )
- are set, in a call to
- .PN XStoreColor
- to change the color cell specified by the pixel member of the
- .PN XcmsColor
- structure.
- This pixel value must be a valid index for the specified colormap,
- and the color cell specified by the pixel value must be a read/write cell.
- If the pixel value is not a valid index, a
- .PN BadValue
- error results.
- If the color cell is unallocated or is allocated read-only, a
- .PN BadAccess
- error results.
- If the colormap is an installed map for its screen,
- the changes are visible immediately.
- .LP
- Note that
- .PN XStoreColor
- has no return value; therefore, a
- .PN XcmsSuccess
- return value from this function indicates that the conversion
- to RGB succeeded and the call to
- .PN XStoreColor
- was made.
- To obtain the actual color stored, use
- .PN XcmsQueryColor .
- Due to the screen's hardware limitations or gamut compression,
- the color stored in the colormap may not be identical
- to the color specified.
- .LP
- .PN XcmsStoreColor
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To store multiple colors of arbitrary format into multiple colormap cells, use
- .PN XcmsStoreColors .
- .IN "color" "storing"
- .IN "XcmsStoreColors" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsStoreColors\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolors\fP\^, \fIncolors\fP\^, \fIcompression_flags_return\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsColor \fIcolors\fP\^[\^]\^;
- .br
- int \fIncolors\fP\^;
- .br
- Bool \fIcompression_flags_return\fP\^[\^]\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIcolors\fP 1i
- Specifies the color specification array of
- .PN XcmsColor
- structures, each specifying a color cell and the color to store in that
- cell.
- Values specified in the array remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .IP \fIcompression_flags_return\fP 1i
- Specifies an array of Boolean values for returning compression status.
- If a non-NULL pointer is supplied,
- each element of the array is set to
- .PN True
- if the corresponding color was compressed, and
- .PN False
- otherwise.
- Pass NULL if the compression status is not useful.
- .\" End marker code here
- .LP
- The
- .PN XcmsStoreColors
- function converts the colors specified in the array of
- .PN XcmsColor
- structures into RGB values and then uses these RGB specifications in an
- .PN XColor
- structures, whose three flags
- .Pn ( DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue )
- are set, in a call to
- .PN XStoreColors
- to change the color cells specified by the pixel member of the corresponding
- .PN XcmsColor
- structure.
- Each pixel value must be a valid index for the specified colormap,
- and the color cell specified by each pixel value must be a read/write cell.
- If a pixel value is not a valid index, a
- .PN BadValue
- error results.
- If a color cell is unallocated or is allocated read-only, a
- .PN BadAccess
- error results.
- If more than one pixel is in error,
- the one that gets reported is arbitrary.
- If the colormap is an installed map for its screen,
- the changes are visible immediately.
- .LP
- Note that
- .PN XStoreColors
- has no return value; therefore, a
- .PN XcmsSuccess
- return value from this function indicates that conversions
- to RGB succeeded and the call to
- .PN XStoreColors
- was made.
- To obtain the actual colors stored, use
- .PN XcmsQueryColors .
- Due to the screen's hardware limitations or gamut compression,
- the colors stored in the colormap may not be identical
- to the colors specified.
- .LP
- .PN XcmsStoreColors
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To store a color specified by name in a single colormap cell, use
- .PN XStoreNamedColor .
- .IN "color" "storing"
- .IN "color" "naming"
- .IN "XStoreNamedColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XStoreNColor.f,v 1.2 88/05/09 08:40:00 mento Exp $
- XStoreNamedColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor\fP\^, \fIpixel\fP\^, \fIflags\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- char *\^\fIcolor\fP\^;
- .br
- unsigned long \fIpixel\fP\^;
- .br
- int \fIflags\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: color.a,v 1.3 88/05/09 13:49:43 mento Exp $
- .IP \fIcolor\fP 1i
- Specifies the color name string (for example, red).
- .\" $Header: pixel.a,v 1.2 88/05/09 08:44:04 mento Exp $
- .IP \fIpixel\fP 1i
- Specifies the entry in the colormap.
- .\" $Header: flags.a,v 1.2 88/04/05 17:24:55 mento Exp $
- .IP \fIflags\fP 1i
- Specifies which red, green, and blue components are set.
- .\" End marker code here
- .LP
- .\" $Header: XStoreNColor.d,v 1.3 88/06/11 07:53:51 mento Exp $
- The
- .PN XStoreNamedColor
- function looks up the named color with respect to the screen associated with
- the colormap and stores the result in the specified colormap.
- The pixel argument determines the entry in the colormap.
- The flags argument determines which of the red, green, and blue components
- are set.
- You can set this member to the
- bitwise inclusive OR of the bits
- .PN DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue .
- If the color name is not in the Host Portable Character Encoding
- the result is implementation dependent.
- Use of uppercase or lowercase does not matter.
- If the specified pixel is not a valid index into the colormap, a
- .PN BadValue
- error results.
- If the specified pixel either is unallocated or is allocated read-only, a
- .PN BadAccess
- error results.
- .LP
- .PN XStoreNamedColor
- can generate
- .PN BadAccess ,
- .PN BadColor ,
- .PN BadName ,
- and
- .PN BadValue
- errors.
- .LP
- .\" $Header: XQueryCol.d,v 1.1 88/06/10 06:04:55 mento Exp $
- The
- .PN XQueryColor
- and
- .PN XQueryColors
- functions take pixel values in the pixel member of
- .PN XColor
- structures, and store in the structures the RGB values for those
- pixels from the specified colormap.
- The values returned for an unallocated entry are undefined.
- These functions also set the flags member in the
- .PN XColor
- structure to all three colors.
- If a pixel is not a valid index into the specified colormap, a
- .PN BadValue
- error results.
- If more than one pixel is in error,
- the one that gets reported is arbitrary.
- .LP
- .sp
- To query the RGB value of a single colormap cell, use
- .PN XQueryColor .
- .IN "color" "querying"
- .IN "XQueryColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XQueryColor.f,v 1.3 88/05/09 09:40:30 mento Exp $
- XQueryColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIdef_in_out\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XColor *\fIdef_in_out\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIdef_in_out\fP 1i
- Specifies and returns the RGB values for the pixel specified in the structure.
- .\" End marker code here
- .LP
- .\" $Header: XQueryColor.d,v 1.4 88/06/11 07:52:34 mento Exp $
- The
- .PN XQueryColor
- function returns the current RGB value for the pixel in the
- .PN XColor
- structure and sets the
- .PN DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue
- flags.
- .LP
- .PN XQueryColor
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .LP
- .sp
- To query the RGB values of multiple colormap cells, use
- .PN XQueryColors .
- .IN "color" "querying"
- .IN "XQueryColors" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- .\" $Header: XQueryColors.f,v 1.3 88/05/09 09:42:25 mento Exp $
- XQueryColors\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIdefs_in_out\fP\^, \fIncolors\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XColor \fIdefs_in_out\fP[\^]\^;
- .br
- int \fIncolors\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" $Header: defs_ret.a,v 1.4 88/05/09 09:43:05 mento Exp $
- .IP \fIdefs_in_out\fP 1i
- Specifies and returns an array of color definition structures for the pixel
- specified in the structure.
- .\" $Header: ncolors.a,v 1.1 88/02/26 10:29:17 mento Exp $
- .IP \fIncolors\fP 1i
- .\"Specifies the number of color definition structures.
- Specifies the number of
- .PN XColor
- structures in the color definition array.
- .\" End marker code here
- .LP
- The
- .PN XQueryColors
- function returns the RGB value for each pixel in each
- .PN XColor
- structure, and sets the
- .PN DoRed ,
- .PN DoGreen ,
- and
- .PN DoBlue
- flags in each structure.
-
- .LP
- .PN XQueryColors
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .sp
- .LP
- To query the color of a single colormap cell in an arbitrary format, use
- .PN XcmsQueryColor .
- .IN "color" "querying"
- .IN "XcmsQueryColor" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryColor\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolor_in_out\fP\^, \fIresult_format\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsColor *\fIcolor_in_out\fP\^;
- .br
- XcmsColorFormat \fIresult_format\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIcolor_in_out\fP 1i
- Specifies the pixel member that indicates the color cell to query,
- and the color specification stored for the color cell is returned in this
- .PN XcmsColor
- structure.
- .\" $Header$
- .IP \fIresult_format\fP 1i
- Specifies the color format for the returned color specification.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryColor
- function obtains the RGB value
- for the pixel value in the pixel member of the specified
- .PN XcmsColor
- structure, and then
- converts the value to the target format as
- specified by the result_format argument.
- If the pixel is not a valid index into the specified colormap, a
- .PN BadValue
- error results.
- .LP
- .PN XcmsQueryColor
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .sp
- .LP
- To query the color of multiple colormap cells in an arbitrary format, use
- .PN XcmsQueryColors .
- .IN "color" "querying"
- .IN "XcmsQueryColors" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryColors\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIcolors_in_out\fP\^, \fIncolors\fP\^, \fIresult_format\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsColor \fIcolors_in_out\fP\^[\^]\^;
- .br
- unsigned int \fIncolors\fP\^;
- .br
- XcmsColorFormat \fIresult_format\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of
- .PN XcmsColor
- structures, each pixel member indicating the color cell to query.
- The color specifications for the color cells are returned in these structures.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .\" $Header$
- .IP \fIresult_format\fP 1i
- Specifies the color format for the returned color specification.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryColors
- function obtains the RGB values
- for pixel values in the pixel members of
- .PN XcmsColor
- structures, and then
- converts the values to the target format as
- specified by the result_format argument.
- If a pixel is not a valid index into the specified colormap, a
- .PN BadValue
- error results.
- If more than one pixel is in error,
- the one that gets reported is arbitrary.
- .LP
- .PN XcmsQueryColors
- can generate
- .PN BadColor
- and
- .PN BadValue
- errors.
- .NH 2
- Color Conversion Context Functions
- .XS
- \*(SN Color Conversion Context Functions
- .XE
- .LP
- This section describes functions to create, modify,
- and query Color Conversion Contexts.
- .LP
- Associated with each colormap is an initial CCC transparently generated by
- Xlib.
- .IN "Color Conversion Context" "creation"
- Therefore, when you specify a colormap as an argument to a function,
- you are indirectly specifying a CCC.
- .IN "CCC" "of colormap"
- .IN "Color Conversion Context" "of colormap"
- The CCC attributes that can be modified by the X client are:
- .IP \(bu 5
- Client White Point
- .IP \(bu 5
- Gamut compression procedure and client data
- .IP \(bu 5
- White point adjustment procedure and client data
- .LP
- The initial values for these attributes are implementation specific.
- The CCC attributes for subsequently created CCCs can be defined
- by changing the CCC attributes of the default CCC.
- .IN "CCC" "default"
- .IN "Color Conversion Context" "default"
- There is a default CCC associated with each screen.
- .NH 3
- Getting and Setting the Color Conversion Context of a Colormap
- .XS
- \*(SN Getting and Setting the Color Conversion Context of a Colormap
- .XE
- .LP
- .sp
- To obtain the CCC associated with a colormap, use
- .PN XcmsCCCOfColormap .
- .IN "XcmsCCCOfColormap" "" "@DEF@"
- .IN "colormap" "CCC of"
- .IN "CCC" "of colormap"
- .IN "Color Conversion Context" "of colormap"
- .\" Start marker code here
- .FD 0
- XcmsCCC XcmsCCCofColormap\^(\^\fIdisplay\fP, \fIcolormap\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .\" End marker code here
- .LP
- The
- .PN XcmsCCCofColormap
- function returns the CCC associated with the specified colormap.
- Once obtained,
- the CCC attributes can be queried or modified.
- Unless the CCC associated with the specified colormap is changed with
- .PN XcmsSetCCCOfColormap ,
- this CCC is used when the specified colormap is used as an argument
- to color functions.
- .sp
- .LP
- To change the CCC associated with a colormap, use
- .PN XcmsSetCCCOfColormap .
- .IN "XcmsSetCCCOfColormap" "" "@DEF@"
- .IN "colormap" "CCC of"
- .IN "CCC" "of colormap"
- .IN "Color Conversion Context" "of colormap"
- .\" Start marker code here
- .FD 0
- XcmsCCC XcmsSetCCCOfColormap\^(\^\fIdisplay\fP, \fIcolormap\fP\^, \fIccc\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- Colormap \fIcolormap\fP\^;
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .\" $Header: cmap.a,v 1.2 88/05/09 06:39:13 mento Exp $
- .IP \fIcolormap\fP 1i
- Specifies the colormap.
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- The
- .PN XcmsSetCCCOfColormap
- function changes the CCC associated with the specified colormap.
- It returns the CCC previously associated to the colormap.
- If they are not used again in the application,
- CCCs should be freed by calling
- .PN XcmsFreeCCC .
- .NH 3
- Obtaining the Default Color Conversion Context
- .XS
- \*(SN Obtaining the Default Color Conversion Context
- .XE
- .LP
- The default CCC attributes for subsequently created CCCs can be changed
- by changing the CCC attributes of the default CCC.
- .IN "CCC" "default"
- .IN "Color Conversion Context" "default"
- A default CCC is associated with each screen.
- .sp
- .LP
- To obtain the default CCC for a screen, use
- .PN XcmsDefaultCCC .
- .IN "XcmsDefaultCCC" "" "@DEF@"
- .IN "Color Conversion Context" "default"
- .IN "CCC" "default"
- .\" Start marker code here
- .FD 0
- XcmsCCC XcmsDefaultCCC\^(\^\fIdisplay\fP, \fIscreen_number\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- int \fIscreen_number\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .IP \fIscreen_number\fP 1i
- Specifies the appropriate screen number on the host server.
- .\" End marker code here
- .LP
- The
- .PN XcmsDefaultCCC
- function returns the default CCC for the specified screen.
- Its visual is the default visual of the screen.
- Its initial gamut compression and white point
- adjustment procedures as well as the associated client data are implementation
- specific.
- .NH 3
- Color Conversion Context Macros
- .XS
- \*(SN Color Conversion Context Macros
- .XE
- .LP
- Applications should not directly modify any part of the
- .PN XcmsCCC .
- The following lists the C language macros, their corresponding function
- equivalents that are for other language bindings, and what data they both
- can return.
- .sp
- .LP
- .IN "DisplayOfCCC" "" "@DEF@"
- .IN "XcmsDisplayOfCCC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- DisplayOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .sp
- Display *XcmsDisplayOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- Both return the display associated with the specified CCC.
- .LP
- .sp
- .IN "VisualOfCCC" "" "@DEF@"
- .IN "XcmsVisualOfCCC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- VisualOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .sp
- Visual *XcmsVisualOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- Both return the visual associated with the specified CCC.
- .sp
- .LP
- .IN "ScreenNumberOfCCC" "" "@DEF@"
- .IN "XcmsScreenNumberOfCCC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- ScreenNumberOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .sp
- int XcmsScreenNumberOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- Both return the number of the screen associated with the specified CCC.
- .sp
- .LP
- .IN "ScreenWhitePointOfCCC" "" "@DEF@"
- .IN "XcmsScreenWhitePointOfCCC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- ScreenWhitePointOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .sp
- XcmsColor *XcmsScreenWhitePointOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- Both return the white point of the screen associated with the specified CCC.
- .sp
- .LP
- .IN "ClientWhitePointOfCCC" "" "@DEF@"
- .IN "XcmsClientWhitePointOfCCC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- ClientWhitePointOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .sp
- XcmsColor *XcmsClientWhitePointOfCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- Both return the Client White Point of the specified CCC.
- .NH 3
- Modifying Attributes of a Color Conversion Context
- .XS
- \*(SN Modifying Attributes of a Color Conversion Context
- .XE
- .LP
- To set the Client White Point in the CCC, use
- .PN XcmsSetWhitePoint .
- .IN "XcmsSetWhitePoint" "" "@DEF@"
- .IN "Client White Point" "of Color Conversion Context"
- .\" Start marker code here
- .FD 0
- Status XcmsSetWhitePoint\^(\^\fIccc\fP\^, \fIcolor\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor *\fIcolor\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .ds Co new Client White Point
- .\" $Header: color_gen.a,v 1.2 88/08/04 11:07:59 mento Exp $
- .IP \fIcolor\fP 1i
- Specifies the \*(Co.
- .\" End marker code here
- .LP
- The
- .PN XcmsSetWhitePoint
- function changes the Client White Point in the specified CCC.
- Note that the pixel member is ignored
- and that the color specification is left unchanged upon return.
- The format for the new white point must be
- .PN XcmsCIEXYZFormat ,
- .PN XcmsCIEuvYFormat ,
- .PN XcmsCIExyYFormat ,
- or
- .PN XcmsUndefinedFormat .
- If \fIcolor\fP is NULL, this function sets the format component of the
- Client White Point specification to
- .PN XcmsUndefinedFormat ,
- indicating that the Client White Point is assumed to be the same as the
- Screen White Point.
- .sp
- .LP
- To set the gamut compression procedure and corresponding client data
- in a specified CCC, use
- .PN XcmsSetCompressionProc .
- .IN "XcmsSetCompressionProc" "" "@DEF@"
- .IN "gamut compression" "setting in Color Conversion Context"
- .IN "gamut compression" "procedure"
- .IN "gamut compression" "client data"
- .\" Start marker code here
- .FD 0
- XcmsCompressionProc XcmsSetCompressionProc\^(\^\fIccc\fP\^, \fIcompression_proc\fP\^, \fIclient_data\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsCompressionProc \fIcompression_proc\fP\^;
- .br
- XPointer \fIclient_data\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIcompression_proc\fP 1i
- Specifies the gamut compression procedure that is to be applied
- when a color lies outside the screen's color gamut.
- If NULL and when functions using this CCC must convert
- a color specification to a device-dependent format and encounters a color
- that lies outside the screen's color gamut,
- that function will return
- .PN XcmsFailure .
- .ds Cd the gamut compression procedure
- .IP \fIclient_data\fP 1i
- Specifies client data for \*(Cd or NULL.
- .\" End marker code here
- .LP
- The
- .PN XcmsSetCompressionProc
- function first sets the gamut compression procedure and client data
- in the specified CCC with the newly specified procedure and client data
- and then returns the old procedure.
- .sp
- .LP
- To set the white point adjustment procedure and corresponding client data
- in a specified CCC, use
- .PN XcmsSetWhiteAdjustProc .
- .IN "XcmsSetWhiteAdjustProc" "" "@DEF@"
- .IN "white point adjustment" "setting in Color Conversion Context"
- .IN "white point adjustment" "procedure"
- .IN "white point adjustment" "client data"
- .FD 0
- .\" Start marker code here
- XcmsWhiteAdjustProc XcmsSetWhiteAdjustProc\^(\^\fIccc\fP\^, \fIwhite_adjust_proc\fP\^, \fIclient_data\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsWhiteAdjustProc \fIwhite_adjust_proc\fP\^;
- .br
- XPointer \fIclient_data\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIwhite_adjust_proc\fP 1i
- Specifies the white point adjustment procedure.
- .ds Cd the white point adjustment procedure
- .IP \fIclient_data\fP 1i
- Specifies client data for \*(Cd or NULL.
- .\" End marker code here
- .LP
- The
- .PN XcmsSetWhiteAdjustProc
- function first sets the white point adjustment procedure and client data
- in the specified CCC with the newly specified procedure and client data
- and then returns the old procedure.
- .NH 3
- Creating and Freeing a Color Conversion Context
- .XS
- \*(SN Creating and Freeing a Color Conversion Context
- .XE
- .LP
- You can explicitly create a CCC within your application by calling
- .PN XcmsCreateCCC .
- These created CCCs can then be used by those functions that explicitly
- call for a CCC argument.
- Old CCCs that will not be used by the application should be freed using
- .PN XcmsFreeCCC .
- .sp
- .LP
- To create a CCC, use
- .PN XcmsCreateCCC .
- .IN "XcmsCreateCCC" "" "@DEF@"
- .IN "Color Conversion Context" "creation"
- .IN "CCC" "creation"
- .\" Start marker code here
- .FD 0
- XcmsCCC XcmsCreateCCC\^(\^\fIdisplay\fP, \fIscreen_number\fP\^, \fIvisual\fP\^, \fIclient_white_point\fP\^, \fIcompression_proc\fP\^,
- .br
- \fIcompression_client_data\fP\^, \fIwhite_adjust_proc\fP\^, \fIwhite_adjust_client_data\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- int \fIscreen_number\fP\^;
- .br
- Visual *\fIvisual\fP\^;
- .br
- XcmsColor *\fIclient_white_point\fP\^;
- .br
- XcmsCompressionProc \fIcompression_proc\fP\^;
- .br
- XPointer \fIcompression_client_data\fP\^;
- .br
- XcmsWhiteAdjustProc \fIwhite_adjust_proc\fP\^;
- .br
- XPointer \fIwhite_adjust_client_data\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .IP \fIscreen_number\fP 1i
- Specifies the appropriate screen number on the host server.
- .\" $Header: visual_gen.a,v 1.1 88/07/10 10:05:08 mento Exp $
- .IP \fIvisual\fP 1i
- Specifies the visual type.
- .IP \fIclient_white_point\fP 1i
- Specifies the Client White Point.
- If NULL, the Client White Point is to be assumed to be the same as the
- Screen White Point.
- Note that the pixel member is ignored.
- .IP \fIcompression_proc\fP 1i
- Specifies the gamut compression procedure that is to be applied
- when a color lies outside the screen's color gamut.
- If NULL and when functions using this CCC must convert
- a color specification to a device-dependent format and encounters a color
- that lies outside the screen's color gamut,
- that function will return
- .PN XcmsFailure .
- .IP \fIcompression_client_data\fP 1i
- Specifies client data for use by the gamut compression procedure or NULL.
- .IP \fIwhite_adjust_proc\fP 1i
- Specifies the white adjustment procedure that is to be applied
- when the Client White Point differs from the Screen White Point.
- NULL indicates that no white point adjustment is desired.
- .IP \fIwhite_adjust_client_data\fP 1i
- Specifies client data for use with the white point adjustment procedure or NULL.
- .\" End marker code here
- .LP
- The
- .PN XcmsCreateCCC
- function creates a CCC for the specified display, screen, and visual.
- .LP
- .sp
- To free a CCC, use
- .PN XcmsFreeCCC .
- .IN "XcmsFreeCCC" "" "@DEF@"
- .IN "Color Conversion Context" "freeing"
- .IN "CCC" "freeing"
- .\" Start marker code here
- .FD 0
- void XcmsFreeCCC\^(\^\fIccc\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .\" End marker code here
- .LP
- The
- .PN XcmsFreeCCC
- function frees the memory used for the specified CCC.
- Note that default CCCs and those currently associated with colormaps
- are ignored.
- .NH 2
- Converting Between Color Spaces
- .XS
- \*(SN Converting Between Color Spaces
- .XE
- .LP
- .sp
- To convert an array of color specifications in arbitrary color formats
- to a single destination format, use
- .PN XcmsConvertColors .
- .IN "color conversion"
- .IN "color" "conversion"
- .IN "XcmsConvertColors" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsConvertColors\^(\^\fIccc\fP\^, \fIcolors_in_out\fP\^, \fIncolors\fP\^, \fItarget_format\fP\^, \fIcompression_flags_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor \fIcolors_in_out\fP\^[\^]\^;
- .br
- unsigned int \fIncolors\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- Bool \fIcompression_flags_return\fP\^[\^]\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- If conversion is between device-independent color spaces only
- (for example, TekHVC to CIELuv),
- the CCC is necessary only to specify the Client White Point.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of color specifications.
- Pixel members are ignored and remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .IP \fIcompression_flags_return\fP 1i
- Specifies an array of Boolean values for returning compression status.
- If a non-NULL pointer is supplied,
- each element of the array is set to
- .PN True
- if the corresponding color was compressed, and
- .PN False
- otherwise.
- Pass NULL if the compression status is not useful.
- .\" End marker code here
- .LP
- The
- .PN XcmsConvertColors
- function converts the color specifications in the specified array of
- .PN XcmsColor
- structures from their current format to a single target format,
- using the specified CCC.
- When the return value is
- .PN XcmsFailure ,
- the contents of the color specification array are left unchanged.
- .LP
- The array may contain a mixture of color specification formats
- (for example, 3 CIE XYZ, 2 CIE Luv, ...).
- Note that when the array contains both device-independent and
- device-dependent color specifications, and the target_format argument specifies
- a device-dependent format (for example,
- .PN XcmsRGBiFormat ,
- .PN XcmsRGBFormat )
- all specifications are converted to CIE XYZ format then to the target
- device-dependent format.
- .NH 2
- Callback Functions
- .XS
- \*(SN Callback Functions
- .XE
- .LP
- This section describes the gamut compression and white point
- adjustment callbacks.
- .LP
- The gamut compression procedure specified in the Color Conversion Context
- is called when an attempt to convert a color specification from
- .PN XcmsCIEXYZ
- to a device-dependent format (typically
- .PN XcmsRGBi )
- results in a color that lies outside the screen's color gamut.
- If the gamut compression procedure requires client data, this data is passed
- via the gamut compression client data in the CCC.
- .LP
- During color specification conversion between device-independent
- and device-dependent color spaces,
- if a white point adjustment procedure is specified in the CCC,
- it is triggered when the Client White Point and Screen White Point differ.
- If required, the client data is obtained from the CCC.
- .NH 3
- Prototype Gamut Compression Procedure
- .XS
- \*(SN Prototype Gamut Compression Procedure
- .XE
- .LP
- The gamut compression callback interface must adhere to the
- following:
- .IN "XcmsCompressionProc" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- typedef Status (*\^XcmsCompressionProc\^)\^(\^\fIccc\fP\^, \fIcolors_in_out\fP\^, \fIncolors\fP\^, \fIindex\fP\^, \fIcompression_flags_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor \fIcolors_in_out[]\fP\^;
- .br
- unsigned int \fIncolors\fP\^;
- .br
- unsigned int \fIindex\fP\^;
- .br
- Bool \fIcompression_flags_return[]\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of color specifications.
- Pixel members are ignored and remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .IP \fIindex\fP 1i
- Specifies the index into the array of
- .PN XcmsColor
- structures for the encountered color specification that lies outside the
- .PN Screen 's
- color gamut.
- Valid values are 0 (for the first element) to ncolors \- 1.
- .IP \fIcompression_flags_return\fP 1i
- Specifies an array of Boolean values for returning compression status.
- If a non-NULL pointer is supplied,
- and a color at a given index is compressed, then
- .PN True
- should be stored at the corresponding index in this array.
- .\" End marker code here
- .LP
- When implementing a gamut compression procedure, consider the following
- rules and assumptions:
- .IP \(bu 5
- The gamut compression procedure can attempt to compress one or multiple
- specifications at a time.
- .IP \(bu 5
- When called, elements 0 to index \- 1 in the array of color specification
- array can be assumed to fall within the screen's color gamut.
- In addition these color specifications are already in some device-dependent
- format (typically
- .PN XcmsRGBi ).
- If any modifications are made to these color specifications,
- they must upon return be in their initial device-dependent format.
- .IP \(bu 5
- When called, the element in the color specification array specified
- by the index argument contains the color specification outside the
- screen's color gamut encountered by the calling routine.
- In addition this color specification can be assumed to be in
- .PN XcmsCIEXYZ .
- Upon return, this color specification must be in
- .PN XcmsCIEXYZ .
- .IP \(bu 5
- When called, elements from index to ncolors \- 1
- in the color specification array may or may not fall within the
- screen's color gamut.
- In addition these color specifications can be assumed to be in
- .PN XcmsCIEXYZ .
- If any modifications are made to these color specifications,
- they must upon return be in
- .PN XcmsCIEXYZ .
- .IP \(bu 5
- The color specifications passed to the gamut compression procedure
- have already been adjusted to the Screen White Point.
- This means that at this point the color specification's white point
- is the Screen White Point.
- .IP \(bu 5
- If the gamut compression procedure uses a device-independent color space not
- initially accessible for use in the color management system, use
- .PN XcmsAddColorSpace
- to insure that it is added.
- .NH 3
- Supplied Gamut Compression Procedures
- .XS
- \*(SN Supplied Gamut Compression Procedures
- .XE
- .LP
- The following equations are useful in describing gamut compression
- procedures.
- .EQ
- delim %%
- .EN
- .LP
- .Ds 0
- %CIELab~Psychometric~Chroma ~=~ sqrt(a_star sup 2 ~+~ b_star sup 2 )%
-
- %CIELab~Psychometric~Hue ~=~ tan sup -1 left [ b_star over a_star right ]%
-
- %CIELuv~Psychometric~Chroma ~=~ sqrt(u_star sup 2 ~+~ v_star sup 2 )%
-
- %CIELuv~Psychometric~Hue ~=~ tan sup -1 left [ v_star over u_star right ]%
- .De
- .LP
- The gamut compression callback procedures provided by Xlib are as follows.
- .LP
- .PN XcmsCIELabClipL
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing or increasing CIE metric lightness (L*)
- in the CIE L*a*b* color space until the color is within the gamut.
- If the Psychometric Chroma of the color specification
- is beyond maximum for the Psychometric Hue Angle,
- then, while maintaining the same Psychometric Hue Angle,
- the color will be clipped to the CIE L*a*b* coordinates of maximum
- Psychometric Chroma.
- See
- .PN XcmsCIELabQueryMaxC .
- No client data is necessary.
- .LP
- .PN XcmsCIELabClipab
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing Psychometric Chroma,
- while maintaining Psychometric Hue Angle,
- until the color is within the gamut.
- No client data is necessary.
- .LP
- .PN XcmsCIELabClipLab
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by replacing it with CIE L*a*b* coordinates
- that fall within the color gamut while maintaining the original
- Psychometric Hue
- Angle and whose vector to the original coordinates is the shortest attainable.
- No client data is necessary.
- .LP
- .PN XcmsCIELuvClipL
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing or increasing CIE metric lightness (L*)
- in the CIE L*u*v* color space until the color is within the gamut.
- If the Psychometric Chroma of the color specification
- is beyond maximum for the Psychometric Hue Angle,
- then, while maintaining the same Psychometric Hue Angle,
- the color will be clipped to the CIE L*u*v* coordinates of maximum
- Psychometric Chroma.
- See
- .PN XcmsCIELuvQueryMaxC .
- No client data is necessary.
- .LP
- .PN XcmsCIELuvClipuv
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing
- Psychometric Chroma while maintaining Psychometric Hue Angle,
- until the color is within the gamut.
- No client data is necessary.
- .LP
- .PN XcmsCIELuvClipLuv
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by replacing it with CIE L*u*v* coordinates
- that fall within the color gamut while maintaining the original
- Psychometric Hue
- Angle and whose vector to the original coordinates is the shortest attainable.
- No client data is necessary.
- .LP
- .PN XcmsTekHVCClipV
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing or increasing the Value dimension
- in the TekHVC color space until the color is within the gamut.
- If Chroma of the color specification is beyond maximum for the particular Hue,
- then, while maintaining the same Hue,
- the color will be clipped to the Value and Chroma coordinates
- that represent maximum Chroma for that particular Hue.
- No client data is necessary.
- .LP
- .PN XcmsTekHVCClipC
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by reducing the Chroma dimension
- in the TekHVC color space until the color is within the gamut.
- No client data is necessary.
- .LP
- .PN XcmsTekHVCClipVC
- .IP
- Brings the encountered out of gamut color specification into the
- screen's color gamut by replacing it with TekHVC coordinates
- that fall within the color gamut while maintaining the original Hue
- and whose vector to the original coordinates is the shortest attainable.
- No client data is necessary.
- .NH 3
- Prototype White Point Adjustment Procedure
- .XS
- \*(SN Prototype White Point Adjustment Procedure
- .XE
- .LP
- The white point adjustment procedure interface must adhere to the following:
- .IN "XcmsWhiteAdjustProc" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- typedef Status (*\^XcmsWhiteAdjustProc\^)\^(\^\fIccc\fP\^, \fIinitial_white_point\fP\^, \fItarget_white_point\fP\^, \fItarget_format\fP\^,
- .br
- \fIcolors_in_out\fP\^, \fIncolors\fP\^, \fIcompression_flags_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor *\fIinitial_white_point\fP\^;
- .br
- XcmsColor *\fItarget_white_point\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor \fIcolors_in_out[]\fP\^;
- .br
- unsigned int \fIncolors\fP\^;
- .br
- Bool \fIcompression_flags_return[]\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIinitial_white_point\fP 1i
- Specifies the initial white point.
- .IP \fItarget_white_point\fP 1i
- Specifies the target white point.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of color specifications.
- Pixel members are ignored and remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .IP \fIcompression_flags_return\fP 1i
- Specifies an array of Boolean values for returning compression status.
- If a non-NULL pointer is supplied,
- and a color at a given index is compressed, then
- .PN True
- should be stored at the corresponding index in this array.
- .NH 3
- Supplied White Point Adjustment Procedures
- .XS
- \*(SN Supplied White Point Adjustment Procedures
- .XE
- .LP
- White point adjustment procedures provided by Xlib are as follows.
- .LP
- .PN XcmsCIELabWhiteShiftColors
- .IP
- Uses the CIE L*a*b* color space for adjusting the chromatic character
- of colors to compensate for the chromatic differences between the source
- and destination white points.
- This procedure simply converts the color specifications to
- .PN XcmsCIELab
- using the source white point and then converts to the target specification
- format using the destinations white point.
- No client data is necessary.
- .LP
- .PN XcmsCIELuvWhiteShiftColors
- .IP
- Uses the CIE L*u*v* color space for adjusting the chromatic character
- of colors to compensate for the chromatic differences between the source
- and destination white points.
- This procedure simply converts the color specifications to
- .PN XcmsCIELuv
- using the source white point and then converts to the target specification
- format using the destinations white point.
- No client data is necessary.
- .LP
- .PN XcmsTekHVCWhiteShiftColors
- .IP
- Uses the TekHVC color space for adjusting the chromatic character
- of colors to compensate for the chromatic differences between the source
- and destination white points.
- This procedure simply converts the color specifications to
- .PN XcmsTekHVC
- using the source white point and then converts to the target specification
- format using the destinations white point.
- An advantage of this procedure over those previously described
- is an attempt to minimize hue shift.
- No client data is necessary.
- .LP
- From an implementation point of view,
- these white point adjustment procedures convert the color specifications
- to a device-independent but white-point-dependent color space
- (for example., CIE L*u*v*, CIE L*a*b*, TekHVC) using one white point
- and then converting those specifications to the target color space
- using another white point.
- In other words,
- the specification goes in the color space with one white point
- but comes out with another white point,
- resulting in a chromatic shift based on the chromatic displacement
- between the initial white point and target white point.
- The CIE color spaces that are assumed to be white-point-independent
- are CIE u'v'Y, CIE XYZ, and CIE xyY.
- When developing a custom white point adjustment procedure that uses a
- device-independent color space not initially accessible for use in the
- color management system, use
- .PN XcmsAddColorSpace
- to insure that it is added.
- .LP
- As an example,
- if a white point adjustment procedure is specified by the
- Color Conversion Context
- and if the Client White Point and Screen White Point differ, the
- .PN XcmsAllocColor
- function will use the white point adjustment
- procedure twice:
- .IP \(bu 5
- Once to convert to
- .PN XcmsRGB
- .IP \(bu 5
- A second time to convert from
- .PN XcmsRGB
- .LP
- For example, assume the specification is in
- .PN XcmsCIEuvY
- and the adjustment procedure is
- .PN XcmsCIELuvWhiteShiftColors .
- During conversion to
- .PN XcmsRGB ,
- the call to
- .PN XcmsAllocColor
- results in the following series of color specification conversions:
- .\" Do these need to be font coded?
- .IP \(bu 5
- From
- .PN XcmsCIEuvY
- to
- .PN XcmsCIELuv
- using the Client White Point
- .IP \(bu 5
- From
- .PN XcmsCIELuv
- to
- .PN XcmsCIEuvY
- using the Screen White Point
- .IP \(bu 5
- From
- .PN XcmsCIEuvY
- to
- .PN XcmsCIEXYZ
- (CIE u'v'Y and XYZ are white-point-independent color spaces)
- .IP \(bu 5
- From
- .PN XcmsCIEXYZ
- to
- .PN XcmsRGBi
- .IP \(bu 5
- Finally from
- .PN XcmsRGBi
- to
- .PN XcmsRGB
- .LP
- The resulting RGB specification is passed to
- .PN XAllocColor
- and the RGB
- specification returned by
- .PN XAllocColor
- is converted back to
- .PN XcmsCIEuvY
- by reversing the color conversion sequence.
- .NH 2
- Gamut Querying Functions
- .XS
- \*(SN Gamut Querying Functions
- .XE
- .LP
- This section describes the gamut querying functions that are provided
- by Xlib.
- These functions allow the client to query the boundary
- of the screen's color gamut in terms of the CIE L*a*b*, CIE L*u*v*,
- and TekHVC color spaces.
- .IN "gamut querying"
- Functions are also provided that allow you to query
- the color specification of:
- .IP \(bu 5
- White (full intensity red, green, and blue)
- .IP \(bu 5
- Red (full intensity red while green and blue are zero)
- .IP \(bu 5
- Green (full intensity green while red and blue are zero)
- .IP \(bu 5
- Blue (full intensity blue while red and green are zero)
- .IP \(bu 5
- Black (zero intensity red, green, and blue)
- .LP
- The white point associated with color specifications passed to
- and returned from these gamut querying
- functions are assumed to be the Screen White Point.
- .IN "Screen White Point"
- This is a reasonable assumption,
- since the client is trying to query the screen's color gamut.
- .LP
- Note that the following naming convention is used
- for the "Max" and "Min" functions:
- .LP
- .Ds 0
- Xcms\fI<color_space>\fPQueryMax\fI<dimensions>\fP
-
- Xcms\fI<color_space>\fPQueryMin\fI<dimensions>\fP
- .De
- .LP
- Note that the \fI<dimensions>\fP consists of letter or letters
- that identify the dimension or dimensions of the color space
- that are not fixed.
- For example,
- .PN XcmsTekHVCQueryMaxC
- is given a fixed Hue and Value for which maximum Chroma is found.
- .NH 3
- Red, Green, and Blue Queries
- .XS
- \*(SN Red, Green, and Blue Queries
- .XE
- .LP
- To obtain the color specification for black
- (zero intensity red, green, and blue), use
- .PN XcmsQueryBlack .
- .IN "XcmsQueryBlack" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryBlack\^(\^\fIccc\fP\^, \fItarget_format\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .ds Cs zero intensity red, green, and blue
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the specified target format
- for \*(Cs.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryBlack
- function returns the color specification in the specified target format
- for zero intensity red, green, and blue.
- .sp
- .LP
- To obtain the color specification for blue
- (full intensity blue while red and green are zero), use
- .PN XcmsQueryBlue .
- .IN "XcmsQueryBlue" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryBlue\^(\^\fIccc\fP\^, \fItarget_format\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .ds Cs full intensity blue while red and green are zero
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the specified target format
- for \*(Cs.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryBlue
- function returns the color specification in the specified target format
- for full intensity blue while red and green are zero.
- .sp
- .LP
- To obtain the color specification for green
- (full intensity green while red and blue are zero), use
- .PN XcmsQueryGreen .
- .IN "XcmsQueryGreen" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryGreen\^(\^\fIccc\fP\^, \fItarget_format\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .ds Cs full intensity green while red and blue are zero
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the specified target format
- for \*(Cs.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryGreen
- function returns the color specification in the specified target format
- for full intensity green while red and blue are zero.
- .sp
- .LP
- To obtain the color specification for red
- (full intensity red while green and blue are zero), use
- .PN XcmsQueryRed .
- .IN "XcmsQueryRed" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryRed\^(\^\fIccc\fP\^, \fItarget_format\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .ds Cs full intensity red while green and blue are zero
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the specified target format
- for \*(Cs.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryRed
- function returns the color specification in the specified target format
- for full intensity red while green and blue are zero.
- .LP
- .sp
- To obtain the color specification for white
- (full intensity red, green, and blue), use
- .PN XcmsQueryWhite .
- .IN "XcmsQueryWhite" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsQueryWhite\^(\^\fIccc\fP\^, \fItarget_format\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColorFormat \fItarget_format\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .IP \fItarget_format\fP 1i
- Specifies the target color specification format.
- .ds Cs full intensity red, green, and blue
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the specified target format
- for \*(Cs.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsQueryWhite
- function returns the color specification in the specified target format
- for full intensity red, green, and blue.
- .NH 3
- CIELab Queries
- .XS
- \*(SN CIELab Queries
- .XE
- .LP
- .sp
- To obtain the CIE L*a*b* coordinates of maximum Psychometric Chroma
- for a given Psychometric Hue Angle and CIE metric lightness (L*), use
- .PN XcmsCIELabQueryMaxC .
- .EQ
- delim %%
- .EN
- .LP
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "Psychometric Chroma"
- .IN "Psychometric Chroma" "maximum"
- .Ds 0
- %CIELab~Psychometric~Chroma ~=~ sqrt(a_star sup 2 ~+~ b_star sup 2 )%
-
- %CIELab~Psychometric~Hue ~=~ tan sup -1 left [ b_star over a_star right ]%
- .De
- .IN "XcmsCIELabQueryMaxC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELabQueryMaxC\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIL_star\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIL_star\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum chroma
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ls maximum chroma
- .IP \fIL_star\fP 1i
- Specifies the lightness (L*) at which to find \*(Ls.
- .ds Lc maximum chroma
- .ds lC hue angle and lightness
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*a*b* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELabQueryMaxC
- function, given a hue angle and lightness,
- finds the point of maximum chroma displayable by the screen.
- It returns this point in CIE L*a*b* coordinates.
- .LP
- .sp
- To obtain the CIE L*a*b* coordinates of maximum CIE metric lightness (L*)
- for a given Psychometric Hue Angle and Psychometric Chroma, use
- .PN XcmsCIELabQueryMaxL .
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "CIE metric lightness" "maximum"
- .IN "XcmsCIELabQueryMaxL" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELabQueryMaxL\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum lightness
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ch maximum lightness
- .IP \fIchroma\fP 1i
- Specifies the chroma at which to find \*(Ch.
- .ds Lc maximum lightness
- .ds lC hue angle and chroma
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*a*b* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELabQueryMaxL
- function, given a hue angle and chroma,
- finds the point in CIE L*a*b* color space of maximum
- lightness (L*) displayable by the screen.
- It returns this point in CIE L*a*b* coordinates.
- An
- .PN XcmsFailure
- return value usually indicates that the given chroma
- is beyond maximum for the given hue angle.
- .sp
- .LP
- To obtain the CIE L*a*b* coordinates of maximum Psychometric Chroma
- for a given Psychometric Hue Angle, use
- .PN XcmsCIELabQueryMaxLC .
- .IN "Psychometric Hue Angle"
- .IN "Psychometric Chroma"
- .IN "CIE metric lightness"
- .IN "Psychometric Chroma" "maximum"
- .IN "CIE metric lightness" "maximum"
- .IN "XcmsCIELabQueryMaxLC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELabQueryMaxLC\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum chroma
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Lc maximum chroma
- .ds lC hue angle
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*a*b* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELabQueryMaxLC
- function, given a hue angle,
- finds the point of maximum chroma displayable by the screen.
- It returns this point in CIE L*a*b* coordinates.
- .sp
- .LP
- To obtain the CIE L*a*b* coordinates of minimum CIE metric lightness (L*)
- for a given Psychometric Hue Angle and Psychometric Chroma, use
- .PN XcmsCIELabQueryMinL .
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "CIE metric lightness" "minimum"
- .IN "XcmsCIELabQueryMinL" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELabQueryMinL\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha minimum lightness
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ch minimum lightness
- .IP \fIchroma\fP 1i
- Specifies the chroma at which to find \*(Ch.
- .ds Lc minimum lightness
- .ds lC hue angle and chroma
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*a*b* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELabQueryMinL
- function, given a hue angle and chroma,
- finds the point of minimum lightness (L*) displayable by the screen.
- It returns this point in CIE L*a*b* coordinates.
- An
- .PN XcmsFailure
- return value usually indicates that the given chroma
- is beyond maximum for the given hue angle.
- .NH 3
- CIELuv Queries
- .XS
- \*(SN CIELuv Queries
- .XE
- .sp
- .LP
- To obtain the CIE L*u*v* coordinates of maximum Psychometric Chroma
- for a given Psychometric Hue Angle and CIE metric lightness (L*), use
- .PN XcmsCIELuvQueryMaxC .
- .EQ
- delim %%
- .EN
- .LP
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "Psychometric Chroma"
- .IN "Psychometric Chroma" "maximum"
- .Ds 0
- %CIELuv~Psychometric~Chroma ~=~ sqrt(u_star sup 2 ~+~ v_star sup 2 )%
-
- %CIELuv~Psychometric~Hue ~=~ tan sup -1 left [ v_star over u_star right ]%
- .De
- .IN "XcmsCIELuvQueryMaxC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELuvQueryMaxC\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIL_star\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIL_star\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum chroma
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ls maximum chroma
- .IP \fIL_star\fP 1i
- Specifies the lightness (L*) at which to find \*(Ls.
- .ds Lc maximum chroma
- .ds lC hue angle and lightness
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*u*v* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELuvQueryMaxC
- function, given a hue angle and lightness,
- finds the point of maximum chroma displayable by the screen.
- Note that it returns this point in CIE L*u*v* coordinates.
- .sp
- .LP
- To obtain the CIE L*u*v* coordinates of maximum CIE metric lightness (L*)
- for a given Psychometric Hue Angle and Psychometric Chroma, use
- .PN XcmsCIELuvQueryMaxL .
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "CIE metric lightness" "maximum"
- .IN "XcmsCIELuvQueryMaxL" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELuvQueryMaxL\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum lightness
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ls maximum lightness
- .IP \fIL_star\fP 1i
- Specifies the lightness (L*) at which to find \*(Ls.
- .ds Lc maximum lightness
- .ds lC hue angle and chroma
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*u*v* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELuvQueryMaxL
- function, given a hue angle and chroma,
- finds the point in CIE L*u*v* color space of maximum
- lightness (L*) displayable by the screen.
- Note that it returns this point in CIE L*u*v* coordinates.
- An
- .PN XcmsFailure
- return value usually indicates that the given chroma
- is beyond maximum for the given hue angle.
- .sp
- .LP
- To obtain the CIE L*u*v* coordinates of maximum Psychometric Chroma
- for a given Psychometric Hue Angle, use
- .PN XcmsCIELuvQueryMaxLC .
- .IN "Psychometric Hue Angle"
- .IN "Psychometric Chroma"
- .IN "CIE metric lightness"
- .IN "Psychometric Chroma" "maximum"
- .IN "CIE metric lightness" "maximum"
- .IN "XcmsCIELuvQueryMaxLC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELuvQueryMaxLC\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha maximum chroma
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Lc maximum chroma
- .ds lC hue angle
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*u*v* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELuvQueryMaxLC
- function, given a hue angle,
- finds the point of maximum chroma displayable by the screen.
- Note that it returns this point in CIE L*u*v* coordinates.
- .sp
- .LP
- To obtain the CIE L*u*v* coordinates of minimum CIE metric lightness (L*)
- for a given Psychometric Hue Angle and Psychometric Chroma, use
- .PN XcmsCIELuvQueryMinL .
- .IN "Psychometric Hue Angle"
- .IN "CIE metric lightness"
- .IN "CIE metric lightness" "minimum"
- .IN "XcmsCIELuvQueryMinL" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsCIELuvQueryMinL\^(\^\fIccc\fP\^, \fIhue_angle\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue_angle\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Ha minimum lightness
- .IP \fIhue_angle\fP 1i
- Specifies the hue angle in degrees at which to find \*(Ha.
- .ds Ch minimum lightness
- .IP \fIchroma\fP 1i
- Specifies the chroma at which to find \*(Ch.
- .ds Lc minimum lightness
- .ds lC hue angle and chroma
- .IP \fIcolor_return\fP 1i
- Returns the CIE L*u*v* coordinates of \*(Lc
- displayable by the screen for the given \*(lC.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsCIELuvQueryMinL
- function, given a hue angle and chroma,
- finds the point of minimum lightness (L*) displayable by the screen.
- Note that it returns this point in CIE L*u*v* coordinates.
- An
- .PN XcmsFailure
- return value usually indicates that the given chroma
- is beyond maximum for the given hue angle.
- .NH 3
- TekHVC Queries
- .XS
- \*(SN TekHVC Queries
- .XE
- .LP
- To obtain the maximum Chroma for a given Hue and Value, use
- .PN XcmsTekHVCQueryMaxC .
- .IN "Chroma"
- .IN "Chroma" "maximum"
- .IN "XcmsTekHVCQueryMaxC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsTekHVCQueryMaxC\^(\^\fIccc\fP\^, \fIhue\fP\^, \fIvalue\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue\fP\^;
- .br
- XcmsFloat \fIvalue\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Hu in which to find the maximum Chroma
- .IP \fIhue\fP 1i
- Specifies the Hue \*(Hu.
- .ds Va maximum Chroma
- .IP \fIvalue\fP 1i
- Specifies the Value in which to find the \*(Va.
- .ds Lc maximum Chroma along with the actual Hue and Value
- .ds lC maximum Chroma
- .IP \fIcolor_return\fP 1i
- Returns the \*(Lc at which the \*(lC was found.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsTekHVCQueryMaxC
- function, given a Hue and Value,
- determines the maximum Chroma in TekHVC color space
- displayable by the screen.
- Note that it returns the maximum Chroma along with the actual Hue
- and Value at which the maximum Chroma was found.
- .sp
- .LP
- To obtain the maximum Value for a given Hue and Chroma, use
- .PN XcmsTekHVCQueryMaxV .
- .IN "Value"
- .IN "Value" "maximum"
- .IN "XcmsTekHVCQueryMaxV" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsTekHVCQueryMaxV\^(\^\fIccc\fP\^, \fIhue\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Hu in which to find the maximum Value
- .IP \fIhue\fP 1i
- Specifies the Hue \*(Hu.
- .ds Ch maximum Value
- .IP \fIchroma\fP 1i
- Specifies the chroma at which to find \*(Ch.
- .ds Lc maximum Value along with the Hue and Chroma
- .ds lC maximum Value
- .IP \fIcolor_return\fP 1i
- Returns the \*(Lc at which the \*(lC was found.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsTekHVCQueryMaxV
- function, given a Hue and Chroma,
- determines the maximum Value in TekHVC color space
- displayable by the screen.
- Note that it returns the maximum Value and the actual Hue and Chroma
- at which the maximum Value was found.
- .sp
- .LP
- To obtain the maximum Chroma and Value at which it is reached
- for a specified Hue, use
- .PN XcmsTekHVCQueryMaxVC .
- .IN "Chroma"
- .IN "Value"
- .IN "Chroma" "maximum"
- .IN "Value" "maximum"
- .IN "XcmsTekHVCQueryMaxVC" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsTekHVCQueryMaxVC\^(\^\fIccc\fP\^, \fIhue\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Hu in which to find the maximum Chroma
- .IP \fIhue\fP 1i
- Specifies the Hue \*(Hu.
- .ds Lc color specification in \
- XcmsTekHVC for the maximum Chroma, the Value at which \
- that maximum Chroma is reached and actual Hue
- .ds lC maximum Chroma
- .IP \fIcolor_return\fP 1i
- Returns the \*(Lc at which the \*(lC was found.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsTekHVCQueryMaxVC
- function, given a Hue,
- determines the maximum Chroma in TekHVC color space displayable by the screen
- and the Value at which that maximum Chroma is reached.
- Note that it returns the maximum Chroma,
- the Value at which that maximum Chroma is reached,
- and the actual Hue for which the maximum Chroma was found.
- .sp
- .LP
- To obtain a specified number of TekHVC specifications such that they
- contain a maximum Values for a specified Hue, and the
- Chroma at which the maximum Values are reached, use
- .PN XcmsTekHVCQueryMaxVSamples .
- .IN "Chroma"
- .IN "Value"
- .IN "Chroma" "maximum"
- .IN "Value" "maximum"
- .IN "XcmsTekHVCQueryMaxVSamples" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsTekHVCQueryMaxVSamples\^(\^\fIccc\fP\^, \fIhue\fP\^, \fIcolors_return\fP\^, \fInsamples\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue\fP\^;
- .br
- XcmsColor \fIcolors_return[]\fP\^;
- .br
- unsigned int \fInsamples\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Hu for maximum Chroma/Value samples
- .IP \fIhue\fP 1i
- Specifies the Hue \*(Hu.
- .IP \fInsamples\fP 1i
- Specifies the number of samples.
- .IP \fIcolors_in_out\fP 1i
- Returns nsamples of color specifications in XcmsTekHVC
- such that the Chroma is the maximum attainable for the Value and Hue.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsTekHVCQueryMaxVSamples
- returns nsamples of maximum Value, Chroma at which that maximum Value
- is reached, and the actual Hue for which the maximum Chroma was found.
- These sample points may then be used to plot the maximum Value/Chroma
- boundary of the screen's color gamut for the specified Hue in TekHVC color
- space.
- .sp
- .LP
- To obtain the minimum Value for a given Hue and Chroma, use
- .PN XcmsTekHVCQueryMinV .
- .IN "Value"
- .IN "Value" "minimum"
- .IN "XcmsTekHVCQueryMinV" "" "@DEF@"
- .\" Start marker code here
- .FD 0
- Status XcmsTekHVCQueryMinV\^(\^\fIccc\fP\^, \fIhue\fP\^, \fIchroma\fP\^, \fIcolor_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsFloat \fIhue\fP\^;
- .br
- XcmsFloat \fIchroma\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- Note that the CCC's Client White Point and White Point Adjustment procedures
- are ignored.
- .ds Hu in which to find the minimum Value
- .IP \fIhue\fP 1i
- Specifies the Hue \*(Hu.
- .ds Va minimum Value
- .IP \fIvalue\fP 1i
- Specifies the Value in which to find the \*(Va.
- .ds Lc minimum Value and the actual Hue and Chroma
- .ds lC minimum Value
- .IP \fIcolor_return\fP 1i
- Returns the \*(Lc at which the \*(lC was found.
- The white point associated with the returned
- color specification is the Screen White Point.
- The value returned in the pixel member is undefined.
- .\" End marker code here
- .LP
- The
- .PN XcmsTekHVCQueryMinV
- function, given a Hue and Chroma,
- determines the minimum Value in TekHVC color space displayable by the screen.
- Note that it returns the minimum Value and the actual Hue and Chroma at which
- the minimum Value was found.
- .NH 2
- Color Management Extensions
- .XS
- \*(SN Color Management Extensions
- .XE
- .LP
- The Xlib color management facilities can be extended in two ways:
- .IP \(bu 5
- Device-Independent Color Spaces
- .IP
- Device-independent color spaces that are derivable to CIE XYZ
- space can be added using the
- .PN XcmsAddColorSpace
- function.
- .IP \(bu 5
- Color Characterization Function Set
- .IP
- A Color Characterization Function Set consists of
- device-dependent color spaces and their functions that
- convert between these color spaces and the CIE XYZ
- color space, bundled together for a specific class of output devices.
- A function set can be added using the
- .PN XcmsAddFunctionSet
- function.
- .NH 3
- Color Spaces
- .XS
- \*(SN Color Spaces
- .XE
- .LP
- The CIE XYZ color space serves as the "hub" for all
- conversions between device-independent and device-dependent color spaces.
- Therefore, associated with each color space
- is the knowledge to convert an
- .PN XcmsColor
- structure to and from CIE XYZ format.
- For example, conversion from CIE L*u*v* to RGB requires the knowledge
- to convert from CIE L*u*v* to CIE XYZ and from CIE XYZ to RGB.
- This knowledge is stored as an array of functions that when applied
- in series will convert the
- .PN XcmsColor
- structure to or from CIE XYZ format.
- This color specification conversion mechanism facilitates
- the addition of color spaces.
- .LP
- Of course, when converting between only device-independent color spaces
- or only device-dependent color spaces,
- short cuts are taken whenever possible.
- For example, conversion from TekHVC to CIE L*u*v* is performed
- by intermediate conversion to CIE u*v*Y and then to CIE L*u*v*,
- thus bypassing conversion between CIE u*v*Y and CIE XYZ.
- .NH 3
- Adding Device-Independent Color Spaces
- .XS
- \*(SN Adding Device-Independent Color Spaces
- .XE
- .LP
- To add a device-independent color space, use
- .PN XcmsAddColorSpace .
- .IN "XcmsAddColorSpace" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- Status XcmsAddColorSpace\^(\^\fIcolor_space\fP\^)
- .br
- XcmsColorSpace *\fIcolor_space\fP\^;
- .FN
- .IP \fIcolor_space\fP 1i
- Specifies the device-independent color space to add.
- .\" End marker code here
- .LP
- The
- .PN XcmsAddColorSpace
- function makes a device-independent color space (actually an
- .PN XcmsColorSpace
- structure) accessible by the color management system.
- Because format values for unregistered color spaces are assigned at run-time,
- they should be treated as private to the client.
- If references to an unregistered color space must be made
- outside the client (for example, storing color specifications
- in a file using the unregistered color space),
- then reference should be made by color space prefix
- (see
- .PN XcmsFormatOfPrefix
- and
- .PN XcmsPrefixOfFormat ).
- .LP
- If the
- .PN XcmsColorSpace
- structure is already accessible in the color management system,
- .PN XcmsAddColorSpace
- returns
- .PN XcmsSuccess .
- .LP
- Note that added
- .PN XcmsColorSpaces
- must be retained for reference by Xlib.
- .NH 3
- Querying Color Space Format and Prefix
- .XS
- \*(SN Querying Color Space Format and Prefix
- .XE
- .LP
- To obtain the format associated with the color space
- associated with a specified color string prefix, use
- .PN XcmsFormatOfPrefix .
- .IN "XcmsFormatOfPrefix" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- XcmsColorFormat XcmsFormatOfPrefix\^(\^\fIprefix\fP\^)
- .br
- char *\fIprefix\fP\^;
- .FN
- .IP \fIprefix\fP 1i
- Specifies the string that contains the color space prefix.
- .\" End marker code here
- .LP
- The
- .PN XcmsFormatOfPrefix
- function returns format for the specified color space prefix
- (for example, "CIEXYZ").
- Note that the prefix is case-insensitive.
- If the color space is not accessible in the color management system,
- .PN XcmsFormatOfPrefix
- returns
- .PN XcmsUndefinedFormat .
- .LP
- .sp
- To obtain the color string prefix associated with the color space
- specified by a color format, use
- .PN XcmsPrefixOfFormat .
- .IN "XcmsPrefixOfFormat" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- char *XcmsPrefixOfFormat\^(\^\fIformat\fP\^)
- .br
- XcmsColorFormat \fIformat\fP\^;
- .FN
- .IP \fIformat\fP 1i
- Specifies the color specification format.
- .\" End marker code here
- .LP
- The
- .PN XcmsPrefixOfFormat
- function returns the string prefix associated with the color specification
- encoding specified by format.
- Otherwise, if none is found, it returns NULL.
- Note that the returned string must be treated as read-only.
- .NH 3
- Creating Additional Color Spaces
- .XS
- \*(SN Creating Additional Color Spaces
- .XE
- .LP
- Color space specific information necessary
- for color space conversion and color string parsing is stored in an
- .PN XcmsColorSpace
- structure.
- Therefore, a new structure containing this information is required
- for each additional color space.
- In the case of device-independent color spaces,
- a handle to this new structure (that is, by means of a global variable)
- is usually made accessible to the client program for use with the
- .PN XcmsAddColorSpace
- function.
- .LP
- If a new
- .PN XcmsColorSpace
- structure specifies a color space not registered with the X Consortium,
- because format values for unregistered color spaces are assigned
- at run-time they should be treated as private to the client.
- If references to an unregistered color space must be made outside the
- client (for example, storing color specifications in a file using the
- unregistered color space), then reference should be made by color space prefix
- (see
- .PN XcmsFormatOfPrefix
- and
- .PN XcmsPrefixOfFormat ).
- .\" Start maker code here
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef (*XcmsConversionProc)();
- typedef XcmsConversionProc *XcmsFuncListPtr;
- /* A NULL terminated list of function pointers*/
-
- typedef struct _XcmsColorSpace {
- char *prefix;
- XcmsColorFormat format;
- XcmsParseStringProc parseString;
- XcmsFuncListPtr to_CIEXYZ;
- XcmsFuncListPtr from_CIEXYZ;
- int inverse_flag;
- } XcmsColorSpace;
- .De
- .LP
- The prefix member specifies the prefix that indicates a color string
- is in this color space's string format.
- For example, "ciexyz" or "CIEXYZ" for CIE XYZ, and "rgb" or "RGB" for RGB.
- Note that the prefix is case insensitive.
- The format member specifies the color specification format.
- Formats for unregistered color spaces are assigned at run-time.
- The parseString member contains a pointer to the function
- that can parse a color string into an
- .PN XcmsColor
- structure.
- This function returns an integer (int): non-zero if it succeeded
- and zero otherwise.
- The to_CIEXYZ and from_CIEXYZ members contain pointers,
- each to a NULL terminated list of function pointers.
- When the list of functions are executed in series,
- it will convert the color specified in an
- .PN XcmsColor
- structure from/to the current color space format to/from the CIE XYZ format.
- Each function returns an integer (int): non-zero if it succeeded
- and zero otherwise.
- Note that the white point to be associated with the colors is specified
- explicitly, even though white points can be found in the Color Conversion
- Context.
- The inverse_flag member, if non-zero, specifies that for each function listed
- in to_CIEXYZ,
- its inverse function can be found in from_CIEXYZ such that:
- .LP
- .Ds 0
- Given: n = number of functions in each list
-
- foreach i, such that 0 <= i < n
- from_CIEXYZ[n - i - 1] is the inverse of to_CIEXYZ[i].
- .De
- .LP
- This allows Xlib to use the shortest conversion path,
- thus, bypassing CIE XYZ if possible (for example, TekHVC to CIE L*u*v*).
- .NH 3
- Parse String Callback
- .XS
- \*(SN Parse String Callback
- .XE
- .LP
- The callback in the
- .PN XcmsColorSpace
- structure for parsing a color string for the particular color space must
- adhere to the following software interface specification:
- .IN "XcmsParseStringProc" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- typedef int (*XcmsParseStringProc)\^(\^\fIcolor_string\fP, \fIcolor_return\fP\^)
- .br
- char *\fIcolor_string\fP\^;
- .br
- XcmsColor *\fIcolor_return\fP\^; /* color to compress */
- .FN
- .IP \fIcolor_string\fP 1i
- Specifies the color string to parse.
- .IP \fIcolor_return\fP 1i
- Returns the color specification in the color space's format.
- .\" End marker code here
- .NH 3
- Color Specification Conversion Callback
- .XS
- \*(SN Color Specification Conversion Callback
- .XE
- .LP
- Callback functions in the
- .PN XcmsColorSpace
- structure for converting a color specification between device-independent
- spaces must adhere to the
- following software interface specification:
- .\" Start maker code here
- .FD 0
- Status ConversionProc\^(\^\fIccc\fP, \fIwhite_point\fP, \fIcolors_in_out\fP, \fIncolors\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor *\fIwhite_point\fP\^;
- .br
- XcmsColor *\fIcolors_in_out\fP\^;
- .br
- unsigned int \fIncolors\fP\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIwhite_point\fP 1i
- Specifies the white point associated with color specifications.
- Note that the pixel member is ignored
- and that the color specification is left unchanged upon return.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of color specifications.
- Pixel members are ignored and remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .\" End marker code here
- .LP
- Callback functions in the
- .PN XcmsColorSpace
- structure for converting a color specification to or from a device-dependent
- space must adhere to the
- following software interface specification:
- .\" Start maker code here
- .FD 0
- Status ConversionProc\^(\^\fIccc\fP, \fIcolors_in_out\fP, \fIncolors\fP, \fIcompression_flags_return\fP\^)
- .br
- XcmsCCC \fIccc\fP\^;
- .br
- XcmsColor *\fIcolors_in_out\fP\^;
- .br
- unsigned int \fIncolors\fP\^;
- .br
- Bool \fIcompression_flags_return\fP\^[\^]\^;
- .FN
- .IP \fIccc\fP 1i
- Specifies the CCC.
- .IP \fIcolors_in_out\fP 1i
- Specifies an array of color specifications.
- Pixel members are ignored and remain unchanged upon return.
- .IP \fIncolors\fP 1i
- Specifies the number of
- .PN XcmsColor
- structures in the color specification array.
- .IP \fIcompression_flags_return\fP 1i
- Specifies an array of Boolean values for returning compression status.
- If a non-NULL pointer is supplied,
- and a color at a given index is compressed, then
- .PN True
- should be stored at the corresponding index in this array.
- .\" End marker code here
- .LP
- Conversion functions are available globally for use by other color
- spaces.
- The conversion functions provided by Xlib are:
- .TS H
- lw(2i) lw(3.5i).
- _
- .sp 6p
- .B
- Function Converts
- .sp 6p
- _
- .sp 6p
- .TH
- .R
- T{
- .PN XcmsCIELabToCIEXYZ
- T} T{
- From
- .PN XcmsCIELabFormat
- to
- .PN XcmsCIEXYZFormat .
- T}
- T{
- .PN XcmsCIELuvToCIEuvY
- T} T{
- From
- .PN XcmsCIELuvFormat
- to
- .PN XcmsCIEuvYFormat .
- T}
- T{
- .PN XcmsCIEXYZToCIELab
- T} T{
- From
- .PN XcmsCIEXYZFormat
- to
- .PN XcmsCIELabFormat .
- T}
- T{
- .PN XcmsCIEXYZToCIEuvY
- T} T{
- From
- .PN XcmsCIEXYZFormat
- to
- .PN XcmsCIEuvYFormat .
- T}
- T{
- .PN XcmsCIEXYZToCIExyY
- T} T{
- From
- .PN XcmsCIEXYZFormat
- to
- .PN XcmsCIExyYFormat .
- T}
- T{
- .PN XcmsCIEXYZToRGBi
- T} T{
- From
- .PN XcmsCIEXYZFormat
- to
- .PN XcmsRGBiFormat .
- T}
- T{
- .PN XcmsCIEuvYToCIELuv
- T} T{
- From
- .PN XcmsCIEuvYFormat
- to
- .PN XcmsCIELabFormat .
- T}
- T{
- .PN XcmsCIEuvYToCIEXYZ
- T} T{
- From
- .PN XcmsCIEuvYFormat
- to
- .PN XcmsCIEXYZFormat .
- T}
- T{
- .PN XcmsCIEuvYToTekHVC
- T} T{
- From
- .PN XcmsCIEuvYFormat
- to
- .PN XcmsTekHVCFormat .
- T}
- T{
- .PN XcmsCIExyYToCIEXYZ
- T} T{
- From
- .PN XcmsCIExyYFormat
- to
- .PN XcmsCIEXYZFormat .
- T}
- T{
- .PN XcmsRGBToRGBi
- T} T{
- From
- .PN XcmsRGBFormat
- to
- .PN XcmsRGBiFormat .
- T}
- T{
- .PN XcmsRGBiToCIEXYZ
- T} T{
- From
- .PN XcmsRGBiFormat
- to
- .PN XcmsCIEXYZFormat .
- T}
- T{
- .PN XcmsRGBiToRGB
- T} T{
- From
- .PN XcmsRGBiFormat
- to
- .PN XcmsRGBFormat .
- T}
- T{
- .PN XcmsTekHVCToCIEuvY
- T} T{
- From
- .PN XcmsTekHVCFormat
- to
- .PN XcmsCIEuvYFormat .
- T}
- .sp 6p
- _
- .TE
- .NH 3
- Function Sets
- .XS
- \*(SN Function Sets
- .XE
- .IN "function set"
- .IN "function set" "LINEAR_RGB"
- .LP
- Functions to convert between device-dependent color spaces
- and CIE XYZ may differ for different classes of output devices
- (for example, color versus gray monitors).
- Therefore, the notion of a Color Characterization Function Set
- (hereafter referred to as a Function Set) has been developed.
- A function set consists of device-dependent color spaces
- and the functions that convert color specifications
- between these device-dependent color spaces and the CIE XYZ color space
- appropriate for a particular class of output devices.
- The function set also contains a function that reads
- color characterization data off root window properties.
- It is this characterization data that will differ between devices within
- a class of output devices.
- .IN "Device Color Characterization"
- For details about color characterization data is
- stored in root window properties,
- see the section on Device Color Characterization in the
- \fIInter-Client Communication Conventions Manual\fP.
- The LINEAR_RGB Function Set is provided by Xlib
- and will support most color monitors.
- Function sets may require data that differs
- from those needed for the LINEAR_RGB Function Set.
- In that case,
- its corresponding data may be stored on different root window properties.
- .NH 3
- Adding Function Sets
- .XS
- \*(SN Adding Function Sets
- .XE
- .LP
- To add a Color Characterization Function Set, use
- .PN XcmsAddFunctionSet .
- .IN "XcmsAddFunctionSet" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- Status XcmsAddFunctionSet\^(\^\fIfunction_set\fP\^)
- .br
- XcmsFunctionSet *\fIfunction_set\fP\^;
- .FN
- .IP \fIfunction_set\fP 1i
- Specifies the Color Characterization Function Set to add.
- .\" End marker code here
- .LP
- The
- .PN XcmsAddFunctionSet
- adds a Color Characterization Function Set to the
- color management system.
- If the Function Set uses device-dependent
- .PN XcmsColorSpace
- structures not accessible in the color management system,
- .PN XcmsAddFunctionSet
- adds them.
- If an added
- .PN XcmsColorSpace
- structure is for a device-dependent color space not registered
- with the X Consortium,
- because format values for unregistered color spaces are assigned
- at run-time they should be treated as private to the client.
- If references to an unregistered color space must be made outside the
- client (for example, storing color specifications in a file
- using the unregistered color space),
- then reference should be made by color space prefix
- (see
- .PN XcmsFormatOfPrefix
- and
- .PN XcmsPrefixOfFormat ).
- .LP
- Additional function sets should be added before any calls to other
- Xlib routines are made.
- If not, the
- .PN XcmsPerScrnInfo
- member of a previously created
- .PN XcmsCCC
- does not have the opportunity to initialize
- with the added Function Set.
- .NH 3
- Creating Additional Function Sets
- .XS
- \*(SN Creating Additional Function Sets
- .XE
- .LP
- Creation of additional Color Characterization Function Sets should be
- required only when an output device does not conform to existing
- function sets or when additional device-dependent color spaces are necessary.
- A function set consists primarily of a collection of device-dependent
- .PN XcmsColorSpace
- structures and a means to read and store a
- screen's color characterization data.
- This data is stored in an
- .PN XcmsFunctionSet
- structure.
- A handle to this structure (that is, by means of global variable)
- is usually made accessible to the client program for use with
- .PN XcmsAddFunctionSet .
- .LP
- If a Function Set uses new device-dependent
- .PN XcmsColorSpace
- structures,
- they will be transparently processed into the color management system.
- Function Sets can share an
- .PN XcmsColorSpace
- structure for a device-dependent color space.
- In addition, multiple
- .PN XcmsColorSpace
- structures are allowed for a device-dependent color space;
- however, a Function Set can reference only one of them.
- These
- .PN XcmsColorSpace
- structures will differ in the functions to convert to and from CIE XYZ,
- thus tailored for the specific Function Set.
- .\" Start maker code here
- .LP
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct _XcmsFunctionSet {
- XcmsColorSpace **DDColorSpaces;
- XcmsScreenInitProc screenInitProc;
- XcmsScreenFreeProc screenFreeProc;
- } XcmsFunctionSet;
- .De
- .\" End marker code here
- .LP
- The DDColorSpaces member is a pointer to a NULL terminated list
- of pointers to
- .PN XcmsColorSpace
- structures for the device-dependent color spaces that are supported
- by the Function Set.
- The screenInitProc member is set to the callback procedure (see following
- interface specification) that initializes the
- .PN XcmsPerScrnInfo
- structure for a particular screen.
- .LP
- The screen initialization callback must adhere to the following software
- interface specification:
- .IN "XcmsScreenInitProc" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- typedef Status (*XcmsScreenInitProc)\^(\^\fIdisplay\fP, \fIscreen_number\fP, \fIscreen_info\fP\^)
- .br
- Display *\fIdisplay\fP\^;
- .br
- int \fIscreen_number\fP\^;
- .br
- XcmsPerScrnInfo *\fIscreen_info\fP\^;
- .FN
- .\" $Header: display.a,v 1.1 88/02/26 10:26:29 mento Exp $
- .IP \fIdisplay\fP 1i
- Specifies the connection to the X server.
- .IP \fIscreen_number\fP 1i
- Specifies the appropriate screen number on the host server.
- .IP \fIscreen_info\fP 1i
- Specifies the
- .PN XcmsPerScrnInfo
- structure, which contains the per screen information.
- .\" End marker code here
- .LP
- The screen initialization callback in the
- .PN XcmsFunctionSet
- structure fetches the Color Characterization Data (device profile) for
- the specified screen,
- typically off properties on the
- screen's root window; then it initializes the specified
- .PN XcmsPerScrnInfo
- structure.
- .IN "device profile"
- .IN "Color Characterization Data"
- If successful, the procedure fills in the
- .PN XcmsPerScrnInfo
- structure as follows:
- .IP \(bu 5
- It sets the screenData member to the address
- of the created device profile data structure
- (contents known only by the function set).
- .IP \(bu 5
- It next sets the screenWhitePoint member.
- .IP \(bu 5
- It next sets the functionSet member to the address of the
- .PN XcmsFunctionSet
- structure.
- .IP \(bu 5
- It then sets the state member to
- .PN XcmsInitSuccess
- and finally returns
- .PN XcmsSuccess .
- .LP
- If unsuccessful, the procedure sets the state member to
- .PN XcmsInitFailure
- and returns
- .PN XcmsFailure .
- .LP
- The
- .PN XcmsPerScrnInfo
- structure contains:
- .\" Start maker code here
- .Ds 0
- .TA .5i 2.5i
- .ta .5i 2.5i
- typedef struct _XcmsPerScrnInfo {
- XcmsColor screenWhitePoint;
- XPointer functionSet;
- XPointer screenData;
- unsigned char state;
- char pad[3];
- } XcmsPerScrnInfo;
- .De
- .\" End marker code here
- .LP
- The screenWhitePoint member specifies the white point inherent to
- the screen.
- The functionSet member specifies the appropriate Function Set.
- The screenData member specifies the device profile.
- The state member is set to one of the following:
- .IP \(bu 5
- .PN XcmsInitNone
- indicates initialization has not been previously attempted.
- .IP \(bu 5
- .PN XcmsInitFailure
- indicates initialization has been previously attempted but failed.
- .IP \(bu 5
- .PN XcmsInitSuccess
- indicates initialization has been previously attempted and succeeded.
- .LP
- The screen free callback must adhere to the following software
- interface specification:
- .IN "XcmsScreenFreeProc" "" "@DEF@"
- .\" Start maker code here
- .FD 0
- typedef void (*XcmsScreenFreeProc)\^(\^\fIscreenData\fP\^)
- .br
- XPointer \fIscreenData\fP\^;
- .FN
- .IP \fIscreenData\fP 1i
- Specifies the data to be freed.
- .\" End marker code here
- .LP
- This function is called to free the screenData stored in an
- .PN XcmsPerScrnInfo
- structure.
- .bp
-