Convert RGB ->CMYK and CMYK->RGB

[Eccentric_body98BC]

Hi!

I have some problem.

PS Color profile = Adobe RGB (1998). Color mode=RGB.

I set the black color R1 G1 B1 and in accordance with CMYK, so I get C91 M79 Y62 K97. But if I first enter the same code in CMYK I get R5 G5 B5. Now if I ask the RGB color R5 G5 B5 in Smuk I will be shown again another code C91 M78 Y62 K97 Why is this happening? How to understand which RGB code in CMYK best matches the code. Are there colors that translate back and forth and give the same code values?

Thank you.

[D Fosse]

It's because CMYK profiles compensate for ink density. You can never print a pure 0-0-0 black.

All CMYK profiles have a total ink limit. If you go over that, you get ink smearing and refusal to dry properly. The numbers you get when converting is the deepest black possible. They will vary with different CMYK profiles, because each profile represents a certain press/paper/ink process.

Actually the compensation isn't even a full compensation, it doesn't take into account the reflectance and properties of the paper. To get a match from screen to print you also need to set your monitor black point accordingly.

[c.pfaffenbichler]

And it’s not just the Ink Limit, the GCR (or UCR) also comes into play to determine the relative amounts of the four colors used to make up neutrals. 

[Eccentric_body98BC]

Ок. But it happend with other colors too, not only with black. For Example R192 G173 B142 converts into C71 M3 Y54 K0. And C71 M3 Y54 K0 converts into R110 G174 B143, and  R110 G174 B143 converts into C71 M2 Y54 K0. All this happens in a one color profile.The shades of the resulting colors are almost identical. But I do not understand what color correspondences are more correct to specify to the customer in the logbook.

PS CMYK COATED FROGRA39(ISO12647-2:2004)

[D Fosse]

And which RGB?

You cannot specify color without also specifying a color space. All these numbers are specific to profile. And also keep in mind that roundtripping uses the working space as basis for the calculation, unless measured from an open document which will override the working space.

That said, I don't get your numbers into FOGRA39, either from sRGB, Adobe RGB or ProPhoto. So I have no idea what RGB you're starting from. It doesn't add up.

[Eccentric_body98BC]

Color Space RGB: Adobe RGB (1998)

Color Space CMYC: COATED FROGRA39(ISO12647-2:2004)

Color mode: RGB

And all this color transformations (R192 G173 B142 -> C71 M3 Y54 K0; C71 M3 Y54 K0 -> R110 G174 B143; R110 G174 B143 -> C71 M2 Y54 K0 ) occur within the same file, and within the same color profile.

what do I need to do to get a clearer match between RGB and CMYK codes?

do I need to choose other color spaces? maybe there is some combination of them, in which there is a clearer correspondence between RGB and CMYK, or maybe there is something else??

[c.pfaffenbichler]

Adobe RGB 192-173-142 results in FOGRA39 21-29-44-7 with Relative Colorimetric here (see screenshots). 

Which Intent are you using?

Please post meaningful screenshots. 

[Eccentric_body98BC]

Sorry, its small mistake not 192  R109 G173 B142

R109 G173 B142 -> C71 M3 Y54 K0; C71 M3 Y54 K0 -> R110 G174 B143; R110 G174 B143 -> C71 M2 Y54 K0

[c.pfaffenbichler]

Color Conversions have consequences … 

What is the issue really? What are you trying to achieve and why would it involve multiple Color Conversions? 

[Eccentric_body98BC]

I want to find out if there are any colors that when converting from RGB to CMYK and then back from CMYK to RGB give the same code.

[Test Screen Name]

Sometimes, randomly, converting to a colour and back again may give the same colour. But it is just luck. Colour conversion is not a mathematical formula that can be reversed. 

[D Fosse]

I couldn't get those numbers to match either. I think the OP either has

• untagged documents, or
• is making screenshots, assuming the original document profile is still valid (which it isn't), or
• has working spaces different from whatever documents are open. In that case, numbers are calculated from the working spaces unless there is an active document that overrides it.

[D Fosse]

The black point compensation will still affect all the numbers to varying degrees. And then - as c.p. pointed out above - you also have GCR (gray component replacement) and UCR (under color removal) modifying the numbers.

The extra black ink throws all kinds of wrenches into the equation. What goes one way doesn't necessarily go the other way.

[c.pfaffenbichler]

You omitted to mention which CMYK. 

[NB, colourmanagement]

Hi,

You've been asked "Why?" but have not replied?

Does this help your understanding?: https://www.colourmanagement.net/advice/about-icc-colour-profiles/#what_profiles_do

In a conversion from RGB to CMYK the colour values are being remapped from a 3 channel colour space to a 4 channel colour space (because we now have black ink involved throughout most of the colour space [not just in neutrals, normally]- this decided by the "black generation" settings chosen when creating the CMYK profile). 

Unravelling this conversion is not 100% predictable. 

Whilst you may find that some colours, when converted between some RGB and some CMYK colour spaces, make the round trip 100% unaltered, in many cases this will just not be the case.

This also applies to RGB > RGB > RGB conversions, gamut mapping (and the resulting concatenation [crushing] of some high gamut colour values, irrespective of rendering intent) as well as mathematical rounding errors and choices made in the mapping by the designer of the software that created the ICC profiles create this situation - which you seem to think of as an anomaly.

I hope this helps

if so, please "like" my reply and if you're OK now, please mark it as "correct", so that others who have similar issues can see the solution

thanks

neil barstow, colourmanagement.net :: adobe forum volunteer

[please do not use the reply button on a message in the thread, only use the one at the top of the page, to maintain the thread title and the chronological order]

[c.pfaffenbichler]

I also like the analogy of language – if a text (that is not extremely simple) is translated from one language to another and then that is being translated to the original language again there is a high probability that the result will not match the original text word-for-word.  

[Test Screen Name]

I agree. There is no reason, none, never to convert colours and later convert them back, except broken workflows. I like the translation analogy too. Imagine writing a book, having it translated to Chinese, then deleting the original book because it could always be translated back if needed. It is clear that it would not be the same book. A workflow which designs in one colour space and converts WITHOUT ARCHIVING FIRST is a broken workflow.

[Eccentric_body98BC]

Thank you all for your answers, I can understand why the values change when the conversion is reversed. But I can't understand whether in the future, when selecting colors, you need to select them so that they give the same code when forming back and forth, so that they are commutative?

[Test Screen Name]

" whether in the future, when selecting colors, you need to select them so that they give the same code when forming back and forth, so that they are commutative?" No, because you never go back and forth.

I think I may know where this is coming from. Some people find themselves stuck between a colour managed workflow and one where someone has given a list of CMYK or RGB colours to match. The problem is, you cannot mix these two workflows. The list of colours to match generally means the person choosing them doesn't know colour management.

[D Fosse]

There's a gotcha when going from RGB to CMYK, and it's the black ink. Or ink density and purity in general. The problem is that CMYK profiles aren't ideal, synthetic color spaces like the standard RGB spaces. They are based on real printing conditions. They describe physical inks on physical paper, laid down by a physical offset press. It's where the rubber hits the dirt, so to speak. So CMYK profiles have to compensate for a lot of imperfections. That's why forwards and backwards may not be the same thing.

If you go back and forth between standard RGB color spaces it should be consistent (as long as it's within gamut). In low precision (8 bit) you may get rounding errors, but if the precision is high enough you should end up with the same numbers. But CMYK is not in this high ideal world. CMYK profiles are intended as destination profiles. One way.

[rob day · Accepted solution]

Most of what you are seeing is a rounding error when the Info panel is set to 8-bit. In 8-bit the CMYK readout is in 1 percent increments, but 8-bit obviously has 256 gray levels so the CMYK values are rounded. A highend press is certainly able to print more than 100 gray levels.

Here’s your starting AdobeRGB value with Info panel set to 8-bit. The sample on the left is the Actual color and on the right the expected CMYK conversion to FOGRA 39, using Relative Colorimetric as the Intent with BPC on.

If I set the Info panel samples to 32-bit I get .427|.678|.557

If I duplicate the file and do an AdobeRGB-to-FOGRA39-to-AdobeRGB conversion I get .424|.678|.557—an effective match:

[Eccentric_body98BC]

Thank you all again for your answers. But, advise please a way to correctly select CMYK colors for printing, so that they roughly correspond to what I see on the screen in RGB. Because it seems that just getting the values from the eyedropper is not enough.

[rob day]

If the mode of your Photoshop document is RGB, and the Info panel’s eydropper is set to CMYK, the CMYK numbers show the expected conversion from your RGB document’s assigned RGB profile to the current Color Settings’ Working CMYK space using the chosen Intent and Black Point Compensation.

The Intent is the preference for how colors outside of the CMYK gamut are brought into gamut. Generally using Relative Colorimetric with BPC turned on produces the least amount of appearance change in out-of-gamut colors.

If you turn on Proof Colors with the Proof Setup set to Working CMYK you will get a soft proof of how your RGB document is expected to print—the RGB preview will be brought into the Working CMYK gamut. With Proof Colors turned on you can check the output CMYK numbers, and get a CMYK preview for a specific press condition without actually making the conversion to CMYK.

The accuracy of the soft proof and output numbers depends on both your Monitor profile and the chosen CMYK profile. Is your monitor profile an accurate representation of your monitor’s properties, and have you chosen the correct CMYK profile for the destination printing press (will your printer really be printing to that profile)?

[NB, colourmanagement]

Hi

To get the right conversion from RGB to CMYK you use a CMYK profile. The CORRECT CMYK profile.

Properly crafted CMYK profiles are able to successfully convert RGB colour data to adapt it to the restricted colour and tonal range available from ink on paper. 

The nearest printed equivalents for the colours in your RGB document are calculated dusing the ICC  profile conversion. 

You MUST have the right CMYK profile for the actual printing process that will be used, it's like a tranaslation between 2 languages, guessing doesn’t cut it. You must know the actual destination language - that’s what's defined within the CMYK ICC profile.

I hope this helps

if so, please "like" my reply and if you're OK now, please mark it as "correct", so that others who have similar issues can see the solution

thanks

neil barstow, colourmanagement.net :: adobe forum volunteer

[please do not use the reply button on a message in the thread, only use the one at the top of the page, to maintain the thread title and the chronological order]