43
Replies
I wouldn't have thought that the presence of any placed element comprising some level of transparency/blend mode would throw the whole page into CMYK simulation?
Hi Roger, InDesign doesn’t have a single document color mode, it lets you mix objects with different color modes on the same page—AI and PS have single document color modes, so they don’t need a Transparency Blend Space. ID needs a Blend Space because eventually, depending on the output destination, the entire page or spread will need to be flattened into a single color space.
For example, if you are working for a web destination, your InDesign page will likely have to be exported to a flattened JPG or PNG web image format—the entire page or selection, not just the objects with transparency, will get flattened to a single color space on the JPEG/PNG image export.
For example here I have Lab, RGB, and CMYK color fills blended together, with my Blend Space set to RGB. With Overprint/Separation Preview turned off I get a preview of a flattened export to document RGB:
If the destination is print, the page will still eventually get flattened when it is RIP’d—the entire page will have to be RIP’d into a single color space. Also the Blending mode Effects behave differently depending on the color space—you can see that in Photoshop if you try the Difference Blending mode in an RGB vs. CMYK document. So, if I change my document Blend Space to CMYK, the Lab color, which is set to Difference behaves differently, and the entire page previews in the document’s CMYK space, reflecting what will happen when the page is RIP’d:
Also, more to your original question, besides the Blend Space and Overprint Preview settings @Test Screen Name mentioned, the InDesign Color Settings Color Management Policies could also affect the display of a placed RGB image whether it has an embedded profile or not. It’s important to note the CM Policies are saved with the document when it is created–the Color Settings’s Policies don’t affect an existing document.
If my document’s saved RGB Policy is set to Preserve Embedded Profiles, and the placed image was saved with the sRGB profile embedded, it will display as sRGB even when my ID document’s RGB profile assignment is different—ProPhoto RGB in this case:
If the document was created with the RGB Policy set to Off, then the InDesign document would be created with no RGB profile assignment, placed RGB images would have their profiles ignored, and the profile assignment would fallback to the Color Settings’ Working RGB Space. Here the doc’s RGB Policy is Off, and my current RGB Working Space is ProPhoto:
Dear Rob,
I appreciate the pain you took to document all your excellent points. Believe me, I'm pretty good with all that stuff myself, policies, honouring placed images embedded profiles and transparency blending. I'm not afraid of rolling my sleeves and dig in all that dirt with my students since color management is one way I've earned a living in the print world for many years.
With your kind help and that of others, I now understand that ALL page elements are "promoted" the Document CMYK space as soon as any page elements has any "transparency" attributes turned on, as in my lowly "RGB additive synthesis" Overlay mode demo.
I pay very close attention to my Color Settings in all four CC applications starting with Photoshop, Illustrator, InDesign and Acrobat. Bridge works fine on its own, using my monitor profile as the Destination for any selected image, matching Photoshop's rendering to the screen.
The thing I still don't understand and I tried a "Chat support" session with Adobe about it, yesterday -- what a waste of time, it was --, is IF the whole page is thrown into "CMYK", why are the native elements handled differently? Why not ALL page elements be treated the same?
Here are two screen captures that document this behavior, from two consecutive InDesign pages (wish I could attach the document here?), "Page 1" and "Page 2".
On Page 1, there are four elements, three elements are imported Photoshop RGB images, and 1 element, top right-hand corner, is "InDesign" native elements, created in RGB.
You see the difference? Why on eartg is the "native" element NOT rendered the same as the imported elements?
According to your understanding, as soon as any page elements has any transparency attribute, the whole page is thrown into CMYK, if that's the Document Blend space.
Well, if that was the case, Page 2 below, ought not to be shown in the CMYK Blend space since I deleted the "Native" element? In other words, nothing on this page has any transparency :
You see what I mean?
My problem is I don't know how to interpret InDesign's behavior?
And, the same goes for Illustrator. Here is an RGB document with three different RGB elements shown with Proof Colors (CMYK) :
- Left is a placed RGB Photoshop image
- Center is a native element, three circles with an unflattened Overlay blend mode
- Right is a native element "flattened" into separate, non-blended vector elements :
Obviously, here again, the "native" element appears to be flattened in RGB space BEFORE being rendered into CMYK. Would you agree that this is the case?
If that is the expected behavior, for some reason, I don't agree that this is "correct"? To me, ALL elements on the page should be equally treated. And that's not what I am finding, Rob.
I keep coming back to my expectation that, placed RGB images in InDesign ought to display the same as viewed in Photoshop, GIVEN THE SAME Color Settings, and that seems to be the case, regardless of "Print" vs "Web" Transparency Blend space, Here is a screen capture from my desktop showing the same RGB image in both Photoshop and InDesign :
That behavior, to me, is "logical".
Next, what if I was to add my infamous RGB graphic to the Photoshop's document, and place THAT into InDesign, how would that display? Well, regardless of whether I have Proof Colors selected or NOT, the choice of Transparency Blend space is all that matters, clearly, CMYK Document Blend space selectively process "native" vs "foreign" elements, and there is no UI to effect that behavior, Mr. Day? Here's another screen capture :
I really don't know what to say?
Hi Roger, it looks to me like it is the collision of blending spaces—your Photoshop files are blending in sRGB and your ID page is blending into Document CMYK (US Web Coated SWOP in your sample page).
If I set your InDesign document’s Blend Space to RGB, and turn off Overprint/Separation Preview, everything matches:
If I then turn on Separation Preview I get a Document CMYK soft proof—the expected output to US Web Coated SWOP. Again everything on the page matches:
If I soft proof the Photoshop sRGB files to US Web Coated SWOP, ID and PS match:
You can work with an RGB Blend Space for print but the Export gets tricky, because the black only text can get converted to 4-color when the page is exported to CMYK and flattened (e.g., PDF/X-1a)
You can protect the Black text by exporting to PDF/X-4 with no color conversion and flatten the pages using AcrobatPro’s Flattener tool. Export to PDF/X-4, with flattening in Acrobat after the export:
Question: the fact that the imported Photoshop file is "sRGB" should not come into the picture since the InDesign "Document RGB mode" is also sRGB.
Right, the but if you are trying to get a match between ID and PS blended colors you can’t mix profiles. It’s easier to see when the colors are not on the edge of the gamut:
Same values conflicting profiles
My point is why, on earth, when "Transparency Blend space" is set to CMYK, why are the "native" sRGB elements handled differently from the "imported" sRGB elements?
You can’t set a CMYK Blend Space in a Photoshop RGB image, so there isn’t a comparison. I think it’s because InDesign doesn’t have a single document color mode.
Of course, if I was to adopt an "RGB Transparency Blend space" in all my InDesign documents, there would never be a "problem" since, clearly, ALL RGB content is handled equally, all seemingly flattened in RGB space, first, before converting to CMYK.
You could have a problem with CMYK builds you want to protect. You can see that if you check your 0|0|0|100 Black text in Separation Preview with the RGB Blend Space:
Also, a PDF/X-4 Export with live transparency can do this in Output Preview without an intervention. Blending is Exclusion:
there would never be a "problem" since, clearly, ALL RGB content is handled equally
You also might have a problem when your RGB editing space is sRGB—sRGB clips a large chunk of the CMYK gamut. You can see the problem if I fill a rectangle with 100% Cyan, which is so far outside of the sRGB gamut it would get clipped on the conversion and output as 69|14|0|0 CMYK:
—sRGB clips a large chunk of the CMYK gamut" is debatable... at least in my view.
Apple’s ColorSync Utility will show 3D plot space comparisons. It’s pretty obvious when you compare sRGB with a common offset space like Coated GRACoL. The white plot is sRGB and the color outside of the white would be unavailable on a conversion from sRGB to GRACoL. It would get considerably worse with bigger print spaces e.g., Inkjet
The clipping is obvious in the Separation numbers when I check CMYK fills with the blend space set to sRGB:
Rob,
Your points are well taken, rest assured, but they are the "typical" points most people I know make? ColorSync utility is fine to get an idea of "relative" gamut sizes, I won't dispute that. But sadly, ColorSync is unable to show an RGB image as a series of points INSIDE an ICC profil 3D projection.
I developped a small Matlab script to study exactly the business of "clipping". I have yet to run into an image that uses a lot of the (typically) "Cyan" colors that are presumably outside the typical CMYK gamut. It has to do with the nature of the imagery that people capture everyday? And I'd beg to know your experience and others, Rob?
I have yet to run into an image that uses a lot of the (typically) "Cyan" colors that are presumably outside the typical CMYK gamut.
sRGB wouldn’t always be a problem, but here‘s an example where I can clearly see significant clipping in the CMYK output values.
The top image has ProPhoto assigned, and the bottom image is a copy, converted to sRGB via Convert To Profile... I have both soft proofing to Coated GRACoL.
Right away you can see the conversion from ProPhoto to sRGB has destroyed the details in the water, and it will get worse with the conversion to GRACoL. I’m sampling a blue and yellow color that gets crushed by the sRGB conversion—99|15|0|0 outputs as 78|29|0|0, and 0|2|100|0 outputs as 4|0|89|0. Not only does it look bad, there would be no way to color correct the sRGB version and get the needed 100|15|0|0 output value because it is not in the sRGB gamut.
AdChoices