[CREATE] assets library

Kai-Uwe Behrmann ku.b at gmx.de
Wed Sep 26 03:51:28 PDT 2007


> Date: Tue, 25 Sep 2007 21:25:55 +0200
> From: Craig Bradney

> <color space="rgb" r="1" g="2" b="3" name="123color" spot="false" 
> registration="false">

I would add a reference here. "rgb" can be everything, especially across 
computers.


> Date: Tue, 25 Sep 2007 19:15:01 -0300
> From: "Joao S. O. Bueno Calligaris"

> Why not:
> <space name="rgb">
> <color r="1" b="0.5" c="0.33333" name=... />
> <color r="1.0" b="1.0" c="0.33333" name=... />
> </space>

Grouping seems a good idea to me.

> <space name="RGB">
>   <color name="blue"><r>0.0</r><g>0.0</g><b>1.0</b></color>
> </space>

It would be easier to parse, but I am not shure about the style.
 

> Date: Wed, 26 Sep 2007 09:05:32 +0200
> From: Sven Neumann
 
> Conceptually, the color space is an attribute that describes how a color
> is specified, thus it should be an attribute of the color.
> 
> On the other hand, the color space also defines what attributes are
> allowed to define the color. The current proposal allows things like
> 
>  <color space="rgb" h="8" s="9" v="10" name="8910color">
> 
> which would be undefined. Of course one can explicitely disallow this in
> the spec. But you can't express this rule in a DTD, so you cannot easily
> catch it by validation.

Good to have someone with XML knowledge.
 
> I'd vote for something like the following:
> 
>  <color><rgb r="0.23" g="0.42" b="1.0" /></color>
> 
> It is better defined because the colorspace defines its attributes. Also
> you will note that the color values are floating point numbers between
> 0.0 and 1.0. The other examples that I have seen so far used integers
> without actually defining the range of them anywhere.

Good point. We will see more value range dependent things in the future I 
guess, because of HDR becoming more and more popular.

Are the language specifics be allowed for floating point values? Or are 
floats always be defined to english x.x notation?
 
> I also doubt that RGB should be used in such a document without
> specifying it. sRGB would probably be an option. Perhaps the spec should
> predefine a few common color spaces such as sRGB and also allow other
> color spaces to be introduced by specifying a color profile.

Agreed.

> From: "Tor Lillqvist" <tml at iki.fi>
> Subject: Re: [CREATE] assets library

> > > <space name="RGB">
> > >   <color name="blue"><r>0.0</r><g>0.0</g><b>1.0</b></color>
> > > </space>
> > >
> > > It might look verborragic..but then...why go XML anyway?
> 
> I am not an XML expert either, but isn't the above in principle wrong?
> If the colour space name is the value of an attribute, that then means
> that the format in principle should work for any random colour space.
> Then how can there be elements (which after all should be predefined
> in some DTD or whatever) called r, g and b? Wouldn't a more correct
> form be (even more verbose) like:
> 
> <space name="RGB">
>   <color name="blue">
>     <component name="R" value="0" />
>     <component name="G" value="0" />
>     <component name="B" value="1" />
>   <color>
> </space>
> 
> or a bit less verbose:
> 
> <space name="RGB">
>   <color name="blue">0 0 1</color>
> </space>

Despite my lesser XML knowledge, this example would at least allow 
arbitrary colour channels.

How about alpha? I can't think a colour without it. Some applications want 
even more information. 
I can imagine users, who save theyre colour and expect it appears the 
same on opening. They would wonder when alpha is omitted. An then there 
are even more attributes like alpha possible and used.



An other idea for a newly created format is to use the ICC colour space 
signatures. They are already defined and widely used (big endian 
notation taken from icc34.h distributed with littleCMS):
    icSigXYZData                        = 0x58595A20L,  /* 'XYZ ' */
    icSigLabData                        = 0x4C616220L,  /* 'Lab ' */
    icSigLuvData                        = 0x4C757620L,  /* 'Luv ' */
    icSigYCbCrData                      = 0x59436272L,  /* 'YCbr' */
    icSigYxyData                        = 0x59787920L,  /* 'Yxy ' */
    icSigRgbData                        = 0x52474220L,  /* 'RGB ' */
    icSigGrayData                       = 0x47524159L,  /* 'GRAY' */
    icSigHsvData                        = 0x48535620L,  /* 'HSV ' */
    icSigHlsData                        = 0x484C5320L,  /* 'HLS ' */
    icSigCmykData                       = 0x434D594BL,  /* 'CMYK' */
    icSigCmyData                        = 0x434D5920L,  /* 'CMY ' */
    icSig2colorData                     = 0x32434C52L,  /* '2CLR' */
    icSig3colorData                     = 0x33434C52L,  /* '3CLR' */
    icSig4colorData                     = 0x34434C52L,  /* '4CLR' */
    icSig5colorData                     = 0x35434C52L,  /* '5CLR' */
    icSig6colorData                     = 0x36434C52L,  /* '6CLR' */
    icSig7colorData                     = 0x37434C52L,  /* '7CLR' */
    icSig8colorData                     = 0x38434C52L,  /* '8CLR' */
    icSig9colorData                     = 0x39434C52L,  /* '9CLR' */
    icSig10colorData                    = 0x41434C52L,  /* 'ACLR' */
    icSig11colorData                    = 0x42434C52L,  /* 'BCLR' */
    icSig12colorData                    = 0x43434C52L,  /* 'CCLR' */
    icSig13colorData                    = 0x44434C52L,  /* 'DCLR' */
    icSig14colorData                    = 0x45434C52L,  /* 'ECLR' */
    icSig15colorData                    = 0x46434C52L,  /* 'FCLR' */


Some related file format specifications:
CSS3: http://www.w3.org/TR/css3-color/
SVG:  http://www.w3.org/TR/SVG/color.html
Can someone with according knowledge comment? Possibly from 
Inkscape with theire native SVG support or ...


Will the adoption of one of the above specs meet our needs. Sorry if 
this idea was already rejected.



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



More information about the CREATE mailing list