Color management issue?

[Cameron]

Hey guys,

We've run into this a couple of times now. Generally with supplied files so its hard to see it coming. Today we had a pdf of a business card supplied to print.. the background was one shade of green.. and behind a couple of logos the green matched perfectly on screen with no change in values. When printed however, the green behind the logos boxed itself with a lighter shade of green.

I am thinking it is how its color managing vector vs raster? The file is supplied though so I am having a bit of a hard time..

This is happening when we print to our fiery on our km8000.. we have seen it happen with out onyx rip for our wide format as well.

Hoping someone can help me out a little here. Thanks!

 

[WharfRat]

Probably the background was created in CMYK and the box behind the logo is RGB.

 

[Stephen Marsh]

Was the file a PDF? Did you print the file or drop it in a hot folder for print processing?

Sounds like a transparency issue (flattening), and or additionally perhaps an issue with the transparency blending space.


Stephen Marsh

 

[Cameron]

Good thought on the cmyk rgb.. I honestly forgot to even mention checking that. Tomorrow I will see if we can determine that.

The file was a pdf. We drop all files in hot folders for processing regardless of whether it is going to press, wideformat, or digital.
And i thought of transparency issue, but I dismissed that thought because it wasnt a white box behind it just a slightly different green.. usually when we have transparency issues it fully knocks out the background.

 

[Cameron]

Great call wharfrat. Ran a quick preflight and fixed the rgb, worked like a charm. Should have thought of it, but very appreciative!!

 

[Stephen Marsh]

Do you mean that there was actually an object behind the logo, built in RGB but "matching" the background, while the background was CMYK?

Stephen Marsh

 

[Cameron]

Do you mean that there was actually an object behind the logo, built in RGB but "matching" the background, while the background was CMYK?

Stephen Marsh

Hey Stephen, it seems like the logos were placed in rgb, not positive if they were placed with the rgb version of the same green, but it registered as the exact same cmyk mix in acrobat.. the problem was the print would show a color variance. When we ran preflight and corrected the rgb images in the file, printed perfectly. works for me!

 

[Visualaid]

Hey guys,

We've run into this a couple of times now. Generally with supplied files so its hard to see it coming. Today we had a pdf of a business card supplied to print.. the background was one shade of green.. and behind a couple of logos the green matched perfectly on screen with no change in values. When printed however, the green behind the logos boxed itself with a lighter shade of green.

I am thinking it is how its color managing vector vs raster? The file is supplied though so I am having a bit of a hard time..

This is happening when we print to our fiery on our km8000.. we have seen it happen with out onyx rip for our wide format as well.

Hoping someone can help me out a little here. Thanks!

just rasterize the artwork, the boxes will go away.

 

[Correct Color]

just rasterize the artwork, the boxes will go away.

That's all fine, except that spot colors will go away too. And depending on how you rasterize and to what color space, maybe much more color information as well.

Typically this problem is caused in RIP's when the rendering intents for raster and vector parts of a file are set differently. Such as Relative Colorimetric for vector, and Perceptual for raster images. Setting them to be the same -- the key is for them to be the same, not which intent you use -- will fix it in many cases.


Mike Adams
Correct Color

 

[Visualaid]

That's all fine, except that spot colors will go away too. And depending on how you rasterize and to what color space, maybe much more color information as well.

Typically this problem is caused in RIP's when the rendering intents for raster and vector parts of a file are set differently. Such as Relative Colorimetric for vector, and Perceptual for raster images. Setting them to be the same -- the key is for them to be the same, not which intent you use -- will fix it in many cases.


Mike Adams
Correct Color

How would I even get into our digital copier operator's fiery to check those settings? I'd like to try this.
Thanks for the idea.

 

[Correct Color]

Visualaid,

I don't have a Fiery device here, so I can't point you to the exact spot, but it's in the main advanced color management section of Command Workstation. It's the screen with all the lines running from left to right that describe differing input file possibilities and machine printing configurations.

And, as I recall, it doesn't call the rendering intents by their actual names; it calls them something like 'photographic' and 'presentation' or somesuch. But if you can find that screen, that's where they are.

Note also that in most RIP's and I think this is true of Fiery, you have a choice of setting them for raster and vector, and for RGB and CMYK. So it's conceivable that the OP here could have resolved his issue by changing from RGB to CMYK not because of the file type but because of the rendering intent.

Mike

 

[Greg_Firestone]

How would I even get into our digital copier operator's fiery to check those settings? I'd like to try this.
Thanks for the idea.

Preflight and fix it ahead of time with your preflight/file correction software. The file should be corrected and press-ready by the time it gets to the copier operators hands.

Greg

 

[Correct Color]

Preflight and fix it ahead of time with your preflight/file correction software. The file should be corrected and press-ready by the time it gets to the copier operators hands.

Can't do that.

The file can be made perfectly correctly and this issue can still happen. While there are faults in files that can cause similar problems, this particular issue -- which from my experience has been the greatest cause of these issues -- is not a file issue, it's a RIP issue.

And, typically, older RIP's are set by default with Perceptual for raster and RelCol for vector.


Mike

 

[Greg_Firestone]

Hi Mike,

Please correct me if I'm wrong. If the files are corrected ahead of time and converted to the colorspace of the output device, the RIP shouldn't be performing any color changes. I suppose it could depend on the color management settings of the RIP but technically the colors are already within the gamut of the output device. So why would a rendering intent impact this at the RIP stage?

Greg

 

[Correct Color]

Greg,

I work almost exclusively in large and grand format, so I'm not entirely up to date in pre-flighting files for litho, I suppose. But in large-format, I never set up early-binding workflows. Ever. As far as I'm concerned, one of the main functions of a RIP is to convert files to the destination color space.



Mike

 

[buckeye]

Correct Color,

I've read many threads about color management here on Print Planet and have seen a lot of them that you've replied to and I would put you right up there with a lot of the color guru's here on this site, but I'm not understanding your concept on this one. I would think that if you can fix a pdf downstream before it gets to the RIP, then you wouldn't have to worry about WHICH device it even goes to - color managed or not. Not saying that you're wrong, just that it would seem to be safer to have the file already corrected so that it doesn't matter where it goes.

-Erik

 

[Correct Color]

Erik,

It's not a question of "fixing" the file. Let's say you've got a solid blue background you created in Illustrator, and then you've got some type overprinting it, and you put a drop-shadow behind the type. In this instance, if your rendering intents are different in the RIP, you'll get the effect of the blue being a different color in a little box around the type and the drop shadow.

And it's got nothing to do with the file. What's happening is that the RIP converts the type, its drop shadow and a small area around it to a raster file first, so it applies the designated raster rendering intent to it. The rest of the blue around it gets the vector rendering intent.

Since there's nothing wrong with the file, there's nothing to "fix" save rasterizing the file before RIPing it, which was what people did for years when this problem came up. But as it's become more common as more people have gone to PDF's in large-format workflows -- something I'm hardly a fan of but that's another story -- it's become more and more of an issue, all the RIP companies tout their latest "solutions" and if you look behind the curtain, very quietly they've all changed their default rendering intents to match.

And yes, I suppose you could work around with an early-binding workflow. But that creates it sown set of issues, and again, I may not be up to date in litho, but in large format, it's almost never done.


Mike

 

[buckeye]

Correct Color,

After re-reading the posts, I think you and I are referring to two different things. I don't think Cameron ever did mention if the two different colors were because one was vector and the other raster or if both were raster - just that changing the RGB logo to CMYK is what fixed it. I was just assuming that the background (CMYK) & the logo (RGB) were raster and that fixing it now made more sense.

-Erik

 

[Correct Color]

Erik,

I don't think Cameron ever did mention if the two different colors were because one was vector and the other raster or if both were raster

Okay, but I'm not talking about that either.

In the scenario I described, the entire file is a vector file. The background, the type and the drop shadow are all vector. It's in how the RIP processes them that the issue occurs.

In this case and in cases like this, the RIP takes the type, the drop shadow, and a small area around them, and the RIP converts them to a raster image. Once it does, it then applies the raster rendering intent to that area. The area around it it still processes as vector, so it gets the vector rendering intent. The difference in shade between the two areas is the difference between the two rendering intents.

This happens even if all the color information in the file is correct.

And of course it is possible that the OP had some other issue. But it's also possible that the change from RGB to CMYK solved the problem because the rendering intents specified for CMYK matched, while the ones for RGB did not (which is typical of many Fiery setups.)


Mike

 

[buckeye]

Correct Color,

I understand what you say is happening concerning the rip. I prepare and send files all the time to our KM C8000 and have never run into this issue. I'm not in front of my Command Station workstation at the moment but would that be because both of my rendering intents are at the same setting?

-Erik