When we receive a file from you, the first thing we check is whether there are colours other than CMYK in the file. If the file is built exclusively in CMYK, it will be sent directly for proofing.
Handling wrong profiles with CMYK data / “Profile Mismatch
If we have only received CMYK data from you, we will ignore all input and output profiles and only use the CMYK values that we bring to the ordered output colour space.
Example 1: Data in ISOCoated, proof in ISOCoatedV2 ordered, thus wrong or no CMYK profile embedded.
You send a file with the profile ISOCoated and a colour area in CMYK 100/70/0/0 and order a proof according to ISOCoatedV2.
We ignore the ISOCoated profile and proof the pure colour value 100/70/0/0 according to ISOCoatedV2.
Why do we do this?
In our proofs, we try to reproduce the “lived reality” of the print as well as possible. In many conversations with printers we have seen that in almost 100% of the cases they do not convert profiles from CMYK to CMYK, but instead put a colour value of 100/70/0/0 on the plate without taking CMYK profiles into account, insert paper and print in conformity with the standards. So we also map this way, although it would actually be “more correct” to perform a colour space transfer from ISOCoated 100/70/0/0 to ISOCoatedV2. However, this results in a different colour value, for example 100/63/1/6 for relatively colorimetric conversion with depth compensation or 100/63/3/15 perceptively with depth compensation!
In practice:
One of our customers did not proof 30 slightly different, dark blue colour areas in ISOCoatedV2 on our premises, but on the premises of a colleague, under each of which the CMYK value was in black lettering, in order to sample the colour of a powder-coated surface. The customer defined a very well fitting CMYK colour value on the basis of the proofed colour areas, inserted it into his brochures and started the print jobs. Result: The dark blue was a distinctly different blue than on the reference proof, customer and agency were very dissatisfied and went on troubleshooting. Now the case came to us.
We received a file for proofing according to ISOCoatedV2 and compared it with our colleague’s proof. The colours with the same black CMYK values printed underneath were clearly different, but both proofs were provided with media wedges and measured correctly. After some troubleshooting, we came up with the idea of requesting the original proof from our colleague, which also existed. In this one there was a Fogra27Coated profile, thus an implementation of the old ISOCoated. A proof according to ISOCoatedV2 had been ordered at that time. Had it happened? The colleague had taken the input profiles into account, which resulted in a significant change in the CMYK values of the colour patches, as mentioned above, due to a colour space transfer from CMYK to CMYK. The black printed CMYK values under the colour patches had of course not changed. The patterned CMYK value therefore did not correspond to the proofed value at all. Our customer fell from all clouds: “How, our CMYK values were not proofed”. This would not have happened with us, because we would ignore the embedded profile with CMYK data. In this case this would also have been our customer’s expectations.
After almost two hours, we had determined the “error” (or perhaps rather: the “difference”), created a proof for our customer that was “in line with expectations”, which he could use to determine the appropriate CMYK value in ISOCoatedV2, and solved the problem.
Example 2: RGB colours included
If we receive a PDF file containing RGB images, the next step is to check whether the file is a valid PDF/X-3 or PDF/X-4 file. If this is the case, and all input RGB profiles are correctly marked with colour space (sRGB / AdobeRGB / ECI-RGB-V2 etc.), then we check whether the correct output colour space was used as output intent and whether CMYK data also contained the correct input profiles. If yes, then we proof the file with the settings: “Consider all input and output colour spaces”.
If RGB data should not contain a profile, e.g. if they are created in Device RGB, we generate a “data erroneous” email in which we explain our procedure as follows:
“Dear customer,
The data check has shown that RGB elements are contained in your data. RGB elements can only be safely interpreted in the proof if they are marked with a colour profile and a rendering intent. This is the case, for example, with correct PDF/X-3 and PDF/X-4 data. The correct output intent must also be specified.
At least one of these criteria does not seem to be the case for your file.
The safest way would be to convert the contained RGB data to CMYK. This has the advantage that you have control over the conversion and can view the CMYK result again in Acrobat before uploading the file again for proofing. We can then reliably use your CMYK values for the proof. To do this, call up the current order in your customer account, delete the incorrect data and upload the corrected data.
If, for example, the RGB element should only be a small image that is not relevant for the overall impression of the proof, or if you do not have another file available for the proof, we can of course also use your RGB data for the proof. If available, we then use your RGB source profiles and rendering intents, otherwise we use the sRGB standard and the rendering intent “relative colorimetric with depth compensation”, which in most cases will lead to correct proof results.
If you would like us to proof the supplied RGB data in this way, please let us know. Please do not hesitate to contact us if you have any questions. Many greetings, your proofing team”.
Practice case:
A customer called us, who sent open Adobe InDesign data in ISOCoatedV2 300% with RGB images to the production company for a sophisticated CD production on the advice of the producing company (“The print shop still has a prepress stage, which can then prepare your data perfectly…”). The result of the finished printed CD booklets and inlays did not correspond at all to the calibrated monitor image of our customer, so the client was very unhappy and requested the print data of the production company from the print shop responsible for the print to troubleshoot. Files in “US Web Coated” colour space with 350% ink coverage came back from the printer. For troubleshooting, the customer then had a proof of his data created by us, but had selected the settings “Convert to target profile (retain values)” as usual when writing the proof PDF. We received data completely built up in CMYK, of which we produced a proof according to ISOCoatedV2 300% that fully met the expectations of our customer.
Our error analysis revealed two weaknesses: On the one hand the open InDesign file of our customer with RGB images without embedded profiles, on the other hand the obviously wrong profile conversion of the print shop with InDesign CS2 to “US Web Coated”, a completely outdated profile never used in Europe, which was just delivered with CS2 and was probably never adapted due to lack of competence.
A complaint in this case will of course be difficult, as on the one hand non-profiled RGB data was sent to the production company, and on the other hand no print PDF generated by the data producer in the correct output colour space ISOCoatedV2 300% was supplied. If this had been done, one could at least have argued that the expected colour of the production print would have been comprehensively known.
With us, the case would also not have occurred in the proof, as we reject RGB data not provided with an ICC profile with the above mentioned error message, and do not convert them, as we cannot precisely predict how our customer would have liked to have the data converted.
We are aware that our approach is not 100% the ultimate best approach in all cases, but to the best of our knowledge and belief it is best in line with market practice and the expectations of our customers.
However, we are also happy to accept your individual requirements and circumstances. Give us a call or send us an email and describe your processing requirements which differ from those shown above.