Hi, we are trying to get our entire workflow more streamlined in regards to color management, but are not quite there yet. So I have a couple questions to help make sure I'm going about it correctly and efficiently.

In the past, we almost always created documents in InDesign using the default workspace - US Web Coated SWOP v2. And images were usually converted to this as well.

We have begun to try to keep images as RGB now while editing/retouching, then converting a flattened version, after packaging, to the printer's supplied ICC profile. But still trying to figure out how best to deal with the InDesign file (which of course has the images placed in it). We send everything as InDesign files w/ fonts & links.

- So InDesign files have always just used the default working space. Should I convert to the printer's ICC profile before sending out for proofing?

- With the colors we've picked on this particular job, we've tried to limit it to 2 or 3 channels only (C+M, C+Y, C+M+K, etc.). When converting, these values get changed obviously, and usually add a touch of other channel colors. Would I have to then edit those colors again to make them more 'pure'?

- Would it be better to change the default InDesign working space to the end printer's ICC profile when first starting the project? What if we don't know who it will be going to until later on?

- Is there a way to convert the placed images as well upon packaging the job, or will we always have to go into Photoshop and do this manually on each image? Efficient workflow here?

Any other tips or resources would be GREATLY appreciated. I'm starting to understand the CM process on images in Photoshop, but these usually come to me with some sort of profile. So I'm just converting. Just trying to understand the difference when generating colors and objects from scratch, not 'converting', as you usually do in InDesign.

We have begun to try to keep images as RGB now while editing/retouching, then converting a flattened version, after packaging, to the printer's supplied ICC profile. But still trying to figure out how best to deal with the InDesign file (which of course has the images placed in it). We send everything as InDesign files w/ fonts & links.

Leave the images as RGB with open layers. Place the layered PSD files in InDesign. Use View: Proof Setup to "CMYK soft proof" the RGB in both Photoshop and InDesign (use the printer's CMYK ICC profile). For images already converted to CMYK you can soft proof in the printers CMYK as well, again using View: Proof Setup, the printer ICC profile, and enabling "Preserve Numbers" (be aware of total ink limit however)

Leaving your Photoshop images as source RGB has tremendous advantages. No more going through the conversions in Photoshop and doubling your image files. Also you are free to repurpose the source RGB to whatever destination color you want. For example, you could use InDesign to convert to newsprint CMYK, a sheet fed coated CMYK, a SWOP profile for coated Web publications, or even sRGB for web output. The choice is yours. The one thing to remember - always use View: Proof Setup to see the images in the destination color space. If color adjustments are needed, use non-destructive adjustment layers in Photoshop. These layers can be turned on and off as needed in InDesign (if you place PSD), depending on the needs of the current project.

jethrodesign wrote:

- With the colors we've picked on this particular job, we've tried to limit it to 2 or 3 channels only (C+M, C+Y, C+M+K, etc.). When converting, these values get changed obviously, and usually add a touch of other channel colors. Would I have to then edit those colors again to make them more 'pure'?

In InDesign if you are creating CMYK swatches for a CMYK job, I recommend first assigning the printer's CMYK ICC profile to the InDesign document. Try using the Pantone Process library (avoid the Solids). Any swatches you add will be soft proofed in the printer's CMYK color space. Remember the accuracy of the soft proof depends on two things. One, your monitor must be properly calibrated and profiled. Two, the CMYK profile must be an accurate representation of the print condition.

jethrodesign wrote:

- Would it be better to change the default InDesign working space to the end printer's ICC profile when first starting the project? What if we don't know who it will be going to until later on?

That is one of the pitfalls of print design. If you design thinking it's coated, and then the situation changes down the road and it's going to be uncoated, it's tough. When that happens, in InDesign assign the new CMYK. Then you can soft proof placed RGB in the new CMYK (just turn on Separations Preview). As far as swatches, stick with the Pantone Process. If the colors change too much for your liking, try picking new swatches. Avoid CMYK - CMYK conversions in InDesign, they can be problematic. If you have CMYK Photoshop images, you may need to convert them to the new CMYK in Photoshop, especially if TIL (total ink limit) is an issue (ask your printer). To see total ink limit, create a blank CMYK in Photoshop. Assign the profile. Hit "D". Click on the black foreground color, and add up the CMYK values. For example US Web Coated – 75C, 68M, 67Y, 90K = 300.

The cool thing about RGB images, you avoid that issue completely.

jethrodesign wrote:

- Is there a way to convert the placed images as well upon packaging the job, or will we always have to go into Photoshop and do this manually on each image? Efficient workflow here?

Absolutely not. InDesign will convert to the CMYK, even if you have placed 16 bit layered RGB PSD, InDesign merges the layers on PDF export and converts the merged result to 8 bit CMYK.

Talk with your printer. The decision to supply packaged native files or PDF should be up to you. Most people supply PDFs, but if the need for edits after proofing comes up more than likely the printer will request a new PDF.

If the printer demands CMYK and native files, find another printer.

It comes down to three options:

1. You supply native including RGB, and the printer subscribes to late binding (he converts to CMYK)

2. You supply PDF including calibrated RGB with a CMYK Output Intent, and the printer subscribes to late binding (he converts to CMYK)

This is a deep and complex subject, let me know if you have any questions. One other note: in Photoshop, make sure the RGB and CMYK policies are "Preserve Embedded Profiles." In InDesign and Illustrator, RGB "Preserve Embedded" and CMYK "Preserve Numbers". These are default policies. Use Bridge to synchronize your color settings if you have Bridge, this should give you consistent color across the board.

If you are a Photographer and you convert from RAW, and aren't sure what RGB color space works well for print design, I recommend using Adobe RGB. Try 16 bit if your computer can handle it, and aim for an effective PPI in InDesign (found in the links panel) to be in a resolution window of around 300 - 450 PPI. A good workflow is 300 or 400 PPI in Photoshop, and all images placed at 100% in InDesign (no scaling).

Wow, thanks for the VERY clear and thorough response! This helps a lot.

I think in a nutshell, it looks like a lot of the issues can be handled if final delivery will be a PDF, not native InD files. I'll have to contact the printer and see what they prefer. We don't have the option of choosing printer's for our jobs, clients do. So PDF may not be an option we can choose, we'll have to see on a case-by-case basis. But we definitely send native files more often than PDF.

So just a couple more questions, if that's OK...

In InDesign if you are creating CMYK swatches for a CMYK job, I recommend first assigning the printer's CMYK ICC profile to the InDesign document.

Hmmm, yes that would probably be the best way to go. In this case, however, the document was already almost finished before we got the profile from the printer. So I would assume I need to 'convert' to the printer's profile now, not 'assign' it, correct?!?

Avoid CMYK - CMYK conversions in InDesign, they can be problematic.

So not sure what to do in these cases, then. The document is setup in US Web Coated SWOP v2, but not being output to that. Is it safer to leave in this profile and hope the differences with the print profile are minimal, or convert to the printer's profile and possibly adjust any color numbers that look problematic (such as the adding of less than 1% of a certain color channel)?

Remember the accuracy of the soft proof depends on two things. One, your monitor must be properly calibrated and profiled. Two, the CMYK profile must be an accurate representation of the print condition.

Well, we keep our monitors (Apple Cinema Displays) calibrated to: 5000ºK, 2.0G, and 95cd/m2. This has seemed to be OK for most proofs we compare to. And with this current job, we haven't used this printer before, so not sure about accuracy of their profile.

OK, let me make sure I'm doing this right. We would probably choose option '3', as we want to make sure everything is correct before it gets to the printer.

So in the 'Output' section of the PDF export dialog, we would choose: 'Convert to destination (preserve numbers); Document CMYK'. I'm assuming we would have had to have the document profile set to our printer's profile from the beginning for this to be correct, right?

If it's a situation like we have now, where the document 'working' profile is not the intended end profile (usually US Web Coated SWOP), would we instead choose: 'Convert to Destination; Our printer's ICC profile'? Then for the PDF/X 'Output Intent Profile Name' - also choose the printer's ICC profile?

---------------------

I think I understand the image conversion issues fairly well, but just need more clarity on the 'native created colors' items - things created natively in InDesign. These are the things that it says will not be converted, for instance, if you choose 'preserve numbers'. We want our native colors to be on just as much as the placed images.

Thanks again for any help! I think we deal with 2 different kinds of printers: A) Those who are used to designers not having a clue, so they don't want to give them profiles or anything and let them 'mess it all up'; or B) Those who themselves don't have a clue, so we have to try to take matters into our own hands so that the results can be better and closer to our intent. But I think it's still a complex issue that hasn't taken hold industry-wide yet at all (I'm amazed how many printers don't have profiles, or don't even know why they should).

Hmmm, yes that would probably be the best way to go. In this case, however, the document was already almost finished before we got the profile from the printer. So I would assume I need to 'convert' to the printer's profile now, not 'assign' it, correct?!?

This depends a great deal on in what capacity you are involved with the project. If you are the designer then I recommend assigning. If the color shifts are not too your liking then replace your current Pantone Process swatches with different ones.

Side note: do not use Pantone Solids for CMYK process jobs. Use Pantone Process (the ones that start with DS). Don't use Bridge or Solid to Process or any of that nonsense.

Pantone Solid colors are for spot colors. Period.

Back to assign vs. convert. If you are not in a design capacity, you have to find out what your client wants. Preservation of CMYK numbers or preservation of color appearance on-screen. If you convert to profile in InDesign, the application will attempt to preserve color appearance as it maps to the new CMYK. But your Pantone Process book values go out the window. What's worse, the swatch looks like it holds the library book definition. A lot of confusion.

You also stand to see black become rich black. If the objects are colored [Black] in InDesign they will not be affected. But CMYK black only will be affected.

Another problem with CMYK - CMYK in InDesign. Placed CMYK images will not be affected (default behavior). The behavior can be changed in color settings, but it must be done at the document creation stage, otherwise you have to manually tag images throughout the document. And you must disable "Preserve Numbers" at output.

Illy CMYK is even more problematic. Again the only way to make it undergo a CMYK - CMYK conversion is to disable "Preserve Numbers" when you output the PDF. And you will very likely see impure black and impure gray when you do this.

My perspective for a good workflow. You get a Pantone Process swatch book, pick the colors. They have coated and uncoated. It is true they are not exact, because there are so many different print conditions. But it gets you in the ball park. Then you can soft proof the swatches in various print color spaces depending on what profile is assigned in InDesign.

Images are a different story. Many times a CMYK - CMYK conversion may be very necessary. For example if you have a US Sheetfed Coated with 350% TIL, but you need 260% TIL for uncoated, you need to do a CMYK - CMYK conversion. That's why it's a lot easier if images are RGB.

If CMYK - CMYK conversion is an absolute must, I recommend changing all ID swatches to CMYK mode, and name with color value. Then you essentially have custom CMYK picked colors that have no book relation. Then do the document "Convert to Profile". Make sure any placed CMYK Photoshop is tagged with the embedded profile (it must not say Document CMYK in links). Then when you output PDF choose "Document CMYK" and disable Preserve Numbers. Check the PDF for impure black and impure gray using Acrobat.

OK, thanks again! I'm in the middle of sending two jobs to two different printers as we speak, so this is all very timely. And by the way, we are the designers. And we do almost everything as process these days, only an occasional spot-color job sneaks in, but not often. We used to use Pantone Process books, but found they are too limiting in choices, and as you noted, they are just one of many different printing processes, so it's not a true indication in all cases anyway. All colors in InDesign documents are setup as CMYK values.

So Printer #1 when asked for profiles said "Why do they need them? We'll convert their RGB images." So for the sake of time, this is what I've done this round for the first time (as this is one of the most highly regarded printers in Los Angeles). Maybe when the job goes on press, I can go down there and talk to the prepress guy directly and better explain our situation. But the InDesign file was already setup as US Web Coated SWOP, so we'll see how they convert this. This puts the responsibility on them to match colors.

But for Printer #2, this is the first job we've run with them, and we want to do it right from the beginning. So after seeing that the PDF that was converted to the printer's profile on export had converted all black to rich black, INCLUDING ALL TYPE, I know this is not an option.

So I 'assigned' the printer's profile to the document, then went in and manually changed all swatches to better match the original colors (they had become darker, but fortunately, there were only 5 or 6 colors). In checking the image profiles, however, the CMYK images now say they are using the printer's (document) profile. Did it assign it to them, or convert them?

And this printer was OK receiving PDFs, so I'll export using 'Convert to Destination (Preserve Numbers) and Document CMYK - which is now the correct profile.

--------

So I guess my biggest concern is still how best to setup our InDesign documents when we don't know who the end printer will be. Unfortunately for us, this is a lot of the time. So I need to figure out the best and safest workflow for these situations.

This depends a great deal on in what capacity you are involved with the project. If you are the designer then I recommend assigning. If the color shifts are not too your liking then replace your current Pantone Process swatches with different ones.

To expand on this there is a Photoshop trick you may want to know. It takes some of the subjectivity out of remapping book colors.

Say you have a Pantone Process coated swatch in a US Sheetfed Coated document. The swatch is DS 178 1-C (purple).

Now you find it it needs to o to Japan newspaper. Go to Photoshop, make a blank US Sheetfed. Go to color picker, choose Color Library and go to the swatch. Then flip back to the picker. Go to the L value and retype the number you see, hit enter.

Assign Japan newspaper. Back to the picker. Go to color library, select Pantone Process Uncoated. Photoshop tells you the new swatch to use.

With my color settings it's DS 171-U. You may not get the exact same result depending on your color settings. But it's a good method of remapping a book swatch from one CMYK space to another. If you do this, then it's a matter of assigning a different CMYK in InDesign, and replacing the current swatch with the new one Photoshop gives you.

OK, thanks again! I'm in the middle of sending two jobs to two different printers as we speak, so this is all very timely. And by the way, we are the designers. And we do almost everything as process these days, only an occasional spot-color job sneaks in, but not often. We used to use Pantone Process books, but found they are too limiting in choices, and as you noted, they are just one of many different printing processes, so it's not a true indication in all cases anyway

I have to question about the limiting part. I would agree that Solid to Process or Bridge, libraries that try to map Solids to CMYK are limiting and also very confusing (invariably someone always looks at the solid swatch instead of the process equivalent). But the Pantone Process libraries have thousands and thousands of colors to choose from, just about the whole CMYK spectrum. And you also don't have to worry about ending up with 1 or 2 percent of an ink, the values are very straightforward. And even the very darkest of these swatches do not put excess ink on the sheet (often an important consideration).

You don't even have to reference swatch books if you don't want, the library is in the software. The color will soft proof in the CMYK space of the document.

The Pantone Process libraries do not contain a rich black swatch. People have different preferences for that, I like 40C 30M 30Y 100K. It works well as a vector swatch. The biggest consideration is making sure vector black solids match image black solids if the two print side by side.

jethrodesign wrote:

So I guess my biggest concern is still how best to setup our InDesign documents when we don't know who the end printer will be. Unfortunately for us, this is a lot of the time. So I need to figure out the best and safest workflow for these situations.

If you don't know who the end printer will be, you should at least know the stock. And the quantity should tell you if it will be web or sheetfed (more than likely)

On the IDEAlliance website there are three really good default CMYKs to use. I will try to find the link to the webpage. One is a GRACOL for Sheetfed Coated, the others are SWOP profiles for web publications, also coated.

Uncoated gets a little trickier. If it's a normal uncoated sheet you are probably OK using US Web Uncoated or US Sheetfed uncoated, I believe both have a TIL of 260%. Newsprint is a different story. Do you do any newsprint work?

So I 'assigned' the printer's profile to the document, then went in and manually changed all swatches to better match the original colors (they had become darker, but fortunately, there were only 5 or 6 colors). In checking the image profiles, however, the CMYK images now say they are using the printer's (document) profile. Did it assign it to them, or convert them?

It assigned the new CMYK. The only way to convert those in InDesign is to disable Preserve Numbers. You also have to go to Object: Image Color Settings and set the embedded profile.

It may be easier to batch convert in Photoshop if you really need to do it. But after you assign in InDesign, it displays the image CMYK number data in the new CMYK space. How do the images look? If they look good, I would leave them be, unless you have a total ink limit consideration. If the job is coated and the images are US Web Coated I'm sure TIL is fine.

OK, thanks again for all the help. I am getting closer to figuring out a better workflow.

But I've been working for the last hour on a random bizarre bug that I've never encountered before. I'll try to explain best I can:

Upon using 'Convert to Destination (Preserver Numbers or Not)' in the PDF export dialog, using the 'Document CMYK' profile, there is a shift in color for 1 particular element. We have a grayscale image of a bunch of dots that is placed in a frame in InDesign. This image is 'colorized' in InDesign by setting an image color and a frame color (the image color appears as the 'foreground' and the frame color is the 'background'). We've been doing this all the way back to the Quark days (many years). But if the 'background/frame' color is a combination of C+M+Y (with no black), the Magenta and Yellow values are shifted to the Yellow and Black channels (for example - 52c, 5m, 10y, 0k becomes 52c, 0m, 5y, 10k).

I have never run into this before, and we've run this job with the same element many times now over the last couple years. But I have always used 'No Color Conversion' in my PDFs in the past. So it has something to do with the 'conversion'.

So far I've tried:

- Creating new document with just single element, also created from scratch.

- Starting with different profiles (to make sure the profile wasn't corrupt).

- Choosing 'Preserve Numbers' or not when outputting PDF.

- All sorts of color combinations. It also appears that if there is black in the color, this value gets shifted to the magenta channel, then the magenta & yellow bump down.

- Checked the grayscale image to make sure it was flat, and using pure black & white colors. It is.

This one has me completely stumped. Not even sure where to look for help. The file really needs to go out, but even if I change the color slightly to make this not happen, I am now very concerned that there might be a bug in the whole 'Convert to Destination' setting when exporting PDFs from ID CS3. Maybe it takes a very unique set of circumstances to make it apparent, but I'm concerned if I don't notice it and it gets through.

Any ideas or places to look for help on this? I'd really like to try the whole 'convert everything upon exporting PDF' method, so I don't have to collect all the images, batch convert them and relink, every time it needs to go out to a printer.

Oh, this is killing me. This job needs to go out, and I've been spending hours trying to figure out how to make a proper PDF, with all colors being converted to the printer's CMYK profile.

So thinking that it's possibly a bug in the 'Export to PDF' functionality in CS3, I've been trying to get it to work with printing to Distiller (we have Acrobat 8 Pro). But the settings here are different than in the export dialog from InDesign, so I'm not totally sure how to set it up to produce similar results.

This is how I assumed it 'should' work:

- Document is using printer's profile, colors have been adjusted as necessary.

- All photos are using their embedded profiles - some RGB, some SWOP CMYK, one CMYK without embedded profile.

- In print dialog, Color Management tab, 'Color Handling' is set to: 'Postscript Printer Determines Color' so that Distiller will make conversions, not InDesign, correct?

- And the 'Preserve CMYK Colors' checkbox is UNCHECKED. I'm assuming this would normally force all colors to convert, although in this case since the document color space is already the output color space (printer's profile) no conversion should happen anyway, correct?

- And I made a copy of the default PDFX3 2002 profile in Distiller with these changes:

OK, sorry. A couple more details on the PDF bug that is holding everything up for me right now.

When looking at a Preflight result of my PDF in Acrobat Pro, I notice one main difference between the elements that look proper, and those that have the color shift (there are multiple instances of this element using different colors - only certain color combos cause the color shift).

Comparing a 'properly rendered' element, and one that is shifting the channels, the difference is in the Base and Alternate color spaces:

- The properly rendering element has a 'Base Color Space' called "DeviceN color space: "Cyan" "Black" "Yellow". (and yes, these are the only channels it is using). It has an Alternate Color Space with our printer's profile named. Then it has one more Alternate Color Space under this called:' DeviceCMYK color space'.

- The incorrectly rendering element has a 'Base Color Space with our printer's profile named. Then there is an Alternate Color Space called: 'DeviceCMYK color space'.

It appears that when the background (frame) of a colorized grayscale image in InDesign contains at least 3 channels of color information, and the foreground (image) has at least 2 channels, the color values switch around to different channels. I tried it on another element that wasn't having the problem and sure enough, when I added some color to a 3rd channel, the colors got ALL CRAZY! And they always use the 'Document Color Space' that is specified in the Export to PDF dialog.

- Does this help anyone debug this issue???

- Any ideas of workarounds???

I can post a bug report to Adobe, but it's kind of a difficult to explain, and they won't help me get this working for the jobs I have to get out now anyways.

Read through again, your issue appears somewhat complex. If possible post a file or a PDF. Note the following:

1. What version of Acrobat? Is it 8?

2. InDesign has no grayscale color management. When you output and convert to destination CMYK, preserve numbers or no, any grayscale image moves to Device N.

3. Avoid the post script distiller workflow. We can figure out an export solution.

4. Use Separation Preview in InDesign. What are the color readouts of the colorized grayscale when you do that?

5. Make absolutely certain you are outputting Doc CMYK. In Acrobat check the output intent. Does it match the doc CMYK? Note if you output Doc CMYK preserve numbers makes no difference in regards to the colorized grayscale.

6. Create brand new CMYK swatches in ID with the proper values and re-color the image and container

7. This grayscale - does it have screens of black? In the screened areas the two swatches will merge. So if the image was 70% you would have 70% of the image color and 30% of the container color.

8. Make absolutely certain that the picture object in InDesign has no applied effects (blend modes, opacities etc)

9. If all else fails you can apply the colorization in Photoshop and save as CMYK image (but that is a last resort you shouldn't have to do that)

To summarize a little more on the color spaces you are seeing in Acrobat preflight:

Anything called "Device" is uncalibrated (has no profile tag). If, from InDesign, you output "Convert to Destination" cmyk, everything in the PDF will be Device, and there will be no RGB or Grayscale. There will just be Device CMYK or Device N. To another user all content is assumed to be in the color space of the Output Intent. So even though none of the PDF content is calibrated, the entire PDF document is tagged so to speak.

If you have placed CMYK Photoshop images with profiles that differ from the ID document CMYK, ID will still see these images as Doc CMYK. Check the links panel you will see that the image ICC says "Doc CMYK". So preserve numbers or no, these images' numbers will be preserved. The only way to change this behavior is to tag the CMYK images in InDesign with Object: Image Color Settings. Hardly anyone ever does this.

With placed CMYK the print industry standard is to preserve CMYK numbers and that is why the Adobe defaults are what they are.

The above information is not directly related to your grayscale image issue. Just know that the grayscale problem you have encountered has a logical explanation of some sort. There is no ghost in the machine. It could be that the file is OK and you are getting buggy readings in Acrobat. Whatever it is we'll figure it out.

OK. I'm back on it. Worked til 10pm last night trying to figure it out, finally had to give up and go home.

I'll read more carefully through all the replies when I get a chance, but I believe I have discovered a most random and bizarre bug in the Export to PDF function from InDesign.

SO THIE ANSWER...

It appears to have something to do with the image being resampled when making the PDF. The type of compression doesn't seem to affect it (I tried JPEG or NONE).

- When the image must be resampled (because the effective resolution is higher than what you specify in the dialog, in my case 450dpi), the colors shift around and the image is set as the document profile (subject to the 'convert' I would imagine).

- But when the image does not have to be resampled (because it's effective resolution is lower than the threshold set), the image displays properly and uses the DeviceN profile. * Now it's interesting to note that in the Acrobat Preflight, the colors listed for the image (and the 'DeviceN color space') are ordered "Cyan Black Magenta Yellow", instead of the typical CMYK. This is also the type of reodering that is happening with the images that don't display properly (the M & Y channels shift to the Y & K channels).

So there you have it. WAY too many hours of trial & error to come up with something that Adobe should figure out (I'm wondering if it's still there in InDesign CS4?).

So I need to get this job out ASAP, then I'll check back in on figuring out the whole workflow issue (my original question).

** I've attached a sample PDFs showing the issue for your amusement. The image doesn't fill the frame, so you can see where the color shifts...

I looked at your files, and sure enough didn't get the problem. At least NOT UNTIL I converted your InDesign file to certain other profiles (which I had done in my document). So I thought I had a bad profile from this printer, but I tried a bunch of different profiles, and most of them caused the issue. US Web Coated SWOP or US Sheetfed Uncoated, for instance, do NOT cause the problem. But my custom profiles (I tried a few I've received from different printers), as well as the default FOGRA27, DID cause the problem.

- Change the swatch colors numbers back to what they were so that they're using the same channels, etc. (52, 3, 14, 0 for bkgnd, 70, 0, 0, 16 for fgnd).

- Check the effective resolution of the image. It needs to be MORE than the threshold set to resample in Export to PDF dialog. For instance, your image is currently 450dpi, but the default for PDF/X-4 is to downsample images GREATER than 450, so this won't downsample. Make it 451dpi or greater, or change the threshold in PDF dialog.

- Set output to Convert to Destination, and specify the document profile.

Let me know if you see it. I know I'm probably the only person in existence to ever use this combination of factors, and produce this error, but it still caused a huge headache, and also caused a lot of trust issues in moving to a more PDF workflow, converting to profiles at the very end like this. It has to be 100% reliable, or we'll probably just stick with sending native files and converting images in Photoshop. But I can see how the PDF workflow 'could' simplify things for us, IF it doesn't cause other issues (like this).

Thanks again for all your help. If you help figure this issue out, I'll make a recommendation that your name come up in the InDesign credits when you launch the program!!!

UNFORTUNATELY, after 'fixing' the problem by decreasing the size of the image to less than 450dpi effective resolution (which completely 'fixes' the problem on screen and when checking numbers in Acrobat), we just go the proofs back from the printer and the problem is not only there, it's WORSE.

The file was run through a Prinergy RIP to an Epson 9800 printer for our proof. But now, not only the elements with 3+ channels of color in the background are causing the problem, ALL of the color combinations are now causing the problem! So the elements that weren't causing issues before are now showing the same problems. But this time, the backgrounds behind the dots are actually lighter in color, instead of darker as they were in the PDFs I was dealing with earlier.

So apparently I've found a random bug in Export to PDF that possibly not too many people run across, but is enough to make us not feel comfortable using this method (as it already cost us one round of proofing). So I'll be doing it the old-fashioned way and uploading the native InDesign files and links (converted to their profile in Photoshop) like we usually have done in the past.

- Can you verify that this issue does NOT appear to happen in InDesign CS4? We don't have a copy to test, but may need to upgrade in the future anyway.

- Know of whom at Adobe I could bring this issue up with? I know we're way outside of any technical support window (if they even offer that anymore). I would need someone pretty saavy with printing/color management.

- I had at one point selected the image and made it 99% opacity to try to introduce transparency, but this didn't help.

If your PDF was correct then that is definitely printer error (although certainly still an unexpected, unexplained problem for them)

Possibly they could convert the PDF using Acrobat to the Output Intent. No color numbers change, but Device N becomes Device CMYK. Unfortunately this is not possible directly from InDesign, the conversion has to be done in Acrobat. Not sure if that would solve the printer's RIP issue or not.

I have not been able to replicate the issue in CS4 but will test further.

There is a viable CS3 solution, very simple, requiring no Photoshop intervention. See attached. In Swatch panel define either the foreground or background swatch as spot. In Ink Manager make the spot process. The output will be correct.

- I had at one point selected the image and made it 99% opacity to try to introduce transparency, but this didn't help.

That would work but you have to output PDF/X-1a flattening transparency

As far as contacting Adobe, if the problem does not occur in CS4 they won't bother with it. I may post about this in the InDesign forum. I think it definitely qualifies as a bug. It seems to be triggered somehow by converting to profile.

I noticed something odd when I recreated the problem. The doc was FOGRA27. I output doc cmyk and it was OK. Then I converted to the other profile and restored swatch values. When I re-output the profile was still at FOGRA27 and I had to switch to Doc CMYK. That's not normal behavior, it's like InDesign is getting confused.

OK, thanks for all the investigation you've done on this! It's been most helpful.

I spoke with the printer today, and he looked at the PDF that is generated by the Prinergy system (directly from the PDF I sent), and he did see the issue that we saw on the proof. So with all of the conversions and stripping of profiles that RIPs may do to a file, I just think the PDF is not going to be safe enough for us to use. I'm having him output our InDesign file now with all images converted to their profile in Photoshop. We'll see how this compares to the PDF-generated proof.

I did look at your solution of specifying spot colors & using ink manager, but even with this, the end images are still using different profiles (even though they look OK on screen). The images that would generally cause the 'problem' are using the CMYK/printer's profile as the color space, but images that weren't initially causing issues on screen (using less color channels) are using DeviceN color space. So I think this just presents extra issues that the RIP needs to figure out, and in our case didn't figure them out correctly.

So I think until we get ID CS4 (assuming that this does actually fix the problem), we'll stick with sending InDesign files or choosing 'No Color Conversion' on PDFs.

------------------------------

But now back to the actual topic...

If you don't know who the end printer will be, you should at least know the stock. And the quantity should tell you if it will be web or sheetfed (more than likely)

On the IDEAlliance website there are three really good default CMYKs to use. I will try to find the link to the webpage. One is a GRACOL for Sheetfed Coated, the others are SWOP profiles for web publications, also coated.

Uncoated gets a little trickier. If it's a normal uncoated sheet you are probably OK using US Web Uncoated or US Sheetfed uncoated, I believe both have a TIL of 260%. Newsprint is a different story. Do you do any newsprint work?

So I think what you are suggesting is that if we don't have an end printer's profile when starting a job is:

A) Try to assign a profile that is at least closer to the end intent than the ancient default US Web Coated SWOP v.2

or B) If it's not too much hassle, do what we did this time and 'assign' the printer's profile when we get it, then re-adjust any colors to get back to where they were intended (if they actually shift much anyway).

I think I may already have a GRACOL and newer SWOP profiles that we can use. I'm sure these would be better than the default US Web Coated SWOP (although most printers are used to dealing with this anyway).

Most of the jobs we run these days are sheetfed, uncoated, and with U/V.

I did look at your solution of specifying spot colors & using ink manager, but even with this, the end images are still using different profiles (even though they look OK on screen). The images that would generally cause the 'problem' are using the CMYK/printer's profile as the color space, but images that weren't initially causing issues on screen (using less color channels) are using DeviceN color space. So I think this just presents extra issues that the RIP needs to figure out, and in our case didn't figure them out correctly.

To clarify none of the content of the PDF has ICC profiles, everything is Device with the output intent. It is completely normal to have Device N and Device CMYK together in the same output.

Device N usually does not cause a problem, printers process and RIP this color space all the time. This particular bug is somewhat unusual. Hopefully it will not be a common occurrence, but I'm glad you pointed it out.

jethrodesign wrote:

So I think what you are suggesting is that if we don't have an end printer's profile when starting a job is:

A) Try to assign a profile that is at least closer to the end intent than the ancient default US Web Coated SWOP v.2

or B) If it's not too much hassle, do what we did this time and 'assign' the printer's profile when we get it, then re-adjust any colors to get back to where they were intended (if they actually shift much anyway).

I think I may already have a GRACOL and newer SWOP profiles that we can use. I'm sure these would be better than the default US Web Coated SWOP (although most printers are used to dealing with this anyway).

Most of the jobs we run these days are sheetfed, uncoated, and with U/V.

Assign vs. convert is up to you. You may find converting in InDesign is an effective workflow to get the most accurate color. Most users probably do not convert to profile in InDesign because the swatches end up having crazy decimal values, and also the gray component tends to get introduced. And as you mentioned you can get 1 or 2 percent of a colorant which is a little odd.

US Web Coated SWOP is not a really bad profile or anything, but it describes a web print condition, and also predates the IdeAlliance SWOP.

Both GRACoL and SWOP are based on particular solid ink Lab values on certain sheets. C,M,Y, CM, MY, CY, CMY, and K. The paper has to also be a certain Lab value and type.

The new G7 standard can be incorporated with both GRACoL and SWOP. This deals with Lab values of tints. For example 25 K, 50 K and 75 K should print at specific Lab values relative to the paper white and the black solid. CMY grays must also print at specific Lab values, this helps to achieve gray balance. CMY gray examples are 25C 19M 19Y, 50C 40M 40Y, and 75C 66M 66Y. These normally should be a close visual match to the black tints.

GRACoL is geared toward sheetfed on a #1 coated sheet. SWOP is Web. The two SWOP profiles are for #3 and #5 sheets (coated)

As far as uncoated G7 can be implemented, but you can't have a certified uncoated sheet. The reason is you can't attain the same solid ink densities on uncoated. They are lighter. However you can still measure tint densities and gray balance relative to the solid densities and the paper white.

It is all structured on Lab now, unlike in the old days when it was all based on ink densities and dot gain. However pressman do not usually measure Lab. So when G7 is implemented, Lab is translated to ink density measurements. The gray balance is addressed with plate calibration.

The main problem with the old density based standards is the color part, which they tried to address with dot gain for each ink. But dot readings are based on density, with an equation used to convert the measurements (Murray Davies, Yule Niesen). It gets very confusing, so the standards moved to Lab, a universal device independent color space.

Typically to monitor production sheets, the printer measures the solid ink densities on sheets, and also read plates to make sure they are consistent. On a critical sheet they can measure the densities of the tints, and even the Lab values of the CMY tints to check gray balance.

If you are doing uncoated work, you will probably need to get the printer's profile if you need really accurate color on a particular sheet. The main difference is the gamut is smaller, the solids are lighter, the press gain is different, and the TIL in the CMYK profile is lower than for a coated sheet.

To clarify none of the content of the PDF has ICC profiles, everything is Device with the output intent. It is completely normal to have Device N and Device CMYK together in the same output.

OK, sorry. I was looking at the images in Acrobat's preflight. The images are listed with a base color space of either "ICC based color space: ACE_0308_80_VEL_AM.icc" (our printer's profile), or "DeviceN color space: "Cyan" "Yellow" "Black".

And even under the 'Color Spaces' drop-down, there are listings for: 'DeviceCMYK color space'; 'DeviceGray color space'; 'DeviceN color space'; as well as 'ICC based color space: ACE_0308_80_VEL_AM.icc'.

So I assumed it meant these profiles were what was 'attached' to each of these images somehow. I guess I'm not reading the preflight info correctly (or understanding correctly)?!?

-----------------------

Unfortunately, though, we just got the second proof back from the printer. This one was output from our InDesign file directly, not from PDF. And all images had been converted in Photoshop to their profile (using Relative Colorimetric, not sure what process Export to PDF uses). And while we definitely don't have the problem with the color shift behind the dots, the overall color is not quite as accurate as it was with the PDF : (

I didn't expect any difference at all in color, but the second proof is definitely a bit lighter in magenta, both in images and solid tones. It's slight (maybe 3-5%) but still noticeable, especially in certain skin tones.

So we're a bit stuck now. I think we're going to run a quick small test from a PDF exported from InDesign CS4 and see how this does, but if that doesn't work I guess we'll just have to push magenta on press or alter images (do not want to do this).

Thanks again for all of the helpful explanations! Do you get paid from Adobe or any industry color management consortiums?!?!? You should ; )

So I assumed it meant these profiles were what was 'attached' to each of these images somehow. I guess I'm not reading the preflight info correctly (or understanding correctly)?!?

An easy way to check for ICC in Acrobat is to go to "Calibrated" in output preview. The opposite of calibrated is Device. If you output "Convert to Destination" (preserve numbers or no) from InDesign, it's all Device in Acrobat

However if you output "No Color Conversion", any RGB will be calibrated in the PDF. It has to have the source ICC, so when it does get converted to the Output Intent it will be a proper conversion

jethrodesign wrote:

Unfortunately, though, we just got the second proof back from the printer. This one was output from our InDesign file directly, not from PDF. And all images had been converted in Photoshop to their profile (using Relative Colorimetric, not sure what process Export to PDF uses). And while we definitely don't have the problem with the color shift behind the dots, the overall color is not quite as accurate as it was with the PDF : (

A few questions:

1. For the first proof, did you convert RGB to printer CMYK using InDesign?

2. For the 2nd proof, did you convert RGB to printer CMYK using Photoshop?

3. Did the images undergo CMYK - CMYK conversions on either the first or second proof?

I'm not sure what happened. For the two proofs to look different, there had to have been a difference in how the color was converted.

I know this is a bit late and it might be of no real help at this stage of the situation of the O.P. but I would like to suggest reading the PDF/X FAQ, by Martin Bailey, so as to clearify some basic issues about the PDF/X set of standards (transparency, use of output intent, resolution, best flavour for each use, etc.)

THANKS as always for the great responses! I will read through that PDF to get a better understanding of what's going on.

I have a couple quick questions for another proof we're about to run. I made a PDF from InDesign CS4, using the same 'Convert to Destination (Preserve Numbers)' as our first PDF. This does NOT appear to cause the color shift issue we had been having. So apparently Adobe fixed that issue, whatever it was.

So our printer also ran a 3rd proof for us over the weekend from our InDesign files where they allowed their RIP to handle the color conversions instead of InDesign (Postscript Printer Determines Color' in the print dialog). The first InDesign file they ran, where I thought the colors weren't as good, was using 'Let InDesign Determine Colors' in the print dialog. So in the latest proof, the solid colors (everything produced within InDesign) look spot-on. I can't imagine we'd get any better color match here. The photographs, however, were better than the first round, but possibly swung too far the other direction (too much magenta now instead of too little). These photographs were converted to their profile in Photoshop.

But now I'm wanting them to try one last proof from our PDF exported from InDesign CS4 (now that the color shift issue is not a problem). However, I also want the colors to be as spot-on as the last InDesign file we got.

- So in Acrobat, with my latest PDF from CS4, how should it be sent to their RIP?

- From the Advanced tab in Acrobat, for color profile, should it use 'Output Intent' (which is their profile); 'Same as Source (no color management)'; or 'Printer/Postscript Color Management'? I'm imagining to get the same results as the InDesign file, we would use 'Postscript color management'.

And you were right, at least in this lastest PDF. Everything appears to be DeviceCMYK.

THANKS!!! This is just tediously challenging to figure out completely.

The PDF is an output format. The printer should submit the PDF file to the RIP. Sending a post script file is unnecessary.

The idea is the CMYK ripped images submitted to the proofer should contain the same CMYK values that are present in the PDF. InDesign has already performed the conversion, so all values you see in Acrobat should remain intact.

I must still be a bit confused (which is why I've been posting questions ).

So if the printer does submit the PDF file directly to the RIP (and not print from Acrobat), then this must be what they did the first time (and on the little test proof we sent over Friday). But the solid tones (which have the same values in the PDF as in the native InDesign file), don't look as accurate as the latest InDesign proof. Images do look similar, though, I suppose.

- So when he printed from InDesign, using 'Postscript Printer Handles Colors', what does this do differently from sending the converted PDF straight to their RIP?

- 'Should' these files be completely identical technically?

This is the last test we'll be able to run (this is #4 when it should have only been 1). So I guess we'll just have to go for it and choose between the CS4 generated PDF or the native InDesign file using 'Postscript Printer Handles Color'.

I just so hope that I can fully understand this whole process someday...

Well, I just spoke with the pre-press guy who's running all these proofs. He told me that he does indeed send the PDF file directly to the RIP. So that was my misunderstanding.

But he did also say that the difference we got in the two InDesign proofs was NOT because of a different setting in the InDesign print dialog like I thought (setting 'Postscript Printer Handles Color'). It was instead because of a change he made directly on the RIP to have the RIP color manage the files. For the second InDesign proof, he apparently set something in the RIP to have it manage the color or convert the embedded profiles, not sure exactly what. But this is what produced the best color.

So we are now having him output one last proof from our PDF exported from CS4. With this PDF, though, he will do the same thing with the RIP to have it handle the color management or conversions. This was NOT done on the very first PDF that was output.

I wish I knew more details about exactly what he was 'changing' on the RIP itself, but I don't right now. I think we are both doing our best to understand this process as well as possible right now. And all of your help has been INVALUABLE! Our print rep was just here picking up the proofs and saw me making a post, and is convinced you must get paid by Adobe or somebody to help out so much. I do hope you are compensated in some way for sharing your knowledge. What you sow you will reap however - and that is good...

If post scripting from ID, if you select "Post Script printer" you are foregoing Adobe color management.

So any RGB in the file would be converted to CMYK by the print engine

Generally you want to use Adobe CM. So post script would be Composite CMYK. Under Color Management in the print dialog you would choose "Let InDesign Determine", the document radio button, and the printer profile would be "Document CMYK"

This would be the post script equivalent of Document CMYK (preserve numbers) in PDF export.

It sounds like Post Script Printer produced a better output for the native InDesign colors on the proof? I'm not exactly sure what happened to cause that. But the ripped page needs to match the CMYK values in the InDesign file.

The print provider may be able to open and evaluate the RIPped output to ensure the CMYK numbers aren't changing somehow. If the numbers match, then the proof (if it is calibrated) is an accurate representation of the file, and hopefully it is a close match to your soft proof.

If printer has color management incorporated into the RIP, you may be able to just output PDF/X-4 with "No Color Conversion". The CMYK Output Intent will still be included in your PDF output and the RIP converts any RGB to that.

Thanks for the kind remarks. I am not employed by Adobe. I enjoy posting and helping others, and in the process of sharing what I know I usually learn quite a bit myself.

This being a user to user forum all posts must not be accepted as cold hard facts. I try to provide good information but occasionally someone proves me wrong (I am not an expert by any means). Sometimes in the other forums the discussions border on arguments, but most of the time it is in good fun. If the forums steer a few people in the right direction that is enough reward for most of the people who post regularly.

Well, I got the 'official' workflow from the printer. This is what they say concerning their internal systems:

We profile after we calibrate our press. So we get our press up to Gracol dot gains with standard density's using software that adjust our plate curves. We created the press profile using Profile Wizard Pro (kodak software). The swatches were read with an eEyeOne device.

This is the profile that we were originally sent and that we used for the InDesign document as well as any conversions.

Our Epsons have thier own profiles from the manufacture for their paper. There is calibration software that makes sure that the Epson profiles are printing true (ProoferClient).

This would probably be the profile that the RIP converted our files to when they allowed the RIP to 'convert or color manage' the files. This was done on our second InDesign proof and final PDF proof (created from InDesign CS4). These looked pretty much identical.

We also received the 'post-RIP' files that were converted, and the color numbers definitely have been altered from what was in the file. But these are also definitely MUCH more accurate to our screen/soft-proof than when they let InDesign handle the color management (and the RIP did NOT convert the numbers). The solid colors (elements generated in InDesign) are almost spot-on, about as good of a color match as we have gotten. The photos are decent, but not quite as accurate. But they are better than the file that was color managed from InDesign.

======================

So it's still a bit hazy to me what the 'best' or 'most proper' workflow should be, from our images & InDesign files, through delivery, to proofing, and eventually to press. Seems like there are the potential for profiles and/or conversions at any place along the path:

Is there any reference that really clearly describes a 'best-case' workflow in a simple and understandable method, including specifics for incorporating the various Adobe products (Photoshop images, Illustrator EPS', InDesign master files, Acrobat PDFs), and different proofing/press stages.

It's understandable why color management is still not completely integrated into a lot of print workflows. In our experience there are relatively few true 'experts' who completely understand the best way to implement a total strategy, and can get it to work all the way to press. So people do 'half-color-managed' workflows, or miss an important step or two. In our case here, I know a 'bit', the pre-press guy I was working with knows about the same as me, maybe a bit less. So we do our best to piece as much together as possible and get the job done. A lot of times, we either adjust colors in the document to compensate for color differences, or even more commonly, adjust color on press to try to get a better final product.

THANKS A LOT! I hope through all the confusion in this thread (mostly on our end, or Adobe's), some clarity will come through that can help others in our position.

I'm not sure about the details of your printer's workflow, but I'm glad you're getting an acceptable result. I would think the Adobe color management would be accurate but it's hard to say what works best for your printer.

The Epson proofer is a wide gamut print device with 7 or 8 inks. Usually for the proof there are two profiles involved, one describing the proofer color space and the other the press color space. In a normal workflow, a RIpped CMYK image file is submitted to the proofer with values that match what you see in the original output from InDesign. This gets mapped to the proofer space, then the press space, but these two conversions are an internal process of the proofer software.

Likewise the pages that get sent for the final offset screening process for plate output normally have the original InDesign PDF file values, with plate calibration curves applied at the very end.

But if the printer is applying an additional color conversion pre RIP, and you are seeing good results on the proof, there is no problem that I can see. Good luck with this and your future projects.

So it's still a bit hazy to me what the 'best' or 'most proper' workflow should be, from our images & InDesign files, through delivery, to proofing, and eventually to press. Seems like there are the potential for profiles and/or conversions at any place along the path:

Is there any reference that really clearly describes a 'best-case' workflow in a simple and understandable method, including specifics for incorporating the various Adobe products (Photoshop images, Illustrator EPS', InDesign master files, Acrobat PDFs), and different proofing/press stages.

As far as a color chain goes:

Photography (RAW) - RGB - Press CMYK.

Usually the RAW conversion is already done by the photographer. So from the designer's perspective, it's a matter of one good conversion (RGB - CMYK). Proofing and plate calibration are outside of this and not really part of the file conversion chain.

Plate calibration (comprised of curves) is there to enable the press to print to a specified standard. Plate calibration is generally not the designer's concern because it varies from shop to shop.

Proofing has two facets, soft proof and hard proof. Both of these are based on the press. Either one is just an effort to simulate the press (destination) color.

In the end as you move from design to press there is really only need for one ICC file conversion. You have source color (RGB) which gets mapped to press color (CMYK) and that's it. A proofer or monitor profile is something you deal with rarely (if at all) in InDesign or Photoshop or any of the Adobe programs. It is in place to enable the device to match the press color space.

In the instance of vector swatches, the designer oftentimes has no conversion at all to deal with, if the document is press CMYK, and the swatches are CMYK defined.

One of the regular posters here has written a book that deals with CMYK press workflows, if you're interested. It is called CMYK 2.0 by Rick McCleary. Published by Peach Pit and available at Amazon.

I should try to clarify some of what I stated yesterday, and I really hope the following information is accurate:

After Adobe color management is done (whether with InDesign or Photoshop), you end up with press CMYK color values in the output.

The page gets RIPped and the result is a Device CMYK image with number values matching the unripped CMYK output.

Before the Epson ink jet device can produce a reliable proof, two things must be established: the native color space of the proofer, and the target color space of the press. Both of these gamuts are initially expressed using Lab values. The Lab values then get converted to CMYK to produce two unique CMYK color spaces.

One describes the native proofer CMYK, the other describes press target color in the context of proofer CMYK. The native proofer gamut is HUGE, and the target press gamut is small.

Once these two spaces are defined, a ripped Device CMYK image can be submitted to the proofer. The proofer understands this image to be native proofer color, even though the file is already press CMYK numbers. In the context of the proofer, the CMYK numbers must change in order to achieve press target color.

The reason is, the native proofer CMYK gamut is a lot larger, having 7 or even 8 inks to work with. It is not at all like a normal offset press CMYK.

So the proofer color chain is:

Device CMYK (BIG) - Lab (BIG) - Press CMYK in proofer context (SMALL)

It is helpful to think of one particular color. For instance 100 C 50 M. This is a nice bright blue. If Device color was printed on the Epson, this blue color would be REALLY intense. So a conversion of color must occur for the blue to get dumbed down and appear as it will on press. The C and M numbers may drop, and yellow (the gray component) will be introduced. You might end up with 89C 45M 10Y. HOWEVER this is for proofing purposes only. These new CMYK numbers are NOT sent to plate or press. It is my belief that the ripped numbers you mentioned being different is a result of a proofer conversion (but please let me know if I am wrong).

When the blue color does go to plate, the original ripped 100 C 50 M is submitted. Plate curves are applied. But this process is not ICC, just as any curve adjustment to a CMYK image in Photoshop is not ICC.

So from the standpoint of the designer using Adobe color management there is only a need for one ICC color conversion to press CMYK. The proofer and plate details are internal prepress workflows.

Hope this helps, I just wanted to eliminate any confusion resulting from my rushed posts yesterday.