On Mon, Jul 7, 2008 at 8:46 PM, James Cloos <cloos@...1016...> wrote:
"Andy" == Andy Fitzsimon <andyfitz@...400...> writes:
[Looks like I'm a bit behind, but anyway... -JimC]
Andy> I guess convert all to display as rgb while screen ( using normal Andy> colour profile ) and then convert all to cmyk on export?
You have the right concept but the wrong colour space.
The lingua franca space should be CIELab. And that is probably also the best space to use in the PDFs.¹ (CIE's LUV and the derived LogLuv spaces are also usable, but PDF has CIELab support, so that wins.)
CIE Lab have no advantage over for instance linear light RGB using for instance the sRGB primaries. It actually has disadvantages as CIE Lab fails to be the perceptually uniform color space it aims to be, and hue shifts are introduced when you move colors towards the neutral axis in the space.
A linear light RGB space with well defined primaries would be based on reality (physics) and not an ad-hoc model trying to describe the subjective human experience of colors. Failing that CIE XYZ could be used, but that provides little meaning.
The components in CIELab either should be either floats (fixed point when compiling on systems which lack hardware floating point) or should be scaled to 16-bit integers for all internal uses, including all math.
CIE lab defines both 8bit and 16bit data types for those components widths.
But yes, you convert everything to a common colour space (colour profiles tell you how) and do the math there.
No, you cannot convert from CMYK to any RGB, CIE Lab, CIE XYZ or similar three dimensionsal color space, and back again to CMYK without losing information contained in the original CMYK buffer. If you were to use a space that could handle this you would have to use a color space that had at least as many dimensions as the highest one in question, (this quickly leads to 32 component multispectral buffers, which most probably is not where we want to be.)
/Øyvind K.