Are you using a PDF/X-4 RGB workflow?
- Thread starter Magnus
- Start date
Dov Isaacs
Well-known member
Quite frankly, all PDF-native RIPs/DFEs (i.e., no internal conversion from PDF to PostScript) based on either Adobe or Global Graphics (i.e., Harlequin) OEM technology from the last 15 years support PDF/X-4-based workflows. Likewise, professional design software (i.e., InDesign, Illustrator, Photoshop, Quark, etc. but not Adobe Express or Canva) fully support ICC-color managed workflows in which non-CMYK based colors (including RGB and LaB) are tagged with the correct ICC color profiles.
The “got'cha” is that one can have a perfectly “correct” PDF/X-4 file that doesn't reflect what the graphic artist / designer really intended due to the graphic artist / designer's lack of understanding of the fundamentals of color. Obviously, the same problem exists for pure CMYK workflows, although in such CMYK-only workflows, the print service provider is more readily able to blame the customer!
The “got'cha” is that one can have a perfectly “correct” PDF/X-4 file that doesn't reflect what the graphic artist / designer really intended due to the graphic artist / designer's lack of understanding of the fundamentals of color. Obviously, the same problem exists for pure CMYK workflows, although in such CMYK-only workflows, the print service provider is more readily able to blame the customer!
Magnus
Well-known member
There is often a discrepancy between what software can do and what users choose to do with it.Quite frankly, all PDF-native RIPs/DFEs (i.e., no internal conversion from PDF to PostScript) based on either Adobe or Global Graphics (i.e., Harlequin) OEM technology from the last 15 years support PDF/X-4-based workflows. Likewise, professional design software (i.e., InDesign, Illustrator, Photoshop, Quark, etc. but not Adobe Express or Canva) fully support ICC-color managed workflows in which non-CMYK based colors (including RGB and LaB) are tagged with the correct ICC color profiles.
The “got'cha” is that one can have a perfectly “correct” PDF/X-4 file that doesn't reflect what the graphic artist / designer really intended due to the graphic artist / designer's lack of understanding of the fundamentals of color. Obviously, the same problem exists for pure CMYK workflows, although in such CMYK-only workflows, the print service provider is more readily able to blame the customer!
Dov Isaacs
Well-known member
I am in violent agreement with that thought!
Magnus
Well-known member
Since we stopped providing CMYK profiles to our customers and simplified our PDF instructions to the absolute essentials, we've seen a significant decrease in color complaints. Many customers today are not deeply familiar with print production and often find CMYK concepts challenging to grasp. When we, as the printer, tell them, "Don't worry about the color space of your images—we'll handle the CMYK conversion," it's often met with a sense of relief.The “got'cha” is that one can have a perfectly “correct” PDF/X-4 file that doesn't reflect what the graphic artist / designer really intended due to the graphic artist / designer's lack of understanding of the fundamentals of color. Obviously, the same problem exists for pure CMYK workflows, although in such CMYK-only workflows, the print service provider is more readily able to blame the customer!
This doesn’t mean we neglect color quality—quite the opposite. We maintain a highly controlled and carefully managed color workflow, ensuring consistency and accuracy from file to print.
repro_glenn
Member
"correctly" is too vague to answer.
Do you reject files with the wrong Output Intent? – I bet the answer is No.
Do you honour or ignore wrong cmyk profiles? – I bet the answer is very split
What do you do with unwanted spot colours? – YMMV
Handling Profiled RGB ought to be straightforward for a modern RIP, but it's still difficult to get absolutely consistent results between different Printer's Workflows. Conversion Intent for Adobe apps is almost always Relative Colorimetric, but on RIPs its often Perceptual.
Magnus
Well-known member
Great input Glenn! Yes, "correctly" is indeed quite vague."correctly" is too vague to answer.
Do you reject files with the wrong Output Intent? – I bet the answer is No.
Do you honour or ignore wrong cmyk profiles? – I bet the answer is very split
What do you do with unwanted spot colours? – YMMV
Handling Profiled RGB ought to be straightforward for a modern RIP, but it's still difficult to get absolutely consistent results between different Printer's Workflows. Conversion Intent for Adobe apps is almost always Relative Colorimetric, but on RIPs its often Perceptual.
As you say different printers handle these aspects in different ways. Here’s how we manage them at the moment:
• We discard the CMYK output intent of incoming files and assign our "house CMYK" (Fogra51 with a proprietary perceptual gamut mapping table). Typically, the creator of the PDF (our customer) embeds the profile that matches their CMYK standard workspace in their layout software and we do not have any need for that.
• We usually discard all embedded CMYK profiles (somewhat controversial, perhaps) but this approach has significantly reduced errors and complaints. Previously, handling tagged CMYK objects (such as line art and images) in different ways could introduce inconsistencies. Of course, we make exceptions: if a customer submits a coffee table photobook in SWOP CMYK, we will reach out, and in specific cases, we honor embedded CMYK profiles.
• Unwanted spot colors are converted by automatically mapping color names to their Pantone v4 Lab values (as an alternate color space). The Lab values are then converted to Fogra51 using relative colorimetric with black point compensation. If a spot color name isn’t found in Pantone v4, we convert it from its alternate color space as is.
• All RGB content (respecting embedded profiles, using sRGB as fallback) is converted perceptually to our "house CMYK" (ignoring embedded rendering intent). From there, we perform a CMYK-to-CMYK conversion to specific fingerprinted profiles within our RIP/DFEs. This ensures consistency across different output devices and substrates.
This workflow wouldn't pass the Ghent PDF/X-4 test suite, but it minimizes issues and keeps our customers satisfied while maintaining a high level of automation — for now.
repro_glenn
Member
Comparing your’s to mine:
• We discard the CMYK output intent of incoming files and Apply a CMYK Target Profile to the database “F39_v1.icc” (Kodak’s take on “Fogra39”). Typically, the creator of the PDF (our customer) embeds the profile that matches their CMYK standard workspace, if they ask I’ll suggest they use Fogra 39 or Fogra 51 even if we are printing on uncoated, in general they don’t ask.
• We usually discard all embedded CMYK profiles (somewhat controversial, perhaps) but this approach has significantly reduced errors and complaints. Previously, handling tagged CMYK objects (such as line art and images) in different ways could introduce inconsistencies. Of course, we make exceptions: if a customer submits a coffee table photobook in SWOP CMYK, we will reach out, and in specific cases, we honor embedded CMYK profiles. 100% agree, converting is worse than assigning unless you use DeviceLink. Reaching out to someone who might care is best approach.
• Unwanted spot colors are converted by automatically mapping color names to their Pantone V3 Lab values (as an alternate color space) As defined in a Factory Library inside Prinergy. The Lab values are then converted to “F39_v1.icc” (I don’t have any control over Intent of this conversion). If a spot color name isn’t found in Pantone V3, I can choose PANTONE-V4 M1, or I can custom Define the alternate color space, or I can use the alternate color space defined in the file. If the alternate color space is cmyk or DeviceRGB or ProfiledRGB then the conversion intent is Perceptual.
I have left V3 as the default because we have a lot of legacy files that repeat, and I want to convert these the same cmyk values.
Also if these files are printed Digital and they are not trying to use overprint or blend modes I’ll often leave Spot Colours in the print pdf for the Digital’s RIP to use its own PANTONE Library.
• All RGB content (respecting embedded profiles, using AdobeRGB1998 as fallback) is converted perceptually to Kodak’s “F39_v1.icc” CMYK (ignoring embedded rendering intent). From there, we have in house CMYK-to-CMYK to press fingerprinted targets to get uncoated print as close as we can to Fogra 51 inkjet proofs. (Customers really don’t like FOGRA 52 proofs. I really don’t like FOGRA 52 proofs and the results on press vary wildly because of the huge range of shades between uncoated stocks)
• Actually “All RGB content” is incorrect, we do a bit of Wide Format inkjet and if it comes in as Profiled RGB, that’s how it gets presented to the Fiery RIP sometimes if its mixed profiles I’ll convert All to AdobeRGB or eciRGB_V2, then manually set the RIP to target those.
I don’t think either yours or mine is Ghent PDF/X-4 test suite correct. I don’t think you can nail down “correct”
Leaving aside the “proprietary” conversions, we still would get different results with DeviceRGB just because you choose sRGB as fallback and I choose AdobeRGB1998.
We both get different results than the customer would get, if they converted direct in InDesign or Photoshop using Relative Colourimetric.
I hate it when a customer sends Proof pdfs in one color space then sends amended pdfs in another.
And then there is the “proprietary”, obviously I don’t know the pros and cons of your system but with mine I’d say Kodak’s conversions are sometimes better sometimes worse than Adobe’s (If I’d set Adobe to Perceptual) but mainly just a little bit different. One exception for me is a ProPhoto RGB.icc conversion always seems better with Kodak, Adobe often seems to suffer with over saturation and clipping. Maybe its Kodak owning its own icc maybe its just my SDR display on the iMac.
Interested to get anyone else's take on it.
• We discard the CMYK output intent of incoming files and Apply a CMYK Target Profile to the database “F39_v1.icc” (Kodak’s take on “Fogra39”). Typically, the creator of the PDF (our customer) embeds the profile that matches their CMYK standard workspace, if they ask I’ll suggest they use Fogra 39 or Fogra 51 even if we are printing on uncoated, in general they don’t ask.
• We usually discard all embedded CMYK profiles (somewhat controversial, perhaps) but this approach has significantly reduced errors and complaints. Previously, handling tagged CMYK objects (such as line art and images) in different ways could introduce inconsistencies. Of course, we make exceptions: if a customer submits a coffee table photobook in SWOP CMYK, we will reach out, and in specific cases, we honor embedded CMYK profiles. 100% agree, converting is worse than assigning unless you use DeviceLink. Reaching out to someone who might care is best approach.
• Unwanted spot colors are converted by automatically mapping color names to their Pantone V3 Lab values (as an alternate color space) As defined in a Factory Library inside Prinergy. The Lab values are then converted to “F39_v1.icc” (I don’t have any control over Intent of this conversion). If a spot color name isn’t found in Pantone V3, I can choose PANTONE-V4 M1, or I can custom Define the alternate color space, or I can use the alternate color space defined in the file. If the alternate color space is cmyk or DeviceRGB or ProfiledRGB then the conversion intent is Perceptual.
I have left V3 as the default because we have a lot of legacy files that repeat, and I want to convert these the same cmyk values.
Also if these files are printed Digital and they are not trying to use overprint or blend modes I’ll often leave Spot Colours in the print pdf for the Digital’s RIP to use its own PANTONE Library.
• All RGB content (respecting embedded profiles, using AdobeRGB1998 as fallback) is converted perceptually to Kodak’s “F39_v1.icc” CMYK (ignoring embedded rendering intent). From there, we have in house CMYK-to-CMYK to press fingerprinted targets to get uncoated print as close as we can to Fogra 51 inkjet proofs. (Customers really don’t like FOGRA 52 proofs. I really don’t like FOGRA 52 proofs and the results on press vary wildly because of the huge range of shades between uncoated stocks)
• Actually “All RGB content” is incorrect, we do a bit of Wide Format inkjet and if it comes in as Profiled RGB, that’s how it gets presented to the Fiery RIP sometimes if its mixed profiles I’ll convert All to AdobeRGB or eciRGB_V2, then manually set the RIP to target those.
I don’t think either yours or mine is Ghent PDF/X-4 test suite correct. I don’t think you can nail down “correct”
Leaving aside the “proprietary” conversions, we still would get different results with DeviceRGB just because you choose sRGB as fallback and I choose AdobeRGB1998.
We both get different results than the customer would get, if they converted direct in InDesign or Photoshop using Relative Colourimetric.
I hate it when a customer sends Proof pdfs in one color space then sends amended pdfs in another.
And then there is the “proprietary”, obviously I don’t know the pros and cons of your system but with mine I’d say Kodak’s conversions are sometimes better sometimes worse than Adobe’s (If I’d set Adobe to Perceptual) but mainly just a little bit different. One exception for me is a ProPhoto RGB.icc conversion always seems better with Kodak, Adobe often seems to suffer with over saturation and clipping. Maybe its Kodak owning its own icc maybe its just my SDR display on the iMac.
Interested to get anyone else's take on it.
Magnus
Well-known member
Interestingly, we have arrived at the same conclusions on many aspects.
Regarding our choice of sRGB as a fallback, our reasoning is as follows: A customer who "messes up" and submits untagged RGB images is likely not working with high-end print products. In such cases, it's more probable that the source of these images is sRGB rather than AdobeRGB. Additionally, if AdobeRGB is mistakenly assigned to an sRGB image, it results in oversaturation, most noticeably in warm skin tones. Conversely, if an sRGB profile is assigned to an AdobeRGB image, the worst outcome is a slight desaturation.
Yes, It would indeed be interesting to hear other peoples takes on this subject.
Regarding our choice of sRGB as a fallback, our reasoning is as follows: A customer who "messes up" and submits untagged RGB images is likely not working with high-end print products. In such cases, it's more probable that the source of these images is sRGB rather than AdobeRGB. Additionally, if AdobeRGB is mistakenly assigned to an sRGB image, it results in oversaturation, most noticeably in warm skin tones. Conversely, if an sRGB profile is assigned to an AdobeRGB image, the worst outcome is a slight desaturation.
Yes, It would indeed be interesting to hear other peoples takes on this subject.
repro_glenn
Member
Again 100% agree on your reasoning.
For the last 3 years I've set my Indesign Default RGB Working Space to sRGB. sRGB is the most likely for anything sourced from the internet, its the most likely for an out of camera JPEG (which for me was why I switched when I realised InDesign doesn't see it).
My reasoning for choosing AdobeRGB in the Prinergy setup
• Historic, that's how it was set up when I arrived, so again any legacy jobs that need converting again get converted the same.
• For our Litho and Digital we mainly print on uncoated, so we get a slight de-saturation, Perceptual conversions produce a slight desaturation and contrast (compared to Adobe Apps using Relative Colourimetric & BPC), so if sRGB is assigned to an AdobeRGB that's a third slight de-saturation.
For me I'd rather have slightly oversaturated than under, its only really skin tones that can't usually take it. If a job is mainly skin tones in Device RGB I'd probably have a conversation with the customer, and/or use Acrobat's Color Convert up front. I guess I'm fortunate to have the time.
For the last 3 years I've set my Indesign Default RGB Working Space to sRGB. sRGB is the most likely for anything sourced from the internet, its the most likely for an out of camera JPEG (which for me was why I switched when I realised InDesign doesn't see it).
My reasoning for choosing AdobeRGB in the Prinergy setup
• Historic, that's how it was set up when I arrived, so again any legacy jobs that need converting again get converted the same.
• For our Litho and Digital we mainly print on uncoated, so we get a slight de-saturation, Perceptual conversions produce a slight desaturation and contrast (compared to Adobe Apps using Relative Colourimetric & BPC), so if sRGB is assigned to an AdobeRGB that's a third slight de-saturation.
For me I'd rather have slightly oversaturated than under, its only really skin tones that can't usually take it. If a job is mainly skin tones in Device RGB I'd probably have a conversation with the customer, and/or use Acrobat's Color Convert up front. I guess I'm fortunate to have the time.
Similar threads
