Peter Nermander wrote: > Excuse a novice here, but is that REALLY a job for a pixel editor? A pixel is > a > pixel, you don't have dot gain for a pixel. Dot gain comes in when you > rasterize > the pixel. And rasterization is the task for the RIP You are right, there is no dot gain on pixels. The reason why you need to worry about GCR, UCR, and the ink separations is because when you convert an image from RGB to CMYK, you are making use of a color table that tells the app how to break down the RGB colors to approximate what you see on the monitor to what inks will be used to describe the same information in the CMYK color space. In a professional environment it is crucial to be able to choose how the colors get separated.
You can look up GCR and UCR in wikipedia for rough explanations about how they break down colors respectively. The gist is that with GCR (Gray Color Replacement) the black channel holds most of the detail, with UCR (Under Color Replacement) the detail is mostly in the CMY channels. They both have their merits, but I use UCR to convert all of my images. Then I go back and tweek what needs to be tweeked. This kind of thing is important because once you convert the image and take the detail out of a channel, it is gone. You can push the remaining pixels around to alter the image, but the same document converted using each GCR and UCR will show drastically different results. Personally, I am just not comfortable using a 'conversion on the fly' method like the one used in Scribus. I have nothing against the Scribus devs, who have otherwise done great work, but I just cannot work that way. A freshly converted image will always need additional work. If the Gimp cannot allow for CMYK work, then other tools must be used. It was pointed out by Hal, I believe, that there are other OSS tools like Krita and Cinepaint that can be used for CMYK work, and they are certainly another way to go for OSS color correction. If not, there is always Photoshop under Crossover Office. -Nate
