Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox [EMAIL PROTECTED] wrote: [cmyk comversion] Where I work it is a very critical process. Any tips here? If gimp would support CMYK on-screen, how would the users work be different? Do users actually adjust CMYK themselves or do they just draw using predefined CMYK values? I mean, is the principal problem the missing CMYK colours in RGB, or is the principal problem the looks the same on-screen as on print. The latter could be solved largely outside the gimp (tiff plug-in), the former obviously not. with less compulsive designers it is much less critical. This feature would not get gimp into prepress houses, but might help out the casual designer who is preparing artwork for a short print run. Would it be worth it? ;) The most common/best way to do trapping that I have seen is to trap after the rip using a program like creo/scitex full auto frame (which isn't quite as auto as the name implies:). Obviously, as only then you have the full image. Hey, the new postscript can do in-rip trapping ;- (adobe claims yet another revolution ;) even if it doesn't have a setting I dont think we should modify the default behaviour of gimp to work around a bug in quark :) well, it depends on wetehr you call this a bug or not. if quark lacks the functionality (if!) to bind profiles to images it's not a bug ;) 3. (optional, but important) finally enhance the paths to be multipart, contain holes etc. simon? smoon? ;) How is #3 optional? :) Well... it's the most difficult part. 1 and 2 could probably be done even in gimp-1.2, #3 is a problem. Also, if you don't have clipping paths you still can print many photos ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) Thanks for writing this stuff up. I think I should mention that I work in the prepress department of a highend lithographic printing company so that you know what my biases are when reading my comments below. 1. colour matching for photos is a don't care. Ok, this is a blatant lie, however, exact colours are not that much of a concern for photos. Much more important are logo colours (most companies have pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. You should not create a logo requiring Logo Colours in a program such as photoshop or gimp. You will get superior results using a vector based application such as illustrator. Sometimes you will need to match a logo captured in a photograph to a specific logo colour , but the first step would be to convert your photograph to CMYK. Logo Colours (aka spot colors or PMS colors) can already be used in gimp if you are only using one ink at a time. Just save your image as a grayscale tiff and place the image in quark using whatever ink you want. 2. Logo colours are not CMYK. Yupp. Logo colours might not be representable in CMYK at all (gold etc...). Even if, you often (but not always) want seperate planes for important colours. Most uses of spot colours want the concept of an indexed channel, i.e. a channel where each value represents a different palette colour. No bleeding with image contents. Gimp's channels can be used instead, which is not that perfect for all uses, but exists and at least photoshop doesn't offer a better solution ;) They also allow gradients of a single spot colour, which indexed channels wouldn't allow. Wether all this makes them easier or harder to use is something to explore. In my experience, when you are using a spot color in a raster image you are not usualy working with a logo. Usually you are trying to match a color in a photograph that is not representable in the CMYK color space such as some reds and oranges. Any image that you would want indexed Logo Colours for would be better off handled in a vector based program such as illustrator. 3. You don't print from within the gimp. At least you don't print brochures from within the Gimp. You use gimp for artwork, often the logos, but you obviously don't set text using the Gimp. You instead import images into some layout program (quark xpress ;). I was told that the principal reason for bad quality of gimp images within quarkxpress is that quarkxpress imports gimp's rgb tiffs like garbage. I was told that loading the rgb data into photoshop, associating sRGB with it (changing _nothing_ else) improved the quality very much, making the results reproducable on printers. Without absolute colours, they look different. In my experience people don't use gimp (or photoshop) for logos (I mean for print work, of course the web is a whole different story) I am not certain, but I think that the rgb-cmyk conversion is not done by quark, but by the postscript rip when you print your file. Regardless of weather it is quark or the rip that convert the colour, setting the colour profile to sRGB in gimp is the wrong fix. There should be a setting on either quark or the rip that tells it what color profile to use for images that have no assigned profile. Where I work, we _never_ place rgb files in quark. If a client of ours gives us file in RGB the first thing we will do is convert it to CMYK in photoshop. 5. Logos are done by overlays. At least one method of using spot colours is to create them as seperate channels. Tiff/Eps are reportadly able to save additional channels in a way that a program can read them sensibly. The spot colour planes are then laid over the other graphics. For this to work a mask is necessary, since channels range from white (not transparent) to channel colour, at leats in quarkxpress. It seems that traditional masks are not what's called for - instead you want a path saved in the tiff/eps file (don't ask me wether that is possible). This clipping path is then used for the overlay - gimp can't create this kind of paths, nor can it save it. The industry standard way of saving raster files that have spot channels in them is the DCS file format (A very close cousin of EPS). Clipping paths are commonly used to overlay an image over text or another image in quark.
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox [EMAIL PROTECTED] wrote: pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. You should not create a logo requiring Logo Colours in a program such as photoshop or gimp. You will get superior results using a vector based application such as illustrator. That's what I was told, too (together with: many people do it with photoshop anyways ;) Sometimes you will need to match a logo captured in a photograph to a specific logo colour , but the first step would be to convert your photograph to CMYK. But how critical is that process? Do you think that my main point - cheap conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and would enable gimp to enter prepress world (even if not at all perfect)? Logo Colours (aka spot colors or PMS colors) can already be used in gimp if you are only using one ink at a time. Just save your image as a grayscale tiff and place the image in quark using whatever ink you want. What about the clipping path, though? I'd guess you want to overlay these layers often. are not usualy working with a logo. Usually you are trying to match a color in a photograph that is not representable in the CMYK color space Any image that you would want indexed Logo Colours for would be better off handled in a vector based program such as illustrator. I was told that trapping can be done with expensive plug-ins for photoshop only, which would make sense, since trapping is (AFAICS, no idea actually) not really well-defined for photos, what users would buy such a trapping plug-in for photoshop? In my experience people don't use gimp (or photoshop) for logos (I mean for print work, of course the web is a whole different story) But gimp already works fine for the web, so that's a problem ;) I am not certain, but I think that the rgb-cmyk conversion is not done by quark, but by the postscript rip when you print your file. That would nicely explain why it looks like crap. setting the colour profile to sRGB in gimp is the wrong fix. There should be a setting on either quark or the rip that tells it what color profile to use for images that have no assigned profile. Unfortunately, users usually don't have control over the rip. I guess whatever rip is used just uses it's defaults for RGB. quark is a difefrent story - what if quark doesn't have such a setting? But I think that acse would be rather irelevant once we have CMYK in tiff. can't create this kind of paths, nor can it save it. The industry standard way of saving raster files that have spot channels in them is the DCS file format (A very close cousin of EPS). I knew eps couldn't do it (directly ;). Ok, prepare for: REVISED CONCLUSIONS (ordered my importance). 1. implement CMYK saving in tiff and eps. 2. enhance tiff(?) eps to save all channels paths in whatever format is actually understood (DCS for eps). one path must be marked as clipping path (e.g. by name Clipping Path or by some parasite (gimp-clippath on the image containing the ascii form of the path tattoo or somesuch). 3. (optional, but important) finally enhance the paths to be multipart, contain holes etc. simon? smoon? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
pcg@goof.com ( Marc) (A.) (Lehmann ) wrote: On Tue, Nov 27, 2001 at 05:51:14PM +, Jens Ch. Restemeier [EMAIL PROTECTED] wrote: 2. Associate sRGB or any other colourspace with the saved data in tiff/eps. It doesn't matter wether it's true or not, just give programs something to depend on. Well, actually this would be true. sRGB is defined using the phosphors standartised for HDTV and used for monitors. Ehrm. Each and every monitor phosphor is different. lighting is different. Contrast settings are different Okay, let's write this in other words: sRGB is based on ITU-R BT.709 primaries which are for example standartised for HDTV and should be reasonably close to most computer monitors, too. And if you don't adjust your monitor for your lighting conditions you can't expect any colourmanagement to work. My point is/was, if you tag your graphics as sRGB you are as right as you can get without doing real colourmanagement (i.e. translating from your screen into a specific coloursystem). Reading material: http://www.inforamp.net/~poynton/ColorFAQ.html http://casa.colorado.edu/~ajsh/colour/rainbow.html http://www.srgb.com/ And as gimp does no colour management except for a gamma correction on display we can ass assume that the image is in sRGB colourspace. We can't ;) I know. Jens P.S.: I CC'ed this back to the list. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Tuesday, 27 Nov 2001, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) [observations snipped] Wow! Marc Lehmann has written an email that's actually useful and well-thought out! His 60% CMYK makes sense to me. Now all I need is the time to implement it. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Hmm .. this is a pretty cool writeup. :) On Tue, Nov 27, 2001 at 03:10:15PM +0100, Marc A. Lehmann wrote: [...] CONCLUSIONS - THE 60% WAY TO CMYK If one were so bold as to draw some conclusions, they would probably be very similar to these: [...] 3. Educate users about channels and what they can be used for - on this Systems I was frequently confronted with users who were unhappy with the gimp because it didn't allow them to do things as easily as under photoshop. Often(!) I was able to get exactly the same results, with a much easier and faster sequence than the one that user used with Photoshop. Can you remember any specific examples of this? It would help show us where the gimp's channels and layers setup does things better in some sense. Malcolm -- Tolkien is hobbit-forming. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Hi, 2. Associate sRGB or any other colourspace with the saved data in tiff/eps. It doesn't matter wether it's true or not, just give programs something to depend on. Well, actually this would be true. sRGB is defined using the phosphors standartised for HDTV and used for monitors. And as gimp does no colour management except for a gamma correction on display we can ass assume that the image is in sRGB colourspace. (Well, sRGB is the implied colourspace on Windows(TM) if you don't set enything specific.) Jens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
