Hi,

On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote:

I managed to export text while keeping the same appearance that it had in GIMP using PangoCairo. Exporting images with cairo was also possible if I saved the images first as PNGs and then used cairo PNG surfaces to draw them.

Why so complex? You can have a look at the Print plug-in to see how to transfer the image projection to a Cairo surface without the need to save as PNG.

Sven

Hello,

On Fri, Mar 20, 2009 at 7:53 PM, Sven Neumann wrote:

Hi,

On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote:

Why so complex? You can have a look at the Print plug-in to see how to transfer the image projection to a Cairo surface without the need to save as PNG.

Thanks Sven, I haven't known that. I found what I needed in print-preview.c, and I'll try this code out soon.

I should be able to build a small demo that does default printing for layers and text as one image, however there are several questions we should consider:

1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). 2. PDFs don't have anything such as transperent backgrounds for the pages. Should we ask the user for a background color for each page, or should we get the background color from the current gimp context? (Or mayber we should simply make it white) 3. When drawing paths, how should we ask the user where to draw each path? Also, how will he tell us how to fill/stroke it? Abusing the layer names doesn't sound right, and it won't be user-friendly if he would need to manually relocate his paths inside the plugin's preview...
The only solution I can see for handling this would be to wait for vector layers in GIMP, however I haven't heard of any recent progress in this direction.

-- LightningIsMyName

Hi,

On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:

1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of).

Why would we want to allow the user to create multi-paged PDF files?

Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for.

Sven

Sven Neumann wrote:

Hi,

On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:

1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of).

Why would we want to allow the user to create multi-paged PDF files?

Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for.

Sven

Indeed, what is the advantage of pdf export of a single image?

Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image.

PDF would just be a simple wrapper and this would best be done by and pdf editor that fully supports all the pdf features. It's unlikely gimp would want to maintain full functionality just to do this export.

The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to.

I could be wrong but that was my recollection.

gg wrote:

Sven Neumann wrote:

Hi,

On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:

1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of).

Why would we want to allow the user to create multi-paged PDF files?

Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for.

Sven

Indeed, what is the advantage of pdf export of a single image?

Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image.

PDF would just be a simple wrapper and this would best be done by and pdf editor that fully supports all the pdf features. It's unlikely gimp would want to maintain full functionality just to do this export.

The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to.

I could be wrong but that was my recollection.

Maybe. But my OpenOffice has "export as PDF" options in Impress (PowerPoint-like), Calc (Excel-like) and Writer (Word-like). OpenOffice is free and available, as we all know, for Windoze, MAC, and *nix.

When I want a multipage PDF of a bunch of images, I write them to jpg, paste them into a Writer document, then export them to PDF. I know it's clunky, but it works.

-- Burnie

Hi,

On Sat, 2009-03-21 at 12:41 +0100, gg wrote:

The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to.

I am pretty sure that this is not the case. The GIMP Print plug-in creates PDF files easily and we don't pay Adobe any money for that.

Sven

Hi,

On Sat, 2009-03-21 at 12:41 +0100, gg wrote:

Indeed, what is the advantage of pdf export of a single image?

If it is just a simple PDF, then nothing. But if it includes color profiles, support for spot colors, resolution-independent text layers, crop markers etc., then it would be a versatile format for getting your image printed processionally. But we definitely need someone who has some experience with using PDF for this purpose to tell us what exactly is needed.

Sven

Hello again,

On Sat, Mar 21, 2009 at 11:15 AM, Sven Neumann wrote:

Hi,

On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:

1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of).

Why would we want to allow the user to create multi-paged PDF files?

Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for.

I believe that we should have the option to export multi-paged PDFs, since we have the option to import them, and to me it makes sense that we should be able to export what we can import. Gimp may not be a page-layout program, yet doing multi-paged PDFs isn't too hard, and won't hurt anyone...

And about what you said on page layout tools, there is some sense in what you said. Therfore, I think it would be indeed simpler to ignore paths untill gimp has vector layers, since these aren't the main point of the PDF plugin. The only feature I believe that is necessary, is to draw single-colored rectangles as drawing and not as bitmap-images (Imagine a background layer for a large scale image - a bitmap image can be a big waist of memory).
However, this can be solved easily by finding all the layers in the image which have only 1 color (same RGBA values everywhere). I still need to figure out how to do this (probably using gimp_histogram in some way).

-- LightningIsMyName

On 3/21/09, gg wrote:

Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image.

Ahem, and what is your expertize to make such a bold statement?

The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to.

I nearly choked when I read this. The next statement of that kind would be "GIMP doesn't support CMYK because of patents". I don't really know what makes you think there is any legal issue regarding creating PDF files, but rest assured that there is no such issue.

Alexandre

Hi,

On Sat, 2009-03-21 at 21:36 +0200, LightningIsMyName wrote:

I believe that we should have the option to export multi-paged PDFs, since we have the option to import them, and to me it makes sense that we should be able to export what we can import.

The whole point of calling it "Import" is to make clear that you can't save this again.

Gimp may not be a
page-layout program, yet doing multi-paged PDFs isn't too hard, and won't hurt anyone...

Of course it would hurt. It binds development resources for creating and maintaining it. If a feature does not fit with our product vision, then we are not going to include it.

Doing multi-page PDF export simply because we can do it is not going to happen. What we need here is a user story. Without that, it doesn't make sense to discuss PDF export at all.

And about what you said on page layout tools, there is some sense in what you said. Therfore, I think it would be indeed simpler to ignore paths untill gimp has vector layers, since these aren't the main point of the PDF plugin. The only feature I believe that is necessary, is to draw single-colored rectangles as drawing and not as bitmap-images (Imagine a background layer for a large scale image - a bitmap image can be a big waist of memory).

I don't understand why that is needed. What is our goal here? To create PDF files as small as possible? IMO the goal for PDF export should be to improve support for professional printing. File size is not important for that. Paths are also not important for that. If people need vector art, then they should use a vector editor. What matters is color profiles, CMYK color separation in the export process, support for spot colors, crop marks, ...

As I said already, we can't discuss the details unless we know what the goals are. So we need to have one or more user stories for PDF export first. And we need to check these against our product vision to see if they are worth supporting.

Sven

On Sun, Mar 22, 2009 at 6:19 AM, Sven Neumann wrote: [...]

I don't understand why that is needed. What is our goal here? To create PDF files as small as possible? IMO the goal for PDF export should be to improve support for professional printing. File size is not important for that. Paths are also not important for that. If people need vector art, then they should use a vector editor. What matters is color profiles, CMYK color separation in the export process, support for spot colors, crop marks, ...

As I said already, we can't discuss the details unless we know what the goals are. So we need to have one or more user stories for PDF export first. And we need to check these against our product vision to see if they are worth supporting.

I see two possible use cases:

1. Proofing artwork - you need to prepare a proof before going to press. You send that proof to a client and they print it out and get a reasonable hard proof.

2. Submission to a printing company - you need to submit hi-res artwork to a printing company.

For either case to be useful, the PDF export needs to at least support: CMYK color mode, ICC profiles, spot colors, trim marks, crop area, and bleed area. Embedding or outlining (vector) fonts, registration marks, encryption, and downsampling of image/photo layers could possibly be useful.

That being said, both use cases would only come about when setting up a full-color job (CMYK, etc.) - and it is very likely that the printing company would accept (and perhaps prefer) a hi-res raster format like TIFF, PNG, or JPEG. I submit PDFs all of the time for proofing and printing but 90% are pure vector, 9% are vector with embedded bitmap images, and only the remaining 1% are completely raster (I've used at least one printing company that accepts pdf *only*).

IMHO: Attempting to redraw solid colors as vector would not be a good idea . File size is not really a concern - creating PDFs that print in a reliable manner and are as accurate as possible would be the main challenge. If GIMP comes to support vector layers at some point, then an option to rasterize those layers or keep them as vector should be presented at the time of PDF export. Multi-page is not something that GIMP should worry about at all - there are plenty of tools to join PDFs already, and multi-page documents are more the domain of page layout software.

PDF export might be a nice feature, but as a designer I would not use it very often. If I did use it, I would expect it to be *extremely* reliable, and quite verbose about any errors before or during export.

Chris

On Sun, 22 Mar 2009 09:47:00 -0500, Chris Mohler wrote:

I see two possible use cases:

1. Proofing artwork - you need to prepare a proof before going to press. [...]

2. Submission to a printing company - you need to submit hi-res artwork to a printing company.
[...]

What would be the advantage of handling a .pdf generation at application level instead of at operating system level ? (i.e. via print command)

Cristi

2009/3/22 Cristian Secar? wrote:

What would be the advantage of handling a .pdf generation at application level instead of at operating system level ? (i.e. via print command)

Far more features supported.

Install Scribus, go to File - Export - Save as PDF, then visit Fonts, Security, Color (make sure you choose "Output intended for: Printer" and enable "Use custom rendering settings" checkbox) and Pre-Press tabs.

Alexandre

Hi,

On Sun, 2009-03-22 at 09:47 -0500, Chris Mohler wrote:

I see two possible use cases:

1. Proofing artwork - you need to prepare a proof before going to press. You send that proof to a client and they print it out and get a reasonable hard proof.

2. Submission to a printing company - you need to submit hi-res artwork to a printing company.

For either case to be useful, the PDF export needs to at least support: CMYK color mode, ICC profiles, spot colors, trim marks, crop area, and bleed area. Embedding or outlining (vector) fonts, registration marks, encryption, and downsampling of image/photo layers could possibly be useful.

That being said, both use cases would only come about when setting up a full-color job (CMYK, etc.) - and it is very likely that the printing company would accept (and perhaps prefer) a hi-res raster format like TIFF, PNG, or JPEG.

Thanks a lot for your input. That was very useful.

So would you say that it makes more sense to spend time improving the TIFF save plug-in or would it be a better idea to invest that development into a powerful PDF export? My experience with TIFF is that it is an extremely difficult format as most of the important features are implemented as some sort of extension that is not part of the TIFF 6.0 specification. I would hope PDF to be better specified.

Sven

Sven wrote:

So would you say that it makes more sense to spend time improving the TIFF save plug-in or would it be a better idea to invest that development into a powerful PDF export? My experience with TIFF is that
it is an extremely difficult format as most of the important features are implemented as some sort of extension that is not part of the TIFF 6.0 specification. I would hope PDF to be better specified.

bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export?

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Sun, 22 Mar 2009 21:23:24 +0300, Alexandre Prokoudine wrote:

Far more features supported.

Install Scribus, go to File - Export - Save as PDF, then visit Fonts, Security, Color [...]

I assume it all depends on the application used for .pdf generation. Adobe Distiller (& Acrobat) has a comprehensive set of options. Not 100% sure, but perhaps Ghostscript based applications too, except that the user has to know the Ghostscript parameters (i.e. hard to use for more than basic .pdf generation, but possible).

Cristi

Hi,

On Sun, 2009-03-22 at 19:33 +0100, peter sikking wrote:

bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export?

Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more in line with our product vision.

Sven

Sven wrote:

bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export?

Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more
in line with our product vision.

when I wrote the previous message I already knew that this is the only counter-argument that I was going to accept.

so now we really need some trend spotting from those in our community who deal with serious printing jobs.

and when then moving forward with pdf, we should keep in mind what a GIMP document actually is: a single canvas/image (please do not mention the animation hacks we have...)

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Just my two cents;

TIFF is more important to GIMP because TIFF is widely used on printing and CG works. Its a common practice to use TIFF images in professional page layout programs like Scribus and Adode InDesign for example. And some 3d programs (like zbrush) use TIFF for export texture maps (in high bit dephs).

A better TIFF support would be more in sync with GIMP, me thinks.

PS: sorry for any English mistakes. =/

On Sun, Mar 22, 2009 at 11:13 PM, peter sikking wrote:

so now we really need some trend spotting from those in our community who deal with serious printing jobs.

It's difficult to talk about trends with regards to printing industry which tends to be quite conservative.

If you tell Scribus guys "My printer demands TIFF" they will most likely reply "Then you bloody well find another printer". Except there can be no other printer. Just two weeks ago I've heard from two different people: for the first guy there was no printer in his area to do color trapping on-site, so they asked him to do it himself, and no free DTP software supports it; for the second guy the printer demanded CDR (native Corel files) instead of PDF.

Point of fact: a really good application should be implying the least dangerous workflow (which is definitely PDF based) while supporting all kinds of perversions.

Alexandre

I send files to print shops every week. Here in argentina even serious printers require proprietary file formats like AIs and CDR, though they're fine with tiffs and PDFs.
I don't understand why there is so much interest in supporting PDF export from GIMP, since the exported data will be only bitmap, and in that case a tiff file is enough and is absolutely compatible with every design program out there.
In my oppinion, PDF only makes sense if there is mixed data like bitmap images and vector shapes or text. For flattened bitmaps, I'd say TIFF is even safer than PDF.
My current workflow consists in separate RGB images to a CMYK tiff using the Separate+ Plugin. Usually I do some black overprint tweaking using the faux channels that Separate+ creates. When I need a PDF, I use Scribus or this script:http://my.opera.com/area42/blog/cmyk-tiff-2-pdf-for-gimp

I think PDF will only make sense when vector shapes, CMYK color and spot channels are in GIMP.
Meanwhile, Separated Tiffs are enough and I think that putting time and efforts on a PDF exporter wouldn't make a real difference.

I'd prefer to see the separate plugin integrated in gimp, direct save of the separated tiff through the save plugin, importing separated tiffs directly (opening CMYK tiffs currently results in an uncorrected image with distorted colors wich is pretty unusable).

So -1 to this. There are oteher things far more important than this.

Gez.

2009/3/22 peter sikking :

Sven wrote:

bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export?

Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more
in line with our product vision.

when I wrote the previous message I already knew that this is the only counter-argument that I was going to accept.

so now we really need some trend spotting from those in our community who deal with serious printing jobs.

I often use GIMP as a part of my work flow - but almost never for preparing the final artwork for submission to the printing company - mainly due to the aforementioned lack of CMYK color space.

Only ~1% of my PDF files submitted to printing companies are 100% raster. PDF seems (to me) to be gaining ground against formats like TIFF, but it's not a "standard" yet (for raster images anyway). On one hand, TIFF is still more widely accepted than PDF. On the other hand, PDF is well documented. On the gripping hand, neither format is useful for print jobs without the CMYK color space - which I know is somewhat arbitrary, but many printing companies expect files in CMYK. If I have a choice, I use TIFF or PNG for raster pre-press images - but it might be wise to look to the future: PDF format has options (like crop area and bleed) that are useful to printers and the format seems to be slowly catching up to the "standards" (at least in my experience over the past few years in the US).

and when then moving forward with pdf, we should keep in mind what a GIMP document actually is: a single canvas/image (please do not mention the animation hacks we have...)

You and I are in 100% agreement on this point ;)

So to recap, I would welcome a printer-friendly PDF export if someone wants to work on it, though without CMYK support built-in it's not very useful just yet. From what I understand though, once GEGL integration is complete, any plugin could be refactored or rewritten to use higher bit depth and other color spaces.

Chris

Hi,

On Mon, 2009-03-23 at 14:31 -0500, Chris Mohler wrote:

So to recap, I would welcome a printer-friendly PDF export if someone wants to work on it, though without CMYK support built-in it's not very useful just yet. From what I understand though, once GEGL integration is complete, any plugin could be refactored or rewritten to use higher bit depth and other color spaces.

We don't plan to support editing images in CMYK. But what you need to get your images printed is a color separation based on the RGB and printer CMYK color profiles. This can very well be part of a PDF export plug-in. The separate+ plug-in shows how this can be done for TIFF files.

Sven

Sven Neumann wrote:

We don't plan to support editing images in CMYK.

Sven

The product vision states that "GIMP is a high-end photo manipulation application" and that certainly includes support for editing images in the CMYK color space. We can't call ourselves high-end without that support. I, for one, have plans to implement support for CMYK editing, but that is quite far into the future.

- Martin

Hi,

On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:

The product vision states that "GIMP is a high-end photo manipulation application" and that certainly includes support for editing images in the CMYK color space.

It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos.

Being able to do a color separation to CMYK is sometimes required in order to prepare an image for print (even though the printer can almost always do this much better). Editing an image in CMYK is not required though.

Sven

Sven Neumann wrote:

On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:

The product vision states that "GIMP is a high-end photo manipulation application" and that certainly includes support for editing images in the CMYK color space.

It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos.

Photos are usually taken in the RGB color space, but usually printed in the CMYK color space. Support for editing in both these color spaces is to me clearly within the scope of a high-end photo manipulation application.

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space.

- Martin

Hi,

On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space.

Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason.

Sven

On Mon, Mar 23, 2009 at 2:57 PM, Sven Neumann wrote:

Hi,

On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:

The product vision states that "GIMP is a high-end photo manipulation application" and that certainly includes support for editing images in the CMYK color space.

It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos.

Being able to do a color separation to CMYK is sometimes required in order to prepare an image for print (even though the printer can almost always do this much better). Editing an image in CMYK is not required though.

It is helpful to see an approximation of CMYK on the screen before you go to print - many colors available in the RGB color space fall outside of the CMYK gamut. RGB blue is likely the worst offender - fill an image with solid #0000FF and print it to a color printer and you will see quite a shift in color.

Take a simple case: annotating a photo with some text (for print use) - working in CMYK space would prevent the user from using #0000FF as the text color (or actually convert it from #0000FF to its CMYK equiv on the fly) - giving a reasonably accurate representation of the final printed output on the screen.

A more complicated case: removing small black text from the CMY channels manually (to improve legibility) - or more realistically only applying the small text to the K channel. Editing the channels in CMYK would be more comfortable than running through the separation process first and then making changes - and the ability to use CMYK swatches (in this case C=0, M=0, Y=0, K=100) could also speed things up dramatically.

Of course this is not a trivial task, and I'm not holding my breath. Although it might not be hard to throw up a projection of the current image with a generic CMYK profile applied to it - that would be enough to satisfy the simple use-case above. Oh, and I guess we're rapidly drifting off-topic in re to PDF export ;)

Chris

Sven Neumann wrote:

On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space.

Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason.

I am by no means a photography professional and my point of view comes mostly from what other people have said regarding CMYK support; I don't have any direct sources to give.

Could you perhaps clarify/give references to your claim that high-end photo editing apps are pushing for an RGB only work-flow? If you are going to print an image, CMYK _will_ play a role in your work-flow.

- Martin

FYI, my company writes most of its own output in PostScript for high end laser printers (e.g., Xerox I-GEN 3 and 4). We avoid CMYK. But we're not a pre-canned application company, we write everything ourselves. All of our printers work great with RGB colorspace. The need for CMYK is usually based on the software that goes with the printer or the shop's chosen software helper applications. I suspect that CMYK in the laser printer market is just something passed on from wet press. However, people often send CMYK art to us, and we need the ability to import CMYK into RGB.

About PDF: PDF has some of its own drawing language, but when it comes to raster, it simply embeds bitmaps. That imbedded bitmap can be an almost exact copy of tiff, png, gif, whatever. PDF is a hybrid vector language with embedded bitmap. I'd love the ability to import or export with PDF pages translated to/from layers.

And kudos to gimp for having the best quality PostScript. Gimp outputs valid PostScript, which I can't say the same for on most Adobe products. PDF used to be a proprietary thing, where Adobe made readers free, and writers pay, but they turned it into an open standard and anyone is free to do whatever they want these days. I'd trust gimp to do a better job at a PDF implementation than I would Adobe.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Hi,

On Mon, 2009-03-23 at 15:27 -0500, Chris Mohler wrote:

It is helpful to see an approximation of CMYK on the screen before you go to print - many colors available in the RGB color space fall outside of the CMYK gamut. RGB blue is likely the worst offender - fill an image with solid #0000FF and print it to a color printer and you will see quite a shift in color.

GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors.

Take a simple case: annotating a photo with some text (for print use) - working in CMYK space would prevent the user from using #0000FF as the text color (or actually convert it from #0000FF to its CMYK equiv on the fly) - giving a reasonably accurate representation of the final printed output on the screen.

In order to do that, all you need is to be able to select an RGB color by specifying the CMYK values (and of course you should get exactly that CMYK color then as a result of the RGB->CMYK conversion). You can already do that. If you specify a CMYK profile, the CMYK color selector will make use of that.

Sven

On Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote:

GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors.

Last time I did a softproof in GIMP I ended up with darker and less saturated prints. So I did a simple test --- captured screenshots of a window holding "normal" view of a photo and a "softproof", then merged them into a multilayer image and changed softproof shot's layer mode to "difference". Everything except just few pixels was black. I was probably doing something really stupid, but to me it sounded like softproof was broken. It was fairly recently and I didn't have time to write a proper report (and I didn't try that with other photos). If you are interested, I still could do that.

Alexandre

Alexandre Prokoudine wrote:

On Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote:

GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors.

Last time I did a softproof in GIMP I ended up with darker and less saturated prints. So I did a simple test --- captured screenshots of a window holding "normal" view of a photo and a "softproof", then merged them into a multilayer image and changed softproof shot's layer mode to "difference". Everything except just few pixels was black. I was probably doing something really stupid, but to me it sounded like softproof was broken.

This doesn't say much about soft-proof being broken or not, it depends on many things such as the accuracy of the color profile, the image itself, and the rendering intent that was used.

- Martin

On Mon, 23 Mar 2009, Martin Nordholts wrote:

I am by no means a photography professional and my point of view comes mostly from what other people have said regarding CMYK support; I don't have any direct sources to give.

Could you perhaps clarify/give references to your claim that high-end photo editing apps are pushing for an RGB only work-flow? If you are going to print an image, CMYK _will_ play a role in your work-flow.

I do work in the printing industry, and I can tell you that output is still CMYK, and will remain CMYK for at least the next few years. Well, some of it is 6-color Hexachrome.

And the newest technology is digital presses like the HP Indigo, which are also 6-color or more. The cheap ones cost upwards of $160,000, not counting the product maintenance contract. No one is going to turn around and buy another press that uses a completely different workflow after dropping that much money on a brand new press just 4 years ago.

I have seen no evidence that anyone is moving from a CMYK or 6-color workflow to an all-RGB workflow. I do know that some desktop printers use RGB color inputs, but those are desktop printers, not professional presses.

The workflow may be different for photo editing than for some of the documents that I work on (most are spot jobs, but some involve image manipulation), especially with things like photo kiosks, but professional-quality press output will remain CMYK for quite some time.

I recognize that CMYK editing is a difficult thing, and I'd encourage you to take the time to do it right, but I'd also encourage you to do it. It may take some work to convert current Adobe users to GIMP, but the way GIMP works now, you ensure that they can't even consider it.

Full disclosure: I use Adobe products at work, but GIMP at home. I much prefer the UI of GIMP to that of Photoshop, and it works just fine for the amateur work that I enjoy as a hobby at home. In fact, GIMP can do all the professional things that I need it to at work--all except CMYK and spot. I don't even really use 16-bit much, and I can work around PMS colors.

If GIMP had CMYK support, I could take my work home.

Sven wrote:

Martin wrote:

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo
app should support editing also in this color space.

Why? Because you say so?

wow, the return of the cmyk wars.

the photo part is not the issue, the vision also speaks of

"GIMP [...] supports creating original art from images"

I agree with the point that all of GIMP should be pure rgb based, with support for cymk import, export and cymk color selection.

let me quote myself from 2 weeks ago about managing and checking and optimising export to lossy formats:

"my rough plan for supporting that looks like overlaying the image with a projection screen (lets not call it a layer) that simulates the lowering of fidelity. then this projection screen itself could contain several layers of optimisations and corrections that users may want to take. the high fidelity image data is still available for further development.

"bonus:

"that recent ars technica review had a really clarifying metaphor for cmyk for print workflows. along the lines of: the cmyk file is the LP pressing of the rgb master tape. seeing this cmyk conversion as a fidelity reducing (colour gamut) 1-way conversion, it looks like the projection screen plan above could be the beginning of a working cmyk support solution."

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hi,

On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote:

I do work in the printing industry, and I can tell you that output is still CMYK, and will remain CMYK for at least the next few years.

Output, yes, of course. But where in this process do you actually edit an image in CMYK? I don't mean converting it to CMYK to get it printed. I mean actual editing after the conversion. Could you give us some examples of where that is needed?

Sven

From: Sven Neumann
Date: Mon, 23 Mar 2009 23:18:23 +0100

On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote:

> I do work in the printing industry, and I can tell you that > output is still CMYK, and will remain CMYK for at least the next > few years.

Output, yes, of course. But where in this process do you actually edit an image in CMYK? I don't mean converting it to CMYK to get it printed. I mean actual editing after the conversion. Could you give us some examples of where that is needed?

The most obvious example to me (and this has been discussed wrt Gutenprint and other printer drivers) is to allow printing "text black" -- text (or similar) that should be printed with black ink, which is usually more crisp than composite.

This is essentially a special case of a spot color. An alternative would be RGB+K.

My sense is that this should not be a very high priority for GIMP -- we never got around to implementing it and nobody has complained. But it is one possible use case for CMYK (although I think RGB+K would be a better input space for it, anyway -- and if you're going to do that, you might just as well generalize the spot color support).

When people do send CMYK data to Gutenprint, the large majority of the time it's either because they don't really understand what CMYK is (it's very device and media specific) or because we have a problem with the GCR parameters (or some other parameter problem) for a particular printer and CUPS's default RGB->CMYK conversion happens to work better.

Personally, I would *much* rather see development effort go into high bit depth support (which will do a lot of people a lot of good right away) than CMYK editing support. But, that's just my take.

On Monday 23 March 2009 04:56:23 pm Robert Krawitz wrote snip

When people do send CMYK data to Gutenprint, the large majority of the time it's either because they don't really understand what CMYK is (it's very device and media specific) or because we have a problem with the GCR parameters (or some other parameter problem) for a particular printer and CUPS's default RGB->CMYK conversion happens to work better.

One other reason is that they have created custom CMYK profiles for the printer and the color space conversion to the printer CMYK color space is better using that profile than either what the driver or what CUPS does. But this is a very small set of users. But this has nothing to do with editing of the images.

Hal

Sven Neumann wrote:

It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos.

It really depends on what you are used to. To *you* RGB seems natural, while to someone who has been brought up in the printing world, CMYK seems natural, and it's RGB that is "weird". (You know which is which when you ask them to evaluate a photograph. If they say things like "it needs a couple of percent more magenta in the mid tones, and a little less yellow there, ...", they are from the print world, and think in CMYK. Many of these professionals are unbelievably good at being able to spot what needs to be done to an image in CMYK to correct it).

When preparing photographs for printing, it is extremely common to want to edit them in CMYK space so as to be able to get the best looking result within the limitations of that colorspace, and to meet other technical requirements (total ink coverage, black separation, etc.).

There is also the question of whether you define your goals narrowly as photographs, or more generally as images or raster files. If the latter, then there (ideally) shouldn't be any limitation on the number of channels or colorspaces supported by an editing program.

Graeme Gill.

On Mon, 23 Mar 2009, Sven Neumann wrote:

On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote:

I do work in the printing industry, and I can tell you that output is still CMYK, and will remain CMYK for at least the next few years.

Output, yes, of course. But where in this process do you actually edit an image in CMYK? I don't mean converting it to CMYK to get it printed. I mean actual editing after the conversion. Could you give us some examples of where that is needed?

Oh, sure.

Like I said, I mainly work with vectors and spot jobs, but I have, in the past, had to deal with some of these issues. Take the following image, for example:

To properly print this image, it should be trapped--that is, either the red plate or the black plate should be altered so that the red and black overlap. That way, a slight misregistration won't result in a white gap along the border. Trapping is usually pretty small, around .25 pt, but here's an exaggerated example of what will happen if you don't trap and the plates are misregistered:

Some trapping can be done in vector programs and page layout programs, but images with non-geometric edges like the one above cannot. I would have to do it in GIMP, but I cannot do it in GIMP, because that would require having some of the pixels at 100% red and whatever shade of black it is at that point, and GIMP cannot do that because it does not have CMYK support.

Likewise rich black. In cases where you are printing black on a multicolored border, it's useful to print in rich black, usually 60%C, 100%K. This makes the effects of trapping less noticeable.

You can find an example of rich black here:

Again, it is not possible to do this in GIMP without CMYK support.

Also, color correction. If I print a proof and it turns out that it is too cyan, I cannot simply turn up the red, because that will also adversely affect both the cyan and magenta plates.

And finally, I agree with Sven that I don't know why anyone would want to have multipage PDF output for GIMP. I'd much rather see built-in DjVu support.

On Mon, Mar 23, 2009 at 11:17 PM, Sven Neumann wrote:

Hi,

On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space.

Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason.

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

Alexandre

Hello happy CMYK warriors,

This is valuable input you're giving actually How about collecting these use cases for prepress in the wiki here http://wiki.gimp.org/gimp/ ?

(like the UI team did with brainstorm here : http://gimp-brainstorm.blogspot.com/ )

You could put it using these kind of chapters : https://wiki.ubuntu.com/UbuntuWithoutRestricted

This way, we could specify the GIMP a bit better and coordinate dev efforts ;)

enjoy this day !

vincent

On Wed, Mar 25, 2009 at 16:21, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Mon, Mar 23, 2009 at 11:17 PM, Sven Neumann wrote:

Hi,

On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:

Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space.

Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason.

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

Alexandre

On Wed, Mar 25, 2009 at 6:21 PM, Alexandre Prokoudine wrote:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K

3. Some print houses set limit to overall sum of colors, for example 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a little of K and Y this will result in unnatural colors in a newspaper.

4. Live density control for each CMYK channel is a must (Scribus/SVN has that in preview dialog).

I was reminded that I actually forgot

5. Part of an image should be b/w and the rest should be colorized with just one tint. E.g. Cyan + Black for sea. separate+ and exporting are of no help here.

Alexandre

On Wed, 25 Mar 2009, Alexandre Prokoudine wrote:

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K

The Christian Science Monitor does this pretty frequently, and 2-color ads and brochures are fairly popular because they are cheap. You can look online for examples, but I have to get to my prepress job now.

To me it's somewhat strange that GIMP's product vision doesn't mention prepress needs explicitly.

Agreed. I don't think anyone here is looking for a Photoshop clone (I know that I personally hate PS for a variety of reasons), but we do realize that it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not the best move.

On Wed, 25 Mar 2009, Vincent Lordier wrote:

This is valuable input you're giving actually How about collecting these use cases for prepress in the wiki here http://wiki.gimp.org/gimp/ ?

(like the UI team did with brainstorm here : http://gimp-brainstorm.blogspot.com/ )

You could put it using these kind of chapters : https://wiki.ubuntu.com/UbuntuWithoutRestricted

This way, we could specify the GIMP a bit better and coordinate dev efforts ;)

enjoy this day !

I'd be happy to, but I've got to get to work. InDesign is a flaky POS software that makes me wish there were a better free alternative.

But since there isn't, I'll have to write up some examples when I get home.

On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote:

Agreed.  I don't think anyone here is looking for a Photoshop clone (I know that I personally hate PS for a variety of reasons), but we do realize that it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not the best move.

Do we realize that? :)

It is true that GIMP is usually seen as to-be-photoshop-substitution and its maturity in various areas in fact is the reason why people switch to GIMP. However GIMP doesn't seem to be driven by a will to make Photoshop die, die, die :)

Alexandre

Alexandre Prokoudine wrote:

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

A vision is an expression of the project of what they want the software to be.

There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported.

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote:

There is choice in there, and the user community cannot demand that GIMP does certain things.

It's quite an interesting point, because you are talking about demanding, whereas I'm talking about meeting users needs :) And you do understand the difference, do you? :)

presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press.

So what you are saying basically is that you see GIMP users as human beings living in a parallel world where all of the things mentioned above do not exist, workflows are perfectly RGB based and nobody ever has to deal with color separations other than exporting :)

Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level.

Alexandre

Alexandre Prokoudine wrote:

On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote:

There is choice in there, and the user community cannot demand that GIMP does certain things.

It's quite an interesting point, because you are talking about demanding, whereas I'm talking about meeting users needs :) And you do understand the difference, do you? :)

in general: users have lots of needs, but it is GIMP's team choice to meeting these needs _well_. the stress is on well, because if you decide to do it in your vision, you have to strive to be the best in that department.

website mock-ups and code generation; multi-page, multi-column page layouts; hard disk de-fragmentation: users have these needs, but GIMP will not help them with these.

presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press.

So what you are saying basically is that you see GIMP users as human beings living in a parallel world where all of the things mentioned above do not exist, workflows are perfectly RGB based and nobody ever has to deal with color separations other than exporting :)

If you had carefully read what I am offering to design for GIMP you will see that it is a lot more than an export.

I am talking about covering the main image window with a "projection screen" in this case for cmyk, whenever one wants, from the first to the last second of the project, that with the profile
of the printing press will give you some idea (I know there are limits) of how it will come off the press. this projection screen will have its own layers where one can take corrective measures to make the output look good within the possible output range. these corrective layers will hen be used of course for the mastering/export to cmyk. all the cmyk tricks you talk about (ink decomposition, trapping) can be set up for the projection screen and where possible previewed there.

the overall task is actually mastering the image for printing press, where cmyk happens to be an important factor in the world of today.

Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level.

I would like to have this answered answer first: why can't they do it with scribus? are we the last piece of (free) software in the world that can help them?

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Wed, Mar 25, 2009 at 12:44 PM, peter sikking wrote:

Mix master tape (in rgb) and then cut the lp (in cmyk).

I can express any CMYK color in RGB - but not the other way around. Therefore, I "master" all of my print jobs in CMYK, and if I "cut" something like a preview for a client then I use RGB space. So you see, it's actually quite the opposite in my world. This is why GIMP is only a small portion of my day to day work flow - it is not printer-friendly (yes, friendly to the device sitting on your desk, but not a person who is a printer).

And I agree that Scribus is coming along nicely and will (hopefully) become a robust page layout program - but I think where GIMP comes into the arena is creating a single image that will be printed (in a magazine, screen printed, newspaper, whatever). Something like PDF+CMYK export is a good first step, but ultimately CMYK editing and channel operations are needed to make GIMP suitable for preparing an image for print.

Chris

On Wed, Mar 25, 2009 at 1:58 PM, peter sikking wrote:

Alexandre Prokoudine wrote:

Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level.

I would like to have this answered answer first: why can't they do it with scribus? are we the last piece of (free) software in the world that can help them?

Ah, but Scribus is a layout program, not an image editor. Ideally, one would prepare images for printing with GIMP, then embed them in a page with Scribus. Having control over the CMYK (or spot color) makeup of the image in GIMP should make things smoother when setting the image in Scribus.

As to the projection screen, that approach sounds complicated. But if it can give a fairly honest CMYK projection and allow for manually adjusting the channels, then it would go a long way toward solving some of these problems.

Chris

On Wed, Mar 25, 2009 at 7:06 PM, Chris Mohler wrote:

On Wed, Mar 25, 2009 at 12:44 PM, peter sikking wrote:

Mix master tape (in rgb) and then cut the lp (in cmyk).

I can express any CMYK color in RGB - but not the other way around. Therefore, I "master" all of my print jobs in CMYK, and if I "cut" something like a preview for a client then I use RGB space.  So you see, it's actually quite the opposite in my world.  This is why GIMP is only a small portion of my day to day work flow - it is not printer-friendly (yes, friendly to the device sitting on your desk, but not a person who is a printer).

And I agree that Scribus is coming along nicely and will (hopefully) become a robust page layout program - but I think where GIMP comes into the arena is creating a single image that will be printed (in a magazine, screen printed, newspaper, whatever).  Something like PDF+CMYK export is a good first step, but ultimately CMYK editing and channel operations are needed to make GIMP suitable for preparing an image for print.

I consider spot colors much more important than CMYK. I also consider CMYK a special case of spot colors. Spot colors could be implemented using GEGL ops that take a set of grayscale buffers (plates) as input and provides RGB soft-proofing
(potentially even animated for gloss/metallic inks). This would leave the image processing
algorithms dealing with sane or mildly sane color models like gray scale, RGB, YCbCr or CIE Lab,
while allowing the user direct control over the contents of spot colors and seeing a preview
of the resulting processing.

If the above is considered CMYK support I would be supportive of it. CMYK support in the
form of CMYK and CMYKA pixel buffers as a first class citizen (or even a third grade citizen)
with support in most operations and routines is something I will continue to oppose.

/Øyvind K.

On Wed, Mar 25, 2009 at 9:58 PM, peter sikking wrote:

If you had carefully read what I am offering to design for GIMP you will see that it is a lot more than an export.

I am talking about covering the main image window with a "projection screen" in this case for cmyk, whenever one wants, from the first to the last second of the project, that with the profile
of the printing press will give you some idea (I know there are limits) of how it will come off the press. this projection screen will have its own layers where one can take corrective measures to make the output look good within the possible output range. these corrective layers will hen be used of course for the mastering/export to cmyk. all the cmyk tricks you talk about (ink decomposition, trapping) can be set up for the projection screen and where possible previewed there.

So at the point of final projection users will gain access to each of the CMYK channels separately? That indeed sounds like a fair solution.

However, there still is a question of being able to use spot colors, e.g. in vector layers.

I would like to have this answered answer first: why can't they do it with scribus? are we the last piece of (free) software in the world that can help them?

You can do things like using spot color based duo-/tri-/quadrotones in Scribus, but you run into limitations, because these kinds of raster effects are not a natural part of a desktop publishing application. And a DTP application tends to rather collect and layout already mastered content than try to substitute a sophisticated vector or bitmap graphics editor.

Alexandre

Hi,

Chris Mohler schrieb:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

From past examples (trapping, rich black) i've come to think that

hand-optimized CMYK separations can't be transformed back to RGB losslessly (quite opposite to gamut issues). Can some RGB color space be tricked to accommodate overprinting uses?

greetings, peter

On Wed, Mar 25, 2009 at 2:44 PM, yahvuu wrote:

Hi,

Chris Mohler schrieb:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

Not really. What I was trying to say is that I send RGB proof images to my customers, even though the artwork is in CMYK - and they get a fairly honest representation of the final print. I do not actually convert from CMYK->RGB->CMYK though - just export RGB from the CMYK image.

From past examples (trapping, rich black) i've come to think that

hand-optimized CMYK separations can't be transformed back to RGB losslessly (quite opposite to gamut issues).

Yeah - that will lead to problems.

Can some RGB color space be tricked to accommodate overprinting uses?

On that I have no idea...

Chris

On Wed, Mar 25, 2009 at 10:44 PM, yahvuu wrote:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

It's not :) And I believe that a small portion of CMYK colors is out of gamut for RGB too , by the way :)

Alexandre

Alexandre Prokoudine wrote:

It's not :) And I believe that a small portion of CMYK colors is out of gamut for RGB too , by the way :)

Both RGB and CMYK are device dependent color spaces and without any kind or further specification one can not say how the former relates to the latter

You can compare for instance sRGB RGB and US Web Coated SWOP CMYK, but not just RGB and CMYK

Sorry for nitpicking

- Martin

On Wed, Mar 25, 2009 at 11:06 PM, Martin Nordholts wrote:

Both RGB and CMYK are device dependent color spaces and without any kind or further specification one can not say how the former relates to the latter

That goes without saying :)

Alexandre

Alexandre Prokoudine a écrit :

On Wed, Mar 25, 2009 at 6:21 PM, Alexandre Prokoudine wrote:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K

3. Some print houses set limit to overall sum of colors, for example 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a little of K and Y this will result in unnatural colors in a newspaper.

4. Live density control for each CMYK channel is a must (Scribus/SVN has that in preview dialog).

I was reminded that I actually forgot

5. Part of an image should be b/w and the rest should be colorized with just one tint. E.g. Cyan + Black for sea. separate+ and exporting are of no help here.

Working in CMYK at one point in the workflow is a question of control. You need to obtain a predictable result on press and you need to work with what you really have, often "exactly", in terms of color combination. When printing in color on an offset press you have 3 possibilities. a) Spot colors (blended or preblended inks that could be just any color), b) 4-color process (CMYK inks) c) Hexachrome or 6-color process CMKYGO.

So, pursuing with this interesting list of real-case scenario or why can’t we just rely on RGB throughout the creation process (while I agree some people can decide they work only with it):

6. In a layout, you have a picture from which you want to pick a specific color and apply it to another element in the page. You will want to have control over that color. For instance, if this color is to be applied on text, you will want to make sure you don’t end up with ink in the four channels because on press you might (you probably will) encounter registration issues with such tiny elements as the hairline portion of a font. You will need to limit this to a 3 color combinations. Now, how do you do this with a RGB>CMYK converter? There has to be some human supervision in the process. So, it doesn’t matter really if you do the whole work in GIMP instead of if you split the job between Scribus and GIMP or Inkscape for instance: at some point you will need to have all color elements to speak the same language and this language will have to be the lower common denominator: CMYK.

7. You want side by side a dark background and a color image. Both can be created in GIMP but for the dark background you will really want to control the combination of inks that produces that specific color and again it’s going to be difficult to just let the converter do the job without you being in full knowledge of what’s going on behind the scene.

I realise that my examples are not purely "image" manipulation (which is the core task of GIMP) but instead "image usage and combination" but really, this is mostly what graphic design is all about!

8. If a user is not concerned about precision, he/she might not need that much control over an image but if you work for an ad agency that needs to produce tons of images that include, for instance, skin tone — then you also need to have total control over the colors and this has to be done in CMYK which is the very end of the workflow. In the end we will have to turn the image into CMYK and it does really happen often that we have to adjust colors at this far point in the workflow.

9. While prepress and press shops can handle pretty easily RGB data, it’s going to be a "best effort" made by the RIP itself according to curves and algoritms the designer has no control over. And I know not many designers who will accept that. At some point, they will need both a good converter and means to adjust the resulting image. This is fine-tuning, I agree.

10. The packaging industry makes a great use of CMYK + Spot colors. To convince yourself, unfold any packaging and you will notice all the press marks on the inner flaps and the colors used. This means that both pixel and vector driven applications need to be able to work in CMYK + Spot if we want to address the packaging industry needs. There is quite a lot of design there to accomplish!

I guess we could find other real life scenarios where CMYK control is important or even stronger, a necessity.

I humbly wish this short intervention will help understand better the needs from the print point of view.

Louis

Alexandre

On Wed, 25 Mar 2009, peter sikking wrote:

Alexandre Prokoudine wrote:

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

A vision is an expression of the project of what they want the software to be.

There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported.

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

Scribus is vector-based, not raster based.

I do not believe that Scribus has any intent to be allow raster-based editing, but I could be wrong.

I have CC'd the Scribus list. Let us hear their opinions. Does Scribus intend to allow people to tackle the problems listed above?

Or would you be able to trap the following image with Scribus?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

As someone who works in prepress, I can tell you that when we take it from original artwork to press, we have to run any raster artwork through Photoshop or a competing product.

peter sikking wrote:

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

So you're saying that Scribus should add a pixel editing package to their application, so that they can support CMYK and other non-RGB color spaces, duplicating an awful lot of what's in GIMP ?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

[ ie. handling CMYK and other colorspaces is a superset capability, with RGB being a subset, and the colorspace is orthogonal to the pixel manipulation capabilities ]

Graeme Gill.

On Thu, 26 Mar 2009, Graeme Gill wrote:

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

For the record, Scribus does allow pixel editing.

When you right click on an image and select Edit Image, it opens the image in GIMP.

I think that's pretty strong evidence that there's no intent to do raster editing in Scribus itself.

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

FYI, Krita is extremely buggy. It has an SDI, which some people (e.g. me) don't like, but the code will improve and there may be improvements in the interface. Krita may indeed surpass GIMP. Sad, really, since I think GIMP can be the better product.

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork.

But you've got the time to do it before the others catch up, and you've got GEGL, the toolset to do it right.

Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it. That's the point of Open Source!

If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else.

From the outside, GIMP is seen as a shining example of what open

source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS.

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

Gez.

On Wed, 25 Mar 2009, Guillermo Espertino wrote:

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

Sadly for the cause of CMYK, that's not really a good example. That's a better example for the need for Pantone and other color matching system support.

Which GIMP will eventually need, but I'm thinking that day will come a decade or two from now, hopefully when there's an open source rival for Pantone.

(I actually plan to take that task on, myself in a few years, as part of some research)

yahvuu wrote:

Chris Mohler schrieb:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

It depends on the gamuts of the respective colorspaces. These are all device dependent colorspaces, so their gamuts depend on the device in question. A gamut can be described by a 3 Dimensional volume, and in general two gamuts will have some region in common, a region unique to one gamut, and
a different region unique to the other gamut. This is often the case with RGB and CMYK spaces (ie. sRGB and a typical offset press).

Whether CMYK->RGB->CMYK is roundtrip safe depends on whether the RGB space fully encompasses the CMYK space, or (if it does not), if the gamut mapping is being reversed through the transformations. Some people deliberately use a very large RGB gamut working space to avoid clipping CMYK colors.

Note that by definition you loose the black inking information though such a conversion, as well as a degree of fidelity.

A traditional graphic arts workflow often looks something like:

Capture in RGB

Edit/adjust in RGB and/or Lab

Convert/Separate to CMYK

Adjust in CMYK

Layout/Compose/Add non-image elements in CMYK.

Convert to RGB for soft preview.

Print the CMYK.

Although there are other more complicated ones, including late binding (separating for the particular output device after layout/composition).

Graeme Gill.

Guillermo Espertino a écrit :

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

I cannot agree more. It’s day-to-day work, day-to-day reality.

We could add dozens of examples, I guess.

To this point I don’t believe it’s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer — available at LGM! — that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that’s in the machine, be it toner or printing ink. There is no way to ignore this reality.

We’re back to the basics of color reality. It’s either a projection of light or a reflexion of light. I mean, there are good books on the subject. This part is easy.

At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)?

If we do need further examples, I am ready to provide more info, although I find the examples so far to be really on target.

Cheers!

Louis

Gez.

On Wed, 25 Mar 2009, Louis Desjardins wrote:

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device.

Andrew A. Gill a écrit :

On Wed, 25 Mar 2009, Louis Desjardins wrote:

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device.

This mostly depends on the RIP that is attached to the printer but really, this doesn’t prove the point of the need of CMYK editing ability to be wrong, does it?

Louis

On Wed, 25 Mar 2009, Louis Desjardins wrote:

This mostly depends on the RIP that is attached to the printer but really, this doesn?t prove the point of the need of CMYK editing ability to be wrong, does it?

On the contrary.

Just trying to give people all the facts. I find it helps to avoid being accused of partisanship.

Andrew A. Gill a écrit :

On Wed, 25 Mar 2009, Louis Desjardins wrote:

This mostly depends on the RIP that is attached to the printer but really, this doesn?t prove the point of the need of CMYK editing ability to be wrong, does it?

On the contrary.

Just trying to give people all the facts. I find it helps to avoid being accused of partisanship.

:-)

Ok!

Andrew A. Gill wrote:

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork.

With all the excellent input from people in the printing industry, including you, I think it is as clear as it can be. GIMP needs to support editing in the CMYK color space. Support for editing only in the RGB color space will simply not be enough. The details on _how_ to support this is still an open question, but that we _need_ to is to me just unquestionable.

Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it. That's the point of Open Source!

If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else.

From the outside, GIMP is seen as a shining example of what open

source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS.

I must say I find this a bit arrogant. Supporting someone that is inexperienced with hacking on the GIMP core to implement CMYK, which arguably is the toughest task one can currently take on as far as GIMP hacking goes, would be both very boring and very time consuming. That is not something I want to spend my spare time on. If you want to help implement better support for CMYK you should start working on and looking into the GIMP code. After working on the code for a while you will get your own ideas on how to implement CMYK in the best way.

I've been contributing code to GIMP for quite a while now, and I don't know yet know exactly how to implement support for CMYK editing in the best way. All I know is that GEGL will be a much better base for this than the legacy code. So if you want to help getting CMYK into GIMP, helping with the integration of GEGL will be a good start.

Best regards, Martin

On Thu, 26 Mar 2009, Martin Nordholts wrote:

I must say I find this a bit arrogant.

Maybe. Probably.

But I think it's time for me a a user to stop telling developers what I need and to start asking what you need to make that happen.

I think it's time to stop looking at this from the position of nebulous wants and desires and to start looking at the end product and asking what restrictions need to be placed on its development. Where does it connect to the rest of the program? How does it interact with the rest of the program? When we know that, we'll be able to start figuring out how best to implememt it.

Supporting someone that is inexperienced with hacking on the GIMP core

I'm not asking for support. I'm just asking you what the shape of the hole is that the CMYK peg must fit into.

I'm not really suggesting that I tackle the problem, but in my experience, the first response to ``You should have feature X'' is usually ``You forgot to attach the patch.'' Talk is cheap, and somebody needs to offer to help.

On Wed, 25 Mar 2009, Vincent Lordier wrote:

Hello happy CMYK warriors,

This is valuable input you're giving actually How about collecting these use cases for prepress in the wiki here http://wiki.gimp.org/gimp/ ?

Well, I'm a man of my word and so I just contributed my wiki attempt to do my part to change this from pie-in-the-sky dreaming.

There's an incomplete draft here:

I still need to come up with a good color correction example and a good rich black example, but I should sleep now.

On Thursday, March 26, 2009, 21:20:53, Cédric Gémy wrote:

This is very simple : Illustrator CS4 has just implemented a real multipage PDF support.

You mean something that CorelDraw had for years?

Then again, both CorelDraw and Illustrator are vector editing programs, and having multiple pages in them is natual. GIMP OTOH is primarily a bitmap editor, and as such multipage support doesn't make much sense (and wouldn't easily fit in the workflow).

And finally, I agree with Sven that I don't know why anyone would want to have multipage PDF output for GIMP.

This is very simple : Illustrator CS4 has just implemented a real multipage PDF support.
My opinion, if worth, is that gimp don't have to copy adobe software, even if there are many good idea in those too. Gimp actual CMYK conversion process is good for most of the jobs and actually much more since i know only very few print shop working with a really accurate Color management. But it's true and in some cases having too rich black (such as 300 % or 360 % like i already get on day). Finally, there is a plugin that can export each plate separately, but needs improvement too, for sure. This is also the case with Inkscape. My workflow is usually to make the PDF in Scribus after having imported the RGB picture. The output seems to be better. (at least Adobe user could read InDesign documentation and see this also the workflow recommended now even in Adobe process. And i think once they'll have publish a complete PDF Ripping process it will be more and more the case).

If that helps.

pygmee

Hi all,

Louis Desjardins schrieb:

Guillermo Espertino a écrit :

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first.

Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes.

This is a very common scenario, and it's a task for a image manipulation program.

I cannot agree more. It’s day-to-day work, day-to-day reality.

We could add dozens of examples, I guess.

Please do so. The general need for CMYK support beyond mere color separation has been put out quite clearly. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). By this i mean anything which can't be done by processing the "plates" as separate grayscale channels (see Øyvind Kolas's post).

greetings, peter

El jue, 26-03-2009 a las 21:43 +0100, yahvuu escribió:

Hi all,
just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first.

It won't be useful if the image has to be imported in a program that actually lets you assign CMYK values. Following with my example, the bitmap could be imported into scribus and put together with a logo, with the right CMYK values. Chances are that, though quite similar, the colors won't be the same.

Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes.

But it will still be difficult to specify a color. For instance: I need the background of the image to be C=60%, K=100%. I'd use that combination because I want a rich black with cold shades of gray.
If I use RGB, the separation will include Magenta and Yellow depending on the output profile and I wouldn't want that.

Please do so. The general need for CMYK support beyond mere color separation has been put out quite clearly. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). By this i mean anything which can't be done by processing the "plates" as separate grayscale channels (see Øyvind Kolas's post).

It's fine to adjust the grayscale channels if we get a corrected preview interactively. In fact, that's the way you do some adjustments in Photoshop.
But there are several tools (channel mixer, curves) that is useful to have working in CMYK space.

---

Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created.
If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable.

2009/3/27 Guillermo Espertino wrote:

Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created.
If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable.

It was actually covered by one of the examples I provided, where a user had to do a poster in another application, because the main image was saved and sent in CMYK by his customer :) While it's important to teach customers not to @#$%$#% do so :), it's also important to teach *and* still be able to do the job. Otherwise you would have no return customers and that's what really matters.

Alexandre

Alexandre Prokoudine schrieb:

2009/3/27 Guillermo Espertino wrote:

Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created.
If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable.

It was actually covered by one of the examples I provided, where a user had to do a poster in another application, because the main image was saved and sent in CMYK by his customer :) While it's important to teach customers not to @#$%$#% do so :), it's also important to teach *and* still be able to do the job. Otherwise you would have no return customers and that's what really matters.

actually, it was your first item in the list ;)

greetings, peter

On Thu, 26 Mar 2009, yahvuu wrote:

just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up):

No, you're not.

That came out a little sharp. Let me try to soften it. You're entitled to your opinion, but I just want to make sure that there's no misunderstanding.

I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first.

I said before that I didn't think this was a real use for CMYK, but that is because I think that even if GIMP had CMYK support, it would not be able to perform this task well enough. GIMP would need native Pantone support, which I don't think is really that useful at this time.

As little as I trust Pantone to CMYK, I trust Pantone to RGB even less.

By this i mean anything which can't be done by processing the "plates" as separate grayscale channels (see ?yvind Kolas's post).

This is not fun. What you are suggesting is a very laborious process, and having such a process work properly would probably result in tens of minutes to hours of wasted time, depending on the image in question.

And it still would result in one of the following:

1.) A helper application which creates the CMYK image 2.) GIMP still is unable to deal with trapping or rich black.

On Thu, Mar 26, 2009 at 10:14 PM, Andrew A. Gill wrote:

As little as I trust Pantone to CMYK, I trust Pantone to RGB even less.

By this i mean anything which can't be done by processing the "plates" as separate grayscale channels (see ?yvind Kolas's post).

This is not fun.  What you are suggesting is a very laborious process, and having such a process work properly would probably result in tens of minutes to hours of wasted time, depending on the image in question.

And it still would result in one of the following:

1.) A helper application which creates the CMYK image 2.) GIMP still is unable to deal with trapping or rich black.

I was not describing user interface anywhere in my mail, I was describing underlying implementation mechanisms. GEGL stores pixels in buffers that can store and on demand convert to and from RGB, YCbCr, CIE Lab and Grayscale (dynamically extendable with other color models). Allowing image processing operations to be implemented using the models best fit for a particular operation.

GeglBuffers are not designed to deal with the special cases of multi spectral images (lets say 32bands), spot colors (print plates). Render layers as present in EXR files (blender for instance produces multiple layers that are useful in post processing of the render). These will have
to be dealt with on top.

For CMYK the following ops need to be implemented:

CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output.

CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof.

CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and
should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op.

Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented.

If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI.

The primitives above should provide both preview and control over CMYK the fact that the innermost core doesn't care about CMYK would probably bleed into the user interface in the form that not all operations operate on CMYK images like they do on RGB images, it might not even make sense to accomodate for having layers of CMYK objects but only cater to the hard-core CMYK needs of pre-press, with a core set of the tools (color picker, color balance, curves, color picker) aware of how to deal with the CMYK bundle. Doing things like blurs and pastes would normally operate on the single selected plate, but electing to process for all plates should be possible.

At the moment I do not have interest in CMYK but the above outline is in line with my ideas on how GEGL should evolve.

/Øyvind K.

Date: Thu, 26 Mar 2009 23:08:37 +0000 From: =?ISO-8859-1?B?2Hl2aW5kIEtvbOVz?=

For CMYK the following ops need to be implemented:

CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output.

CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof.

CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and
should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op.

Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented.

If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI.

FYI, most inkjet printers these days are actually 2 bits per physical channel.

A lot of this already exists in Gutenprint; you may want to look at that.

On Thu, 26 Mar 2009, ?yvind Kol?s wrote:

I was not describing user interface anywhere in my mail,

To be honest, I think I missed your message.

If I have mischaracterized what you have said (and judging from what you say below, it looks like someone has), I crave pardon.

Here's what I was disagreeing with:

yahvuu:

Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw).

To justify this, the message continues:

yahvuu:

By this i mean anything which can't be done by processing the "plates" as separate grayscale channels (see ?yvind Kolas's post).

It sounds to me like the latter sentence is referring to the UI, considering the content of the former sentence.

I was describing
underlying implementation mechanisms. GEGL stores pixels in buffers that can store and on demand convert to and from RGB, YCbCr, CIE Lab and Grayscale (dynamically extendable with other color models). Allowing image processing operations to be implemented using the models best fit for a particular operation.

I certainly don't take issue with that.

At the moment I do not have interest in CMYK but the above outline is in line with my ideas on how GEGL should evolve.

At first blush, what you said seems about right. I'll read it more closely and give it more thought.

Hi all,

my previous posting does not stand a quality test, to put it mildly. To save the list from multiple nearly indentical follow-ups, i thinks it's best to bundle my replies here. My apologies for the noise.

yahvuu schrieb:

Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes.

that's my personal wishful thinking. I have to take the blame for misguiding user interface speculations.

Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space

this is plain wrong. Already the levels & curves example shuts me up.

greetings, peter

Hi,

On Wed, 2009-03-25 at 23:21 -0400, Louis Desjardins wrote:

At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)?

Without CMYK support in GEGL/babl, there will be no direct editing of CMYK in GIMP. So whoever wants to see CMYK editing in GIMP should help to
- change GIMP to do all editing using GEGL - make sure that babl/GEGL gains first-class CMYK support

Sven

Andrew A. Gill wrote:

As little as I trust Pantone to CMYK, I trust Pantone to RGB even less.

Actually, Pantone to Spectral to L*a*b* to device space (RGB/CMYK whatever) is pretty good.

Graeme Gill.