Converting RGB to CMYK

[drummerpaco]

I have question on converting RGB images to CMYK.
I know that RGB color gamut is much wider than CMYK, however we like to eliminate color shifting as much as possible.

Currently we have tested that two RGB settings (Adobe RGB (1998) and sRGB) converting to CMYK (Coated GRACoL 2006) using Photoshop CS4.

The test result from Adobe RGB (1998) to CMYK (GRACoL 2006) and sRGB to CMYK (GRACoL 2006) shows different conversion.
Some of the details has been disappeared even though Adobe RGB (1998) has bigger color space, but sRGB to CMYK is still has the original details.

By searching many color management forum, we found many of professionals uses Adobe RGB (1998) convert to CMYK color space which by the test, we found sRGB is better solution.

What is your thoughts and suggestion for converting CMYK o RGB?
Also should we use 1)relative colormetric or 2)perceptual?

 

[Mike F]

colorometric for vector and perceptual for raster is what I was taught.

 

[photoplan]

Hello drummerpaco,

you should use a perceptual intent for RGB pictures.

You can read this :

Understanding Rendering Intents

Color Management: Color Space Conversion

 

[David Milisock]

I have question on converting RGB images to CMYK.
I know that RGB color gamut is much wider than CMYK, however we like to eliminate color shifting as much as possible.

Currently we have tested that two RGB settings (Adobe RGB (1998) and sRGB) converting to CMYK (Coated GRACoL 2006) using Photoshop CS4.

The test result from Adobe RGB (1998) to CMYK (GRACoL 2006) and sRGB to CMYK (GRACoL 2006) shows different conversion.
Some of the details has been disappeared even though Adobe RGB (1998) has bigger color space, but sRGB to CMYK is still has the original details.

By searching many color management forum, we found many of professionals uses Adobe RGB (1998) convert to CMYK color space which by the test, we found sRGB is better solution.

What is your thoughts and suggestion for converting CMYK o RGB?
Also should we use 1)relative colormetric or 2)perceptual?

Ther RGB color sace you use is a matter of requirements, for captures I use prophoto, convert to Adobe RGB or ECI RGB for print ans sRGB for web or presentation.

I use perceptual rendering for all RGB to CMYK conversions because the important thing to remember is that color is a perception and there is no correct way to convert something large to something small however a methode that maintins a persons perception is in my opinion the best.

 

[Lukas Engqvist]

The colour space and the colours used in the images are not allways the same.
To use perceptual rendering is like using an instamatic camera, you fit everything in the picture and get a reasonable representation, a fair compromise. It is also the most reasonable when there is a large difference in gamut size/shape. Synthetic images will have detail all over at the expense of having anything looking it's best. Compromise is sometimes the way to go though!

To use relative, is like making a decision on how to crop an image, what you get you get more of, but it is important to evaluate using proof colours so that you are not compromising in important details. Together with a good monitor and manual assessment/intervention this will allow for brightest and best colours. In preview see that no essential details are lost, if some bright coloured area needs more detail, usually taking down saturation ever so slightly will bring back those details. From Adobe RGB to GRACOL on coated relative colometric will give great results.

Which RGB space to use depends on your source, for untagged images sRGB is a better blind guess, but many photographers will use AdobeRGB. (I would not recommend ProPhoto RGB unless you are using 16 or 32 bit images, and that you are aware that you a large number of colours in that space can not be viewed on any monitor, so you run the potential risk of making edits that you cannnot evaluate. How one would capture in Prophoto I don't know...would that be from Camera Raw, and how would you evaluate it?)
When you are evaluating RGB what to look for in the sRGB is how Cyan is represented. sRGB is weak in representing Cyan, and in that area there are printed colours that you cannot represent in that space.

PS @photoplan ty for the links the one image with the magenta blobs was a nice clear example of the differrences.

 

[gordo]

From Adobe RGB to GRACOL on coated relative colometric will give great results.
[SNIP]

PS @photoplan ty for the links the one image with the magenta blobs was a nice clear example of the differrences.

Relative colormetric is what i've used for the majority of work that I've done for print.

Where is "photoplan ty"?

best, gordo

 

[David Milisock]

The colour space and the colours used in the images are not allways the same.
To use perceptual rendering is like using an instamatic camera, you fit everything in the picture and get a reasonable representation, a fair compromise. It is also the most reasonable when there is a large difference in gamut size/shape. Synthetic images will have detail all over at the expense of having anything looking it's best. Compromise is sometimes the way to go though!

To use relative, is like making a decision on how to crop an image, what you get you get more of, but it is important to evaluate using proof colours so that you are not compromising in important details. Together with a good monitor and manual assessment/intervention this will allow for brightest and best colours. In preview see that no essential details are lost, if some bright coloured area needs more detail, usually taking down saturation ever so slightly will bring back those details. From Adobe RGB to GRACOL on coated relative colometric will give great results.

Which RGB space to use depends on your source, for untagged images sRGB is a better blind guess, but many photographers will use AdobeRGB. (I would not recommend ProPhoto RGB unless you are using 16 or 32 bit images, and that you are aware that you a large number of colours in that space can not be viewed on any monitor, so you run the potential risk of making edits that you cannnot evaluate. How one would capture in Prophoto I don't know...would that be from Camera Raw, and how would you evaluate it?)
When you are evaluating RGB what to look for in the sRGB is how Cyan is represented. sRGB is weak in representing Cyan, and in that area there are printed colours that you cannot represent in that space.

PS @photoplan ty for the links the one image with the magenta blobs was a nice clear example of the differrences.

This is a great discussion!!

The problem with any of the colorimetrics is this and is acerbated as the size of the gamut of the sourse RGB file increases. Example a prophoto image that utilizes a large portion of the gamut may have 70% of the colors out of gamut for the destination space. If converted using a colorimetric 30% of the colors are converted with accurate equivalents but 70% are radically changed altering th perception of the overall image.

This can also be seen using sRGB and Adobe RGB if one uses a scene that has several different but close hue greens in it. A capture that hase the underside of trees is another example.

 

[Stephen Marsh]

Also should we use 1)relative colormetric or 2)perceptual?

As a "general rule" Rel Col. Say 90% of images that I converted might have been slightly better with Rel Col, while say 8% of images might have been better with Perceptual, while say 2% of exceptional images may have used "other" methods to get to an acceptable CMYK version of the RGB original. Of course, in most cases, a Rel Col transform will need BPC turned on in the colour conversion when using the Adobe CMM.

That being said, the wider the gamut the RGB space, the more so that one may need perceptual over Rel Col (presuming that the image actually uses the wider gamut).

On an image by image basis, it is easy to check all four rendering intents when going from RGB to CMYK using a common table based CMYK output/printer profile. If one was doing a blind conversion and wanted a default intent with no user input or feedback, then it is all a matter of trade offs.


Best,

Stephen Marsh

 

[meddington]

Suffice to say that rendering intent choice is gamut and content dependent. As far as larger gamut size goes such as prophoto, theres a choice to make between mapping color to preserve the perceptual relationship (and perhaps sacrificing overall color accuracy and dynamic range), and using relative colorimetric, perhaps clipping colors that the monitor could not display nor could be reproduced via the print process on hand. Each rendering intent has a place. I personally find the vast majority of RGB imagery tagged with AdobeRGB or sRGB coverts quite well with rel. col. One things certain, rendering intent use can be subjective and a one size fits all approach will have caveats.

 

[David Milisock]

As a "general rule" Rel Col. Say 90% of images that I converted might have been slightly better with Rel Col, while say 8% of images might have been better with Perceptual, while say 2% of exceptional images may have used "other" methods to get to an acceptable CMYK version of the RGB original. Of course, in most cases, a Rel Col transform will need BPC turned on in the colour conversion when using the Adobe CMM.

That being said, the wider the gamut the RGB space, the more so that one may need perceptual over Rel Col (presuming that the image actually uses the wider gamut).

On an image by image basis, it is easy to check all four rendering intents when going from RGB to CMYK using a common table based CMYK output/printer profile. If one was doing a blind conversion and wanted a default intent with no user input or feedback, then it is all a matter of trade offs.


Best,

Stephen Marsh

>Of course, in most cases, a Rel Col transform will need BPC turned on in the colour conversion when using the Adobe CMM.


If you do extensive testing Rel COl with BPC on is very much like perceptual just NOT ICC compliant.

 

[Stephen Marsh]

If you do extensive testing Rel COl with BPC on is very much like perceptual just NOT ICC compliant.

Hi David, yes, Rel Col + BPC does render the shadows in a very similar way to a perceptual intent for all intents and purposes. However, the rest of the rendering is usually more contrasty/punchy as it has not been compressed. This is generally preferred, however it is very much image dependent on which is preferred, it is all subjective.

AFAIK the ICC does not specify how a perceptual intent should compress and map to the destination - only that it can. So this ends up as being a "secret recipe" that can vary from one vendors profile creation software to another (example Adobe CMYK profiles compared to other vendors).

Personally I could care less whether BPC is ICC compliant or not, it is the results of RGB to CMYK transforms that really matter to me. If this is a non ICC vendor rendering advantage, then I personally have no problem. One can turn it off it one wishes "ICC compliance" and a resulting picture with trashed shadow detail.

I do care whether shadow detail is preserved or trashed, which is why I would use and generally recommend BPC if shadow detail and or total ink limits were a concern (which in an RGB original the shadows may be quite different to the destination CMYK so BPC in the Rel Col transform is a good thing, ICC compliant or not). If a CMM did not offer something like BPC or the Adobe CMM was not on offer, then I would probably prefer to use perceptual rather than Rel Col - if shadow detail was critical.

Additionally, it would depend on whether one was using a late or early binding colour conversion workflow. I personally would prefer to look after tough RGB to CMYK conversions upstream, manually in Photoshop before going to PDF, rather than to trust the conversion to say a blind hard wired rendering intent in InDesign, Illustrator or Acrobat Pro.

Best,

Stephen Marsh

 

[rich apollo]

I can visualize that using a colorimetric rendering intent (relative or absolute) would yield results as you describe. Adobe98 is a larger colorspace. Using a colorimetric rendering intent would cause clipping, and with Adobe98 being the larger colorspace, more clipping would result from its use. The clipping would cause the loss of detail.

This in no way indicates that sRGB is the better colorspace to use. It was just the best under the conditions you tested. Different image, different rendering intent, black point compensation on (or off), different destination colorspace and you will change your result.

In going from RGB to CMYK I use the perceptual rendering intent, as the CMYK colorspaces I use are smaller than just about any of the RGB colorspaces I'm going to encounter. I also treat raster and vector elements EXACTLY THE SAME. I want raster and vector elements that match to still match when I'm finished with any color transforms. I use sRGB as the default RGB colorspace not for any affinity for the colorspace, but because, statistically speaking, it is the RGB colorspace I'm most likely to come across. I hope that all elements will be tagged with ICC profiles, and my workflow honors any ICC profiles that are embedded.

 

[juergenroesch]

digital vs analog

digital vs analog

Stephen Marsh said, ... the wider the gamut of the RGB space, the more so one may need perceptual over relative colorimetric (presuming that the image actually uses the wider gamut).

Well, anyone really paying attention to that very last part in brackets?

Usually most people do not - and I speak from a bit of experience there. But this is a problem that often doesn't show on screen, but later on press - or sometimes on the proof.

We always tend to think of an analog world where a bigger space means there are more colors. Well, most work is done now digital and this means there is a discreet number of colors that we can work with. A full blown ProPhoto RGB has a huge amount of colors that aren't printable (not sure if I believe the quote of 70% by David, but even if it's only 40% ...), but believe it or not, if you count them, there are no more than 16.7 Mio colors in that space (if you work 8bit) - and guess what: there are also 16.7 Mio colors in sRGB!

What does that mean for our work?
If you take a portrait shot in sRGB you might have 40 levels defining the skin colors. Take the same shot in AdobeRGB and those same colors now are spread over only 28 levels. Now you start retouching, which is changing curves and gradations - reducing used discrete levels to 25. Then you save it as a JPG compressed EPS (the favorite file formats of retouchers in London ... - aaaargh!) and compress levels now to 18 in doing so. Add a CTP curve in your RIP and you are surprised if you see steps and banding in print?

My tip: embed the source working color space and do all retouching there - only then convert to a different working space (preferably 16bit to avoid quantisation loss - i.e. if you split 28 over 40 values, there will be holes - or if you compress 40 to 28 you get on some destinations 2 values together, which will turn visible if you do gradation changes AFTER the conversion). Only then separate - and in this case you might find Rec Col + BPC your best bet as you've done some manual gamut compression already during RGB retouching.

 

[juergenroesch]

large retouching dept - controlling color - late binding

large retouching dept - controlling color - late binding

the above discussion is a permanently occuring one, unfortunately mainly people who don't REALLY require the discussion participate in it (I talk about those that are pretty knowledgeable in color management and conversion like those on here); all those learn-on-the-job and fresh-out-of-college retouchers don't really care and in a large department with 40 retouching stations you find at least 60 different settings as color defaults in the different apps. Few users have their applications synchronized on their workstations, let alone in the department. Images get quickly turned from RGB to CMYK (= MODE CMYK, does it ..., doesn't it?) and then retouching starts. Pump up saturation and contrast, clean the whites, save, next file ...

If your toenails start curling up, then you know what I am talking about.

So how can you standardize an entire department? Is a late binding workflow the solution? What rendering intent in that scenario? Production guidelines?

OK, here an idea - throwing together all we know and have read so far:
- rendering intents are a source of worry as results differ by using different intents and different images call for individual treatment (no intent fits all)
- fixed colors like in clothing samples for a catalog become difficult if the image also contains out of gamut colors as these colors would get compressed as well if applying perceptual.
So it's an either/or situation. Can't we have best of both worlds? I mean give me colorimetric where I have no problem reproducing and just fold in the out-of-gamut colors and maybe give me an option to adjust the blend-over between the rendering intent effects.

Here's what I want:
imagine one of those stress balls made out of foam. Now imagine your hand with the fingers halfway into a fist. How do you fit the stress ball into the hand?
- relative colorimetric: cuts out holes where your fingers fit
- perceptual: replaces the original ball with a smaller one that will fit comfortably
OK, now let's look at that ball again and just do what any human would do: squeeze where the fingers touch!
What happens? The material is soft and gives way where pressed - and only there. So where there is no pressure needed, the original shape remains.
INFO: GRACoL / FOGRA39L 100% yellow is NOT in AdobeRGB, so applying perceptual only reduces it further... - the squeeze ball would leave it where it is.
So now I want to spin this idea further: imagine different foam materials, so a soft foam would only compress very locally around the fingertips (very close to colorimetric) and a firmer foam would carry the compression further into the core (assuming a more perceptual approach).

What we haven't discussed here yet is the gray balance of the images and how they will appear on the printing paper - this is a huge issue when printing catalogs and using LWC papers. Again ICC offers us an either/or situation: ignore the paper or fully compensate for it. While full compensation looks great in a next-to-each-other situation when displaying proofs in a viewing booth, reality is that the human brain starts compensating the white point if you have no reference next to it. And then items would look over-compensated and what looked perfectly neutral in the viewing booth (with references on other substrates next to it) starts looking blue if seen on its own on the more yellowish LWC material.
So again I want a slider to allow me something in the middle, so it looks pretty good in the viewing booth, but also correct on paper.

And while at it, I want it in a way that is deployable in a retouching department where individual users cannot interfere with the settings and also where separation styles (UCR/GCR, TAC and CMY vs K balance) are kept to a standard per print standard (sheetfed, coated, uncoated, web, gravure, ...)

If this works, then I could retouch all images in AdobeRGB or sRGB, then process them through this server based separation station to different print standards and core colors would remain visually near identical independent of the chosen print standard (sheetfed, web, gravure).

If I can get the same processing option for CMYK artwork components, then this would give me a late binding workflow where I can produce a single PDF and produce it looking identical on almost any print process.

Food for thought? Am I expressing what would be desired or am I completely off track in fantasy world with no practical interest?

 

[David Milisock]

Stephen Marsh said, ... the wider the gamut of the RGB space, the more so one may need perceptual over relative colorimetric (presuming that the image actually uses the wider gamut).

Well, anyone really paying attention to that very last part in brackets?

Usually most people do not - and I speak from a bit of experience there. But this is a problem that often doesn't show on screen, but later on press - or sometimes on the proof.

We always tend to think of an analog world where a bigger space means there are more colors. Well, most work is done now digital and this means there is a discreet number of colors that we can work with. A full blown ProPhoto RGB has a huge amount of colors that aren't printable (not sure if I believe the quote of 70% by David, but even if it's only 40% ...), but believe it or not, if you count them, there are no more than 16.7 Mio colors in that space (if you work 8bit) - and guess what: there are also 16.7 Mio colors in sRGB!

What does that mean for our work?
If you take a portrait shot in sRGB you might have 40 levels defining the skin colors. Take the same shot in AdobeRGB and those same colors now are spread over only 28 levels. Now you start retouching, which is changing curves and gradations - reducing used discrete levels to 25. Then you save it as a JPG compressed EPS (the favorite file formats of retouchers in London ... - aaaargh!) and compress levels now to 18 in doing so. Add a CTP curve in your RIP and you are surprised if you see steps and banding in print?

My tip: embed the source working color space and do all retouching there - only then convert to a different working space (preferably 16bit to avoid quantisation loss - i.e. if you split 28 over 40 values, there will be holes - or if you compress 40 to 28 you get on some destinations 2 values together, which will turn visible if you do gradation changes AFTER the conversion). Only then separate - and in this case you might find Rec Col + BPC your best bet as you've done some manual gamut compression already during RGB retouching.

>(presuming that the image actually uses the wider gamut).


Agreed however that gamut my be realized in areas of color not normally associated with being out of gamut. Mid to dark greens are a good example, the underside of leaves and pine needles..

 

[TerryWyse]

Food for thought? Am I expressing what would be desired or am I completely off track in fantasy world with no practical interest?

I know of only ONE system that can do what you say (variable gamut mapping/rendering intents).



Regards,
Terry

 

[Lukas Engqvist]

Don't know have too many books with just underside of pine needles... But if I did maybe I'd be looking at a CMYK+green or CMYK+blue profile for the occasion.

Sorry I didn't mention above that BCP was so self said I didn't mention it. Also I'd like to add that I think Binuscan profiles work a little like juergenroesch implies. I do not have the software myself, but have used a profile that was generated with it, and it was better at mapping pure colours to what we would consider normal behaviour, one of the key areas being bright blues NOT going purple, and yellows NOT going green.

 

[David Milisock]

Don't know have too many books with just underside of pine needles... But if I did maybe I'd be looking at a CMYK+green or CMYK+blue profile for the occasion.

Sorry I didn't mention above that BCP was so self said I didn't mention it. Also I'd like to add that I think Binuscan profiles work a little like juergenroesch implies. I do not have the software myself, but have used a profile that was generated with it, and it was better at mapping pure colours to what we would consider normal behaviour, one of the key areas being bright blues NOT going purple, and yellows NOT going green.

No not books but photographs of trees, shrubs, golf courses. The shadow areas certainly suffer if the original capture is sRGB.

 

[Lukas Engqvist]

@David Milisock OK, I can agree that sRGB isn't the ideal capture space for golf (or swimingpools or other holiday resort promotion).

For images where there is a choice in workflow, I usually go CameraRaw => AdobeRGB (since the choice in ACR is very limited) => Add HSB adjustment layer while toggling Proof Colours to deal with tricky out-of-gamut colours (Using relative and BCP enabled). I leave the the images in RGB, mainly for possible cross-media re-use and it also gives the possibility to repurpose for alternative production workflow (and smaller file sizes).

 

[juergenroesch]

wrong color space / tool for the job?

wrong color space / tool for the job?

No not books but photographs of trees, shrubs, golf courses. The shadow areas certainly suffer if the original capture is sRGB.

the beauty of color management: once you chop space off, you can't bring it back. Simply converting EVERYTHING first to CMYK (often using such silly defaults as AdobeRGB to US Web Coated v2) and only THEN starting retouching in CMYK (because they don't understand RGB) is a clear path to disaster - or should we say 'common practice'?

While those dark greens might be tricky in sRGB to start with, I believe that many processing tools / options are ultimately responsible for the loss you experience.

I suffer natural curiosity and would love to see what your experienced losses are and if improvements could be made (using alternative settings / tools - not hours of manual labor). So if you're up for it, drop me a line (off-list) and I'll give it a shot