[CREATE] Remaining issues for the color spec and future plan

[Chris Lilley]

On Friday, December 7, 2007, 9:50:50 AM, Cyrille wrote:

CB> Hello,

CB> For reference the draft is located at [2]

CB> == Future plan

CB> I think the spec should remained as a "draft" until the first application that
CB> use it is released, and at that time we would release version 1.0.

CB> == Remaining issues
CB> There are a few open points that needs to be addressed :

CB> Blocking issues:
CB> * channel and type. We haven't really decide between float and integers. Or
CB> more like should we allow integer. I can't see any usecase for allowing
CB> integer, but maybe someone has ?

If you allow two types then there is a need for ensuring you get the right one. People may be used to mostly integer values now but that will change over time; going for floats now is better for the future and they can always be rounded to integers if needed.

CB> * range of colors. There is also the problem of range. In case of float,
CB> should we allways limit to [0, 1.0]

No. For color spaces with a restricted gamut such as sRGB there are plenty of real-world colors which require one or more channels to take slightly negative and/or slightly greater than 1.0 values. Once converted to the target colorspace (eg for print, or even to AdobeRGB1998) they are once again in gamut ie in the range [0, 1.0]
 
CB>  (for HDR see bellow) ?
CB> There is also the case of LAB. It's usually ranged like this L in [0 ; 100], a
CB> nd b in [-125; 125], in case of integer should we use those range ? And in
CB> case of float should we use the [0, 1.0] range or L in [0, 1.0] and a and b
CB> in [-0.5 ; 0.5 ] ?

I would want to check the theoretical maximum of a and b; I suspect +- 125 is a 'covers most cases' not a 'covers all cases' value.

CB> Not blocking issues:
CB> * spot colors, there is nothing currently in the draft, and I have no idea of
CB> what is needed, seeing [1] it sounds like it's a matter of adding "Register"
CB> and "Spot" element, to either the color tag or the rgb, srgb, cmyk, ...
CB> elemets. Can someone with knowledge about spot colors comment on this ?

That is pretty much what is required, yes.

CB> * extra information like alpha

And clarify that colors are not premultiplied (to avoid precision loss). As soon as alpha is added, some folks will assume all colors are premultipied :0

CB> * HDR support, that need to be discuss, but for the way Krita currently select
CB> colors in HDR (which is similar to [3]), colors are selected in LDR mode then
CB> the current "luminance" is applied to the color to compute the HDR color.
CB> That means that for the color spec, if we allow the color range to be [0.0 ,
CB> infinity [ , there will be a problem for Krita to know if a color in the
CB> [0.0, 1.0] range is intented to be an HDR color to be use directly like this,
CB> or an LDR color.
CB> There are two options for this :
CB>  - add an attribute to the color that say the user wanted that color to be HDR
CB>  - limit the range to [0.0, 1.0] and add a luminance element that can then be
CB> applied to the color
CB> The main advantage of the second option is that the color has also a meaning
CB> for LDR images.

I generally prefer explicit labelling. For one thing, 0 may not mean the same thing for an HDR image and for a LDR image, where there is no footroom (ie black point compensation has already been added). So no objection to a structure that allows an HDR color to be used as an LDR color but it might not be as simple as a scaling.

CB> [1] http://documentation.scribus.net/index.php/Spot_Colors
CB> [2] 
CB> http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Draft
CB> [3] http://graphics.cs.ucf.edu/HDRPaint/index.php




-- 
 Chris Lilley                    mailto:chris at w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG