On Friday, June 20, 2008, 2:24:20 PM, Louis wrote:
LD> Øyvind Kolås a écrit :
On Fri, Jun 20, 2008 at 4:25 AM, Andy Fitzsimon <andyfitz@...400...> wrote:
Its a really tricky question when blending from multiple colour spaces.. I guess convert all to display as rgb while screen ( using normal colour profile ) and then convert all to cmyk on export? I'm no expert.
The problem is that by converting the colors from CMYK to RGB you reduce the dimensionality, different CMYK color will map to the same RGB triplets, thus you do not preserve color fidelity in this transformation. CMYK -> RGB -> CMYK, most probably do not lead to the original CMYK values (unless they've already been "normalized" by a similar conversion first.)
Correct.
Mixing of RGB is well defined for CMYK on the other hand things are a bit murkier since the color resulting from mixing two CMYK values depends on the inks used, the paper used and other physical attributes.
Yes. As soon as mixing (compositing) is involved, then we need to be in an additive colour space. Although, detecting those regions which are not composited and preserving the CMYK values (same for spot colors) there is still worthwhile.
GEGL currently makes the assumption that it is doing compositing of light, and it considers CMYK to be something to be done at export. Essentially it doesn't support native CMYK processing but allows color managed workflows optimized for RGB inputs, accepting CMYK inputs with the color precision loss, with the ability to then tweak and tune the separation of CMYK on the final composite (or leave it to a DTP or similar program that decides what to do with well defined RGB data.)
For GEGL I think this assumption is a valid one for now, but for cairo to go down this route seems more wrong, it would probably be more natural to convert RGB to CMYK to avoid losing the dimensionality of the colors.
LD> Agree. Converting back from CMYK to RGB seems to me the wrong route too. LD> CMYK is an end-station. It exists only for print and there is no real LD> use of making this conversion back to RGB, at least from my experience. LD> If anyone needs a RGB version, the original images still exist in that LD> color space and it is advisable to use those originals.
LD> Also, if we are to work in CMYK for a composition where we need to LD> actually put in the precise values for each plate, then it is with a LD> clear intention of getting a specific resulting color on press. This is LD> why some people insist so much on having full control on CMYK. But LD> again, going from such specified CMYK color to RGB would not make much LD> sense, imo.
And this is precisely why SVG
- allows optional CMYK colors - requires those colours, if specified, to say what device they are for (calibrated ICC CMYK, for a specific ink set, paper and press) - requires a fallback sRGB be provided.
An alternative, allowing specification in CMYK only and having the user agent dream up some RGB simulation, was not even seriously considered since its so obviously a poor solution.