IPP> FW: Describing colour capabilities (V2)

IPP> FW: Describing colour capabilities (V2)

IPP> FW: Describing colour capabilities (V2)

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Nov 13 15:28:55 EST 1998


FYI,

This is the current thinking about values for the color attribute as
discussed in the IFAX and CONNEG groups.

Carl-Uno

-----Original Message-----
From: Graham Klyne [mailto:GK at dial.pipex.com] 
Sent: Friday, November 13, 1998 7:56 AM
To: Content negotiation list; ietf-fax at imc.org
Subject: Describing colour capabilities (V2)


All,

This note is a re-work of my previous one on this topic, to take account of
Larry's suggestion to re-design the 'color=' feature tag to give a broad
indication of colour capability.

The core of Larry's proposal:

color=none  (binary)
color=grey  (some amount of greyscale, unspecified how much)
color=mapped (palette color adequate for 'gif' images, sender
              should attempt to limit palette necessary; this
              is primarily useful when the ua-media is screen)
color=full   (sufficient color capability that a 'full color'
             image can be sent, although details of gamut, fidelity,
             and rendering method are not indicated).

I have suggested adding another option:

color=fixed  (a fixed number of predefined but unspecified colours
              suitable for office graphics, etc.  Examples would
              be:  pen plotter, EGA display, highlight printer.)

I'd also add a suggestion that 'color=grey', while not specifying a number
of levels of grey, would be presumed sufficient to display grey-scale GIF
images, etc.


The following tags from my previous posting have ben removed:

  color-encoding = CONTINUOUS | PALETTE
    (CONTINUOUS is covered by color=FULL, and
     PALETTE by color=MAPPED or color=FIXED)

  color-components = <unsigned>  (number of colour components)
    (the color/grey distinction is covered by color=, and
     the specific number of components by color-space=)

and one new tag has ben added:

  color-levels = <unsigned>
    (this picks up the specific information provided previously by
     color= or grey=.)


The revised proposal:


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.  The following features
are suggested for describing color capabilities:


* Colour handling capability

color= NONE | GREY | FIXED | MAPPED | FULL

This may be extended by further registrations, but only sparingly.

The intention here is to give a broad indication of colour handling
capabilities that might be used, for example, to select among a small
number of available data resources.


* 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-levels= <unsigned>    (number of distinct pixel values)

This applies to colour and greyscale.
For bi-level (binary) images, a value of 2 is implied.


* Colour interpretation:

color-depth = <unsigned>       (number of distinct values per colour
component)
color-space = RGB              (generic RGB)
              LAB              (generic L*a*b*)
              CMY              (generic CMY)
              CMYK             (generic CMYK)
              + specific colour spaces

'color-depth', in conjunction with the 'color-space' value, indicates the
number of distinct colour values that can be selected:  this may be
different from the number of distinct pixel values (color-levels=) when
MAPPED colour capability is used, and is generally specified only in that
case.

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=NONE) )

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

Colour fax:             (& (image-file-structure=TIFF-C)
                           (image-coding=[MH,JPEG])
                           (color=[NONE,GREY,MAPPED])
                           (color-levels<=256)
                           (color-depth=256)
                           (color-space=[LAB,CIELAB]) )

Web colour image:       (& (image-coding=[JPEG|GIF])
                           (color=MAPPED) )

PC system with 512K bytes video memory:
             (| (& (pix-x<=320)  (pix-y<=240) (color=full) )
                (& (pix-x<=800)  (pix-y<=600) (color=mapped) )
                (& (pix-x<=1024) (pix-y<=768) (color=fixed) ) )

#g

------------
Graham Klyne
(GK at ACM.ORG)



More information about the Ipp mailing list