CMYK

CMYK

Post by robert » Sun, 22 Jun 2003 12:45:24



A little while ago someone posted a question about why CMYK support is
absent from the gimp.  Speculation was it due to some patent issues.  I
now think (but IANAL) there is not patent.  Here's why.

Quite by accident I found the netpbm set of programs (runs on both *nix
and windows, free; windows version requires some additional free software
I think).  One of the programs included in this is
pnmtotiffcmyk, which as the name suggests, will convert pnm files (which
gimp can write directly) to a cmyk tiff file.

How well it does this I can't say since I've never needed it.  However,
the fact this program is freely available in the U.S. leads me to believe
that if there was a patent, the program would have been pulled (the netpbm
programs apparently have been around since at least 1997; not sure when
pnmtotiffcmyk was added).

Since the netpbm programs are gpl, someone with better coding
skills than I could write a plug-in (using the code from netpbm) to allow
gimp to save files directly into cmyk and end this longstanding gimp
short-coming.

BTW, the programs can also convert other file formats to pnm.  Since the
programs are command line, they can be used for mass coversions of one
type of file format to another.

 
 
 

CMYK

Post by Dave Near » Sun, 22 Jun 2003 19:04:08


On Sat, 21 Jun 2003 03:45:24 GMT, robertS said:

Quote:> Since the netpbm programs are gpl, someone with better coding
> skills than I could write a plug-in (using the code from netpbm) to allow
> gimp to save files directly into cmyk and end this longstanding gimp
> short-coming.

This shows something of a lack of understanding as to what CMYK
offers (as does the whole patent discussion).

For the record, CMYK is an additive colourspace representation.
That basically means that any colour can be constituted by adding
components of Cyan, Magenta, Yellow and blacK, where each of
those is on a scale of 0 to 1 (0 being the absence of that
element, 1 being the maximum possible). And that's it. There are
several simple formulae for converting from RGB to CMYK, each of
which are equally as useful (or useless) as the other.

As an example, one such formula is

K = min(1 - R, 1 - G, 1 - B)
C = 1 - R - K
M = 1 - G - K
Y = 1 - B - K

Saving an RGB image as CMYK is as simple as applying any one of
these formulae to the RGB data. But that's not the point.

RGB is not a device independant colourspace. Anyone who's used
the gimp to retouch digital photos and printed the result knows
this. Particularly on a cheap monitor (like mine) you get bluish
tints on everything, or flushed colours, or orange skin, or
whatever (the effect will vary from one screen to another).

Nor is CMYK, as can be seen from its simple relationship with RGB
above.

The benefit of CMYK is that it allows you to calibrate for your
output device (printer), since your printer uses 4 colours, Cyan,
Magenta, Yellow and Black. So saving as CMYK is about as useful
as saving in RGB - CMYK gets useful when you are modifying the
channels to get better colours from a printer. Thus, to do that
you'd still need to have another application that allowed you to
work in CMYK (or, indeed, to work in a device independant colour
scheme like CIE, and convert to CMYK just for calibration at the
end) after saving your image in whatever colourspace you're
using.

For the record, most people don't need CMYK native colourspace
support - and many people who think they might use/need it don't
know what it is. Also, just so ye know, GeGL doesn't
automatically give CMYK, RGB, La*b* or any other colourspace
support - it offers a framework for each of those to be added to
the core of the GIMP more easily. Which isn't the same thing at
all :)

Cheers,
Dave.

--
                David Neary,
        E-Mail: bolsh at gimp dot org
   Work e-mail: d dot neary at phenix dot fr
CV: http://www.redbrick.dcu.ie/~bolsh/CV/CV.html

 
 
 

CMYK

Post by rtt » Sun, 22 Jun 2003 20:56:56




Quote:> On Sat, 21 Jun 2003 03:45:24 GMT, robertS said:
> > Since the netpbm programs are gpl, someone with better coding
> > skills than I could write a plug-in (using the code from netpbm) to
allow
> > gimp to save files directly into cmyk and end this longstanding gimp
> > short-coming.

> This shows something of a lack of understanding as to what CMYK
> offers (as does the whole patent discussion).

> For the record, CMYK is an additive colourspace representation.
> That basically means that any colour can be constituted by adding
> components of Cyan, Magenta, Yellow and blacK, where each of
> those is on a scale of 0 to 1 (0 being the absence of that
> element, 1 being the maximum possible). And that's it. There are
> several simple formulae for converting from RGB to CMYK, each of
> which are equally as useful (or useless) as the other.

> As an example, one such formula is

> K = min(1 - R, 1 - G, 1 - B)
> C = 1 - R - K
> M = 1 - G - K
> Y = 1 - B - K

could you explain please? could you give a concrete sample?
thx
 
 
 

CMYK

Post by robert » Mon, 23 Jun 2003 03:05:20


While your explaination of CMYK is informative, you missed the point of
this paragraph.  Some printers will refuse any graphic not in CMYK format.
That's their policy.  Since Gimp can't output to any CMYK format, people
who might have used Gimp have to look elsewhere (photoshop anyone?).  If
Gimp could at least save to this format, it would help get Gimp into
places it can't go.

And this, IMHO, would be overall a good thing.  The bigger the "market"
for a product, the more support the product gets.  Ever seen a print Gimp
magazine?  There is one for Photoshop.  There are many more Photoshop
tutorials out there than for Gimp.  Perhaps a bigger market would even
help attract more coders, improving Gimp even more for the rest of us.
Hardware support could also increase (esp. on Linux), and that's good for
all of us too.


> On Sat, 21 Jun 2003 03:45:24 GMT, robertS said:
>> Since the netpbm programs are gpl, someone with better coding skills
>> than I could write a plug-in (using the code from netpbm) to allow gimp
>> to save files directly into cmyk and end this longstanding gimp
>> short-coming.

> This shows something of a lack of understanding as to what CMYK offers
> (as does the whole patent discussion).

> For the record, CMYK is an additive colourspace representation. That
> basically means that any colour can be constituted by adding components
> of Cyan, Magenta, Yellow and blacK, where each of those is on a scale of
> 0 to 1 (0 being the absence of that element, 1 being the maximum
> possible). And that's it. There are several simple formulae for
> converting from RGB to CMYK, each of which are equally as useful (or
> useless) as the other.

> As an example, one such formula is

> K = min(1 - R, 1 - G, 1 - B)
> C = 1 - R - K
> M = 1 - G - K
> Y = 1 - B - K

> Saving an RGB image as CMYK is as simple as applying any one of these
> formulae to the RGB data. But that's not the point.

> RGB is not a device independant colourspace. Anyone who's used the gimp
> to retouch digital photos and printed the result knows this.
> Particularly on a cheap monitor (like mine) you get bluish tints on
> everything, or flushed colours, or orange skin, or whatever (the effect
> will vary from one screen to another).

> Nor is CMYK, as can be seen from its simple relationship with RGB above.

> The benefit of CMYK is that it allows you to calibrate for your output
> device (printer), since your printer uses 4 colours, Cyan, Magenta,
> Yellow and Black. So saving as CMYK is about as useful as saving in RGB
> - CMYK gets useful when you are modifying the channels to get better
> colours from a printer. Thus, to do that you'd still need to have
> another application that allowed you to work in CMYK (or, indeed, to
> work in a device independant colour scheme like CIE, and convert to CMYK
> just for calibration at the end) after saving your image in whatever
> colourspace you're using.

> For the record, most people don't need CMYK native colourspace support -
> and many people who think they might use/need it don't know what it is.
> Also, just so ye know, GeGL doesn't automatically give CMYK, RGB, La*b*
> or any other colourspace support - it offers a framework for each of
> those to be added to the core of the GIMP more easily. Which isn't the
> same thing at all :)

> Cheers,
> Dave.

 
 
 

CMYK

Post by Leonard Even » Mon, 23 Jun 2003 04:43:55



> While your explaination of CMYK is informative, you missed the point of
> this paragraph.  Some printers will refuse any graphic not in CMYK format.
> That's their policy.  Since Gimp can't output to any CMYK format, people
> who might have used Gimp have to look elsewhere (photoshop anyone?).  If
> Gimp could at least save to this format, it would help get Gimp into
> places it can't go.

I think you may be missing the point.  Given that there are simple
formulas for converting from RGB to CMYK, doing so is essentially
trivial.  I am sure I could write a simple program to do it if I went to
the trouble of finding out about the relevant file formats.

The problem, I think, is that one wants to look at the image on the
screen and be able to manipulate the four channels directly and examine
the results before saving it.  I was under the impression that the
reason the Gimp doesn't have that capability is that it would require a
major change in the basic architecture of the program.

> And this, IMHO, would be overall a good thing.  The bigger the "market"
> for a product, the more support the product gets.  Ever seen a print Gimp
> magazine?  There is one for Photoshop.  There are many more Photoshop
> tutorials out there than for Gimp.  Perhaps a bigger market would even
> help attract more coders, improving Gimp even more for the rest of us.
> Hardware support could also increase (esp. on Linux), and that's good for
> all of us too.


>>On Sat, 21 Jun 2003 03:45:24 GMT, robertS said:

>>>Since the netpbm programs are gpl, someone with better coding skills
>>>than I could write a plug-in (using the code from netpbm) to allow gimp
>>>to save files directly into cmyk and end this longstanding gimp
>>>short-coming.

>>This shows something of a lack of understanding as to what CMYK offers
>>(as does the whole patent discussion).

>>For the record, CMYK is an additive colourspace representation. That
>>basically means that any colour can be constituted by adding components
>>of Cyan, Magenta, Yellow and blacK, where each of those is on a scale of
>>0 to 1 (0 being the absence of that element, 1 being the maximum
>>possible). And that's it. There are several simple formulae for
>>converting from RGB to CMYK, each of which are equally as useful (or
>>useless) as the other.

>>As an example, one such formula is

>>K = min(1 - R, 1 - G, 1 - B)
>>C = 1 - R - K
>>M = 1 - G - K
>>Y = 1 - B - K

>>Saving an RGB image as CMYK is as simple as applying any one of these
>>formulae to the RGB data. But that's not the point.

>>RGB is not a device independant colourspace. Anyone who's used the gimp
>>to retouch digital photos and printed the result knows this.
>>Particularly on a cheap monitor (like mine) you get bluish tints on
>>everything, or flushed colours, or orange skin, or whatever (the effect
>>will vary from one screen to another).

>>Nor is CMYK, as can be seen from its simple relationship with RGB above.

>>The benefit of CMYK is that it allows you to calibrate for your output
>>device (printer), since your printer uses 4 colours, Cyan, Magenta,
>>Yellow and Black. So saving as CMYK is about as useful as saving in RGB
>>- CMYK gets useful when you are modifying the channels to get better
>>colours from a printer. Thus, to do that you'd still need to have
>>another application that allowed you to work in CMYK (or, indeed, to
>>work in a device independant colour scheme like CIE, and convert to CMYK
>>just for calibration at the end) after saving your image in whatever
>>colourspace you're using.

>>For the record, most people don't need CMYK native colourspace support -
>>and many people who think they might use/need it don't know what it is.
>>Also, just so ye know, GeGL doesn't automatically give CMYK, RGB, La*b*
>>or any other colourspace support - it offers a framework for each of
>>those to be added to the core of the GIMP more easily. Which isn't the
>>same thing at all :)

>>Cheers,
>>Dave.

--

Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208
 
 
 

CMYK

Post by robert » Mon, 23 Jun 2003 05:34:09


Maybe this next statement will should how lacking my programing skills are
(and my understanding of CMYK), but I really have to wonder how difficult
adding that would be.  Already you can decompose an image into several
formats, including CMYK, manipulate them individually, and later
re-compose the image.  How difficult then is it to add a save as CMYK
feature?

Now I do agree that having to split the image up, work one 4 separate
images, then recombine them is not very efficient.  This could certainly
be improved on greatly.  But Gimp can do CMYK, and with the program I
mentioned, you can get a picture saved in CMYK format.

Am I way off base here???



>> While your explaination of CMYK is informative, you missed the point of
>> this paragraph.  Some printers will refuse any graphic not in CMYK
>> format. That's their policy.  Since Gimp can't output to any CMYK
>> format, people who might have used Gimp have to look elsewhere
>> (photoshop anyone?).  If Gimp could at least save to this format, it
>> would help get Gimp into places it can't go.

> I think you may be missing the point.  Given that there are simple
> formulas for converting from RGB to CMYK, doing so is essentially
> trivial.
>  I am sure I could write a simple program to do it if I went to the
> trouble of finding out about the relevant file formats.

> The problem, I think, is that one wants to look at the image on the
> screen and be able to manipulate the four channels directly and examine
> the results before saving it.  I was under the impression that the
> reason the Gimp doesn't have that capability is that it would require a
> major change in the basic architecture of the program.

<snip>
 
 
 

CMYK

Post by Dave Near » Mon, 23 Jun 2003 22:38:37


On Sat, 21 Jun 2003 18:05:20 GMT, robertS said:

Quote:> While your explaination of CMYK is informative, you missed the point of
> this paragraph.  Some printers will refuse any graphic not in CMYK format.
> That's their policy.  Since Gimp can't output to any CMYK format, people
> who might have used Gimp have to look elsewhere (photoshop anyone?).  If

Actually, gimp-print can convert to CMYK.

Dave.

--
                David Neary,
        E-Mail: bolsh at gimp dot org
   Work e-mail: d dot neary at phenix dot fr
CV: http://www.redbrick.dcu.ie/~bolsh/CV/CV.html

 
 
 

CMYK

Post by Dave Near » Mon, 23 Jun 2003 22:45:28


On Sat, 21 Jun 2003 11:56:56 GMT, rtt said:


>> For the record, CMYK is an additive colourspace representation.
>> That basically means that any colour can be constituted by adding
>> components of Cyan, Magenta, Yellow and blacK,

<snip>

Quote:>> As an example, one such formula is

>> K = min(1 - R, 1 - G, 1 - B)
>> C = 1 - R - K
>> M = 1 - G - K
>> Y = 1 - B - K

> could you explain please? could you give a concrete sample?

OK - by the way, there's a colour FAQ which answers this and
other questions (a google search for "color FAQ" should find it).

Say we look at RGB 127,127,127 - a midtone grey. Well, grey can
be drawn using just black ink. Or, we can draw it by mixing equal
amounts of cyan, magenta and yellow (the red, blue and yellow
paints that we used to have as kids). Using just black uses
better ink, so that's a better solution.

But then one black ink might draw darker than another - often
when printing stuff with a back area, it ends up coming out as a
charcoal colour.

Cheers,
Dave.

--
                David Neary,
        E-Mail: bolsh at gimp dot org
   Work e-mail: d dot neary at phenix dot fr
CV: http://www.redbrick.dcu.ie/~bolsh/CV/CV.html

 
 
 

CMYK

Post by Leonard Even » Mon, 23 Jun 2003 22:49:17



> On Sat, 21 Jun 2003 18:05:20 GMT, robertS said:

>>While your explaination of CMYK is informative, you missed the point of
>>this paragraph.  Some printers will refuse any graphic not in CMYK format.
>>That's their policy.  Since Gimp can't output to any CMYK format, people
>>who might have used Gimp have to look elsewhere (photoshop anyone?).  If

> Actually, gimp-print can convert to CMYK.

> Dave.

What do you mean by that.  I don't see any obvious way using my version
of gimp-print to create a file in CMYK format for printing at another time.

--

Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208

 
 
 

CMYK

Post by Rick Tayl » Tue, 24 Jun 2003 07:30:52



> formulas for converting from RGB to CMYK, doing so is essentially
> trivial.  I am sure I could write a simple program to do it if I went
> to the trouble of finding out about the relevant file formats.
> The problem, I think, is that one wants to look at the image on the
> screen and be able to manipulate the four channels directly and
> examine the results before saving it.  I was under the impression that
> the reason the Gimp doesn't have that capability is that it would
> require a major change in the basic architecture of the program.

 It might be nice if that were all taken care of by a dedicated program.

 {An extended print driver/prep/machine interface thing?}

 ...That way it's available to the entire system... you could just call
 it from any program. {like libraries and includes.... It makes everyones
 job that much easier and pushes the system just that much closer to being
 object oriented.}

 http://www.cups.org/
 http://www.atlantictechsolutions.com/scribusdocs/cms.html

 I think color management needs to be dealt with the same way.

 http://www.freecolormanagement.com/color/links.html

 Personally, I hate working backwards... CYMK drives me up the walls.

 I think sRGB and extended color spaces are a bit more important. Then
 again... I don't do a lot of print stuff. I do think it would be nice
 if we could all settle on one and just use that. Seeing as RGB is
 already so popular {and easy} sRGB would seem to be the logical next
 step. {Probably is halfway implemented anyway.}

 I do think it would be nice to have a system in place that would do
 transparent, on the fly conversion so as to accommodate out of date
 machinery.

--

Well, your fingers weave quick minarets
Speak in secret alphabets
I light another cigarette
Learn to forget

{Jim}

 
 
 

CMYK

Post by Karpp » Fri, 04 Jul 2003 17:26:43



> But then one black ink might draw darker than another - often
> when printing stuff with a back area, it ends up coming out as a
> charcoal colour.

> Cheers,
> Dave.

That's why we add 40% of cyan to black areas if we want it to look really
black. (This is something that is really hard to do with an autamatic
RGB->CMYK conversion script.)

Please, add a real CMYK support to GIMP. It would make art book printers
(like me) really happy.

With best regards,
Karppa

 
 
 

CMYK

Post by Dave Near » Fri, 04 Jul 2003 19:07:04


On Thu, 03 Jul 2003 11:26:43 +0300, Karppa said:

Quote:> That's why we add 40% of cyan to black areas if we want it to look really
> black. (This is something that is really hard to do with an autamatic
> RGB->CMYK conversion script.)

That's the only point that I was trying to make - the original
poster suggested that RGB->CMYK might be a 90% solution (not his
words, but that's the impression I got), and I explained that
that wasn't really the problem.

Quote:> Please, add a real CMYK support to GIMP. It would make art book printers
> (like me) really happy.

We'll get there :) In fact, we should be moving to GeGL by the
autumn, and then once someone implements CMYK in gegl, we'll have
it in the gimp core. The transition will probably take a bit of
time (it won't be overnight), but having a better graphics core
will be worth the wait.

Cheers,
Dave.

--
                David Neary,
        E-Mail: bolsh at gimp dot org
   Work e-mail: d dot neary at phenix dot fr
CV: http://www.redbrick.dcu.ie/~bolsh/CV/CV.html