Can you export this file?

[Stephen Marsh]

I agree with you both about the above. Of course you shoud have a well documented color management policy both for customers and staff, and we do. I know about all the issues with converting CMYK to CMYK (we use device links for this with inkreduction/gcr, in a PDF/X-4 workflow). But thats not the issue here.

The question should be:

Should you color manage objects by it's embedded profile? My answer is yes, no mather what color setting the designer has been using in InDesign. What do you think?

And if you disagree, please give me an real life example when this is a bad option.

For RGB elements, it is a no brainer, yes they should be colour managed by their embedded or their assigned/overridden profile.

For CMYK elements, it is not always this easy. Sometimes the visual appearance is critical, other times the numerical build is more important. Sometimes it is both! This is why there are devicelink profile workflows, to ensure that solid primaries and secondaries are retained and perhaps that the K channel is maintained etc. An example is for screen captures or comics that make extensive use of the K channel to hold pure black data, with the CMY channels being for colour only. These could be originally created using a Max GCR type method, or in the case of illustrations they could be created directly in CMYK mode.


Stephen Marsh

 

[Stephen Marsh]

I think Adobe should provide this kind of color management features as a native function. It would be great to have a setting to not convert CMYK line art. But I don't understand why you doesn't want to convert any CMYK-photos?

Best regards,

Magnus, the way I see it is that an *image* is not always a photo.

As has been stated, clients don’t always get it (colour management).

For some the ICC profile tagged/assigned to CMYK data is irrelevant, it is all about the CMYK values in the file. For others, they don’t care about the CMYK build and the ICC profile appearance is all important. There is no way to know where each client may stand by attempting to blindly second guess them. Ask them or state up front the shop’s colour management policies, for both RGB and CMYK.

Yes, if the script or if InDesign could colour manage vector content differently than raster content, there would be more control – which is why I prefer to export to PDF/X-4 and control colour conversions in Acrobat Pro or PDF workflow software where one has more control than is currently offered by InDesign.


Stephen Marsh

 

[Magnus]

Stephen, I disagree. CMYK and RGB numbers Is not a color, the numbers always depends on the output (display, printer or press) thats why we need icc-profiles.

Lets say a client have a orange logo that is 40m and 100y the output can differ alot if you don't color manage. IMHO thats what icc profiles are for, to make that orange look the same on different output-units.

Some times we don't want black or gray to become 4 color separated but thats another issue.

The best would be if Adobe would offer a build in dynamic device link option in the Adobe CMM.

Best regards,

 

[Stephen Marsh]

Stephen, I disagree. CMYK and RGB numbers Is not a color, the numbers always depends on the output (display, printer or press) thats why we need icc-profiles.

Lets say a client have a orange logo that is 40m and 100y the output can differ alot if you don't color manage. IMHO thats what icc profiles are for, to make that orange look the same on differnt output-units.

No surprise, I respectfully disagree with you too Magnus! I also agree in part too. Colour is never simple, it can be case specific and what works for one object in a job does not work for another :]

I agree that without a profile, CMYK values are just that – numbers. In some cases, this is all that they need to be, they don’t require a colorimetric description.

A conversion of a files recipe values is not always required or acceptable.

Not all client expectations or print shop workflows are the same, which is why I feel that it is important for both clients and service providers to be on the same page regarding colour handling:

http://printplanet.com/forums/color-management/34408-can-you-export-file/2#post215602

After all, Adobe recognise this fact and provide InDesign with a mechanism to colour manage RGB elements while ignoring CMYK profiles in linked content. Without this option some InDesign users would just turn CM totally off. The “safe CMYK workflow” option is there for a reason.

Take the following case into consideration:

* An InDesign document may be tagged with a document level ICC profile for “Coated FOGRA 39 (ISO 12647-2:2004)”.

* It may have an image tagged with “coated_FOGRA39_GCR_bas”, which has been purposely separated with the intent to contain heavy GCR as neutral tones/gray balance may be critical for this image.

* InDesign CMYK colour policies set to “preserve embedded profiles”, rather than to “ignore embedded profiles” (safe CMYK workflow).

Result?

The intent to have heavy GCR in a neutral biased image has been lost, the intent has been overridden.

Why?

As the document/output intent is a specific ICC profile named “Coated FOGRA 39 (ISO 12647-2:2004)” and the image has a profile named “coated_FOGRA39_GCR_bas”, the colour policy has dictated that the CMYK file has been re-separated through the ICC PCS, loosing the original CMYK recipe build and K channel.

Now both profiles are targeting the same output condition and are created from the same characterisation data, however the current level of colour management is not smart enough to know this.

Some times we don’t want black or gray to become 4 color separated but thats another issue.

It can be hard to separate this issue from others, when colour management is not smart enough to handle exceptions and users have to jump through hoops to avoid colour management screwing up their work. Don’t get me wrong, CM works and is helpful too, it all depends on the context.

The best would be if Adobe would offer a build in dynamic device link option in the Adobe CMM.

That would be great, however just adding the “faux” preserve black/primaries/promote gray colour conversion options from Acrobat Pro would be a start for vector objects and text. We would need something better for rasters though.


Respectfully,

Stephen Marsh

 

[Magnus]

Thanks for a interesting discussion Stephen!

I don't think that we should mix colors and technical issues. The example above would not be an issue at our shop since we always use agressive GCR (AGFA InkSave in this case). I can not speak for others but in our case we always happy to answer any color management question from our client. But we do not contact the designer every time he/she send us a CMYK image with a missmatching profile to ask what we should do with it. Of course it happens that we contact the designer when we see something strange in a document, but this is not one of those times. We would assign all profiles and convert to output profile (in our workflow PDF/X-4) and take care of technical issues like rich black and GCR. I do not see why a client wouldn't get satisfied with that? So far they are very happy.

Best regards,

 

[gordo]

I remember a client who had a graphic similar to the below who wouldn't pay their bill because the two "&"s that had the same cmyk values were supposed to be the same color. They didn't appear that way so the assumption was that we screwed up.
Sigh.

 

[Stephen Marsh]

I remember a client who had a graphic similar to the below who wouldn't pay their bill because the two "&"s that had the same cmyk values were supposed to be the same color. They didn't appear that way so the assumption was that we screwed up.
Sigh.

Gordo, is this a case of good old simultaneous contrast?! Your sample above does not use just two discreet colours…

Sometimes to get the same two colours to visually appear to be the same, they need to be different and built from 4 discreet colour builds, not the same two!

http://web.mit.edu/persci/gaz/gaz-teaching/flash/contrast-movie.swf


Stephen Marsh

 

[Stephen Marsh]

Thanks for a interesting discussion Stephen!

I don't think that we should mix colors and technical issues.

My pleasure Magnus, it is a good discussion!

I find it hard to separate colours and technical issues (no pun intended).

ICC colour managed RGB input in a CMYK output context is easy, honour the embedded or overridden profile.

ICC colour managed CMYK input in a CMYK output context is not as easy as RGB, depending on expectations.


Stephen Marsh

 

[gordo]

Gordo, is this a case of good old simultaneous contrast?! Your sample above does not use just two discreet colours…

Sometimes to get the same two colours to visually appear to be the same, they need to be different and built from 4 discreet colour builds, not the same two!

You betcha! The sample uses just two colors (the &s are identical hues). Try talking simultaneous contrast to a graphic designer. Try using a spectro to help get recipes to match two colors that it sees and measures as being the same.

Let's see... these two colors look different but have the same Lab values. Hmmmm.

ROTFL

 

[Stephen Marsh]

You betcha! The sample uses just two colors (the &s are identical hues). Try talking simultaneous contrast to a graphic designer. Try using a spectro to help get recipes to match two colors that it sees and measures as being the same.

Let's see... these two colors look different but have the same Lab values. Hmmmm.

ROTFL

My mistake Gordo, I thought that the sample used four discreet colours, however closer inspection reveals three.

I thought that you meant that the designer would build using only two discreet colours, not understanding that they may need three or four discreet colours to visually match “the same colour”.


Stephen Marsh

 

[gordo]

My mistake Gordo, I thought that the sample used four discreet colours, however closer inspection reveals three.

I thought that you meant that the designer would build using only two discreet colours, not understanding that they may need three or four discreet colours to visually match “the same colour”.


Stephen Marsh

I only posted this because I get tired of color management discussions that I can't see as related to the real world. I don't get the point of Magnus' original posted sample and IMHO the thread spiraled down a rabbit hole of confusion. At least to me. The fact that he has happy customers doesn't mean much because they would never supply a file like the one he posted. But I'm not feeling very good so I may be over-reacting.

I'd rather read about what printers actually need to deal with rather than faked up hidden bomb files.

In my experience, and of course I might be a complete idiot, this is what I see (and I'm sure there are more examples):

1- Designer creates their files completely. In that case every bit of art has the same construct - right or wrong - for the destination output. Typically the color settings are the default ones in the various Adobe applications.

2- The printer receives files from a variety of sources and the files need to be brought to a common mechanical construct (i.e. max ink levels). This is typical for newspaper printing where images are coming from wire sources (e.g. Reuters et. al.) which are a combination of sRGB, Adobe 1998, and who knows what CMYK, staff photogs (who typically shoot sRGB), staff reporters using iPhones, and customer readers. These printers usually use an ink optimization application (as in Magnus' situation) that just clobbers everything to bring it to a common mechanical construct - appearance be damned because no one knows what any of it is supposed to look like any way.

Everyone talks about the need to educate the customer but the fact that this strategy hasn't worked for 30 years seems to be ignored.
The color management books are garbage as far as helping any one making productive use of color management is concerned. Unless they have access to a massive amount of technology to experiment with (and are so inclined).
The standards and specifications documents are a joke as far as enabling the typical printer to make practical use of them.
If folks like Frank Romano and Frank Cost - educators at RIT and immersed in color and printing - can't figure it out - doesn't that suggest there is a big problem?

I could go on but there is no point. Read what Dov Isaacs (Adobe) says here: http://printplanet.com/forums/color-management/34233-frank-romano-complains-about-colour-management

Rant over.

 

[Magnus]

ICC colour managed CMYK input in a CMYK output context is not as easy as RGB, depending on expectations.

Stephen Marsh

No one said it was as easy as converting RGB, but we are doing it all day and it works great. I think It's better to solve the problem instead of accept it as a fact.

 

[Magnus]

I only posted this because I get tired of color management discussions that I can't see as related to the real world. I don't get the point of Magnus' original posted sample and IMHO the thread spiraled down a rabbit hole of confusion. At least to me. The fact that he has happy customers doesn't mean much because they would never supply a file like the one he posted. But I'm not feeling very good so I may be over-reacting.

The test file that I posted shows various different problems that DO occur in real life everyday, but maybe not all at once.

I'd rather read about what printers actually need to deal with rather than faked up hidden bomb files.

I thought this was the Color Management section of the forum? And printers do need to up their color management game.

In my experience, and of course I might be a complete idiot, this is what I see (and I'm sure there are more examples):

1- Designer creates their files completely. In that case every bit of art has the same construct - right or wrong - for the destination output. Typically the color settings are the default ones in the various Adobe applications.

So why not correct the wrongs?

2- The printer receives files from a variety of sources and the files need to be brought to a common mechanical construct (i.e. max ink levels). This is typical for newspaper printing where images are coming from wire sources (e.g. Reuters et. al.) which are a combination of sRGB, Adobe 1998, and who knows what CMYK, staff photogs (who typically shoot sRGB), staff reporters using iPhones, and customer readers. These printers usually use an ink optimization application (as in Magnus' situation) that just clobbers everything to bring it to a common mechanical construct - appearance be damned because no one knows what any of it is supposed to look like any way.

I know what CMYK.

Thats what I try to prevent here. And a lot of our customers DO know how their images should look.

Everyone talks about the need to educate the customer but the fact that this strategy hasn't worked for 30 years seems to be ignored. The color management books are garbage as far as helping any one making productive use of color management is concerned. Unless they have access to a massive amount of technology to experiment with (and are so inclined).
The standards and specifications documents are a joke as far as enabling the typical printer to make practical use of them.
If folks like Frank Romano and Frank Cost - educators at RIT and immersed in color and printing - can't figure it out - doesn't that suggest there is a big problem? I could go on but there is no point. Read what Dov Isaacs (Adobe) says here: http://printplanet.com/forums/color-management/34233-frank-romano-complains-about-colour-management

So just because this is a some what complicated issue we shouldn't try to find good solutions?

This thread is not about educating designers, this is about showing people an efficient way how they can work in InDesign (if they want to) to solve a lot of color management problem and save time.

 

[gordo]

The test file that I posted shows various different problems that DO occur in real life everyday, but maybe not all at once.

Exactly. that's why I couldn't see it as related to the real world - customers would never supply a file like that one.

I thought this was the Color Management section of the forum? And printers do need to up their color management game.

Fine, then do a straightforward tutorial.

So why not correct the wrongs?

Fine, then do a straightforward tutorial. In the case that you posted and the way that you posted it, IMHO, did not correct the wrongs. Printers are in the business of reproduction not creative interpretation of customer intentions based on how they constructed their files. I was taught very early on to "let it fail." You don't attempt to correct anything - not even spelling mistakes. The file you posted IMHO should have been printed the way it appeared on screen and on a hard copy proof. That is what you were given, that is the author's intent, that is how it should have been printed. That would also made an interesting discussion.

I know what CMYK.

That was not the point.

Thats what I try to prevent here. And a lot of our customers DO know how their images should look.

Right. That is why the file you posted should have been printed the way it appeared on screen and not been altered by you to look the way you think it should look..

So just because this is a some what complicated issue we shouldn't try to find good solutions?

You are not solving the problem. You are solving the symptom of the problem. So the problem persists. Customers do not learn from their mistakes because either they don't know they made a mistake (your heroics solved it for them behind the scenes) or there is no personal consequence to the customer for making a mistake (your heroics solved it for them behind the scenes). Document creators learn very quickly when they have to pay for a reprint because of mistakes they make.

This thread is not about educating designers, this is about showing people an efficient way how they can work in InDesign (if they want to) to solve a lot of color management problem and save time.

I didn't think the thread was about educating designers. Again, if it's about showing people an efficient way how they can work in InDesign then just do a tutorial because judging by the posts on this thread the people don't appear to have learned your efficient way.

 

[Magnus]

Fine, then do a straightforward tutorial.

Guess you did not look at post no 4.

And I did not altered the file, I color managed it "by the book" and did a tutorial how to do it.

 

[gordo]

Guess you did not look at post no 4.

And I did not altered the file, I color managed it "by the book" and did a tutorial how to do it.

This may be semantics, however, what I see is the file being altered in order to have all the images have the same appearance. You may call it "color managed "by the book" but the work you did changed how the supplied file finally appeared.

You wrote earlier:

I would not contact the author of the document just because the document has a wrong document CMYK-profile or placed content aren´t assigned with it's own ICC, since I know that the authors answer would result in: me doing the above actions.

Maybe, maybe not, unless you are psychic. You made an assumption that the author doesn't know what they are doing and you also assumed that their intent was to make the images have a common appearance. Maybe they were just trying to see how files with different profiles, constructs etc. affected final output. You've taught them that it doesn't matter what they do - you know better and will automatically over-ride their intent.

And I would have to call almost every time someone send us a new file.

Yes. Better to have a clear communication than operate on assumptions. There may be cases where you have an intimate understanding of the client's way of constructing files which might lead you to make experience based assumptions. However, if you have that relationship with the client then why not go one on one with them a show them how to do it right.

And we always send customer a RIP-softproof or RIP-hardproof before production when we receive open documents like InDesign.

Good, but in this case the proof was how the file was displayed and the color differences were strong enough that they would be seen on any display - color calibrated or not. Hence, one could argue, their output intent was to see how images that looked different on the screen would look after being RIPped.

I agree with you about how to handle PDF-files, but we do convert tagged CMYK, and replacing Intent Output.

I call that altering the file. You seem to think that's not altering the file - it's just good color management practice.

What you originally wrote was that:

This is just an experiment to see how people handles Indesign-files and make PDF:s for print.

And Adobe's advice: "For PDF export, the existing PDF/X-4 settings with your favorite output intent profile" - and I guess what happens happens.

 

[toronar]

I agree with gordo here.

The best reason given really is

You made an assumption that the author doesn't know what they are doing and you also assumed that their intent was to make the images have a common appearance. Maybe they were just trying to see how files with different profiles, constructs etc. affected final output. You've taught them that it doesn't matter what they do - you know better and will automatically over-ride their intent.

It leads to death by a thousand paper cuts. Now the customer expects that these images always come out the same, no matter "what they do". If they don't, YOU screwed up, not him.
"But it worked all the times before without a problem!" (Who hasn't heard that one when you bounce a PDF from a customer?)

We try to educate our customers of their mistakes. Sometimes it is a loss, sometimes it works. But it is often better than the usual "ah I'll fix it so that we can start production". Because that is what you'll do for this file/customer for the next years.

 

[Magnus]

Ok, clearly we have a different view on color management and what to do and what not to do with an Indesign doc from a client. In my initial post I was curious to see If anybody else is assigning all profiles and I wanted to show a way of doing it (if one would like to, not saying that everyone should work like this). But this discussion turned out to be about policy rather then color management features and tech. I think I will choose my words better next time I post something similar.
Obviously this is a sensitive subject that stirred up a lot of feelings and that was not what I was aiming for.

Over n out.

 

[Stephen Marsh]

But this discussion turned out to be about policy rather then color management features and tech. I think I will choose my words better next time I post something similar.
Obviously this is a sensitive subject that stirred up a lot of feelings and that was not what I was aiming for.

Over n out.

Magnus, I still wish to talk about “no colour conversion” in the PDF export resulting in “colour conversion”, depending on whether one includes or excludes ICC profiles (this is not a PDF/X4 export concern though)… If anybody is interested that is! Is it a bug, or just my misconception of how InDesign manages colour between colour management policies for honouring or ignoring profiles and the export settings?


Stephen Marsh

 

[Stephen Marsh]

Is this a bug?

Is this a bug?

So, nobody wishes to discuss the elephant in the room? Really?

Perhaps if I showed an infographic to simplify my point (hint, X = incorrect, a CMYK colour conversion)…

Test .zip archive attached (.indd / .idml / .tif)

NOTE: If you open the IDML file rather than the CS6 file, ensure that the placed image has image colour settings set to use the embedded coated_FOGRA39_GCR_bas.icc profile, rather than the document profile of Coated FOGRA39 (ISO 12647-2:2004)

Is it a bug, or just my misconception of how InDesign manages colour between colour management policies for honouring or ignoring profiles and the export settings? I understand that the image profile is different to the document profile, which calls for a conversion – however the export settings are set to no conversion and colour settings call for safe CMYK workflow of ignoring profiles! So what gives? And why does exporting with no ICC profiles honour the CMYK values, when including ICC profiles converts the CMYK values?


Stephen Marsh