[cairo] [RFC] Color space API (partial proposal)
Kai-Uwe Behrmann
ku.b at gmx.de
Sun Feb 28 03:45:53 PST 2010
Am 26.02.10, 22:41 -0800 schrieb Jon Cruz:
> On Feb 25, 2010, at 11:18 AM, Chris Murphy wrote:
>> The Hexachrome workflow, with six primaries, is challenging even with existing professional applications so I'd get the CMYK + spot stuff working before even considering 5+ channel color separations with DeviceN output profiles.
>
> As a minor note, my general preference would be to start by defining an API that could support CMYK *and* CMYKOG or CcMmYK, both with additional spot ink/emboss/etc channels.
I like that gernerical approach very much.
>> From a software engineering standpoint that would help removed the hardcoded assumption of "cmyk*" in the names and in the implementation (I'm wondering if "process plus spot" would make a better description than "cmyk plus spot". etc). It seems clear by this point that color channels will fall into either one of two groups: the process set and individual spots. *If* it were easy to craft a solution without the process==4 hardcoded assumption, that would be nice.
More than 4 cannel printing is since some time really main stream for
photographers. Package printing is going up to 12 channels on press. Multi
spectral commercial imaging workflow(s) have even higher requirements. It
would be nice for later implementors to support that at some point without
the need to add new APIs.
> However, I do agree that it were to be too much work, then deferring that 'till later is entirely reasonable.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo
mailing list