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.
Gimp-developer mailing list