The question often arises whether color profiles should be embedded in the PDF files for proofing.
To answer the question, you have to get some answers: The proof should simulate the subsequent offset printing. For offset printing, with few exceptions, the imagesetters have been configured so that a 70% black in the file is displayed as 70% black on the printing plate, no matter what profile was specified in the file. It didn’t matter whether it was coated paper or uncoated paper: 70% in the file corresponded to 70% on the plate, the choice of the paper printed on resulted in the colour representation.
The proof has also adapted to this: Most proofing service providers ignore embedded profiles, as long as the data is in CMYK and do the same as their print colleagues. Even with grayscale, the profiles are usually ignored and the grayscale is simply assigned to the CMYK black channel. Thus all CMYK and grayscale data are simply interpreted as if they had been created in the output color space. If “ISOCoated V2” is proofed, all images are treated as such, and if “PSOUncoated” is proofed, then the CMYK images are created in this color space.
This is excellent for the majority of files to be proofed. Only RGB colors contained in the data are problematic.
Since the RGB color space is considerably larger than most CMYK color spaces, it must be clear from which color space to convert to CMYK according to which criteria. Most proofing service providers specify a color space from which they convert by default if no RGB color space is defined. This can lead to difficulties: For example, many proof studios choose AdobeRGB as color space because it is large and optimized for offset printing; however, most images from digital cameras come from sRGB and these color spaces differ considerably. Therefore, it is important that the RGB color space and the rendering intend is embedded for a proof, otherwise the proofing software normally selects a color space for conversion to the CMYK color space to be proofed; and this color space is possibly not the one in which the data has be created.
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.
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!
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. (more…)