[CREATE] Swatches: Proposition J

[Cyrille Berger]

On Monday 23 June 2008, you wrote:
> 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.

Yes that would be a good solution. I also wonder if we shouldn't impose sRGB 
to be defined. I thought it was the case, but rereading the space, it appears 
it is optional.

>  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.
 I must say for that the same reason as Kai-Uwe, I don't like the idea of 
embedding binary blobs into XML. 
There are a few ideas about this:

* Jon Cruz's idea of a more general swatch format (for gradients...). That 
could be used, in the future, for transporting a color swatch with its icc 
profiles
* url for downloading (rights and security issues ?)


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

Yes definitively.

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

Yes I agree. It's also needed for type of colorspaces, in Krita, we have some 
color spaces, that are not yet used (and might never be) in other 
applications, it wouldn't make sense to have them in the spec (until other 
applications are interested). And, HDR support could also be an extension.

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

Shouldn't it be the choice of the user ? Even if, I guess, it could be usefull 
in case of multiple color representation, to specify the rendering intents 
that was used to generate that specific color.

-- 
Cyrille Berger