Subject: Describing colour capabilities

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Nov 1998 20:11:55 +0000

All,

The following notes arise from a meeting between myself and Lloyd McIntyre
to discuss the issue of representing colour capabilities for fax and other
applications.  (Any errors here are mine alone.)

This approach has some implications for the -conneg-media-features- draft.
I don't think it would necessarily be appropriate for all of this material
to appear in that memo, but I do think the options that do appear there
should be consistent with this framework.

Our feeling is that the features described in the meadia features draft
don't really capture the range of colour issues that can be important.  The
ideas below are an attempt to capture the important issues without forcing
every user/application to deal with the full complexity of colour
reproduction when what they require is a simple indication of some kind of
colour capability (even if it may be technically subject to
misinterpretation).

The general model for image handling (both colour and non-colour) is
described here from a receiver's perspective;  a similar model operates in
the reverse direction for a scan/send perspective:

     raw          pixel         colour        physical
     bit   -(A)-> values -(B)-> values -(C)-> rendition
    stream

 -  "raw bit stream" is a sream of coded bits
(A) indicates image coding/decoding (MH,MR,MMR,JPEG,JBIG,etc.)
 -  "pixel values" are a single numeric value per pixel
(B) indicates pixel-to-colour value mapping
 -  "colour values" have a separate numeric value for each colour component
    (typically, 1, 3 or 4 components)
(C) indicates how the colour values are related to a physical colour,
    and involves interpretation of the colour value with respect
    to a colour model (e.g. RGB, LAB, CMY, CMYK) and a colour
    space (which is typically device-dependent).
 -  "physical rendition" is a colour value physically realized on a
    display, printer or other device.

There are very many variables which can be applied at each stage of the
processing of a colour image, and any one may be critical to meaningful
handling of a colour image in some circumstances.  In other circumstances
many of the variables may be implied (to some level of approximation) in
the application that uses them (e.g. colour images published on a Web page).

Grey scale and bi-level images are handled within this framework as a
special case, having a 1-component colour model.  Thus, the following
features are suggested for describing color capabilities:

* Image representation/coding constraints:

image-file-structure = TIFF-S | TIFF-F | TIFF-J | TIFF-L | TIFF-C | TIFF-M
image-coding = MH | MR | MMR | JBIG | JPEG
image-coding-constraint = JBIG-T85 | JBIG-T43 | JPEG-T4-E

These may be extended by further registrations.

* Pixel value constraints:

color= <unsigned>    (number of distinct pixel values)

This applies to colour, greyscale and bi-level images.

* Colour value constraints:

color-encoding = CONTINUOUS | PALETTE
color-components = <unsigned>  (number of colour components)
color-depth = <unsigned>       (number of distinct values per colour
component)

'color-components' is 1 to indicate grey-scale image.
'color-components*color-depth' indicates the number of distinct colours
that can be rendered:  this may be different from the number of distinct
pixel values (color=) when palette colour encoding is used.

* Colour interpretation:

color-space = RGB              (generic RGB)
              LAB              (generic L*a*b*)
              CMY              (generic CMY)
              CMYK             (generic CMYK)
              + specific colour spaces

The "generic" colour spaces are provided for applications that don't
know/care the specific colour space used, as long as it follows some
general pattern.  The specific colour spaces refer to precise colour space
definitions, and are used when accurate colour reproduction is needed.  A
receiver that advertises a specific colour space capability should also
advertise a corresponding generic colour space.

color-illuminant = CUSTOM | CIED50
color-gamut = <string>

The color-illuminant feature can be extended by future registrations
The color-gamut string contains either a token indicating some separately
defined gamut or gamut-range, or a sequence of one or more component value
ranges in the form:

    "[lo1..hi1],[lo2..hi2], ... ,[lon..hin]"

The number of component-value ranges must correspond to the number of
components required by the color space used.  For generic gamut matching,
suitable selected tokenized values might be used (e.g. VIDEO, HARDCOPY).
Specific applications might understand the content of the gamut string and
interpret expressions like
    (color-gamut<="[1..100],[-75..75],[-75..125]")
but this would not be a required feature of a generic negotiation framework.

Some examples:
--------------

Simple bi-level fax:    (& (image-file-structure=TIFF-S)
                           (image-coding=MH)
                           (color=2) )

Simple grey-scale fax:  (& (image-file-structure=TIFF-J)
                           (image-coding=[MH,JPEG])
                           (color<=256)
                           (color-components=1) )

Colour fax:             (& (image-file-structure=TIFF-C)
                           (image-coding=[MH,JPEG])
                           (color<=256)
                           (color-components=[1,3])
                           (color-encoding=PALETTE)
                           (color-depth=256)
                           (color-space=[LAB,CIELAB]) )

Web colour image:       (& (image-coding=[JPEG|GIF])
                           (color<=256)
                           (color-components=3) )

#g

------------
Graham Klyne
([email-masked])