I have two questions for you. The image that's causing the questions is attached.
1. I have a CMYK image that has an embedded profile: U.S. Web Coated (SWOP) v2
If I open it in PShop (CS3) with "Use the embedded profile (instead of the working space)" the image opens up and every thing is correct.
But, ff I open it with "Convert document's colors the working space" the image opens up and C, M, Y are the same - but the K channel appears to have been reseparated since it now has C, M, Y tones and the K has changed.
I thought that CMYK values weren't supposed to change (and they didn't for CMY) so, what's going on?
2. What would cause only the 100% K patch in this graphic to change to 4/C in a Rampage workflow?
thx, gordo
PS This question is also posted in the Color Management area.
If I remember right, there were always conversion problems between different softwares, supposedly with CS4 & later versions of Quark, they all comply with Pantone, which is what Rampage does.
It all depends on what you working space is. If it is different from the document's space, you'll get that warning and a conversion. If the working space is the same as the document, there will be no warning and no conversion.
Dan Curry
Looking for prepress work in the Baltimore area. FusionPro, Apogee, & Prinergy.
So is there something in the Rampage workflow that is turned on that should be turned off?
I.e. Since it's CMYK going in I don't want the file altered. I want the same tint values of the original preserved.
I've never used Rampage, but I would guess that yes there is a setting that needs to be changed. How are you feeding Rampage - printing directly to it, printing to a PostScript file, or direct export of PDF from native app? There could be a conversion applied at that stage as well.
Dan Curry
Looking for prepress work in the Baltimore area. FusionPro, Apogee, & Prinergy.
What version of Rampage and what file format is being sent to the rip? I know you said the image was cmyk but did you send an eps or pdf to the rip? I know that if you send a pdf that contains an unmanaged rgb image to the rip, pre Version 12, the rgb to cmyk look up table is horrendous. Eps files don't have this problem.
What version of Rampage and what file format is being sent to the rip? I know you said the image was cmyk but did you send an eps or pdf to the rip? I know that if you send a pdf that contains an unmanaged rgb image to the rip, pre Version 12, the rgb to cmyk look up table is horrendous. Eps files don't have this problem.
Erik
AFAIK it's an Illustrator CMYK .eps file sent to the printshop. Don't know what they do at their end.
1. If you are converting from the documents embedded profile into the application working space, then the pixel values will change. Photoshop color settings’ rendering intent will also play a role in how the pixels change. If the source and destination profiles are somewhat similar such as old Swop and new Swop then the CMY channels will only change slightly in terms of dot area and cross-channel contamination. The black channel will change drastically per black generation settings in the destination profile.
2. A CMYK file will pass through without conversion in Rampage ROOM workflow unless you are using the PDF trap engine color manager YouTube - Rampage PDF Color Manager.f4v. I cannot imagine why only the 100K would convert unless black purity is set to preserve and the 100K patch actually has come slight contamination such as 1% cyan in it. Also if the 100K is a spot black instead of a process black then the alternate cmyk (or rgb) values could be passing into the RIP if the spot color is not defined in the spot color libraries.
"In my Illustrator Preferences, all blacks are to display and output as rich blacks. It didn't occur to me to change that setting. And the printer's prepress didn't override the spec.
I didn't place the chart into any Quark or InDesign document; I sent the original .ai file."
LinkBack URL
About LinkBacks
Why do CMYK process builds get changed?
Reply With Quote
Originally Posted by buckeye
