On Fri, 2001-11-30 at 10:06, pcg@xxxxxxxx wrote: > On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox <jaycox@xxxxxxxx> 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? Users actually adjust the 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. Having the image on screen look similar to the printed image is nice, but not required. The problem with rgb is not that it can't represent some colors available with CMYK inks. The problem is that aproximatly 20% of the colors available in RGB cannot be represented in CMYK. If you simply map the colors that are outside of the CMYK gamut to the closest possible color you end up with flat spots in your image. There are other methods for mapping between dissimilar gamuts such as the different ICC profile rendering intents, but none of them work well on all images (and for many images none of them work well). The most important task that prepress image editing applications have to accomplish is this: After looking at a proof of your image you must be able to correct the image so that your next proof will look like what you want it to (usually the transparency that it was scanned from). This is generaly easier to do when you are working in the same colorspace as your printing device. There are certain classes of corrections which would require deep voodoo if you were trying to do them in RGB mode (for example getting rid of banding in individual seperations, or adding shape to highly saturated portions of your image). Jay Cox jaycox@xxxxxxxx
