Convert from RGB > CMYK

[Werby]

Leaves them hannging

Leaves them hannging

Correct me if I'm wrong here, profiles for output only interprets image info, if so, vendor downstream should be able to assign their profile to an untagged CMYK without problem. How does this leave them hanging?

This is another point you may be confused on. Assigning a profile is vastly different from CONVERTING to a profile. When you CONVERT an image from say Adobe RGB to SWOP v2, you are creating a CMYK file separated for the printing condition "SWOP V2". You have created a specific flavor of CMYK that is built for a specific output condition. Will it be output that way? Probably not, but by including that profile with your CMYK file (NOT untagged), you are letting the vendor downstream know what kind of CMYK you've made. If your file is untagged, they have no way of knowing how you separated the file.

I would rather provide them with generic CMYKs

There is no such thing as "generic" CMYK. You MUST use a profile to create a CMYK file in Photoshop. Remember, even when you go Image/Mode/CMYK, you are converting using the profile in your Color Settings. So there is always a profile associated with a CMYK file, and you aren't helping anybody by removing it. Printers don't ASSIGN profiles, they CONVERT from one profile to another. If they are going to convert your image to their output condition (their profile) they need to have a profile to convert FROM. This is what Rich meant by "leaving them hanging".

When you ASSIGN a profile to an image, you are not changing the CMYK values in the image, you are simply attaching a tag that says "this is the output intent". This is only useful if that output intent is actually how the image was separated. If I assign ISO Uncoated to a profile that was separated to SWOP v2, that doesn't make the file look good on uncoated paper. To get it to look good on uncoated paper, I need to CONVERT from SWOP v2 to ISO uncoated. So leaving a file untagged just creates confusion, and opens the door for the wrong profile to be assigned, which will guarantee that it prints incorrectly.

All that being said, most printers aren't going to re-separate a CMYK image. It is pretty firmly established in the U.S. printing culture that you don't mess with supplied CMYK files. And it's true that if a fairly accurate SWOP or GRACoL proof is made from a CMYK file, a printer should be able match that proof without re-separating, in which case a profile is not needed. In the past, it was considered risky to attach a profile for fear that somebody downstream wouldn't know how their RIP worked and the file would get accidentally re-separated, or that an operator downstream would see the embedded profile and get confused. However, NOW, in 2008, it is considered bad form to send untagged files. NO HARM can come to your file as long as you embed the profile that was used to create the separations, and if a printer WANTS to re-separate, they have the means to do so.

-Todd Shirley

 

[Tech]

Convert profile = cmyk separation
Assign profile = output intent, output may not match original cmyk separation due to untagged
No generic cmyk (sorry for being unclear)? Our specialist tends to used SWOPv2 for proof color

So final RGB files with adobe 1998 profile, color corrected using SWOPv2 for color proof (when vendor profile is not provided) would still be more color accurate than an untagged CMYK? More color accurate than what target? We know what paper stock production ordered, but to what ink/press conditions?

Forgive me if I'm being thick here.

 

[Werby]

So final RGB files with adobe 1998 profile, color corrected using SWOPv2 for color proof (when vendor profile is not provided) would still be more color accurate than an untagged CMYK? More color accurate than what target? We know what paper stock production ordered, but to what ink/press conditions?.

As others have been saying, and I re-iterate, unless you have an established relationship with a printer, you probably shouldn't be sending them RGB. If you are separating your RGB to SWOP v2 and are creating SWOP certified proofs, and those proofs are approved for color, then you should be releasing SWOP v2 CMYK files. That is definitely the most bulletproof approach to achieving predictable color.

If you don't have a vendor profile that describes the exact printing condition your job will print on (and who does?) you are forced to pick some commonly available, known specification for visual appearance, like SWOP or GRACoL or FOGRA39. This is inevitably a bit of a compromise, as it doesn't actually match your final print condition, but a decent printer should be able to get that visual appearance. So you both kind of agree on a "middle ground" which you can achieve in proofing and they can achieve on press. Welcome to color management!

To answer your question: NO, an Adobe RGB (1998) file would NOT be more color accurate than untagged CMYK – the RGB would be worse in terms of matching the SWOPv2 proof that you are creating. The color target in this equation is your proof. Now, because SWOP v2 is the most common CMYK profile (due to being the default in Photoshop), the downstream printer might accurately GUESS that you converted the RGB file to SWOP v2 to make the proof, or he might accurately GUESS that your untagged CMYK file is SWOP v2, but then again he might guess wrong, too. Why should the printer guess? Just send a tagged CMYK file! The RGB is worse in this scenario because it is less likely that it will be separated correctly. Not only is the printer guessing what profile to convert to, but what rendering intent, CMM, black point compensation, etc. So there are many MORE ways to screw up the RGB than the untagged CMYK. However, by including your profile with the CMYK, you've eliminated all the guesswork.

-Todd

 

[Lukas Engqvist]

Your desiger

Your desiger

Added: I'm not surprised person in charge of photo dept doesn't agree with working with smaller generic CMYK color space. The difference between getting colors that can be reproduce on paper vs what he/she thinks should be is the real issue.

OK I'm with you. You may do well to invest in a Pantone Bridge swatch book so you can educate your designer to see the pantone with the CMYK equivalent can be an eye opener. Also give your designer a basic colour management course.
What is nice to do sometimes is to open several windows of an image in photoshop and set them to different printing conditions and that way show that going from RGB to CMYK brings you from this to that, etc. This is one area we all need to work together to give designers a united front cutting out the uncertainty.

 

[Tech]

@Werby
Now you understand what we are dealing with? Photo dept prefers keeping all files in RGB unless they have vendor profile. Even after correction they forward these RGB images to designers, often (probably 95% of the times) without final conversion to CMYK and without embedded profile unless production instructs them to do so (because some vendors actually ask for it!). Why not convert? Tha't mine question too.

Going back to my original post, I get this workflow discussion every few months with our specialist because others questions his results. When he gets a headache, I get one too because our current RGB workflow is flawed.

@Lukas
I would love to have open discussion with our designers/photo/production and re-evaluate our RGB workflow, although I get the feeling staffs at lesser positions could care less to learn the difference between what can be reproduce and what they expect from their richer RGB images. With top-dawgs being comfortable with the status quote, the only person whom wants to discuss is the specialist and only when he is getting heat.

 

[Lukas Engqvist]

Tech, this is not preaching at you but an attempt to give you a means of educating your co-workers.
For Photographers try this analogy.
Working in RGB allows you to capture a subject. You then wish to display the picture/print it in CMYK. CMYK is threfore the frame in which you display the picture. If the subject doesn't fit the frame you have two options.
Zoom out, this is what perceptual conversion does it zooms out till all the colours fit the frame, the colours become smaller, in colour terminology that means less contrast. You are fitting vibrant colours in a not so vibrant space. The internal relationship will be correct, your brightest colours will still be your brightest colours, but nothing is very bright compared to the original.
Alternative 2. Cropping. When I take a portrait I decide what is essential and I usually crop the portrait quite close. There are areas of the subject that will not be displayed in the frame, but what is essential I have preserved. If there is something esential that i am afraid of loosing well I have to think about that when composing the picture, not when developing the negative. This is what relative conversion does What colours can be mapped to the output will remain. Much more vibrant than perceptual, but there are colours that I risk to crop. Cropping here means they will be as bright as possible but that many not be as intended.
This is where the proof preview comes in it is a view to show how the cropped result will look. If you want to get a quick overview of the colours that risk getting cropped use your gamut warning, thant's what it's for. Colours withing gamut are preserved exactly in converting from RGB to CMYK using relative conversion. Out of gamut colours are to be decided by the photographer/art director how they are to be brought in gamut using selective adjustments or hue saturation. Alternatively the software can do it for you, if you don't care… but then you have no right to complain afterwards because you did infact care.

(Using the AdobeRGB does have one big weakness (sorry Adobe, but it is a fact) and that is the representations of yellow. You cannot get a pure 100% CMYK yellow using AdobeRGB.
I'm talking of the colours 91-100% Y. If you try you will either have to add magenta or you will end up with a cyan cast 3%. On film this was not a problem because it was washed out in that below 3% the tones were clipped anyway. Today it is a problem, and you can see it everywhere , lime green sunsets, sports cars whatever. But there has to be a practical soloution how to work here and now, while we need to keep voicing the need for a better RGB to be set as the default in our software. We have used an RGB workflow for the past 8 years and are thouroughly happy with it, still looking into how to improve yellows.)

 

[michaelejahn]

*SIGH*

-- yes, agree with R. Engqvist. -- It is ALWAYS 'safe' to send PDF/X1a. This sets an expectation level and helps you defend your prepress decision(s). The fact is, this puts the ball squarely in the court of the print output producer, as it is THEIR job to make the color look as you INTENDED - the entire point of a blind exchange between two parties - who knows what they will need to do to honor your output intent ! They may be printing Rotogravure with type 4 inks or on a Xerox iGen - this is now THEIR problem, not yours.

If you are not familiar with Self Publishing giant Lulu.com - this is EXACTLY what they do - they get self published books from the outside - then process them - then send color books out -- all PDF files -- all flattened and CMYK PDF/X1a. These are sent to the POD shops whom service them world wide, and lulu.com expects (demands) TR001. This puts the responsibility squarely in the print service providers lap. If you have a savvy supplier, you can approach them about PDF/X-3, 4 or 5 workflows, but chances are they wll give you the BSOI (Blank Stare Of Ignorance)

Stop SPDFS

Stop The Transparencide.

Michael Jahn's blog

Michael Jahn
Jahn & Associates
PDF Color Conversion Specialist
1824 North Garvin Avenue
Simi Valley
California 93065
Office: (805) 527 8130
Cell: (805) 217 6741
Email: [email protected]
Skype: michaelejahn
Twitter: Twitter / michaelejahn

 

[Louis Dery]

*SIGH*

-- yes, agree with R. Engqvist. -- It is ALWAYS 'safe' to send PDF/X1a. This sets an expectation level and helps you defend your prepress decision(s). The fact is, this puts the ball squarely in the court of the print output producer, as it is THEIR job to make the color look as you INTENDED - the entire point of a blind exchange between two parties - who knows what they will need to do to honor your output intent ! They may be printing Rotogravure with type 4 inks or on a Xerox iGen - this is now THEIR problem, not yours.

Hi Michael,
Agree with you.

About "THEIR job to make the color look as INTENDED", how do you suggest to make this happend?
CMYK to CMYK repurposing? Curves? DeviceLink?
Just want to know what is your ides about it.
Many are sating that if you "change" the CMYK file, client won’t be happy. BUT, if you don’t, will you be able to match THEIR INTENTED colors?

Louis Dery
TGLC inc.
TGLC Solutions de Gestion de Couleur et Contrôle Couleur: Logiciels PerfX, Formation, Intégration, Certification

 

[Pork Rind]

Pork why X3 and not X4, RGB and Transparency can be issue in X3, since you may get part of an image converted to CMYK and anoher part not (that was my experience, but it was a couple of years back when I decided to go X1a until X4 was ripe)?

Ah, this was a little while back. X4 wasn't ready and my vendors in China wouldn't have known what to do with it anyway. There were indeed some issues with flattening mixed-mode docs, but a little care in file building eliminated most all of that. X1a took care of the real problem files when necessary.

 

[format]

"There is no such thing as "generic" CMYK."
An image produced on a CMYK scanner is surely Generic CMYK.

 

[Lukas Engqvist]

I have never scanned in CMYK, so please correct me if I am wrong, but any RGB scanner has (or can have) a scanner profile and I would assume a CMYK scanner would have the same.
There is a generic CMYK if we are talking about unmanaged colour, but surely when better soloutions are available there is no need to cling to older methods. Unmanaged colour is simpler at the price of being less predictable.

 

[meddington]

Some older drum scanners only delivered CMYK (despite any internal/non-iCC conversion from RGB which the operator had no control over). The CMYK output was largely adjusted towards the press/Matchprint output by the scanner operator, and thus I wouldn't really classify it as generic CMYK either...rather closed-loop to each specific operation.

 

[ASM]

"There is no such thing as "generic" CMYK."
An image produced on a CMYK scanner is surely Generic CMYK.

Nanana - all scanners scan in RGB. The CMYK conversion is in the software. A scanner is, after all, a camera with CCDs or CMOS. Good ones have seperate R,G and B sensors, most have beam splitters to provide R,G and B data.

There's no generic CMYK

 

[mattbeals]

So what's wrong with PDF/X-3? It works just fine as long as you have the process controls in place to accurately proof the RGB to CMYK conversion. You have to have tight communication between everyone for a PDF/X-3 to work as intended. PDF/X-4 can be just as problematic with allowing for live transparency. If you want to be absolutely bullet proof then you have to go with PDF/X-1a.

Got to communicate which ever way to go.

 

[Luc St-Pierre]

1) What is the point in making corrections in soft proof color mode and not go ahead making final CMYK conversion

The point may be not knowing for a fact what CMYK device will be used in the end. To me, there is no such thing as a “conversion” to CMYK. Generic CMYK does not exist. Going CMYK is performing a color separation for a specific destination, a specific printing device. This separation will remap colors according to destination profile and therefore must be done once, and to be as effective as possible, must be done from a RGB or LAB file. Converting to Profile is the worst move to do. It means you will actually perform a color separation totally based on LUT (look-up tables). Reseparate such a file in another CMYK destination may cause severe color shifts or artefacts in the final output.

 

[juergenroesch]

generic CMYK test

generic CMYK test

this test requires a digital proofer and some design software

Try the following
- create in any application a few boxes with whatever CMYK values you like. Use really odd combinations, not solids. e.g. one patch uses CMYK values of 60/50/40/30. You should have at least 4-8 boxes on your sheet - their values should be quite different
- save the file and send it to the proofer using your standard setup
- now change the proofing standard on your proofing system and repeat the print
- do this for several randomly picked color standards, or even better supplied printer profiles

For accurate proofing you should use in an ICC based proofing solution absolute colorimetric rendering intent.

Stick all the resulting proofs up in your viewing booth. Remember, they now represent different printers printing the same CMYK values.

If they all look identical you found Generic CMYK and I'm the Queen of England


So if anyone supplies untagged CMYK to a printer you can expect anything in the range (or even outside) of what you currently look at in your viewing booth.

If you on the other hand pick one from the booth that you like and look up the color standard it represents as a proof and tag that to your file, anyone who receives your file would immediately know which visual result you expect.

Now how they achieve that is a different question. Linear adjustments, repurposing by reseparating or just some plain old density and blanket pressure adjustment on the press are some possibilities. But usually if they are unable to supply what you tagged without major rework, they likely will contact you and discuss the issue to find a solution which works for both. Wouldn't you prefer that over them just printing your file and giving you one random pick of what you were now looking at in your viewing booth?


We also read about rendering intents, gamut scaling and gamut clipping. Unfortunately this is all you currently get in PhotoShop and most Adobe applications. On top of that the conversions created by these applications are somewhere between basic and disgusting - but extremely flexible.

You get much better separation or conversion results from some (but not all) device-link products. Some even expand the rules of gamut translations by giving you flexible (adjustable) choices betwen scaling and clipping by keeping most of the core space relative and gently mapping in out-of-gamut colors. Also the relativity of colors in the gamut is important and most standard ICC conversions create a non-linear introduction of the channels during the separations. This can become noticable in smooth background shades which after separating or conversion can show bumps and ripples.


I could go on, but as the thread is already a few days old i don't know if there's still interest in it. If so - please post a comment.