On 3/22/11, Jacek Poplawski wrote: >>> I need CMYK support for photo retouch, to create better colors. >>> CMYK is no different than LAB, HSV or RGB. It is colorspace like >>> others, but uses 4 channels instead 3. >> >> Right, all colorspaces are equal, but some are more equal than others >> :-) The willingness to go from a wider gamut to a narrower gamut for >> editing what will then go to a different color space once again is, >> er, equally amazing :) > > I just mean that they should be treated similarly :) For photography? I very much doubt that. When it comes to all things related to photography, the point is to preserve as many colors as possible. Which is how all those ProPhotoRGB and the like were introduced all those years ago. Jumping between wide and narrow gamuts effectively kills useful information. Hardly better colors, sorry. It *might* be OK to go from RGB to CMYK in case the picture will then be saved to CMYK TIFF or CMYK PSD and inserted into a DTP app, an even then you need a profile for exactly the printing device that will be used, because in case of printing color reproduction depends on things like the kind of paper and the kind of inks. There simply is no such thing as device independent CMYK profile. So editing an arbitrary picture in arbitrary CMYK color space defined by an arbitrary ICC profile simply doesn't make any sense. For some reason this has become a sad common practice, but it doesn't mean that it's the right thing to do :) Even working in CMYK natively from scratch makes sense in just one case: when you create an illustration for printing and, again, you have the profile for the device that will do the printing. Otherwise you just screw up color reproduction. Given how design tends to be multidevice now, especially branding (same pictures used in e.g. printed leaflets and on website) the best workflow is to work with high bit depth precision in a color space with as wide gamut as possible (not CMYK) and then selectively tune things for every output device. The earlier proposal by Peter Sikking (a special projection in output device color space) makes quite a lot of sense there, *if* there will be additional tools implemented to do on-site work like trapping etc. and *if* it will be possible to assign spot colors and export them properly to PDF. The latter right now simply isn't possible, because the existing PDF exporter uses Cairo which is still missing spot colors implementation in thePDF backend. There are so many things regarding CMYK and printing like GCR and UCR and best method for rendering intent for each job that should be taken into consideration when going from RGB to CMYK that treating CMYK as any arbitrary color space is simply impossible. I can understand how this could be frustrating for someone who is used to treat CMYK exactly that way, though. Alexandre Prokoudine http://libregraphicsworld.org _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
