-- cut -- > The agrreded idea among GIMP developers is that CMYK as an _image > editing mode_ will not be implemented in GIMP. Where as there maybe > in the future more straightforward ways foreasier CMYK separation and printing. > That is due to the fact that CMYK is more the mapping to inks of a > printing method > than a color mode. Quite similar can be said about RGB or any other device dependent color model. But first of all there is not only one CMYK. CMYK name itself denotes a family of color spaces. So it is for RGB too. > Even though this is the "de facto" printing method for > volume, and even personal printing, CMYK values don't have a > 1:1 mapping of color values as are visible to the eye, or representable > in computer videos or images. It's not so easy. Each CMYK color vector can be injectively mapped to color visible to the eye. > (which color is "black" in an image? > (100, 100, 100, 0), > (0,0,0,100) or (100, 100, 100,100)? ) > That said, for generating CMYK Tiff files as expected for some of > today's printshops, and even allowing for some per-plate correction > of the amount of colorants in each part of the image, there is the third party > plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ ) > I believe that installing and getting used to that might your requirements > for CMYK. While useful I consider it only a half-solution. > So ..what is the idea for GIMP presently and on the long term, is that proper > printing requires actually conversion between the color spaces of the various > devices used in the press chain (video monitor, proof printer, large > scale printer), > making use of _color profiles_ . With proper calibration of devices and use of > color profiles one can ensure that a color shade will look on paper, under > certain lighting conditions, as it does look on the screen at editing > time. All the > time the colors are represented internally as an RGB tripplet, and > just the printing > driver, or software, takes care of mapping the normalized color to the actual > colorants in use on the device - taking into account information on the > device's color profile. Even so, if we consider ICC color management scheme, there's still potential problem: rendering intent. Which one will printshop use? It's all OK if used colors are well within output color space, but what if not? It's not so rare case. In such case the decision which colors to transform unreproducible colors to is left to printshop not the designer. And what if you want to use some non-standard trick with colorants values? Every color conversion can be done with properly prepared color profile but in practice it's much easier and faster to modify color values in device color space and preview results e.g. on RGB device than mangle color profile each time. Quite often it's better to drop color management completely on "printing side" and prepare material directly for specific device (more exactly: CtF/CtP + actual printing machine + paper) – gives you less surprises in the end. Color management is cute idea but it's not panaceum and sometimes we're better off without it. > On GIMP's roadmap, there lays, in the future, a way to preview a per plate > separation of the image prior to having it exported to a CMYK file in a > more integrated way than currently possible with the separate+ plug-in. But that > depends on the implementation of a new, very different, U.I. that will allow > for non-destructive editing, among other things. Work on this U.I. will start > only after current development cycle (which will yield GIMP 2.8). > > Meanwhile, if you find that GIMP with the Separate+ plugin is not > enough for your > office's needs, there are other Open Source graphic editing programs that > offer varying CMYK capabilities, such as Krita and Cinepaint. -- cut -- One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having "metallic" overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for? My best regards tb _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
