On 28 March 2012 18:09, Chris Lilley <[email protected]> wrote: > On Wednesday, March 28, 2012, 6:08:36 PM, Boudewijn wrote: > > BR> Wouldn't it be easier to just define the working space with a > BR> profile in openraster, and take it from there? > > That would be simpler, and more flexible - avoids boxing people in to only > sRGB and linear-sRGB.
It's linearRGB, not linear-sRGB. Is that an intentional loophole, or am I just imagining it? :D Boxing in might not be a problem. We're technically only defining the *compositing* space for display here. Choice of working space for everything else is up to the app (not sure how much use that is, however...) The restrictive reading of what already have: OpenRaster's draft spec already requires the primaries of sRGB when compositing for display because it defines its Porter-Duff ops in terms of SVGCompositing; the concrete bases for which are either SVG1.2Tiny or SVG1.1. 1.2Tiny is sRGB only. SVG1.1Full permits any color space you like, but notes that "[...] in this specification, color interpolation occurs in an RGB color space even if an ICC-based color specification is provided (see ‘color-interpolation’)"). Therefore, convert to "sRGB linear" before compositing if the internal colour space uses different primaries. Liberal reading: Suspect that Porter-Duff separable compositing ops can actually be done sanely with linear tristimulus values in *any* RGB colour space provided src and dst are . But uncertain (here my colour theory ends). This would only get us so far because not all of the compositing ops we could implement are separable, making white point matter. Probably. -- Andrew Chadwick _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
