color Inconsistencies

[rande]

Wonder if someone can put me on the right path.
We've been having problems on occasion.
The pressman is having to bring down the cyan and sometime the magenta
to match our proofs.
The proofer checks out fine.
He's able to hit most jobs with the densities setup my the screen guys.
But sometimes he really struggles with cyan and magenta. He's just switched units
so that should rule out the unit.
My question is; assuming that everything above and related to that part of it
checks out. Is there something in client files that could be messing things up; such as color management (which I'm not an expert on). We for the most part make postscript files and run thru distiller. We have had color management off in Indd. but recently I've had it on.
Are the clients saving their files differently? We get PDF alot, I have nailed it down to what type of files yet.

RGB 1998
US Web Coated Swop v2

CM-
RGB - preserve
CMYK - Preserve

Is there something in TrueFlow that would affect certain files differently.

Any colormanagement preflighting we should be doing to make this more consistent ?
Grachol 7
TF4.01
CS3

 

[gordo]

[SNIP]
The pressman is having to bring down the cyan and sometime the magenta
to match our proofs.
The proofer checks out fine.[SNIP]

Could you elaborate on those two statements?
What do you mean that the proofer checks out fine? If you are supplying the proofs, how have you validated their conformance to a color standard/specification?

best, gordon p

my print blog here: Quality In Print current topic: lpi vs dpi

 

[rande]

He's bringing down the densities. by about 10.

To test the proofer we were told to run a strip of the color chart and visually compare.

I recently upgraded the proofer software and calibrated and ran a strip of my color chart that I compare to the original color proof.

this problem has been happening for a while now even before the upgraded.

the pressman doesn't think its the proofs either.

 

[rath307]

Do you make your prepress proofs on the same stock
as you Print on? Does it occur more on uncoated stock or coated stock? is your rip honoring embeded color profile's or does it strip them out. If the file supplied is RGB do you let the rip convert to
CMYK or do you convert in Photoshop before ripping. And which
ever it is do you do it the same way each time. Last but not
the least do you check your plate calibration often.

 

[gordo]

to rande


The reason for starting with the proof is that it might provide the simplest answer, before you drill down into color manglement.
So you are saying that the proofs that you now output look the same as the proofs you output in the past? That if you proofed a job you did 6 months ago and compared it to a proof of the same file you did today - the proofs would look the same? Also 6 months ago the proofs and presswork were aligning - but now they don't?
If the answers are "yes" then the problem may be with the plates or the press.
If the press has no problems with other-than-you supplied files and proofs - then that may indicate something at your end has changed.

On a sidebar - it's a bit late now but this is another good example of why everyone should maintain a "golden reference" - see here:
Quality In Print: The Golden Reference - part 1 of 2
and here:
Quality In Print: The Golden Reference - part 2 of 2

best, gordon p

 

[rande]

Do you make your prepress proofs on the same stock
as you Print on? Does it occur more on uncoated stock or coated stock? is your rip honoring embeded color profile's or does it strip them out. If the file supplied is RGB do you let the rip convert to
CMYK or do you convert in Photoshop before ripping. And which
ever it is do you do it the same way each time. Last but not
the least do you check your plate calibration often.

Not on the same stock. We print on gloss. We're matching proofs most of the time, but we want to tighten it up and don't understand what is going on.

We have curves for coated and uncoated, not the problem.

I was told that the rip does strip profiles, then looking closer it looks like you can set it up to allow profiles. so I don't know. But they did tell me that the rip should not be affecting color at all from what the client has embedded.
I wonder if theres something we should be checking on client files to see what they've embedded that might be causing a prolem and change it.

We convert RGBs in photoshop.
I recently had a job that came in as RGB and I exported out of Indd with color management on Adobe 1998
and the files came out richer. Last year with the same job I converted them in photoshop and they were washed out. So I'm trying to get a handle on that.

We have a color bar with 50%s and RGB on them to check. I don't believe any of that is the problem if most of the jobs are fine. What would make 10 to 20 % of them react like this? that is the question. If assuming plates, proofs and press are fine, what, in the clients file or in TF would cause something like this?

 

[prepresscolor]

If I might, I would like to ask you some questions:
1. What type of press (sheetfed or web)?
2. Proofs made on what? With what find of color management software?
3. What type of press ink and what are the operating densities?
4. Are all your Adobe software part of CS3 or CS4 or older?
5. Where are you and what kind of facility are your presses in and what kind of weather have you been having?

 

[rande]

If I might, I would like to ask you some questions:
1. What type of press (sheetfed or web)?
2. Proofs made on what? With what find of color management software?
3. What type of press ink and what are the operating densities?
4. Are all your Adobe software part of CS3 or CS4 or older?
5. Where are you and what kind of facility are your presses in and what kind of weather have you been having?

1 sheet
2 Epson 9880 - CGI Oris color tuner
3 Vansons (however you spell it)
Should be / need to adjust

c-135 / 120
m- 140 / 135
y- 100 / always fine
k- 170 / 160
He says when he needs to adjust it always real close to the same adjustments.

4. CS3
5. All kinds of weather.

I was thinking though. What ever he sees on the proofs should be what he gets on plates.
So even if there was a problem with the files we would see that on the proofs, so I'm at a loss
of what could be causing this.

 

[rande]

Do you make your prepress proofs on the same stock
as you Print on? Does it occur more on uncoated stock or coated stock? is your rip honoring embeded color profile's or does it strip them out. If the file supplied is RGB do you let the rip convert to
CMYK or do you convert in Photoshop before ripping. And which
ever it is do you do it the same way each time. Last but not
the least do you check your plate calibration often.

I think it could be boiling down to the stock.
We looked at afew of his samples and they look different. We're setup for byden and I noticed he was using some other papers.
But should that be affecting the cyan that much to were he'd need to adjust his density by up to 15?

 

[dimitri]

Do you have common color settings between vector and bitmap graphics?
Do you have documented LAB and grey balance values of what your proof was and what it is now? Or the press inks? The LABs might still be matching, so density would have secondary importance in that case. If you don't have historic documented values, compare the LAB of a proof that you had to adjust on press, and of one that you did not have to adjust on press. This might eliminate proof variation for example.

Then... press variation: What is your dot gain variation? If, for example something has changed on the press and the magenta unit prints heavier, you might need to run the solid ink density lower to compensate for that so that you match the proof. A lot of things can take place on a press, changing the dot gain, and I would think that documenting those press measurables over time (dot gain, density, grey balance) would allow you to make sure that indeed a change has happened on press, and then reliably adjust.

If your magenta and cyan is off, then even your yellow could be off, only that it's changes could be less sensitive due to the status T filter density that doesn't pick up us much variation. This might be the least likely of cases, but what is your grey balance with the magenta or cyan low? Are you still grey balanced?

And a more rhetoric question. Why tighten up a density variation of just 0.10 points? Is it worth re-engineering the universe when you can get there with just one more pull, if that? Are you able to print every job at 1.35 magenta all the time? Can you keep the press stable all the time so that you have NO press variation? To me this is impossible, so: what is an allowable density variation from run to run or across the sheet (at the sheet size you are running)?

...some thoughts/variables to examine and start eliminating areas.

-D

 

[rande]

Do you have common color settings between vector and bitmap graphics?
Do you have documented LAB and grey balance values of what your proof was and what it is now? Or the press inks? The LABs might still be matching, so density would have secondary importance in that case. If you don't have historic documented values, compare the LAB of a proof that you had to adjust on press, and of one that you did not have to adjust on press. This might eliminate proof variation for example.

Then... press variation: What is your dot gain variation? If, for example something has changed on the press and the magenta unit prints heavier, you might need to run the solid ink density lower to compensate for that so that you match the proof. A lot of things can take place on a press, changing the dot gain, and I would think that documenting those press measurables over time (dot gain, density, grey balance) would allow you to make sure that indeed a change has happened on press, and then reliably adjust.

If your magenta and cyan is off, then even your yellow could be off, only that it's changes could be less sensitive due to the status T filter density that doesn't pick up us much variation. This might be the least likely of cases, but what is your grey balance with the magenta or cyan low? Are you still grey balanced?

And a more rhetoric question. Why tighten up a density variation of just 0.10 points? Is it worth re-engineering the universe when you can get there with just one more pull, if that? Are you able to print every job at 1.35 magenta all the time? Can you keep the press stable all the time so that you have NO press variation? To me this is impossible, so: what is an allowable density variation from run to run or across the sheet (at the sheet size you are running)?

...some thoughts/variables to examine and start eliminating areas.

-D

Well thats a lot to think about.
I'm thinking its his paper.
But to answer some of your questions.
-Vector & bitmap?
-proof check is just visual normally. I just got out the numbers to check also.
-we have colorbars with cmyk rgb where he checks LAB and I guess thats giving him gray balance info too.
-I have checked the plates many times no real dot gain there.
Dot Gain curve:\c - +5.2/m - -1/y - +2.5/k - -1

I take it no one can think of a CM/profile issue that could be causing this.
I've been trying to get a handle on CM but I have yet to understand why its used and how to use it in the workflow.
We turn CM off and do postscript files. Leave color unchanged in Distiller.
If we export out of Indd cs3, it messes up picture boxes sometimes; we can't trust it.
Example; say you have a row of boxes lined up, exporting will shift them so they don't line up anymore. One time it nicked/distorted the lines.

thanks for the thoughts; would appreciate any more.
we're just starting to monitor closer, so we'll see what happens.

 

[rande]

Well the pressman doesn't seem to think so far that its the paper brightness.
What else could it be?
Types of files and how they're saved.
Clients CM settings.