Hi,
Carl Worth has just told me they've got people who could work on CMYK support in Cairo, but they still need someone to tell them what exactly end-user applications want Cairo to do.
It seems to me that we want two things:
1) optional output to CMYK PDF/PS/EPS 2) separation preview
What Carl now says is:
"(1) would probably be a good place to start. But I still have questions about how inkscape would like this to work. Particularly, with regard to what colorspace(s) inkscape would like to use to provide color values to cairo. What colorspace(s) would be used for blending. What to do with source colors from multiple spaces, etc."
Do we want to use this chance to wet our toes in prepress waters? ;-)
Alexandre
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.
Both Bulia and JonCruz would have a much better idea of how we want to talk to cairo and show it to our users.
Any idea guys?
-Andy
On Fri, Jun 20, 2008 at 1:17 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
Hi,
Carl Worth has just told me they've got people who could work on CMYK support in Cairo, but they still need someone to tell them what exactly end-user applications want Cairo to do.
It seems to me that we want two things:
- optional output to CMYK PDF/PS/EPS
- separation preview
What Carl now says is:
"(1) would probably be a good place to start. But I still have questions about how inkscape would like this to work. Particularly, with regard to what colorspace(s) inkscape would like to use to provide color values to cairo. What colorspace(s) would be used for blending. What to do with source colors from multiple spaces, etc."
Do we want to use this chance to wet our toes in prepress waters? ;-)
Alexandre
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.)
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. 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.
/Øyvind K.
Ø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.)
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. 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.
Agree. Converting back from CMYK to RGB seems to me the wrong route too. CMYK is an end-station. It exists only for print and there is no real use of making this conversion back to RGB, at least from my experience. If anyone needs a RGB version, the original images still exist in that color space and it is advisable to use those originals.
Also, if we are to work in CMYK for a composition where we need to actually put in the precise values for each plate, then it is with a clear intention of getting a specific resulting color on press. This is why some people insist so much on having full control on CMYK. But again, going from such specified CMYK color to RGB would not make much sense, imo.
Louis
/Øyvind K.
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.
"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.)
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.
But yes, you convert everything to a common colour space (colour profiles tell you how) and do the math there.
-JimC
1] If the user supplies an output colour profile, you can convert the CIELab to that and use DeviceCMYK. (Or DeviceRGB if the output profile happens to specify that it is an RGB output profile.)
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.
"Øyvind" == Øyvind Kolås <pippin@...85...> writes:
Øyvind> CIE Lab have no advantage over for instance linear light RGB using for Øyvind> instance the sRGB primaries. It actually has disadvantages as CIE Lab Øyvind> fails to be the perceptually uniform color space it aims to be, and Øyvind> hue shifts are introduced when you move colors towards the neutral Øyvind> axis in the space.
Perceptually uniform is better, yes, but I question converting to *any* RGB space when the output is to be reflective. It might be OK for flex when printing transparent/translucent labels, but for printing on opaque surfaces???
Øyvind> A linear light RGB space with well defined primaries would be Øyvind> based on reality (physics) and not an ad-hoc model trying to Øyvind> describe the subjective human experience of colors. Failing that Øyvind> CIE XYZ could be used, but that provides little meaning.
That model, empirically, works. And the point of the question was to support the needs of the prepress community.
Øyvind> No, you cannot convert from CMYK to any RGB, CIE Lab, CIE XYZ or Øyvind> similar three dimensionsal color space, and back again to CMYK Øyvind> w/o losing information contained in the original CMYK buffer.
The fact that we only have three cones implies that any colour differences found in a CMYK file can be represented in XYZ and 3D spaces derrived therefrom, even if the raw math seems to loose data.
It is always healthy to look at things from several viewpoints and to debate, but inkscape really shouldn't convert to RGB internally except when the output is to be RGB.
Personally, I've come to like LogLuv as a working space:
http://en.wikipedia.org/wiki/Logluv_TIFF http://www.anyhere.com/gward/papers/jgtpap1.pdf http://www.anyhere.com/gward/pixformat/tiffluv.html
(Given that vector art will likely only /specify/ a small number of colours--as opposed to caculate, as in gradients, filters and such-- I'd use the full 48-bit version of logLuv for calculations, colour dialogs, etc. The 32-bit or 24-bit versions are better for photos and other raster art.)
-JimC
In Estonia, CMYK is mostly used for prepress, as almost everywhere. Spot colors are also used quite a lot. But I have never heard of anybody using CIE Lab or whatever else.
Øyvind> No, you cannot convert from CMYK to any RGB, CIE Lab, CIE XYZ or Øyvind> similar three dimensionsal color space, and back again to CMYK Øyvind> w/o losing information contained in the original CMYK buffer.
The fact that we only have three cones implies that any colour differences found in a CMYK file can be represented in XYZ and 3D spaces derrived therefrom, even if the raw math seems to loose data.
You are right about the fact, that CMYK _color_ can be represented using 3D color map. But you have to agree that some information gets unrecoverably lost. I will show this with a little example. Lets say we have solid background of cmyk(50,20,10,0) and we print black text on it. As Inkscape has no "Black overprint" option yet, we have to do it using right text color of cmyk(50,20,10,100). When you look at color separations, no letter cutouts should be visible. Now imagine the text color got converted to RGB, it ends up as rgb(0,0,0), which is correct representation on screen (when using color profiles, then not). When you convert it back to CMYK, you never know what it ends up like, whether cmyk(0,0,0,100); cmyk(96,78,89,100) or something else, definitely not original cmyk(50,20,10,100).
It is always healthy to look at things from several viewpoints and to debate, but inkscape really shouldn't convert to RGB internally except when the output is to be RGB.
In my humble opinion all effects and whatsoever manipulates colours, should use objects original colourspace, whenever possible. If not, then some fallback colorspace, but effect writers should be allowed to implement several algorithms for as many colour spaces they want, to preserve information. When fallback space ise used, the completion notice (on statusbar) should state it clear.
All the best Mattias
On Wed, Jul 9, 2008 at 8:17 AM, Mattias wrote:
In my humble opinion all effects and whatsoever manipulates colours, should use objects original colourspace, whenever possible. If not, then some fallback colorspace, but effect writers should be allowed to implement several algorithms for as many colour spaces they want, to preserve information. When fallback space ise used, the completion notice (on statusbar) should state it clear.
I'd like to point out that one of most irritating things about AI is that in CMYK mode all SVG filters are off, because they require RGBA. This is definitely not something we want in Inkscape for e.g. imported CMYK bitmaps ;-)
Alexandre
participants (7)
-
Alexandre Prokoudine -
Andy Fitzsimon -
Chris Lilley -
James Cloos -
Louis Desjardins -
Mattias -
Øyvind Kolås