Subject: Colour features

From: Graham Klyne <[email-masked]>
Date: Thu, 12 Nov 1998 12:43:57 +0000

At 11:13 11/11/98 -0800, McIntyre, Lloyd wrote:

>> [...]  Hence the proposal noted and posted
>> separately
>> for dealing with colour representation.
>	[McIntyre, Lloyd]  Additional attributes are essential if color
>is to be dealt with  in an honest manner.

One possibility that occurred to me was to handle all colour-related
features features in a separate 'conneg' registration document, so that
media-features can move forward quickly and yet avoid the colour details
becoming part of work that is perceived as being fax-specific.

#g

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

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 12 Nov 1998 22:11:39 PST

What about if we remove any notion of 'number of channels' from
the color capability, and just stick with a simple enumeration:

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

This removes the relatively useless 'silly state' where you could
say 'color=4' but have no idea whether the 16 colors are a fixed
or changable gamut, etc. It leaves in place the possibility that
other values of color might be registered if they're actually useful.

In addition, I can add a note saying that more details of color
matching will be left to another document.

I think that this level of color indication is useful.
> becoming part of work that is perceived as being fax-specific.

A separate document on 'Media features for color devices' would be
good.

Larry

---

From: Al Gilman <[email-masked]>
Date: Fri, 13 Nov 1998 10:45:34 -0500 (EST)

> other values of color might be registered if they're actually useful.

Making all silly states illegal will make some useful states 
unreachable.

The following is just an impression, but it would seem that the
information model previously suggested may be rich enough to
state the color resolution capability of a color-weak user, and
this enumeration would seem incapable of doing that.  I will see
if we can get a reading from the Lighthouse on this.

The other problem is that I think I want to know opaque 3-D color
from translucent 4-D color.  But that could be accomodated by
replacing "full" with two more choices on the order of "opaque |
semiopaque".

> matching will be left to another document.

Is it time to amend our concept of the technology proposal to
include an initial batch of registrations as one of the
components?  These items would not have the force of a standard,
but would have registered definitions from the outset and relieve
pressure on the standards-track RFC's to define things.  Can we
have a registration-track RFC?

Where this comes from is the following idea: If we were to go
forward with the summary set of color grades, I would sure like
to be more confident that the more elaborate scheme would work as
a registration.  The wording of the registration should be
a piece of the review package for the bundle.  Why not just make
a few such registrations part of the package?

Al

-- all quote below

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 14 Nov 1998 11:44:31 PST

> Making all silly states illegal will make some useful states 

No, not at all. Other states (other capabilities) just require
other capability tags. These are just the 'commonly useful' ones.

There are many other kinds of capabilities that cannot be expressed
in this formulation; for example, Xerox makes 'highlight color' printers
that print 'black' and one other color simultaneously, e.g.,
black and red. I'm not sure it's useful to say 'color=fixed',
though. What could you do with just that amount of information?

The point is not to build a comprehensive description of capabilities,
but just a set of gross characterizations that are adequate for
deciding among common choices -- the kinds of things that are available
in the 'save as' dialog in typical image editing programs, for
example.
 
> if we can get a reading from the Lighthouse on this.

The question is whether those who typically prepare alternate
renditions of images for general use would find this enumeration
useful in deciding which of several images to send.
  
> replacing "full" with two more choices on the order of "opaque |

? This really confuses me. The nature of the device vs. the
gamut of colors.

The problem with 'fixed' is that it's just a limitation of 'mapped'.

> have a registration-track RFC?

? -media-features- contains just some COMMON features

> a few such registrations part of the package?

Because it's necessary to get them right. All we need to know
at this point is that the registration process is credible.

Larry