Coated & Uncoated Pantone Simulation on Digital Presses/Copiers

Started by Nate, May 13, 2016, 08:22:38 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

How you would prepare the digital file in the following example?

Leave the spot color spec'd as coated. (Simulate the coated swatch and try to match the brochure.)
2 (50%)
Remap the spot color to the uncoated version for the digital production file. (Simulate the uncoated swatch and try to match the envelope).
2 (50%)

Total Members Voted: 4

Fontaholic

Also, sometimes I will just convert a problematic PMS color to its "approved" CMYK breakdown and send it to the DCP that way.

Most of the time, I get a very accurate representation/output of the desired color.

Cheers,
John the Fontaholic :drunk3:

Nate

Quote from: Tracy on May 13, 2016, 01:22:53 PMFor Nate, can you explain what you said about the operator changing the definition?
This may be helpful for me to understand
Sorry for the late reply--we've been shorthanded the past couple of weeks and I've been stuck running our wide format department.

Anyway, it's hard to accurately describe this without getting a bit technical, so bear with me.

As a disclaimer, I want to mention that I'm still relatively new to the industry. I started in Prepress about 3 years ago and while I've learned a lot in that time, I know I still have a lot to learn as well. Feel free to yell at me if anything I say below is inaccurate or misleading.


Part One: CMYK percentages are not universal.

In any printing process, the appearance of a color depends on more than just raw CMYK values. Due to differences in color components (ie. Ink vs. Toner, different ink manufacturers, etc), two different machines will yield a different result with the same cmyk values even if they are printed on the same stock.

Device profiling accounts for these differences by interpreting the CMYK values as representing an intended appearance rather than specific percentages of ink or toner. If you know what process/output profile the CMYK values were built for, you can anticipate the intended appearance of those CMYK values and convert them to give you a result that looks the same on the actual output device as it would on the intended output device. (CMYK to CMYK conversion should be performed with DeviceLink profiles rather than ICC conversion due to potential problems with regenerating the black channel)

The PDF/X-4 standard requires an "output intent" profile for exactly this reason. The output intent profile describes the response of the intended output device, so that we know what a given set of cmyk values are intended to look like.

Since most traditional offset presses use similar inks and behave fairly similarly, this wasn't as big of a problem in the past. Digital machines have changed the game quite a bit, as they often have drastically different native responses than a typical offset press (but can be good at emulating various offset press conditions).


Part Two: Inconsistent spot color definitions

In a PDF file, spot colors have both a name and a definition. A spot color could have a standard name such as PANTONE 187C, or any random name the designer chose such as "Super Special Rando-Purple 2". Spot colors must ALSO have a definition, but they can be defined in multiple ways. Spot colors can be defined with ICC-based CMYK recipes, DeviceCMYK recipes, ICC-based RGB values, DeviceRGB values, or (ideally) as L*a*b coordinates. There may be more, but those are the only types of definitions I can think of at the moment.

  • ICC-based CMYK recipes are CMYK percentages that are tagged with a specific output profile (such as US Web Offset SWOP v2, Coated GRACoL 2006, etc.). Since the ICC profile tells the RIP how that color is intended to look, the RIP is able to calculate new CMYK percentages to simulate the appearance of that intended output device.

  • DeviceCMYK recipes are CMYK percentages with no output profile attached. This means if the definition is honored, it will print with identical CMYK percentages on any device, resulting in different appearances across different output devices.

  • ICC-based RGB values are RGB values that are tagged with a specific profile. Just like with digital photos, RGB values can be in sRGB, AdobeRGB, ProPhoto RGB, ColorMatch RGB, etc., etc.. Since we know which RGB colorspace the definition is for, we also to know the intended appearance.

  • DeviceRGB values are RGB values with no profile attached. Again, this means we have no way of knowing the intended color appearance those RGB values are supposed to yield.

  • Finally, L*a*b (aka CIELAB, aka Lab Color) does not describe colors in terms of device-specific colorants like the rest of the color spaces. Instead, L*a*b is based directly on the response of the rods and cones in the human eye. This means that L*a*b colors are always the most precise definitions of color appearance. The one downside to L*a*b; it gives no input on how to actually achieve that color on press.


TL;DR

Okay, now back to the question at hand about the operator changing spot color definitions.

In Xerox FreeFlow Print Server, if "PANTONE Color Processing" is disabled, it will use the spot color definitions from the file (which are subject to all of the inconsistent definitions I've described above).

If "PANTONE Color Processing" is enabled, it will pull spot color definitions from a library of CMYK recipes which can be viewed/edited/created in a tool Xerox calls the "Spot Color Editor". The potential for problems with this is if an operator misuses this ability by editing those definitions to a non-standard appearance.

The most likely scenario I can think of that could lead to this is if two runs of a similar job had different color definitions in the file. For example, if a customer supplies a job with a CMYK recipe for one job, and then later supplies the same job with a spot color instead. The first run would probably be left as-is with the supplied CMYK values regardless of how accurately the customer's conversion represented the intended spot color (since it's supplied as a CMYK recipe we have no way of knowing what PMS it's intended to match). Then when the second job hits the press, their spot color should print more accurately than the first run with a CMYK recipe since it can now use "PANTONE Color Processing" to pull a more accurate recipe for that spot color on our digital press.

At this point the operator has a decision to make. Should he keep the revised color of the new file, or adjust his definition to match the previous run for the sake of consistency? In my mind, this should be the point where the job is kicked back to Prepress and/or the CSR to contact the customer and have them make the call. (edit: If the customer wants to match the previous run, prepress should convert the spot color to the previous 4-color build rather than edit the spot color in the RIP.)

In practice however, the operator doesn't want to take the time to do this and doesn't want to be blamed for holding up the job, so he makes what he considers to be the safe call and matches the previous run by editing his definition of that spot color.

Problem is, if he does this, he's just redefined that spot color to a CMYK recipe that may match this customer's previous run, but will NOT match the standard Pantone swatch on future runs. The next time we get a job from a different customer that uses the same Pantone color, it'll wind up getting the same CMYK recipe that was modified for the other customer and their job will not match the standard Pantone appearance for that color.


Summary:

If "PANTONE Color Processing" is enabled in the RIP, it will use whatever CMYK recipe it finds in the chosen library regardless of the accuracy of that recipe. Any updating of these libraries must be done with care to avoid changing the definition to a recipe that results in a less accurate match to the intended Pantone color.

DAYAMN.. I guess this post got away from me a bit. Hope someone finds this useful. :popcorn:

Tracy

I do!
Thanks for the taking the time!

I guess you need to be careful when changing definitions
and make lots of notes, I can see how this could cause a problem
Thanks Nate!

Slappy

fwiw, I used to work in a shop that ran HP Indigos and we spent countless hours/days profiling, fingerprinting and chasing color matches. It was fun. And at the end of the day, we'd almost always be over-ridden by the sales dood or dezigner. I guess what I took away was just because we could, we probably shouldn't have and in 99.999999% of shops, nobody I've seen is going to put that much weight behind digital matching to offset - even if they tell the clients it does!

/soapbox
A little diddie 'bout black 'n cyan...two reflective colors doin' the best they can.

Farabomb

The boss here is famous for stopping the customer, right before they are about to sign off and saying "we can make xxx better". The look on the pressman's face is priceless as he knows whatever shit just came out of his mouth isn't possible.
Speed doesn't kill, rapidly becoming stationary is the problem

I'd rather have stories told than be telling stories of what I could have done.

Quote from: Ear on April 06, 2016, 11:54:16 AM
Quote from: Farabomb on April 06, 2016, 11:39:41 AMIt's more like grip, grip, grip, noise, then spin and 2 feet in and feel shame.
I once knew a plus-sized girl and this pretty much describes teh secks. :rotf:
They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety.
         â€”Benjamin Franklin

My other job