The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Molumen
Well, basically the behaviour is logical. One of the values of CMY should always be 0, because otherwise you can increase the amount of K to get the same result, by decreasing CMY by the the smallest of their values and increasing K by that amount. So that means: It is not logical to have colours, where not at least CM or Y is 0. However, I agree, sometimes they need to be added, becuase some colours are just defined as that.
cheers!
David
On Wed, 2007-07-18 at 17:18 +0200, momo wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Molumen
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This is a very counterproductive behaviour because graphic designers have to deal with predefined colors from graphic manuals or CMYK translations of spot colors (Pantone, RAL, Toyo etc...). If some color combinations cannot be achieved (and it was my case), then it's a major problem for the users.
An example: today I had to deal with C30 M56 Y100 K37 (it is the CMYK translation of Pantone 463C. Well it was impossible to define that color in Inkscape. The same applies for PANTONE 871 C, PANTONE 872 C, PANTONE 873 C etc... Basically any CMYK color that does not contain a 0% in either C, M, Y or K fields is impossible to generate in Inkscape... :(
Molumen
----- Original Message ----- From: "David Christian Berg" <david@...407...> To: "momo" <momo@...1386...> Cc: inkscape-devel@lists.sourceforge.net Sent: Wednesday, July 18, 2007 5:29 PM Subject: Re: [Inkscape-devel] CMYK imput problem
Well, basically the behaviour is logical. One of the values of CMY should always be 0, because otherwise you can increase the amount of K to get the same result, by decreasing CMY by the the smallest of their values and increasing K by that amount. So that means: It is not logical to have colours, where not at least CM or Y is 0. However, I agree, sometimes they need to be added, becuase some colours are just defined as that.
cheers!
David
On Wed, 2007-07-18 at 17:18 +0200, momo wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Molumen
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Found a pantone/cmyk conversion table, it could be useful for testing purposes:
http://www.logoorange.com/color/color-codes-chart.php
Molumen
----- Original Message ----- From: "momo" <momo@...1386...> To: inkscape-devel@lists.sourceforge.net Sent: Wednesday, July 18, 2007 7:11 PM Subject: Re: [Inkscape-devel] CMYK imput problem
This is a very counterproductive behaviour because graphic designers have to deal with predefined colors from graphic manuals or CMYK translations of spot colors (Pantone, RAL, Toyo etc...). If some color combinations cannot be achieved (and it was my case), then it's a major problem for the users.
An example: today I had to deal with C30 M56 Y100 K37 (it is the CMYK translation of Pantone 463C. Well it was impossible to define that color in Inkscape. The same applies for PANTONE 871 C, PANTONE 872 C, PANTONE 873 C etc... Basically any CMYK color that does not contain a 0% in either C, M, Y or K fields is impossible to generate in Inkscape... :(
Molumen
----- Original Message ----- From: "David Christian Berg" <david@...407...> To: "momo" <momo@...1386...> Cc: inkscape-devel@lists.sourceforge.net Sent: Wednesday, July 18, 2007 5:29 PM Subject: Re: [Inkscape-devel] CMYK imput problem
Well, basically the behaviour is logical. One of the values of CMY should always be 0, because otherwise you can increase the amount of K to get the same result, by decreasing CMY by the the smallest of their values and increasing K by that amount. So that means: It is not logical to have colours, where not at least CM or Y is 0. However, I agree, sometimes they need to be added, becuase some colours are just defined as that.
cheers!
David
On Wed, 2007-07-18 at 17:18 +0200, momo wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Molumen
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wednesday, July 18, 2007, 5:29:13 PM, David wrote:
DCB> Well, basically the behaviour is logical. One of the values of CMY DCB> should always be 0,
No, not necessarily.
The amount of grey component replacement need not be always 100%.
DCB> because otherwise you can increase the amount of K DCB> to get the same result, by decreasing CMY by the the smallest of their DCB> values and increasing K by that amount.
They don't necessarily measure as the same colour when you do that.
DCB> So that means: It is not logical to have colours, where not at least CM DCB> or Y is 0. However, I agree, sometimes they need to be added, becuase DCB> some colours are just defined as that.
And there is a reason they are specified that way :)
As I already learnt, the main reason is the conversion. And as we agree, one has to be able to enter different values. However:
DCB> because otherwise you can increase the amount of K DCB> to get the same result, by decreasing CMY by the the smallest of their DCB> values and increasing K by that amount.
They don't necessarily measure as the same colour when you do that.
I don't see why. I mean, if I have C50 M50 Y50 that should be the same as K50 in my understanding. I should be able to replace any Cx Mx Yx with Kx and hence be able to have one CMY value 0 any time. I do know, it's not handled that way, but I don't see much reason for it.
Maybe you can clarify this for me!
Thanks!
David
On Monday, July 23, 2007, 6:08:44 PM, David wrote:
DCB> As I already learnt, the main reason is the conversion. And as we agree, DCB> one has to be able to enter different values. However:
DCB> because otherwise you can increase the amount of K DCB> to get the same result, by decreasing CMY by the the smallest of their DCB> values and increasing K by that amount.
They don't necessarily measure as the same colour when you do that.
DCB> I don't see why.
So I suggest that you print out some patches with varying levels of grey component replacement and measure them. or even just look at them, since the visual result is fairly clear.
DCB> I mean, if I have C50 M50 Y50 that should be the same DCB> as K50 in my understanding.
The problem is that your understanding is using a very simplified model that does not correspond to current practice or to the measured results. I believe I am correct that your model is
C' = (1 - R) M' = (1 - G) Y' = (1 - B)
and then K = min (C', M', Y') C = C' - K M = M' - K Y = Y' - K
which ignores completely different RGB color spaces, different ink sets, dot gain, illuminants, ink density, halftone screening, viewing conditions and so on. In other words, pretty much all of color management.
This is a very common simplification, and I understand you may have seen it listed in a book, but it is very far from the current state of the art and gives very poor results in practice.
DCB> I should be able to replace any Cx Mx Yx DCB> with Kx and hence be able to have one CMY value 0 any time. I do know, DCB> it's not handled that way, but I don't see much reason for it.
DCB> Maybe you can clarify this for me!
I am happy to recommend some books on color theory and color management if that would be helpful.
David Christian Berg wrote:
... I don't see why. I mean, if I have C50 M50 Y50 that should be the same as K50 in my understanding. I should be able to replace any Cx Mx Yx with Kx and hence be able to have one CMY value 0 any time. I do know, it's not handled that way, but I don't see much reason for it.
Maybe you can clarify this for me!
I don't know a lot about this, and if you're interested I recommend taking Chris up on his offer to recommend some books, but one obvious case where it does matter is when colours don't overlap perfectly (or when colours are "mixed" by using dots of varying size and spacing, I don't remember the correct term right now). In these cases the difference between three different colours that blend together and real grey should be quite obvious (especially at the edges).
Do you mean color trapping?
Molumen
----- Original Message ----- From: "Jasper van de Gronde" <th.v.d.gronde@...528...> To: "David Christian Berg" <david@...407...> Cc: inkscape-devel@lists.sourceforge.net Sent: Tuesday, July 24, 2007 10:44 AM Subject: Re: [Inkscape-devel] CMYK imput problem
David Christian Berg wrote:
... I don't see why. I mean, if I have C50 M50 Y50 that should be the same as K50 in my understanding. I should be able to replace any Cx Mx Yx with Kx and hence be able to have one CMY value 0 any time. I do know, it's not handled that way, but I don't see much reason for it.
Maybe you can clarify this for me!
I don't know a lot about this, and if you're interested I recommend taking Chris up on his offer to recommend some books, but one obvious case where it does matter is when colours don't overlap perfectly (or when colours are "mixed" by using dots of varying size and spacing, I don't remember the correct term right now). In these cases the difference between three different colours that blend together and real grey should be quite obvious (especially at the edges).
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
See comments in bug http://sourceforge.net/tracker/index.php?func=detail&aid=1221603&gro...
Scislac: by the way there's unanswered question for you in that bug
On 7/18/07, momo <momo@...1386...> wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Molumen
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jul 18, 2007, at 8:18 AM, momo wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Yes, it's a bit strange since we aren't really storing CMYK at the moment.
However I have been getting closer to unblocking a few parts of the codebase that will allow us to store CMYK values by using the ICC color data numbers.
This should be happening "Real Soon Now"... but is subject to delays due to my family moving back to our home finally, etc. My current guess is somewhere between 2 weeks through 2 months.
Jon,
these are WONDERFUL news. CMYK support combined to the robust PDF import/export that 0.46 devel already features will make Inkscape a fully usable vector graphic software for offset printing!
Can't wait to see that happening!
Thanks for the great news!
Molumen (aka momo)
----- Original Message ----- From: Jon A. Cruz To: momo Cc: inkscape-devel@lists.sourceforge.net Sent: Friday, August 24, 2007 8:53 AM Subject: Re: [Inkscape-devel] CMYK imput problem
On Jul 18, 2007, at 8:18 AM, momo wrote:
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44 M 27 jumps to 0 Y 61 jumps to 47 B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Yes, it's a bit strange since we aren't really storing CMYK at the moment.
However I have been getting closer to unblocking a few parts of the codebase that will allow us to store CMYK values by using the ICC color data numbers.
This should be happening "Real Soon Now"... but is subject to delays due to my family moving back to our home finally, etc. My current guess is somewhere between 2 weeks through 2 months.
On Aug 23, 2007, at 11:53 PM, Jon A. Cruz wrote:
However I have been getting closer to unblocking a few parts of the codebase that will allow us to store CMYK values by using the ICC color data numbers.
This should be happening "Real Soon Now"... but is subject to delays due to my family moving back to our home finally, etc. My current guess is somewhere between 2 weeks through 2 months.
It's in.
(At least initial support)
On Mon, 2007-09-24 at 21:19 -0700, Jon A. Cruz wrote:
On Aug 23, 2007, at 11:53 PM, Jon A. Cruz wrote:
However I have been getting closer to unblocking a few parts of the codebase that will allow us to store CMYK values by using the ICC color data numbers.
This should be happening "Real Soon Now"... but is subject to delays due to my family moving back to our home finally, etc. My current guess is somewhere between 2 weeks through 2 months.
It's in.
(At least initial support)
What does that mean for me? Any testing, that can be done? I'm really waiting for CMYK support _desperately_
Greetings from Spain!
David
participants (7)
-
Alexandre Prokoudine -
bulia byak -
Chris Lilley -
David Christian Berg -
Jasper van de Gronde -
Jon A. Cruz -
momo