InDesign CM Workflow Questions

[jethrodesign]

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.

THANKS!!!

[Printer_Rick]

jethrodesign wrote:

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)

3. You supply CMYK PDF.

For 2 and 3, export using the PDF/X-4 standard. For 2, "No color conversion" (under Output, Color Conversion). For 3, "Convert to destination" preserve numbers, Document 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).

Hope this helps.

[jethrodesign]

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.

3. You supply CMYK PDF.

For 2 and 3, export using the PDF/X-4 standard. For 2, "No color conversion" (under Output, Color Conversion). For 3, "Convert to destination" preserve numbers, Document CMYK.

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).

[Printer_Rick]

jethrodesign wrote:

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.

[jethrodesign]

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.

[Printer_Rick]

jethrodesign wrote:

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?

[Printer_Rick]

jethrodesign wrote:

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.

Here is the website link I mentioned:

http://www.idealliance.org/industry_resources/branding_media_and_color/gracol

It's on the right SWOP 2006 and GRACOL 2006 profiles. 3 profiles for coated work.

[jethrodesign]

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.

THANKS AGAIN FOR ALL THE HELP!!!

[jethrodesign]

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:

   - Color Management Policies is set to: Convert All Colors to CMYK

   - Document Rendering Intent is: Relative Colorimetric

   - The CMYK Working Space is: Our printer's ICC profile

   - Preserve CMYK Values for Calibrated CMYK color spaces is UNCHECKED

   - In Standards tab, the Output Intent Profile Name is: Our printer's ICC profile

But upon creating the PDF, all internal colors and values look OK, but all images are converted to DeviceCMYK and NOT our printer's ICC profile as specified.

AGH! What am I missing here?!? This is getting frustrating, and more complicated than I though it would be, but it's definitely not due to the excellent help I've been getting : ) Thanks again!!!

[jethrodesign]

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.

[Printer_Rick]

Device N! My favorite subject.

I know you are probably pressed for time but hang on if you can. I will read over your issue and try to get back to you on this as soon as possible.

[Printer_Rick]

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)

10. Make certain the blend space is CMYK (but it probably already is)

[Printer_Rick]

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.

[jethrodesign]

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...

[Printer_Rick]

Well I'm stumped but maybe on the wrong track.

See attached. CS3, (5.0.4). I have polka dots, black on white. Effective PPI is 450.

Grayscale is colorized and so is background.

I output PDF/X-4, downsample to 200PPI (it looks like your example was 200 PPI). No matter what I do I can't replicate your color shift issue. I'm not sure what's causing it exactly.

The downsample should not affect color like what you're seeing. I'm sure turning it off fixed your problem but it doesn't make sense, it shouldn't have caused a problem in the first place.

I tried assigning different CMYK profiles to the document, scaling the image, I even tried converting the image to bitmap and rotating it but the output is always correct.

Maybe my file isn't quite set up like yours but I can't be sure.

[jethrodesign]

OK, the plot thickens (and confusion rises)...

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.

So try this to see if you can simulate the issue:

- Convert your document profile to either FOGRA27, or my attached profile.

- 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!!!

[Printer_Rick]

I have indeed duplicated your problem and the downsampling is somehow related. It appears to be a bug. The issue does not occur in CS4 so far as I can tell.

As far as another fix for CS3 you can introduce transparency. Draw a white box over it set to darken blend mode. Then output PDF/X-1a.

This is as interesting bug and I will look into it more.

[jethrodesign]

Well, at least I know I'm not totally crazy.

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.

THANKS AGAIN!

[Printer_Rick]

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.

[Printer_Rick]

jethrodesign wrote:

- 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.

Anyway it's a strange and interesting problem to say the least.

[jethrodesign]

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.

[Printer_Rick]

jethrodesign wrote:

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.

[jethrodesign]

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 ; )

[Printer_Rick]

jethrodesign wrote:

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.

[Printer_Rick]

Printer_Rick wrote:

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.