Issue 18674 - Can't define a CMYK color and keep the same values
Summary: Can't define a CMYK color and keep the same values
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.3
Hardware: PC All
: P3 Trivial with 14 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
: 41948 51262 69105 126550 (view as issue list)
Depends on:
Reported: 2003-08-26 08:48 UTC by Unknown
Modified: 2015-09-25 09:53 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2003-08-26 08:48:54 UTC
If i define in all 1.0. versions a new CMYK color For example C=80, Y=46, M=9, 
K=0 in draw and save the document and reopen it the values for CMYK are changed 
into C=100, Y=100, M=0, K=0. This happens when the Y and M values are both more 
as 0.
Comment 1 wolframgarten 2003-08-26 09:05:19 UTC
Set to new.
Comment 2 wolframgarten 2003-08-26 09:08:24 UTC
This is reproducible in 1.0.3 and in a current internal version. I do
not get 100/100/0/0 as result but the counts are diffferent than the
ones I typed in. They are changed after the dialog is closed.
Reassigned to Christian.
Comment 3 wolframgarten 2003-08-26 10:37:52 UTC
Set target to next build and prio to 3.
Comment 4 clippka 2003-08-26 13:52:57 UTC
thorsten, please have a look
Comment 5 thb 2003-08-28 12:23:44 UTC
This is inevitable, unfortunately, because we store color in RGB internally. The 
circumstance when these changes do happen is when all three color components (CMY) 
are greater than zero. The common value (i.e. the smallest of all three values) is then 
transfered to K. For example, your C=80, Y=46, M=9, K=0 example becomes C=71, Y=37, 
M=0, K=9, because magenta's 9% is moved to key, and the other two components are 
reduced accordingly.

There are plans to have CMYK stored as an internal format, 
too. But this is probably beyond 2.0
Comment 6 thb 2003-09-12 19:16:56 UTC
Comment 7 thb 2005-06-27 16:22:43 UTC
*** Issue 51262 has been marked as a duplicate of this issue. ***
Comment 8 grsingleton 2005-06-27 16:41:40 UTC
Changed OS to All as this issue affects *NIX as well.
Comment 9 mci 2005-07-07 10:56:09 UTC
*** Issue 41948 has been marked as a duplicate of this issue. ***
Comment 10 irneb 2007-02-02 05:49:23 UTC
I've got a similar problem with CMYK in OOo 2.1. I try setting up a company logo
standard colour (Pantone 301C = CMYK 100% / 53% / 16% / 22%) OOo's RGB result is
(0 / 64 / 158) which is much darker than a (more) "true" conversion which gives
(1 / 94 / 168).
When I change back (in OOo) from RGB to CMYK I get a result of (62% / 37% / 0% /
38%) - this is an unacceptable deviation which can easily be seen to be much
darker than the orriginal - the black (or key) is more and all other colours are
less. Why did you go for this implementation?

Converting between RGB and CMYK is very difficult and several methods are
available - all give inconsistent results. The best method is to use ICC
(International Colour Consortium) profiles to convert between colour spaces. So
why not do away with storing to CMYK (for that matter RGB as well). These are
device dependant and will thus appear different on different machines. Even the
same RGB value will look different when printed, and could even look different
on another screen.

I suggest storing in something like CIELAB, the standard of the ICC profiles
which makes it easy to change from any colour space to another (including RGB,
CMY, CMYK, HSV, HSL, LUV, XYZ, LAB, etc.) with very little programming. There is
even an opensource ICC engine , which can then be
incorporated in office - making it a true device INDEPENDENT program.
Comment 11 thb 2007-02-02 08:26:26 UTC
@irneb: your comments make perfectly sense - the reason why we still don't
handle colors != RGB internally is that massive amounts of code need to be
changed. But rest assured that we're aware of the problem, and whenever we
rework code in the graphics subsystem, we abstract away from the color space.
Comment 12 Regina Henschel 2007-07-10 15:56:42 UTC
*** Issue 69105 has been marked as a duplicate of this issue. ***
Comment 13 vollbracht 2007-07-25 20:39:36 UTC
In pre press we need  black, which is  c 50% m 40% y 40% k 100%. Actually, when
defining this, the result is c 0% m 0% y 0% k 100%, which is "not black enough".
Comment 14 irneb 2010-06-21 10:44:23 UTC
As a stop-gap measure, would it be possible to change only the piece of code
which translates RGB to-and-from CMYK? Obviously this is the major problem which
causes the inconsistency. Even if OOo still stores the colour in RGB form, a
more "accurate" conversion method would at least provide a more consistent CMYK
value. It might still deviate slightly, but to such small effect that the
difference wouldn't be discernible by eye.

As for the "more-black-than-black" colours, this would only be possible using a
different colour storage method. I even think only CMYK has this ability, which
is actually defining a colour which "doesn't exist". The reason behind these
colours are usually to force a printer to use all 4 its inks when creating
black, usually to compensate for the black ink dye being a bit too gray.

In this case we generally don't adjust for such in the documents. We adjust the
printer's settings using colour correction methods. If you know the black comes
out too washed out, the printer needs to be adjusted either mechanically (by
using blacker ink) or through software (using colour correction in the driver).
But then, that's because we own our own large format printers. When you have to
rely on some outside printer service, you don't have this option. I would advise
however, that you use some other type of program for pre-press ... maybe
something like a DTP (search for Scribus)?
Comment 15 vollbracht 2010-06-23 12:38:44 UTC
The conversion from CMY to CMYK as described in
(link from wikipedia) leads to this problem. What about converting as follows:


R = maximum((1 - C + (CONST_C - 1) K), 0) * 255
G = maximum((1 - M + (CONST_M - 1) K), 0) * 255
B = maximum((1 - Y + (CONST_Y - 1) K), 0) * 255


cmy_C = 1 - (R / 255)
cmy_M = 1 - (G / 255)
cmy_Y = 1 - (B / 255)
K = minimum(cmy_C, cmy_M, cmy_Y)
C = cmy_C + (CONST_C - 1) K
M = cmy_M + (CONST_M - 1) K
Y = cmy_Y + (CONST_Y - 1) K

where CONST_C, CONST_M and CONST_Y must be in range from 0 to 1. They might be
configurable dependant on pre press demands. If most brilliant black is
CMYK(0.5/0.4/0.4/1.0) we have to choose CONST_C as 0.5 or 50% and so on.
CMYK values that whould result in a colour more black than the most brilliant
black are changed accordingly.
Comment 16 irneb 2010-06-23 15:04:39 UTC
The problem would still be that the OD# file saves the colour as RGB values. So
this then needs to be exported into a file type which has CMYK abilities
(something like PDF, JPG or TIFF). In which case you can use a PDF Printer
driver (seeing as OOo's PDF export doesn't do CMYK) and apply one of the CMYK
ICC profiles to this driver. You could even obtain the ICC profile specific to
the printer you intend sending it to (hopefully the print-shop or whatever has
such :) ).

The ICC profile can be seen as the formula you suggest with a varying constant.
Depending on the darkness of the colour the constant might need to increase /
decrease. This is accomplished in the profile by having certain sample colours
with near exact matching coordinated values in the target space. The colours in
between then gets extrapolated, so the more samples the more accurate.

As I've stated there is a open source ICC engine available
( which has a reasonably simple way of sending an RGB
value and obtaining another colour space value as result. In their tutorial they
even have a sample of how to convert a BMP between RGB->CMYK and CMYK->RGB.
Comment 17 vollbracht 2010-06-24 14:10:09 UTC
My suggestion was not intended to be a proper solution but merely a work around
for the fact that OOo is an rgb based software.
Its colour range so far is from cmyk(0 / 0 / 0 / 1) to cmyk(0 / 0 / 0 / 0). It
might be a good idea to express these limitations in the corresponding dialogue.
If done so, it would be quite sufficient to accept that entered values slightly
differ from those that are transformed to and back from rgb. But still the
limitation of colour range is ugly and should be configurable. So my wish would
be: Having a simple standard transform with cmyk2rgb( rgb2cmyk( Colour A)) is
always Colour A and rgb2cmyk( cmyk2rgb( Colour B)) is close to Colour B as long
as Colour B is in the configured range from let's say cmyk(0.5 / 0.4 / 0.4 / 1)
to cmyk(0 / 0 / 0 / 0). An additional plug in based on "little cms" might be fine.
Comment 18 thb 2012-07-13 20:51:23 UTC
Reset to default assignee.
Comment 19 oooforum (fr) 2015-09-25 09:53:21 UTC
*** Issue 126550 has been marked as a duplicate of this issue. ***