10 Pre-Press Tips For Perfect Print Publishing

[kasperheim]

Is anyone sold on the “Use RGB instead of CMYK”?

10 Pre-Press Tips For Perfect Print Publishing - Smashing Magazine

 

[kslight]

Never heard of that...not sure if I buy into it. I think you should create your art for your intended output format for the most reproducible color. Maybe you can't get the same range out of CMYK, but customers that create their files in CMYK are not as likely to see as significant of a difference between their screen and the printed piece. That article should be titled "Ten ways to add prepress charges to your next print order by creating your files incorrectly".

 

[William Campbell]

The article is misleading, and fuel for screw-ups when interpreted by the lesser-educated who are most likely to embrace the wonderful "advice."

Sure, we could argue that keeping data in RGB is keeping more of the data. Good for re-purposing. That's fine, but come print time, automatic conversions are no match for the hand of a craftsman, even given today's level of color management technology. And besides (considering re-purposing), shouldn't an image match across media? A screen can match the smaller CMYK gamut easily. A press will never match a vivid RGB image. Why not choose the lowest common denominator? Get to a perfect CMYK image, and instead of as the author suggests, turn it back to RGB when the desired media destination calls for RGB. Operating in this manner, the images will match both printed and other higher gamut media.

While the author of the article doesn't explicitly say "send your printer RGB files," it certainly leaves those who don't dig deeper to think that is what it says. In other words, the article is poorly thought out, and I would advise all to steer away from it.

Another clue -- the article makes no mention of GRACoL. Some of the comments/responses do, but nothing in the actual article. Today we're still battling how Adobe sets the default to "SWOP Web" and clients can't understand why a high quality commercial offset press produces the quality of a web press. What do you expect? Profile an image to web characteristics and you going to get the crap 260% TIC of a web press. Computers only do what they are told. And while the color management modules inside of most modern workflows have improved, given a target profile of SWOP Web, even the best CMM in the universe is only going to do what it is told -- turn that image to something a web press can handle, which is setting the bar awfully low.

The better "advice" would be -- use GRACoL.

No, we get the stellar advice to use RGB.

We have a long way to go...

 

[Magnus]

I work at a large printshop in Sweden and we'v work exactly like the article describes for a couple of years, we also recommend our customers to work that way. The article are not saying that anyone should send RGB-files to the printer (even though that wouldnt be a problem for us as long as the PDF/artwork contains embedded icc profiles), it's about working easy, fast and correct with colormanagement in Indesign. Whats wrong with that?

William: The writer of the article does not mention any specific CMYK-profile cuz thats not whats its about. CMYK is not a work-space it's a destination.

 

[Lukas Engqvist]

As with Magnus we have used this flow since InD 2.0

As with Magnus we have used this flow since InD 2.0

Nothing strange. For us movinig from OPI server wich did the CMYK to using PSD files to be able to utilise the support for live transparency this was the natural way to move. It has a proven track record for stability and trouble free shooting. With images as RGG converting through OPI since mid 80's using the procedure in the article for 99.5% of all jobs since 2002.
(actually if we get a job with CMYK images, with too high TAC fastest and best way to fix is just convert the images to RGB and output)

Would add though use Illustrator technical illustrations in safe CMYK mode! Wich is what we are heading to under point 8, so nothing strange there.

Since PS has no overview of Inklimit It is the most natural way to go.

 

[Stephen Marsh]

Since PS has no overview of Inklimit It is the most natural way to go.

Of course, one can mouse around in Photoshop with the info palette set to display total ink - however there are better ways to do this in Photoshop!

Lukas, you may be interested in this link...

Curvemeister Total Ink Actions

There was a discussion about checking for TIL/TIC/TAC on the Dan Margulis Applied Color Theory email list and Mike Russell of Curvemeister fame created an action for use for checking total ink limits (to avoid problems with the "ink police" as they are known in some corners of the web!).

This free action is fantastic and my thanks go to Mike for making this tool available to the Photoshop community.


Regards,

Stephen Marsh

 

[mattbeals]

Laurens mentioned something on the link provided. Many (I didn't say most or all, just "many") already use an RGB workflow internally and at the last minute convert to CMYK. Some even send RGB PDF/X-3 files with the correct output intent defined. They work in RGB and softproof using the output intent to view press color. But here's something to think about. RGB workflows are more flexible for re purposing content than CMYK based workflows. Once you go CMYK you cannot go back to RGB as William points out. The idea of lowest common denominator is a valid argument from a print perspective. However if you have an RGB workflow you can go to the web, mobile, broadcast, cinema, print (in one form or another), etc. As a brand manager, content owner/publisher/etc you have more flexibility to reproduce the art to its highest fidelity for the specific "medium". A CMYK workflow is becoming the "old" way of working as this need becomes important. It's "comfortable" for printers to work and think CMYK only because it is what they have known for so many years. Print is no longer the dominant medium for publishing content. Therefore it is no longer "prepress", it is becoming "pre media". As I said before, we need the flexibility to publish the content in what ever format on whatever medium we want to the highest level of fidelity. If we think in lowest common denominator terms then we produce the best quality on the least capable medium. That doesn't sound like what a brand owner wants to hear... Might as well throw away the Pantone library then, only part of it is able to be reproduced in CMYK. Which happens to be about the lowest common denominator. Diversity is the key. It's not just ink on paper any more. It's not enough to be "just a printer". Printers, and others, that survive long term are not just going to put ink on paper. They are going to be able to re purpose content for their customers. RR Donnelley is not just putting ink on paper. Part of what they do is re purpose content. So the idea of working RGB internally for a publisher and sending final CMYK is not unreasonable. Nor is the idea of sending RGB data and having the print provider make the final separations. Of course if the print provider is providing more services like asset management then they're very likely to be archiving RGB data (if they are planning ahead).

Maybe this is just another one of my notoriously kooky ideas. But in this economy, and in years past, we have to look beyond "print" in our industry and think outside of the press room. Time to start thinking "premedia". If anyone wants to be a contributor to my site (a bit dusty) premediaworld - Home then please let me know.

 

[Lukas Engqvist]

Of course, one can mouse around in Photoshop with the info palette set to display total ink - however there are better ways to do this in Photoshop!

Lukas, you may be interested in this link...

Curvemeister Total Ink Actions

There was a discussion about checking for TIL/TIC/TAC on the Dan Margulis Applied Color Theory email list and Mike Russell of Curvemeister fame created an action for use for checking total ink limits (to avoid problems with the "ink police" as they are known in some corners of the web!).

This free action is fantastic and my thanks go to Mike for making this tool available to the Photoshop community.

I have seen similar actions, but find them hard to explain and even harder to teach to implement than an RGB workflow. I'd be interested to hear how the discussion went, from the link it provides an answer to an unasked question.

The problem is how do you handle the areas with too much colour? There is no action in photoshop to reduce ink or apply GCR or UCR on a selection, thought that would be necessary for these actions to be truly useful. The only way to limit the ink would be to convert the photoshop image to Lab and then convert it back again using a different separation profile, then reselecting the inverse of the areas indecated by the Ink police, and filling with the original. Explaining that to someone who wants to create freely but just get what they see on screen is a little tricky in my experience.

I would say it is more important for photoshop users to either work with the limitations of each specific output intent, or to work device independantly… ie RGB. There are exceptions and for that I am very thankfull for smart objects wich means you can actually have adjustment layers in RGB in the embeded RGB object and have channel targetsed adjustments in CMYK in the main CMYK document… but the special scenarios where that is applicable is less than 1% of images, and does require a knowlede of the output intent.
(oh Lab would work just as well as RGB but there is an advantage of having the image gamut and output gamut to be of similar size)

I do keep asking Adobe to include the same interface that we find in Acrobat and InDesign, but with an RGB workflow, where the correct separation profile is selected in InDesign it is not possible to get too much ink.
I have also asked Adobe to consider that when having a working CMYK ICC with and embedded ink limit that Inklimit should be honoured.

 

[Magnus]

This is not a problem for us who are using ink-optimizing software like: Binuscan CMS server, Gmg ink optimizer or cmyk2cmyk device link conversion. Dont see the need for this in Indesign. We never have to bother our customers with any TAC/TIC-issues.

 

[mattbeals]

Ink coverage is relatively easily taken care of with a good device link profile and Callas pdfToolbox (plug-in, Server or stand alone) or in the RIP. It should be a non-issue for customers for the most part (there's always an exception). But if you're taking in RGB data then it's a non-issue anyways.

 

[prepression]

Is anyone sold on the “Use RGB instead of CMYK”?

10 Pre-Press Tips For Perfect Print Publishing - Smashing Magazine

I am not sure who wrote this but I would be skeptical. Here's a link to an article that provides better prepress tips:

exploring digital prepress

 

[mattbeals]

Reid Anderson if I recall correctly. It's a good book.

 

[Lukas Engqvist]

Prepression I am not sure I agree with you. The simple reason is that separation RGB data and CMYK data is a very convenient way to handle colour management and safe CMYK at the same time. All RGB is colour managed and all CMYK is safe.
To some extent device links and inksave servers can fix problems that should not have occured with a workflow that follows best practices. I find them techniques to treat a symptom. I would still argue for a best practice and a workflow that is not dependant on "my configuration" (I have press repurposing, but I find that a little off the point).
Resizing all in Photoshop is not a practical solution, yes there are scripts and pluggins that will do it, but if you have an undecisive designer you may end up rescalling an image multiple times, wich is a greater evil than resizing in InDesign.
The phrase RGB colours cannot be matched in print is missleading, because with ECI RGB and coated paper most colours are matchable, most natural colours occuring in photographic images that is.

 

[pcmodem]

I used to be a firm believer in having the customer supply CMYK images each and every time. I am starting to believe in keeping the images as RGB and having them converted to CMYK when Exporting to PDF out of InDesign. It has taken me years to accept that RGB is better, in fact my final acceptance of it happened just last week. I don't practice an RGB workflow but that is the next step.

I do find it interesting in the link prepression posted. The Blog talks about only using CMYK, and then later talks about color managing your documents. If you don't have RGB images, why even color manage your document (unless you don't have a RIP to handle plate curves). He also says to use TIFF and EPS images and not native Photoshop (PSD) or Illustrator (AI) files. This writer is certainly in the 90's using a modern application. It is time he gets with the present day!

 

[Stephen Marsh]

I have seen similar actions, but find them hard to explain and even harder to teach to implement than an RGB workflow. I'd be interested to hear how the discussion went, from the link it provides an answer to an unasked question.

Hi Lukas, I try to get around a bit, however I have not seen such an action before. Have you any links for such similar actions?

I can't remember the original thread 100%, I think it was someone wanting an easy way to evaluate TAC in Photoshop, without having to do so in other software and without having to mouse around the image in Photoshop.

The problem is how do you handle the areas with too much colour? There is no action in photoshop to reduce ink or apply GCR or UCR on a selection, thought that would be necessary for these actions to be truly useful.

It is true that Photoshop does not have a purpose built function to play with GCR/UCR or reduce ink limits in an existing file. That being said, there are many tools, methods and techniques that one can use to reduce the total ink limit and shadow build with Photoshop. The folk that need to come up with these less than ideal hacks may not have access to DLP or other methods of ink saving and they may not wish to totally reseparate the entire image when it is only the total ink that needs minor adjustments.

Anyway, I may be barking up the wrong tree here on this forum, one time I remember running into Chicken Little at the Adobe forums, telling me that the sky would fall in if I adjusted the total ink or the GCR in a file using Photoshop...when from experience of ink on paper I knew otherwise. I did not wish to get into a pissing contest with someone that made many absolute statements without knowing the details on how I was adjusting the total ink build or GCR.


Regards,

Stephen Marsh

 

[Stephen Marsh]

This is not a problem for us who are using ink-optimizing software like: Binuscan CMS server, Gmg ink optimizer or cmyk2cmyk device link conversion. Dont see the need for this in Indesign. We never have to bother our customers with any TAC/TIC-issues.

Magnus, for those of us working in smaller shops that may not have such toys - could you provide a sample CMYK image, both before reducing TAC and after reducing TAC? I can supply an image if you can't. This would be much appreciated as an educational exercise.


Sincerely,

Stephen Marsh

 

[prepression]

Prepression I am not sure I agree with you. The simple reason is that separation RGB data and CMYK data is a very convenient way to handle colour management and safe CMYK at the same time. All RGB is colour managed and all CMYK is safe.
To some extent device links and inksave servers can fix problems that should not have occured with a workflow that follows best practices. I find them techniques to treat a symptom. I would still argue for a best practice and a workflow that is not dependant on "my configuration" (I have press repurposing, but I find that a little off the point).
Resizing all in Photoshop is not a practical solution, yes there are scripts and pluggins that will do it, but if you have an undecisive designer you may end up rescalling an image multiple times, wich is a greater evil than resizing in InDesign.
The phrase RGB colours cannot be matched in print is missleading, because with ECI RGB and coated paper most colours are matchable, most natural colours occuring in photographic images that is.

I prefer to convert images to CMYK so I can apply the right color profile to them. You can resize an image down, but not enlarge it without loosing image quality. Perhaps I am a purist, but I find the tried and true methods continue to produce better results.

 

[Tech]

Have anyone tried actually comparing final product results between RGB workflow vs CMYK workflow? Ultimately that should be the focus. If we all hit the bookstores and compare books printed in the 90s with CMYK workflow and compare to books printed in current flavor of RGB workflow, does anyone think there would be much if any visual difference??? Would end-user consumers that buy these print products care?

It's like arguing about old LCD vs new OLED display technology, each has it's flaws. Truth be told, only geeks like us would care which is what or how it's created, end-user/consumers just want quality products in their hands.

I'm not a firm believe in following any guidelines to the letter, I prefer taking what works and make sure it's efficient enough for everyone involved to follow without overkill and restrict creative solutions. If I have to keep a mix of RGB/CMYK workflow then so be it. Another truth be told, there are plenty of legacy Quark/CMYK files around to last us another decades or more. Who (some of you have) is going to throw money down a rabbit hole and convert to RGB workflow strictly? Who is willing to bet the next revolutionary printing technology is just around the corner and we'll all be arguing about a new workflow in another 5-10yrs? It can't be this much fun chasing your tails all the time can it? What are we? Cats, dogs or men? I say make the tools work for you, not the other way around!

 

[pcmodem]

I believe Tech has it right. In the end you want the tools to work for you.

13 years ago when I started in Prepress, we would change the Faux Bold and Faux Italic to the real font. This was time consuming but it made sure the file was right, I did it because it was the way I was taught. A year or so later after doing it this way and dealing with type re-flow, I asked why we changed the font mappings. It was because of an old RIP we didn't have any more, so I stopped making the changes. Jobs went through faster and the re-flow went away.

The whole point is, we can produce the same if not better results by leaving things alone and letting the system work for us, instead of us working for the system. Leave the RGB images alone, let the profiles convert the RGB images to CMYK. It will save you time.

 

[Magnus]

Magnus, for those of us working in smaller shops that may not have such toys - could you provide a sample CMYK image, both before reducing TAC and after reducing TAC? I can supply an image if you can't. This would be much appreciated as an educational exercise.
Sincerely,

Stephen Marsh

Here's a sample-image I just processed (before and after) with Binuscan CMS Server: http://www.magnussandstrom.se/download/ink_opt.zip
Theres a setting to adjust the "aggressiveness" but this sample is processed with a default setting. In this case the input and output profiles are the same, but in production we use Fogra39 as input and different "pressprofiles" as output and that is when you really gets the most out of it.

One of the pros. with this kind of software is that you dont need to set an TIC-limit. And you can get higher TIC in a (for instance) dark green color (see the square in upper left corner) then in a neutral black. This is not possible with any conventional converting methods (ICC/GCR/Device link etc) so far as I know..

Hope this works as an educational exercise Stephen!

And pcmodem, I second that! ^