Conversion formulas from RGB to CMYK

[~silvery~]

Hi,

I've been writing a Colour swatch tool (in excel! hell yeah!) which allows me to pick a bunch of colours, generate complimentary colours from them, blend between 2 colours in a set number of steps and a whole bunch of other cool stuff, and then output this as a photoshop or illustrator swatch file.

As part of this tool I want to be able to covert the rgb values to cmyk. There is very little information on this on the web and what there is is fairly inaccurate.

For example,

RGB:50,128,128

Converts to CMYK 61,0,0,50 (%) using the formula found at easyrgb.com (this formula is the most prevalent one on the web/web forums)

Photoshop converts these RGB values as CMYK: 80,33,48,8 (%)

While these two colour values are *similar* the ones generated by the easyrgb formulas are nowhere near the photoshop values.

See? stupid useless formulas. (I am aware of the differences and overlap of the two gamuts)

Whilst I know that the conversion done in photoshop is done using ICC templates, and that often these conversions are device dependant, there must be a more realiable way of converting from one colour space to another using good old reliable cold hard maths.

Does anyone know what that might be? you guys at Adobe: I AM LOOKING AT YOU.

Hope you guys can help,

~silvery~

For reference I have included and commented the easyrgb formulas:

First: RGB -> CMY

C = 1 - ( R / 255 )
M = 1 - ( G / 255 )
Y = 1 - ( B / 255 )

Second: CMY -> CMYK

var_K = 1

Initally sets var_K as 1, although this is dependant on variables below

if ( C < var_K )   var_K = C
if ( M < var_K )   var_K = M
if ( Y < var_K )   var_K = Y

This bit finds the smallest value from the CMY range and sets this value as var_K

if ( var_K == 1 ) { //Black
    C = 0
    M = 0
    Y = 0
}

If var_K (the value that K is calculated from) is 1, then all the CMY values are reset to 0

else {
    C = ( C - var_K ) / ( 1 - var_K )
    M = ( M - var_K ) / ( 1 - var_K )
    Y = ( Y - var_K ) / ( 1 - var_K )

If the value of var_K is anything other than 1 then use the smallest value from the CMY range

}
K = var_K

The value of K as filtered out from the conditions above

[Lou Dina]

Silvery,

A set of color numbers expressed as RGB or CMYK mean nothing "UNLESS" a profile is attached.  The profile establishes the boundaries of the RB or CMYK gamut.  RGB and CMYK are "device dependent", meaning that you can get different colors with the same set of numbers.

For example, 240R/25G/30B is definitely a Red, but exactly what color red?  If you send that color to your inkjet printer, you will see red all right, but the precise color of red depends on the inkset, printer, resolution, and paper.  With a wide gamut inkset, a good hi rez printer, and a wide gamut glossy photo paper, that color will be a vibrant red.  If printed on uncoated copy paper on a mediocre printer, those same numbers will result in a rather washed out red.  Same scenario with CMYK....it is device dependent, and the profile gives the numbers meaning.  No profile, no meaning. It's like walking into a video electronics store and looking at 100 TVs, each playing the same station, but they color, contrast and brightness of each TV is different.  Which one is right?

Lab color space is "device independent", so a specific set of Lab numbers always means the same thing, regardless of the output device.  Of course, not every output device can output all colors.  Lab (or a variant) is usually the universal translator that helps devices see color consistently.  Since it is based on human vision, it doesn't need a profile, but RGB and CMYK definitely do.

If you want to learn more, check out www.BruceLindbloom.com and go over his information.  He has formulas and translators galore, and more than enough information to choke a mule.

Hope this helps some.

Lou

[Oliver Krylow]

Thanks Lou,

that clarified the relationship of the numeric color value and color profiles for me.

So are there any "meta" color profiles out there ,that come with their own RGB <-> LAB <-> CMYK conversions, or must every piece of software come up with its own conversion between profiles?

[warzenbeisser]

Hello Oliver,

There are many RGB and CMYK colour spaces that could be considered "standard" – the choice is, however, always arbitrary. For practical purposes, the way to go would be to pick a suitable pair, say sRGB and "SWOP coated v2" (for a workflow from sRGB office documents to U.S. standard web offset printing), and then specify that the conversions you derive thereof just apply for said combination of colour spaces. Unfortunately, there is just no "one size fits all" approach to colour management as explained in the previous answer you received.

Edit: Maybe I misunderstood your question. As per the ICC standard, each ICC colour profile comes with embedded conversion tables from/to the profiled colour space to/from the standard profile connection space (CIE XYZ or CIELAB) for each of four possible rendering intents (perceptive, relative colorimetric, absolute colorimetric, and [maximum] saturation). So the "meta" space you look for is neither RGB nor CMYK but the PCS, i.e. LAB. The conversions themselves are governed by the ICC's specifications, and these are plain math, although different CMMs (colour management modules) might yield slightly different values due to the mapping of out-of-gamut-colours in particular ... Yes, colour science can be very confusing. 😉

Regards,
Eric

[Lou Dina]

Oliver,

I'm not sure what you mean by the term 'meta' color profiles, but I'll take a stab at what I "think" you are asking.  There are some fairly widely accepted "standards" out there for both RGB and CMYK.

In the RGB world, for example, sRGB, Adobe RGB (and to some extent, ProPhoto RGB) have a fairly wide following. These are all ICC profiles, which nail down the boundaries of the color gamut and the definitions of any tri-stimulus combination of red, green and blue. Basically, they are matrix profiles that establish the positions of the Red, Green and Blue primaries, and these positions define the outer limits, or color gamut, of the color space. sRGB is a relatively small color space, so some viewable and printable colors get clipped (sRGB is the general internet, email standard and is widely assumed for many non-color managed appplications, printers, etc). sRGB can handle a fairly wide range of colors, but does clip some colors in brightly colored originals. It has the advantage of being the most widely adopted standard, plus the steps between colors are very close together. I use sRGB for average images, most people pictures, etc. Adobe RGB spreads the primaries further apart, so it describes a wider color gamut. Because the primaries are further apart, the steps are slightly larger from one color to the next, but marginally so. I use Adobe RGB for most of my brightly colored images that will get clipped in sRGB. Adobe RGB is also generally a good choice for images that will ultimately go to a printing press or inkjet. ProPhoto RGB pushes the primaries WAY apart, so it describes a HUGE color gamut...in fact, many of the colors that can be defined in ProPhoto fall outside human vision, and certainly monitors and printers.Due to the wide spacing of steps in ProPhoto RGB, images should be worked in in 16 bit, otherwide you may see some banding and posterization if large edits are made.

In the CMYK world, certain "standards" have been established, mainly for commercial offset printers (both web and sheetfed presses). By creating a standard, they are trying to establish the ink limit, densities, color gamut, dynamic range, gray balance, etc, of a "generic" sheet of commercial printing paper on the average well-maintained press using standard ISO inks, using good process control, mesurements, etc. By it's nature, this process has to encompass a wide cross section of presses, so it may act as a limitation on what some modern presses are capable of, but that's what standards usually do. If a good printer, with a modern press and great process control decides to sidestep the standard, they can probably extend color gamut, dynamic range, etc, but at the cost of no longer being "standardized". If commercial printers are "truly" trying to meet the standard, they will run tests, take measurements, and adjust their entire workflow so it matches the standard, within acceptable tolerances. Lots of shops "claim" to adhere to SWOP or GRACoL standards, but the majority of them don't. Standards for presses make some sense, because blending CMYK inks together (especially if they use ISO standard inks) on paper usually has a reasonably narrow range that works, though the paper makes a huge difference. (the same cannot be said for inkjets, monitors and many other processes, so they generally do not have standards). So for presses, there are standards for matte and coated papers, web presses, sheetfed presses, newsprint, etc. Each of these standards has its own ICC profile (or a family of profiles) that establishes ink limits, color gamuts, etc.

All ICC profiles have the necessary tags and data to comply with the ICC specification. One of those requirements is a "profile connection space", which is usually L*a*b* or a variant. So, an file on your computer may be tagged as an Adobe RGB file, and if you wish to prepare it for a sheetfed press using glossy stock, you could convert the file to GRACoL2006_Coated1v2.ICC (an industry standard profile for No. 1 coated stock on a sheetfed press). Since both files have the ability to "speak Lab" a translation can be made from one color space to the other. The numbers in the Adobe RGB file will be converted to L*a*b* (the universal translator), and then the L*a*b* numbers will be converted to CMYK, specifically GRACoL2006_Coated1v2.ICC. So, now you have a file in CMYK space with new numbers. It is worth noting that RGB has only three colorants to define colors, but CMYK has four. So, while in RGB there is only one way to define a specific color, in CMYK, there are many possible combinations that can generate many colors. This adds complexity to the equation. The CMY colors are called subtractive primaries, and are opposites of RGB (additive primaries). The "K" (black ink) is added for text, line art, neutrality, extra Dmax, and because the CMY inks are not pure and don't deliver a true black all by themselves. If the inks and paper were perfect, you could theoretically get away with CMY all by themselves, except for registration issues, text, line art, etc. Also, the additional "K" ink can help reduce the total ink limit, save ink, reduce costs, and improve quality.

Sorry for the book. This is not a simple subject, and we have only touched the surface.

Lou

[Oliver Krylow]

Thanks for the book.

I see now, that asking for a standardized colour space describing RGB, CMYK, LAB all at once was pretty naive, considering all the output devices dealing with colour.

Still, coming back to the conversion formulas between those "standard" profiles, it seems to me that everybody is just left to implement a formula on his/her own.

Is, for example, the conversion in the Adobe CS, somehow accessible / readable ?

[warzenbeisser]

Yes and no; the conversion look-up tables in an ICC profile are accessible while the algorithms in the Adobe CMM used by the Creative Suite are proprietary and probably not publicly documented. An actual conversion uses both the LUTs and the CMM that interpolates all values between the samples specified by the LUT.

[Lou Dina]

Oliver,

Still, coming back to the conversion formulas between those  "standard" profiles, it seems to me that everybody is just left to  implement a formula on his/her own. Is, for example, the conversion in the Adobe CS, somehow accessible / readable ?

I'm not sure how that would be accomplished (I'm not saying it can't be done). There are a number of things happening in a conversion from one profile to the other.

1. The source and destination profiles have lookup tables and/or curves that define colors, relating each color to the universal translator "profile connection space" (usually Lab or a derivative).

2. Then, there is a color management module (CMM) or "engine" that performs the math, does interpolation, rounding, or whatever it does in the background. This module or engine looks at the two profiles and reconciles the data and actually performs the conversion.

3. Not all CMMs are identical, and you may get slightly different results depending on the one used (Apple, MS, Adobe, Kodak, etc).

4. The above assumes you already have source and destination for conversion, and that you simply want to go from one space to another. Creating these profiles is a whole other science, with a lot of tweaking, black magic and visual adjustment thrown into the mix.

I'd probably start with the ICC (International Color Consortium), looking at their specs, data, papers, etc. You can also look at Bruce Lindbloom's website, which has a lot of color information, theory, formulas, etc. www.brucelindbloom.com. You can also check out Chromix.com. They make various software products, like ColorThink Pro, that can do much or what you are trying to do. But, the formulas are in the background and not visible to the user.

Lou

[Jason Burnett]

Wow, I think I learned more about color gamut in your post than I have in a while, thanks.

My problem is that ADOBE specifically has a mechanisms that they use to convert between any color model and some "CMYK" model used in their Document Color Mode for CMYK.

Realizing the inherent problems with such a standard, Adobe does it anyways.

How can I create a javascript to take the full range of RGB values and convert every one to the same value of CMYK that adobe displays in CMYK Document Color Mode (since it is not device dependent)?
Thanks again fo such great info.

[D Fosse]

Not sure how much you picked up from the rest of the thread, but it all boils down to color spaces.

Image > Mode in Photoshop doesn't really convert between "modes". It converts between whatever color spaces you have set as working spaces in Color Settings.

Numbers are specific to color spaces:

At the center of it all is Lab. That's the reference.

[Royi A]

Hi,

Did you manage to get something which converts from sRGB to SWOP CMYK?

Nothing too accurate, just the ballpark without getting into the whole ICC mess.

[Test Screen Name]

sRGB is defined by its ICC profile. So is SWOP CMYK. Just use an ICM to convert. CMYK profiles and many RGB profiles are defined as look up tables - colour conversions for particular values, with linear or quadratic interpolation to find the value in between. So there is no formula (except in the sense that every algorithm is a formula).

In fact, a typical profile contains multiple look up tables, for two way conversions and different rendering intents. Rendering intents are crucial; there is no single "right" conversion without also specifying the rendering intent.

Of course, you can convert a table of values to build your own lookup for interpolation. Hard to see any advantage.

[Royi A]

Hi,

How about the conversion in an unmanaged system?

Then what would be the conversion?

Thank You.

[G_Hoffmann]

PostScript Language Reference Manual, here Second Edition:

https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0ahUKEwjO1bLljL_JAhVCYA8KHdswBnk...

Page 305

PostScript had been invented earlier than color management systems (CMS) by ICC profiles.

PostScript contained all necessary tools of a CMS, but it proved to be too complicated.

For simple applications one can find generic transforms between DeviceRGB, DeviceGray

and DeviceCMYK (see page 305...).

These transforms may look nowadays quite undsatisfying, but in fact they are useful for

tutorial purposes, e.g. for the construction of color wheels and spectrum bars.

Best regards --Gernot Hoffmann

[G_Hoffmann]

Here we can see a "CMYK color wheel":

http://docs-hoffmann.de/hlscone03052001.pdf

p.16

The meaning of "CMYK color wheel" is explained there.

Such a color wheel contains at the circumference CMYK values

with maximal saturation.

0...1C, 0...1M, 0...1Y, K=0, but one value of a set CMY is always 0.

The color wheel was generated by PostScript.

RGB values are created in HLS (not in HSB, but that doesn't matter),

and immediately converted into CMY values by the generic transform

C=1-R, M=1-G, Y=1-B.

Alternatively one might think of creating such a CMYK wheel by applying

an ICC-profil to an RGB wheel. But this would deliver nothing else

but garbage, because saturated RGB colors in any common RGB space

are out of gamut in common CMYK spaces.

This illustration is as well an answer to questions in this thread:

Re: 12 Step Color Wheel

Unfortunately not only the mathematics but also the underlying color theory

aspects are somewhat complicated.

Best regards --Gernot Hoffmann

[Test Screen Name]

You could use the PostScript formula C=1-R etc, but the result will not be the least bit accurate (I agree, can be useful for other purposes). Better to pick common profiles and use an ICM. There's an open source one if you don't want to use the Mac or Windows platform API. Or. do what I suggested: use an ICM to make your own lookup table. Be aware that interpolating in a 4D table is not a trivial exercise. Most high end real world PostScript RIPs would ignore the spec and apply their own default calibrated colour conversions, just as Acrobat has always ignored the PDF spec.

Interestingly, while PostScript doesn't have ICC profiles it has the CIEBasedABC and CIEBasedDEFG colour models. These include the main ways of expressing colour found in ICC profiles: gamma based, matrix based and sample based.

[Biggs47]

In the print world, we call what you're doing 'rendering intent' or a rendering intent formula. In particular a photographic or perceptual rending intent. How will an output profile handle colors that are out of the CMYK color space. If we don't have rendering intent, the out of gamut colors simple don't print at all. If we use a colorimetric rendering intent, colors out of the gamut are brought to the inside of the nearest edge of the gamut, and in many cases, pile on top of each other. 12 shades of blue may print exactly the same with this intent selected. a proper perceptual intent will not only bring colors into the CMYK space, but reallocate every WITHIN the color space to ensure a nice even stepping of every color being printed.

[NB, colourmanagement]

@Biggs47  Actually it's worth pointing out here that Perceptual Rendering isn't as sophisticated as many think. I'll give some detail-

It seems to be a common misconception that Perceptual rendering does not clip.

Actually it can clip - because it does not actually scale the entire input colour space into the destination space, on the outbound side of the PCS (Profile Conversion Space), it scales a preset gamut "volume" that the profile software manufacturer expected to contain usable data (sometimes this scaling is adjustable in profile making software , as you may be aware).

If a Perceptual conversion did in practice scale the whole of, say, the massive Pro Photo colour space into a printer colour space then the image saturation overall would be very severely scaled and it's not. 

I was taught the above by 'Mr. Photoshop' Thomas Knoll and my friend Steve Upton at Chromix (who understands ICC profiles in ways I couldn’t even dream of). I'm told that Knoll actually came up with Black Point Compensation in Relative Colormetric conversions because he really didn't like Perceptual rendering.

Back in 2001, early in my Colourmanagement journey, Thomas Knoll, the originator of Adobe Photoshop generously wrote to me:

"Neil,

You seem to have discovered how much of a kludge "perceptual" rendering really is with the current ICC profile model,

it would seem so.

The standard description of perceptual intent: "smoothly compresses the entire gamut of the source profile into the gamut output profile without clipping" is absolute b***s***.  I

t does not work this way.

It is impossible to make it work this way with the current ICC profile model. As we observed - it is an unreliable option for saturated images.

The basic problem is that source profile and the destination profile are completely independent.  All the source profile does is tell the CMM how to convert source device colors to the PCS space (basically Lab space).  The source profile has no idea what the destination profile is going to be."

Given that - this is what I generally teach:

In practice Perceptual Rendering is often less useful than it may appear it might be from the standard description of it’s features. The actual situation with a Perceptual Rendering is a little less ideal than it may at first seem because

1: Mapping is NOT of the entire source space to the destination space.

  This means that clipping can result.

2: Conversion might result in un-needed compression of less saturated images

3: Generally, it seems that the Perceptual calculation is “centre” weighted, so that near saturated tones may suffer concatenation as they sometimes do in Relative Colorimetric conversions .

I hope this helps

neil barstow colourmanagement - adobe forum volunteer,

colourmanagement consultant & co-author of 'getting colour right'

See my free articles on colourmanagement online

Help others by clicking "Correct Answer" if the question is answered.

Found the answer elsewhere? Share it here. "Upvote" is for useful posts