On Tue, Mar 8, 2011 at 3:34 PM, Ãyvind KolÃs <pippin@xxxxxxxx> wrote: > 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, True enough, but I'm living on "that edge" ;). > 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. I believe, color management is one of the most misunderstood and non-understood subjects out there generally :). > 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. I don't see it different. > 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). I love that notion! I think of it similarly. Yet there's one thing in print specific color models that's notoriously neglected in color managed systems: image isn't magically put on some white (what is white exactly? ;)) universal material. Image goes through CtP (most of the time nowadays), machine and is placed on material of different characteristics. So, what is really needed for good color management is the profile of each of these stages, or at least whole process. Of course there are some "standard" profiles (e.g. FOGRA) but they all fall short when one is to use for example uncoated, dark red paper. I know, I knowâ egde case, yet as I said before I'm quite often on such edge :). > 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; I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simpleâmaybe even undoableâthat way, but I do like the idea of color model that has complete coverage of visible spectrum. > 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. True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too). Best regards! thebodzio _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
