Issues related with the switch from FOGRA39/47 to FOGRA51/52
Dear Colleagues, It all started with a question raised by Mr. Martin Orpen in his mail dated 22.08.2018 on the colorsync-users list. There was then almost a week long discussion with an open end.
From that point on, I have made several conversions using FOGRA39, FOGRA47, FOGRA51 and FOGRA52 based profiles. At some point I have started generating profiles with the FOGRA51 and FOGRA52 datasets in multiple profiling software applications with different settings to have a better understanding on what is going on.
Mr. Orpen’s original complaint was the lack of yellow in skin tones with conversions made with PSO Coated v3. But when I started doing conversions using this profile, I have ended seeing that that deficiency ih yellow is widespread. Furthermore, what was true for FOGRA51 was also true for FOGRA52-based profiles. To simplify the matter, I have created a Photoshop file in L*a*b* color mode that contained a linear gradient from L*=0 – a*=0 – b*=0 to L*=100 – a*=0 – b*=0. I have placed 10 color sampler points to L*= 5, 15, 25, 35, 45, 55, 65, 75, 85 and 95, to keep track of their changes. I then converted this file into “eciRGB v2” color space. The RGB values at these points came out to be R=G=B=13, 37, 64, 90, 114, 140, 165, 190, 216 and 242, respectively. Starting with this neutral gray RGB gradient, I have done (relative colorimetric with black point compensation) conversions into FOGRA39 using ISO Coated v2 (ECI), into FOGRA51 using PSO Coated v3, into FOGRA47 using PSO Uncoated 12647 (ECI) and into FOGRA52 using PSO Uncoated v3. Below are the CMYK percentages for each of the 10 spots. FOGRA39 conversion: #01 / L*=05 a*=0 b*=0 / C=81 M=72 Y=65 K=85 #02 / L*=15 a*=0 b*=0 / C=75 M=65 Y=61 K=73 #03 / L*=25 a*=0 b*=0 / C=67 M=57 Y=55 K=58 #04 / L*=35 a*=0 b*=0 / C=60 M=50 Y=49 K=44 #05 / L*=45 a*=0 b*=0 / C=53 M=44 Y=43 K=33 #06 / L*=55 a*=0 b*=0 / C=46 M=37 Y=36 K=22 #07 / L*=65 a*=0 b*=0 / C=38 M=29 Y=30 K=13 #08 / L*=75 a*=0 b*=0 / C=29 M=22 Y=23 K=06 #09 / L*=85 a*=0 b*=0 / C=19 M=13 Y=13 K=02 #10 / L*=95 a*=0 b*=0 / C=07 M=05 Y=05 K=00 FOGRA51 conversion: #01 / L*=05 a*=0 b*=0 / C=75 M=63 Y=50 K=89 #02 / L*=15 a*=0 b*=0 / C=67 M=57 Y=47 K=77 #03 / L*=25 a*=0 b*=0 / C=61 M=51 Y=44 K=62 #04 / L*=35 a*=0 b*=0 / C=55 M=46 Y=40 K=48 #05 / L*=45 a*=0 b*=0 / C=50 M=42 Y=37 K=35 #06 / L*=55 a*=0 b*=0 / C=43 M=35 Y=32 K=22 #07 / L*=65 a*=0 b*=0 / C=36 M=28 Y=26 K=12 #08 / L*=75 a*=0 b*=0 / C=27 M=21 Y=20 K=05 #09 / L*=85 a*=0 b*=0 / C=18 M=13 Y=13 K=01 #10 / L*=95 a*=0 b*=0 / C=06 M=05 Y=04 K=00 As you can see, the same color is converted into a different C-M-Y balance as the L* value goes lower with the FOGRA51 conversion. On the other hand, the C-M-Y balance is kept steady till the very dark shadows in FOGRA39. As the CMYK primaries are pretty much the same on both sides and the TVI curves, though different by about 1.7%, have the same C-M-Y balance, I cannot see any reason for the drop in Y as we go down the L* axis. The situation is almost the same with FOGRA47 and FOGRA52. FOGRA47 conversion: #01 / L*=05 a*=0 b*=0 / C=81 M=62 Y=54 K=90 #02 / L*=15 a*=0 b*=0 / C=75 M=59 Y=52 K=80 #03 / L*=25 a*=0 b*=0 / C=65 M=53 Y=47 K=64 #04 / L*=35 a*=0 b*=0 / C=58 M=48 Y=44 K=46 #05 / L*=45 a*=0 b*=0 / C=49 M=40 Y=36 K=36 #06 / L*=55 a*=0 b*=0 / C=38 M=30 Y=28 K=27 #07 / L*=65 a*=0 b*=0 / C=29 M=21 Y=20 K=20 #08 / L*=75 a*=0 b*=0 / C=20 M=15 Y=14 K=14 #09 / L*=85 a*=0 b*=0 / C=12 M=08 Y=08 K=08 #10 / L*=95 a*=0 b*=0 / C=04 M=03 Y=03 K=02 FOGRA52 conversion: #01 / L*=05 a*=0 b*=0 / C=85 M=62 Y=42 K=88 #02 / L*=15 a*=0 b*=0 / C=76 M=58 Y=43 K=78 #03 / L*=25 a*=0 b*=0 / C=66 M=54 Y=39 K=61 #04 / L*=35 a*=0 b*=0 / C=58 M=47 Y=36 K=43 #05 / L*=45 a*=0 b*=0 / C=49 M=40 Y=33 K=28 #06 / L*=55 a*=0 b*=0 / C=40 M=32 Y=28 K=16 #07 / L*=65 a*=0 b*=0 / C=33 M=25 Y=22 K=08 #08 / L*=75 a*=0 b*=0 / C=24 M=17 Y=16 K=03 #09 / L*=85 a*=0 b*=0 / C=15 M=10 Y=10 K=01 #10 / L*=95 a*=0 b*=0 / C=05 M=03 Y=03 K=00 To approach the situation from another angle, I have also converted the same neutral gray RGB file into GRACoL2006 and GRACoL 2013 to see have how they perform under the same conditions. Here are the results: GRACoL2006_Coated1v2 conversion: #01 / L*=05 a*=0 b*=0 / C=83 M=75 Y=71 K=87 #02 / L*=15 a*=0 b*=0 / C=80 M=73 Y=70 K=69 #03 / L*=25 a*=0 b*=0 / C=73 M=65 Y=64 K=49 #04 / L*=35 a*=0 b*=0 / C=64 M=55 Y=55 K=34 #05 / L*=45 a*=0 b*=0 / C=56 M=47 Y=47 K=23 #06 / L*=55 a*=0 b*=0 / C=49 M=40 Y=40 K=12 #07 / L*=65 a*=0 b*=0 / C=41 M=32 Y=33 K=04 #08 / L*=75 a*=0 b*=0 / C=31 M=24 Y=24 K=00 #09 / L*=85 a*=0 b*=0 / C=19 M=13 Y=14 K=00 #10 / L*=95 a*=0 b*=0 / C=06 M=04 Y=05 K=00 GRACoL20013_CRPC6 conversion: #01 / L*=05 a*=0 b*=0 / C=80 M=71 Y=62 K=90 #02 / L*=15 a*=0 b*=0 / C=75 M=67 Y=62 K=75 #03 / L*=25 a*=0 b*=0 / C=69 M=60 Y=57 K=55 #04 / L*=35 a*=0 b*=0 / C=62 M=53 Y=51 K=38 #05 / L*=45 a*=0 b*=0 / C=55 M=46 Y=44 K=25 #06 / L*=55 a*=0 b*=0 / C=46 M=38 Y=37 K=16 #07 / L*=65 a*=0 b*=0 / C=39 M=30 Y=29 K=07 #08 / L*=75 a*=0 b*=0 / C=30 M=23 Y=22 K=02 #09 / L*=85 a*=0 b*=0 / C=18 M=13 Y=13 K=00 #10 / L*=95 a*=0 b*=0 / C=06 M=04 Y=04 K=00 Although the paper white of GRACoL2013 is now in line with 12647-2:2013, it does separate RGB into a C-M-Y balance very similar to GRACoL2006. Extreme loss of yellow ink in areas mid-tone and upwards has many negative side effects. Rich blacks are bluish/purplish and many clients do not like that. Yellow ink typically prints last for a good reason. It contains varnishes that give the image extra gloss and rub resistance. It is also the least tacky of the inks. Hence, by reducing its amount in the separation causes even less yellow ink being transferred to paper. Wet on wet printing sometimes requires more of the final ink to be properly transferred not less. To get round this problem I have tried recalculating the profiles to get some gray axis correction when converting with perceptual rendering intent. The old ProfileMaker v5, CoPrA v4 and Color Toolbox v18 (with incremental control) all have the tools to compensate for the color of paper. Interestingly this feature does help in the highlight to mid-tone range but not in the mid-tone to shadow range. On a recent occasion, I have also witnessed the fact that inkjet contract proofs are not good in simulating the inherent shift towards blue/purple in the shadows. What may appear as a neutral shadow on a certified proof is printed with a blue/purple cast, which may not be visually acceptable the client. This problem needs to be addressed. Doing a conversion in Photoshop using a relative colorimetric or a perceptual rendering intent is quite misleading without switching on the Proof Color View with paper white simulation. You can only see the overall loss of yellow when you activate soft proofing. Given that Photoshop still leaves much to be desired in terms of soft proofing, especially with uncoated papers, you can only use verified/certified inkjet proofs to see the actual result of your RGB to CMYK conversion. While FOGRA39 and FOGRA47 do share an imaginary paper white (95,0,2), being close to a*=0 + b*=0, the conversions made by both profiles maintain some kind of paper relative neutrality. Even if the paper white simulated absolute colorimetric proofs are not precisely matching any real print substrate, we had over the years developed chromatic adaptation skills that would bridge the gap. While the prepress process is rather smooth with FOGRA39, bridging the gap between the contract proof and the real substrate has always been the problematic side. But with FOGRA51 (and as a matter of fact, for the same reason, with FOGRA52) prepress and proofing needs heavy tweaking after RGB to CMYK conversion to introduce some of the lost yellow back to the scene. If not done properly, a proof to print match is tricky especially if you have heavy areas in the image. Hence, the process as a whole became problematic. Dear colleagues, I invite you to shed some light on this in mystery. Best regards, Refik Telhan, EE B.Sc. Light and Color Management Consultancy Aydogdu Sokak 12A, Tarabya Mahallesi Sariyer, 34457, Istanbul, Turkey e-Mail: rtelhan@icloud.com Mobile: + (90) (532) 426 21 87 P.S. The following link will let you download a PDF that contains screen shots of the above conversions. There are also four screen shots from the interface of CoPra 5, showing that the problem is related with the measurement data sets and not with the profiles calculated by Color Toolbox. https://www.dropbox.com/s/vqdjezncf8l60cq/FOGRA_Conversions.pdf?dl=0
Refik Telhan wrote:
Dear colleagues, I invite you to shed some light on this in mystery.
Perhaps you can better explain your workflow assumptions in making use of the FOGRA profiles. A basic property of profiles is that they are only as good as far as they accurately describe the printing process they purport to be for. As far as I can gather, you are taking a profile made by someone else (FOGRA) based on prints that they made with their paper, ink, printing press and measurement conditions, and applying it to your press, with your paper, ink, press setup and visual evaluation conditions, and reporting that it doesn't look very good. In a general sense, nothing unexpected is going on here - the profile doesn't match your output (or vice versa). It would seem to me that the only way this combination is likely to give satisfactory results is if you go to some trouble to make your press behave in a way that very closely mimics the way the FOGRA press was setup, and evaluate the prints in the same way they evaluate them (i.e. viewing booth spectra & UV content). The fact that you get poor results either means that your press and evaluation conditions don't match the ones the FOGRA profile is intended for, or that the FOGRA profile you are attempting to use is not appropriate for your conditions. As a profile making type person, my natural inclination would be to say "profile your press, and use that :-)", but it really comes down to what your intention is. If your intention is to run a press to FOGRA51 conditions so that customers can do separations using the standard FOGRA51 profile, then it seems you aren't currently hitting that mark with your press, or that your evaluation conditions differ markedly from the ones FOGRA51 uses, or that perhaps FOGRA51 press conditions are out of the range possible with your setup. Cheers, Graeme Gill.
On 12 Feb 2019, at 01:11, Graeme Gill <graeme2@argyllcms.com> wrote:
As a profile making type person, my natural inclination would be to say "profile your press, and use that :-)", but it really comes down to what your intention is. If your intention is to run a press to FOGRA51 conditions so that customers can do separations using the standard FOGRA51 profile, then it seems you aren't currently hitting that mark with your press, or that your evaluation conditions differ markedly from the ones FOGRA51 uses, or that perhaps FOGRA51 press conditions are out of the range possible with your setup.
Graeme Here’s an example of the problem: Using any data sets prior to 51 and 52 it was possible to make ICC profiles with different K generation and utilise them in prepress workflows them without the printed results looking any different to those separate using the generic profiles. So a black & white image using a max K FOGRA39 profile will proof identically to a standard conversion and print without grey balance issues. You cannot do this with the 51 and 52 data. If you build a profile in Argyll or i1Profiler from this data the results are terrible. There is no Yellow in the separations! The only workaround with Argyll for high GCR separations in 52 is to first convert using the ECI profile and then use a Device Link to generate the desired K ramp. There is no workaround with i1Profiler, it cannot produce an acceptable 52 profile. Even the generic ECI 52 profile produces results that our clients aren’t particularly happy with. The skin tone doesn’t have enough yellow. So we tend to use GMG’s ColorServer variant which does boost the Y. But, again, this causes more problems because it is easy to spot which images have been separated by which profile. Which means we are no longer able to fix problem images and then drop them seamlessly back into print workflows :( It’s a mess. -- Martin Orpen Idea Digital Imaging Ltd
participants (3)
-
Graeme Gill
-
Martin Orpen
-
Refik Telhan