On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek <thebodzio@xxxxxxxxx> wrote: > have nice black background. Most of the times CMS will try to simulate > that with all colors while it's better to use e.g. just full black and > cyan. Another example: you need to do some trapping. Sometimes it can > be done in RIP but you need to trust that to RIP itself and print > house. These are only a couple of arguments, leaving aside quite > similar cases of printing with paints different than C, M, Y and K. There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense, it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen. In the few cases where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice. Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces; with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ ; http://ffii.org/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
