CMYK in RGB - Explained

31 October 2010

When I first posted the action set for this, I promised I'd write more later about it.  Since then, I've also received a few inquiries asking that I explain what the actions are doing in order to achieve something which many believed wasn't possible.  Today, after much, much too long a delay I'll do that - it seems like an easy topic in comparison to what I last wrote about!  I'll even leave out the math... well, mostly!

To understand what's going on, we need to discuss what happens when we normally convert an image from RGB to CMYK.  In the first place, the color modes themselves are opposite one another - where RGB is additive, CMYK is subtractive (or multiplicative, depending on the verbage you prefer).  This is fairly straightforward to understand, as adding more light in RGB makes things brighter (which is intuitive), while adding more ink (which absorbs, or subtracts, more light) in CMYK makes things darker.  That's the change in color mode.  [If you'd like to read more or see a video, I suggest Joe Francis' discussion of it here].

But traditional conversion to CMYK also involves converting to a different color space.  Not surprisingly, standard printing presses can't reproduce the same range of colors which our increasingly wide-gamut monitors can (at least, not at prices most of us can afford).  So conversion to CMYK also involves a color space change which results in the undesirable color shifts which many users end of feeling is just a part of the CMYK color mode.

To be clear: CMYK conversion also deals with the dot gain of the printing press involved, the interplay of the machine's physical configuration as well the actual density of individual inks.  Like the mathematical difference between subtractive and multiplicative blending, that's beyond what we need to deal with today.
The actions which I presented avoid the issue of color shifts by maintaining the same color space.  Now, there are two ways which we could go about doing this.  In the first, we could pull an old Dan Margulis trick and create a 'false' CMYK profile, spending a lot of time tweaking our color coordinates to both give us a suitably large color space as well as ink primaries which could accurately create said colors.  But that takes time.  And false profiles confuse people.  And above all, it doesn't give you those channels back in your RGB document - which is what I needed at the time.  So let's go with option two.

In option two, we calculate the CMYK equivalent values manually as if we were acting as PS's conversion engine.  I'll spare you the actual math, but the crux of the concept is to act like we're already in a CMYK document.
  1.  We start (because we have to) with the hard part - creating the black layer.  Whereas each of the other channels has a direct analog in RGB (C->R, M->G, Y->B), K has nothing which we can easily relate it to.  Because the CMYK color mode is subtractive, that means that the equivalent K value could be anything from 0 up to the lowest value of the other "inks" (C, M, or Y).  To find that 'maximum black' value, we merge the inverse of each of the R, G, and B channels into a new channel using the Darken blend mode.
  2. Next, we let the user decide whether they want to lighten that black value at all before continuing by giving them a standard Curves dialog.  This lets them tamp down that black to something which gives more emphasis to the color channels should they desire it.
  3. Then we tell PS to show us what the 'CMYK' image would look like without its black component, by subtracting it out of the whole.  Conveniently, this creates the R, G, and B inverses of the C, M, and Y channels which we're after and so we can simply make inverted copies of each to create our final channels - it's that easy!
All of this happens with almost no loss of image fidelity.  In 8bpc color, there is literally no difference between the original image and the CMYK version which we generate.  In 16bpc color we can get errors as high as 64 / 32768, though the average is < 16 / 32768 per channel.  Functionally, it's a lossless conversion while retaining the entire color spectrum which existed in the original image.

A related note and a few completely unrelated observations which I made while writing this:
  • Just because the actions as provided are functionally lossless doesn't mean that the academic in me is satisfied.  When I get some more time I'm going to try to actually make the reconstruction perfect.  If you beat me to it, please let me know :).
  • Don't use the color sampler tool (Info Palette) to test error levels at anything less than 100% zoom.  Otherwise it uses that same awful resizing algorithm which PS uses to preview images on non-HW-accelerated systems in order to estimate what a value might be, not actually reporting the real value to you.  This can give you all sorts of ghosts to chase.
  • There are some idiosyncracies to the way that Calculations and Apply Image each do what should be the same math.  The differences are small, but real.  If I have time in the future I'll delve deeper into it, but just be aware of it if it's the sort of thing which interests you.
  • As discussed a few times elsewhere, there is a difference in the output between the Image->Adjustments version of the Brightness / Contrast tool and its Adjustment Layer counterpart, specifically in how Legacy-mode Contrast is calculated.  The Image->Adjustments version calculates it based around the actual mean value of the image, while the Adjustment Layer version assumes a mean of 127.5.  The results are the same, albeit offset from one another (in brightness) by the distance of the actual mean from 127.5.  Generally speaking that's not terribly important (though it does make an argument for greater granularity in the PS controls), but I filed a bug report with Adobe just the same detailing the problem and asking that they bring the tools into alignment with one another.  The discrepancy confuses some people horribly.  Vote for me as your CS6 Beta Tester :).
Please feel free to ask if you still have questions!

      4 comments:

      Kermy75 said...

      Hi mate

      I've been following since the early days of high pass sucks. And I gotta say you are a genius...

      With this new action I actually understand what you have done and it makes perfect sense how you came about it.

      As far as my colour theory goes, the reasons why we have to assign a CMYK colour space is due to the print limitations of being able to mimic every colour variation within the RGB colour space. And the reason why, and I use Fogra 39 CMYK in my conversion, is that within the UK, it seems to be the industry standard as to what current print is able to achieve. What I'm unsure about is if I 'swap' the Fogra converted channels with your ones, am I creating a CMYK image that is unachievable in print?

      The reason I ask is that currently within my workflow, my CMYK Fogra 39 image when viewed on my calibrated Eizo is pretty spot on when viewed against a calibrated printed proof. Just wondering if you plan on testing this out further using proofing. I'd be very interested in the results.

      If your method can produce a more vibrant CMYK printed image that is the same as the vibrant RGB image I start off with, you will officially be my God...

      Kermy75

      Max said...

      I actually love having controll over the black channel this way. Good for color corrections of skin. This is almost as awesome as the frequency separation which I now use almost every day. I'm actually totally blown away that I've found your blog. You're picking PS apart piece by piece and i love it! :) Greetings from Sweden /Max

      Sean said...

      @Kermy75 - Swapping channels between those which these actions generate and those created by PS itself when you convert to that other color *space* (Fogra 39 CMYK) will not improve the color conversion, unfortunately. That is simply a matter of a smaller color space and the limited ways in which we can map 'big' color to 'small' color. If there's sufficient interest I'll write more about getting better results from color space reduction another time, or if you're really anxious, Dan Margulis' books are fantastic references for color conversion and why sometimes letting PS do all the thinking isn't as good a solution as taking matters into your own hands. Of course, beware - it's pretty heady stuff!

      @Max - Thank you sir!

      Kermy75 said...

      Kinda what I thought was the case. I look forward to your colour space reduction analysis with anticipation. Geeky I know! But you my friend have brought back my need to know why, just cause i'm the curious type. And I'll definitely chase up Dan Margulis', thanks for the heads up...

      -