Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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). -- Jernej Simončič http://eternallybored.org/ Creativity varies inversely with the number of cooks involved with the broth. -- Fitz-Gibbon's Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
El Martes, 24 de Marzo de 2009 03:03:36 Guillermo Espertino escribió: Does that indicate that separate+ is what needs to be enhanced, rather than the core application? This discussion was about a PDF export plugin at the beginning. I was trying to make evident that a PDF export plugin is probably useless without CMYK/SPOT/VECTOR LAYERS, and improving and integrating the Separate+ Plugin instead of focusing on a PDF exporter would make sense and a big difference. I totally agree with Gez. a PDF export plugin now as if you uses convert image.jpg image.pdf from imagemagick Its more usable to improve separate first and later, when CMYK/SPOT/VECTOR LAYERS where integrated on Gimp, make a complete pdf export plugin. Salu2 de jEsuSdA 8) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
CMYK exists because, though is possible theoretically, it isn't possible to generate black from mixing CMY inks. As the C, M and Y inks aren't perfect and have some contaminants, mixing them ends up in a dirty brown instead of pure black. That's why CMYK exists, and that's why it isn't so simple to print an RGB image. The problem resides mostly in the generation of black and gray shades. Although there are systems that do a great job converting a photo to CMYK on the print side, it's still a problem to do a simple task as placing a pure black overprint on a solid color background without destroying some underlaying information on the separation. I'm a designer, not a photographer, and an image manipulation program is an essential part of my workflow. And placing some black text, or editing a large image with a black or gray background, adding black drop shadows, aren't rare at all. And it's a pain without the ability of editing the separated CMYK. It's not about if the printer will handle the file or not, is about creative control. Sometimes you NEED to control the black overprint. Sometimes you need to use spot colors and you need to control the channels and how they overprint. Even with Adobe software, before having spot channels in Photoshop, it was a common practice to separate to CMYK to make 2, 3 or for 2 inks prints (replacing the corresponding plate's ink for a custom ink). Simply because other programs didn't support the Adobe's custom multitone files but did support CMYK tiffs. Well, I can't do duotones with Gimp to insert in a 2 inks flyer. CMYK editing would help. I can't control the black generation of a separation, because the separate+ plugin doesn't support that. It just support existing profiles and there is no control. I can't control CMYK curves. And trust me, that's extremely common. I can live without CMYK, I have some workarounds and can do some tricks, but it certainly makes my designer work harder and less productive. I can wait, I'm ok with the argument it's not trivial, requires a lot of work, requires a lot of refactoring. But I'm not ok when somebody says that it isn't necessary. Maybe it isn't for photographers, but it certainly is for designers. GIMP stands for GNU Image Manipulation Program. Not just for Photograpy. I think that CMYK editing is certainly in the scope of the product vision. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
From: Sven Neumann s...@gimp.org 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. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail l...@uunet.uu.net Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
From: Guillermo Espertino gespert...@gmail.com Date: Mon, 23 Mar 2009 19:59:53 -0300 CMYK exists because, though is possible theoretically, it isn't possible to generate black from mixing CMY inks. As the C, M and Y inks aren't perfect and have some contaminants, mixing them ends up in a dirty brown instead of pure black. Or dirty green/cyan, or dirty magenta, depending upon the colorants... That's why CMYK exists, and that's why it isn't so simple to print an RGB image. The problem resides mostly in the generation of black and gray shades. Although there are systems that do a great job converting a photo to CMYK on the print side, it's still a problem to do a simple task as placing a pure black overprint on a solid color background without destroying some underlaying information on the separation. I'm a designer, not a photographer, and an image manipulation program is an essential part of my workflow. And placing some black text, or editing a large image with a black or gray background, adding black drop shadows, aren't rare at all. And it's a pain without the ability of editing the separated CMYK. It's not about if the printer will handle the file or not, is about creative control. Sometimes you NEED to control the black overprint. Sometimes you need to use spot colors and you need to control the channels and how they overprint. Even with Adobe software, before having spot channels in Photoshop, it was a common practice to separate to CMYK to make 2, 3 or for 2 inks prints (replacing the corresponding plate's ink for a custom ink). Simply because other programs didn't support the Adobe's custom multitone files but did support CMYK tiffs. This really sounds like you're using black as a spot color rather than going generic editing in CMYK space. I question whether doing this in an image editing application is really the right thing to do. If you're doing black text, you probably want the text to be vector rather than raster anyway -- printing an image scaled to 240 DPI is fine, but the text won't look so good at that resolution. In that case, you're better off using something like Scribus to do that kind of overlay, at least until GIMP has vector layers. Well, I can't do duotones with Gimp to insert in a 2 inks flyer. Which again is a spot color kind of use case rather than a CMYK use case. CMYK editing would help. I can't control the black generation of a separation, because the separate+ plugin doesn't support that. It just support existing profiles and there is no control. I can't control CMYK curves. And trust me, that's extremely common. Does that indicate that separate+ is what needs to be enhanced, rather than the core application? -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail l...@uunet.uu.net Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
Hi Robert, thanks for your comments. This really sounds like you're using black as a spot color rather than going generic editing in CMYK space. That was just an example. Another example could be just putting an image in front of a gray gradient background. In my experience, it's not that easy to find a printer that can convert a RGB gray into a perfectly CMYK neutral grey. Or isolating a photograph, putting it on a solid color layer and apply a drop shadow of the isolated image on the color. Why should I send an RGB file and see how my printer's RIP separates the grays and the shadows when I could be specifying: I just want 100% black over the color? They are only real world examples. Probably there are excellent print shops in Germany or USA that deliver excellent results from an RGB jpeg, but that's not always the case. I question whether doing this in an image editing application is really the right thing to do. If you're doing black text, you probably want the text to be vector rather than raster anyway -- printing an image scaled to 240 DPI is fine, but the text won't look so good at that resolution. In that case, you're better off using something like Scribus to do that kind of overlay, at least until GIMP has vector layers. Again, that was just an example. It may be true in a brochure or a magazine page, but what if you need to add a texture to a title, breaking the borders of the characters with a grunge brush? or something like that? But let me show you a very simple example: http://www.flickr.com/photos/superdd/2781429410/ This image was created in Inkscape and exported as PNG. Then in Gimp the yellow part got some texture and color work. What if I want to put that image in a page of a magazine that I'm creating in Scribus, and I want the black part of the image to be the same black (100% black) than the text. In that case I would have, according to your workflow, to: -take the image to gimp, make the texture part, remove the black part, save it, import in scribus the color blob and a black-only SVG version of the drawing, make them match in size and alignment (ouch, I should have imagined that I would need some bleed on the color shape to avoid alignment errors), and export them as a CMYK PDF to send to the print shop Or simply separate in GIMP to CMYK, remove the black part of the CMY channels and tweak the black channel, save as TIFF and import in Scribus. Call me crazy but I choose the last one. Of course there are alternative ways, but sometimes it's faster and more direct, thus preferable, to do it with the image manipulation program that using three or four separated applications for a simple task. Which again is a spot color kind of use case rather than a CMYK use case. Yes, but we don't have spot channels either. At least having CMYK would work as a viable temporal solution until we have spot channels. I find it hard to imagine that GIMP will support spot channels if it won't support CMYK channels. It wouldn't make much sense to add a spot channel to an RGB image, would it? Does that indicate that separate+ is what needs to be enhanced, rather than the core application? This discussion was about a PDF export plugin at the beginning. I was trying to make evident that a PDF export plugin is probably useless without CMYK/SPOT/VECTOR LAYERS, and improving and integrating the Separate+ Plugin instead of focusing on a PDF exporter would make sense and a big difference. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
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: http://www.ets.ru/images/pk75.jpg 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: http://i158.photobucket.com/albums/t102/superluser/whywetrap.png 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: http://www.graphic-design-employment.com/over-printing.html 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. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
