[CREATE] Swatches: Proposition J

[Kai-Uwe Behrmann]

Am 23.06.08, 17:53 -0400 schrieb MenTaLguY:
> On Mon, 2008-06-23 at 19:59 +0200, Cyrille Berger wrote:
> > Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, 
> > but please, don't move spec around without a discution), I can be a little 
> > bit rational, and make a few comments.
> 
> I think your posted response was perfectly reasonable.
> 
> > The main interest is that it allows to define a color in a non-RGB 
> > colorspace, like you allow too, but your proposal doesn't allow a fallback 
> > for application that can only read and use RGB, that would mean they simply 
> > can't use the color.
> 
> The lack of an sRGB fallback built-in is a major problem with my
> approach.  My thinking at the time I wrote the original spec was that
> "fallback" color specifications could be provided as an extension, but I
> did not pursue that further once I realized that the CREATE swatches
> work had proceeded and I needed to synchronize with it rather than
> continue off on my own.
> 
> However, if a color is simultaneously specified in several different
> color spaces, those specifications are going to conflict since the
> conversion between color spaces is dependent on factors like rendering
> intent which are not specified at all in the current form of Proposition
> H.  There does need to be a way to specify which of the several color
> specifications is (are?) authoritative and which are derived.  In the
> case of my format, the authoritative specification would be the <color>
> element, and any derived specifications would be children of it.
> 
> I think the simplest way to address this in the adopted CREATE swatch
> format, would be to designate the first specification for a swatch as
> authoritative, and the remainder as derived.
> 
> > Then there is "color" vs "rgb" for the tag name. Well, originally, we choosed 
> > the second form for the validation purpose, after what Liam said about 
> > validation in the OpenRaster thread last week, it seems it doesn't matter 
> > much anymore. On the other hand, for me it would suck to have to go through 
> > the code in krita to change that (and I don't know if there are other who 
> > have allready implemented the draft and would be unhappy about the change).
> 
> I'm not really concerned with tag or attribute names: they are largely
> cosmetic, and changing them at this point would be needless trouble for
> you and others.
> 
> > The only thing your proposal have, and that the current draft doesn't have is 
> > spot color, but it's not because I am against, or anyone else, it's just that 
> > I don't know what would be the requirements for defining spot colors, so I 
> > prefer to leave that to other.
> 
> Spot colors were actually the motivating reason for me to design the
> format.  But having somewhat caught up with the discussion I am not as
> satisfied with my solution as I had been.

I'd say a wide gamut reference, like CIE*Lab or CIE*XYZ, is one good 
thing for spots. Out of my head, a name would be the other part.
 
> Setting spot colors aside for the moment, because I need to think about
> them more, there are actually several non-cosmetic differences that I'm
> concerned with:
> 
>  1. The ability to embed an ICC profile in the swatch file itself (as
> base-64 encoded data), rather than requiring the user to distribute it
> as an additional "sidecar" file.  Unless implementations provide a
> convenient way to bundle the profile with the swatches, I do not think
> the color management features of the swatch format will get used.
> 
>  2. Allowance in the schema for including annotations using attributes
> and elements from foreign namespaces, at least in specific places (my
> proposal is perhaps overly generous in this regard).  If the schema
> permitted extensions, it would be possible to include foreign
> annotations in defined places, knowing that all conformant
> implementations which did not understand them would be guaranteed to
> safely ignore them.  This would reduce the need for the main
> specification to support features like spot colors.

But it can become as well a burden to must embedd arbitrary large, 
practical 3kB -> 3MB, ICC profiles. My go would be to have one references, 
ideally one of the ICC deployed PCS', and one or more additional colour 
spaces to allow for native colour descriptions without an absolute need 
for conversions.

>  3. By requiring dependencies (e.g. color spaces) to appear before their
> dependents (e.g. colors), I eliminated the need for forward references,
> which would otherwise have increased implementation complexity and
> precluded pure streaming approaches to parsing.  In my experience,
> forward references are rarely implemented properly by first-generation
> "third party" implementations of a format.  In the case of SVG, it was
> something we had to spend quite a bit of time straightening out when we
> inherited the Sodipodi codebase, and I believe forward references have
> been an issue for librsvg in the past as well.  The added complexity of
> forward references is justified for SVG, but I am less sure that that is
> true of swatch files.
> 
>  4. If we specify a color in a color space with a specific ICC profile,
> we also need to know what rendering intent to use when converting the
> color to other color profiles/models.  In many cases this is going to
> depend on the "use" of the color.  Relative colorimetric is probably the
> most reasonable default, but for certain specific colors other rendering
> intents make more sense (e.g. absolute colorimetric for spot colors in
> some color matching system), and I think it needs to be possible to
> indicate this in the swatch file.

There are only a few reason to have a rendering intent predefined:
* as a transport mechanism for remote rendering.
  good for late binding, e.g. sending a job to a calibrated printer
* for a logo colour, to match the nearest possible in opposite to photos

For instance most engines ignore the profile rendering intent. The most 
obvious reason are the cases for mixing of documents and properties. 
Mixing of rendering intents would easily return nonsense, except of very 
few cases. Imagine a mix of different white points, red near to 
media white or bluish tints. I'd would nearly nowhere mix the absolute 
colorimetric intent with something else.

So practically, making the rendering intent optional and defaulting to 
zero, plus some warning and a small explanation why, like the above, would 
be good to have associated to a rendering intent part in the draft.

> I do not think any of these for adjustments would require significant
> changes to existing parsers.  Thoughts?
> 
> -mental

An other point is to use channel names like the colour space short name 
suggests, e.g. (CIE*) XYZ with X,Y and Z channels. This helps for not 
confusing with other similiar looking representations.

A range per colour space for usual colour values would be a good add 
to the draft for easy adaption. 
Can Cmyk channels go from 0...1 or 0...100?

Comments are as well added to the draft page:
http://create.freedesktop.org/wiki/index.php/Talk:Swatches_-_colour_file_format/Draft
I hope there are not too many disturbing suggestions.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org