Dan Margulis Applied Color Theory

Correcting Skies

   Date: Thu, 3 Nov 2005 08:49:48 -0800
   From: David Cardinal
Subject: RE: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

In terms of 8-bit vs. 16-bit, the one area I'm personally most curious about is skies. I don't fully understand all the interactions between initial bit depth, some of the processing I might do (like with PixelGenius burn effect), printer profiles, and driver/RIP, but I do know that for my photography (mostly nature & wildlife) skies can be much more challenging than I initially expected.

I'd be delighted to hear others results in this area.

In my case I've found skies (when reproduced in large prints in particular) to be a valuable yardstick for evaluating printer profiles and profiling solutions. None of the scanner based profile creation systems did that great a job (this is with an Epson 4000 and various papers), while both ProfileMaker and the profiles available with ImagePrint have done much better. I'm getting a copy of PrintFix Pro to evaluate next, as I'd love to be able to recommend a solution to my readers that was less expensive than ProfileMaker + Eye-One.

--David Cardinal
___________________________________________________________________________

   Date: Thu, 3 Nov 2005 21:52:36 EST
   From: Dan Margulis
Subject: Re: Skies (was 16-bit v. 8-bit)

Skies are a sui generis kind of problem for two basic reasons. First, a lot of digicams present us with a lot more noise in the red channel than there has any business being. Second, a lot of machine-generated profiling fails because the profiling package is trying to minimize delta-E (the equation it uses to try to compare the difference between desired and actual output), and in a lot of skies, particularly those of pure color, we get a closer visual match with a *higher* delta-E.

Processing skies is pretty easy if you just remember that the key channels are the red of RGB and the B of LAB. The red always has the heaviest sky; the B usually has the sky completely isolated so that if you need to attack the sky only it's easy to do.

There are three bread and butter moves.

A. If the sky is too weak, or if you want to emphasize the cloud patterns:
     1. In RGB, make duplicate layer.
     2. Image: Apply Image, source red channel, mode Darken, opacity 100%.
     3. Change layer mode to Luminosity.
     4. Adjust layer opacity to taste.

B. If you don't like the color of the sky, use LAB curves to change it. Usually the sky is so far away from anything else that it's easy to do.

C. If the sky is too noisy:
    1. In LAB, make duplicate layer.
    2. Filter>Blur>Surface Blur; good sky settings are Radius 3 Threshold 6;
    3. In Layer Blending Options, go to the Blend If slider, B channel, Underlying Layer
    4. Bring the RH slider slightly to the left of the midpoint, split it by holding down the Option key, and move its left half very slightly further to the left.
    5. Adjust layer opacity to taste.

Naturally if undesired areas are affected by any of these moves, they can be roped out pretty easily with a layer mask.

Dan Margulis
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 08:59:50 -0500
   From: "Mark Segal"
Subject: Re: Skies (was 16-bit v. 8-bit)

Dan,

Many thanks for posting this useful advice. It may well come in handy for many of us.

Speaking of blue, I just installed a new Epson 4800, and using the Epson supplied profile for their Enhanced Matte paper using Matte Black Ink, both the soft proofing and the printed result show that magenta and blue are coming out as light purple and darker purple respectively. (This effect is not immediately evident in photographs, but it shows very clearly on the pure color bands of the Gretag-McBeth printer test page - you know, the one with the bands, the landscape, the lady and an umbrella, etc.) By the way, the Epson 4000 behaved the same way. I can't understand why this happens. Have you (or other Group members) seen it, understand it?

Mark Segal
___________________________________________________________________________

   Date: Fri, 04 Nov 2005 10:01:29 -0500
   From: Jim Rich
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark,

Have you considered it might not be the printer and the printer profile?

It might be on the capture side.

Jim Rich
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 11:08:18 -0500 (EST)
   From: MARK SEGAL
Subject: Re: Skies (was 16-bit v. 8-bit)

Jim,
 
No, I didn't think capture is a relevant consideration in this case, because the file being printed is a printer test file with RGB values at the strongest end of the blue scale being B 250, R 0 and G 0. Unless there is something else I am unaware of, it seems there could be a profile problem, but that too puzzles me because Epson put a great deal of effort into creating good profiles for these professional machines.
 
Mark Segal
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 11:51:02 EST
   From: Dan Margulis
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark writes,

Speaking of blue, I just installed a new Epson 4800, and using the Epson
supplied profile for their Enhanced Matte paper using Matte Black Ink, both the
soft proofing and the printed result show that magenta and blue are coming out
as light purple and darker purple respectively. (This effect is not
immediately evident in photographs, but it shows very clearly on the pure color bands
of the Gretag-McBeth printer test page - you know, the one with the bands, the
landscape, the lady and an umbrella, etc.) By the way, the Epson 4000 behaved
the same way. I can't understand why this happens. Have you (or other Group
members) seen it, understand it?

This blue-vs.-purple problem has come up several times on the list and there are archived articles at
http: //www.ledet.com/margulis/ACT_postings/SeparationIssues/Separation.htm

I discuss the issue somewhat in Chapter 13 of the LAB book. The problem of having rich blues go purple is generic to most machine-generated profiles, such as the SWOP v.2 CMYK profile in Photoshop, or the Epson profiles you mention.

The reason it occurs is that the machine is attempting to make the best match it can to what is desired. Being a machine, it can't simply look at the two colors and decide whether they're close enough, like we can. It has to analyze numbers. It works in LAB, and compares the numbers it would like to get with what it actually can achieve. Ideally, at least in the mind of the machine, there should be only a slight difference, or possibly a zero difference. If there *is* a difference, then it figures out how different the two L's, the two A's, and the two B's are. It mixes those three differences together with a complicated formula and spits out a result called delta-E, which it uses to evaluate how close the colors are. The lower the delta-E, the better--at least in the mind of the machine.

The problem is that delta-E is hopelessly crude, because we humans assign different importances to the L,A, and B channels depending on what color is being portrayed and how dark it is. It's worthless in trying to evaluate whether a profile as a whole is any good--its only value is that a machine has to start somewhere, and this way can get reasonably close to what's wanted without human intervention--except in areas that the output device is going to have trouble reproducing, which are typically blues and very saturated greens.

The file comes in calling for a blue that's too vivid for the output device to match. A human says that if we can't get that vivid of a blue, let's go for one that isn't so vivid. A machine says that the B (yellow vs. blue) is supposed to be very negative and we can't do it, so we make it as negative as we can, but the A (magenta vs. green) is supposed to be slightly positive and that's not a problem.

So says the machine. A human speaking LABtalk would say, no. If the B has to be made less negative then we have to make the A less positive, too, otherwise the blue will seem to purple. The machine disagrees, because if it changes the A value then delta-E goes up, and the machine wants to keep it low, because it doesn't realize that in this particular case, the higher delta-E is a better match.

Dan Margulis
___________________________________________________________________________

   Date: Fri, 04 Nov 2005 11:45:43 -0500
   From: Jim Rich
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark,

This was just an guess. It seems suspect that two printers would give you
the same exact banding problem. And I just spent a few days with a problem
like this at a client and it was a broken scanner.

Another place to check the file is to send it to another printer  such to
see if the banding happens again. If it does, this might be a broken file.

Good luck

Jim Rich
___________________________________________________________________________

   Date: Fri, 04 Nov 2005 12:00:20 -0400
   From: Lee Clawson
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark,

This is a long shot but I did see the same thing (years ago) on an HP inkjet. The magenta inks could vary in hue. One batch that was fine and then it would be bluer in other batches. See if you can find older test pages and inspect the solid M.

Lee Clawson
2/\V/\7 Studio
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 14:30:58 -0500 (EST)
   From: MARK SEGAL
Subject: Re: Skies (was 16-bit v. 8-bit)

Dan,
 
Thank you very much for the explanation of what may be happening. Do you have any recommendations about how to fix it? (I suspect - given how these Epson machines are individually hand-calibrated to a common standard - that ordering custom profiles probably won't help much - though no harm trying. Another option that occurred to me is that when the problem actually looks obnoxious in a soft proof of a real photograph, to adjust the blue using LAB or RGB curves in soft proof mode.)
 
Mark Segal
___________________________________________________________________________

   Date: Fri, 04 Nov 2005 13:22:35 -0700
   From: Andrew Rodney
Subject: Re: Skies (was 16-bit v. 8-bit)

A good custom profile will help a great deal (depending on the package used). Some profile packages suffer this blue shifting to magenta issue. Ixve seen this with canned profiles supplied by both Epson and to a lesser degree but still present, from ImagePrint supplied profiles. Thatxs why I roll my own. Ixve found that profiles generated using ProfileMaker Pro do an excellent job of addressing this issue. You should also see the shift in a good soft proof assuming the output profile preview tables and your display profile are sound. At that point you can decide while viewing a soft proof the best way to edit the values in the file prior to conversion to the output space. You should also play around with rendering intents (Perceptual versus Relative Colorimetric and even Saturation).

Andrew Rodney
___________________________________________________________________________

   Date: Fri, 04 Nov 2005 20:39:43 -0000
   From: "Louis Dina"
Subject: Re: Skies (was 16-bit v. 8-bit)

I use custom profiles and the Epson driver with my 2200 and 4000.  I haven't seen any problems with my blues tilting to magenta.  My soft proofs are usually a very close match to what I get off the printer (when viewed under 5000K lighting).  I found that calibrating my monitor to 5000K gives me the best monitor to print match.  

I did have a blue/magenta problem, however, with ImagePrint RIP, but not with the Epson driver.  

Lou Dina
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 13:09:41 -0700
   From: Chris Murphy
Subject: Delta E, was: Skies (was 16-bit v. 8-bit)

On Nov 4, 2005, at 9:51 AM, Dan Margulis wrote:

The problem is that delta-E is hopelessly crude, because we humans assign
different importances to the L,A, and B channels depending on what color is being portrayed and how dark it is.

There are a couple of problems. The real problem is with LAB, not Delta E. LAB predicts things that don't actually happen.

Second, there is more than one delta-E. Typically the term "delta-E" refers to the original, delta-E 76. (Mathematically 76 is subscripted). There is also 94, cmc, and 00. Each one is an improvement in accurately predicting the visual difference, but comes with increasing complexity. 00 is a multipart equation comprised of about 25 separate computations. The point being that it takes into account the known problems with LAB, and weighs certain color differences heavier than others. Humans are sensitive to blues, something LAB doesn't do a great job of predicted, and hence small delta-E 1976 values translate into large visual differences, whereas delta E 2000 will  result in a much higher value that corresponds better to what we see.

There is still improvement to be made on Delta E 2000.

The file comes in calling for a blue that's too vivid for the output device
to match. A human says that if we can't get that vivid of a blue, let's go for
one that isn't so vivid. A machine says that the B (yellow vs. blue) is
supposed to be very negative and we can't do it, so we make it as negative as we
can, but the A (magenta vs. green) is supposed to be slightly positive and that's
not a problem.

That's overly simplistic and in practice doesn't actually happen with any ICC profiles build with packages in the last 5 or so years. The problems with LAB are well known and while the color mapping schemes still are by far not perfect, they aren't making obviously bad decisions like your description implies. Delta E 76 has long ago gone the way of the Do Do bird with respect to gamut mapping. That it continues to be cited as a goal post in color matching today is nothing short of perverse.

I use Delta E 1976 on occasion because the formula is simple algebra and I can plug it into an Excel spreadsheet or simple scientific calculator from memory, and it's useful to have an idea of the numeric distances when determining of two data sets from the same device have a reasonable discrepancy or if there is some sort of problem with consistency going on. But to actually compare a proof and a press sheet using delta E 1976 is not something I'd recommend. In fact it's probably misleading to do so. It will invariably overestimate differences in colors like yellow and green and consistently underestimate differences in blues, achromatic colors (near neutrals) and pastels.

I've called for stamping out the use of delta E 1976 for a while now, except when doing quick and dirty (and geeky) comparisons of data sets in a statistical context rather than a color evaluation context.

So says the machine. A human speaking LABtalk would say, no. If the B has to
be made less negative then we have to make the A less positive, too, otherwise
the blue will seem to purple. The machine disagrees, because if it changes
the A value then delta-E goes up, and the machine wants to keep it low, because
it doesn't realize that in this particular case, the higher delta-E is a
better match.

An often overlooked factor with blues shifting to purple in print when not predicted by the profile is a change in wet trap behavior on press compared to the behavior at the time the profile was produced. Wet trap will make a big difference in what CM ratio makes blue.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Fri, 4 Nov 2005 15:35:07 -0700
   From: Ron Kelly
Subject: Re: Delta E, was: Skies (was 16-bit v. 8-bit)

Right. This happens to me a lot.

I build my skies and water a bit on the cyan side but it is often not enough and I STILL get purples where I want deep blue.

Is there something about a  heavy cyan area that draws out more magenta ink than would be there if the same magenta plate had no cyan? Could this be affected by the order of printing?

I've discussed this with my printer but even though I consider them excellent generally they either won't tell me or don't know.

If it's a known situation, why isn't it possible to fix it?

'Dem purples is givin me the blues.

Ron Kelly
___________________________________________________________________________

   Date: Sat, 5 Nov 2005 11:58:28 +0000
   From: Andrew Haley
Subject: Re: Skies (was 16-bit v. 8-bit)

MARK SEGAL writes:
 
 Thank you very much for the explanation of what may be
 happening. Do you have any recommendations about how to fix it? (I
 suspect - given how these Epson machines are individually
 hand-calibrated to a common standard - that ordering custom
 profiles probably won't help much - though no harm trying. Another
 option that occurred to me is that when the problem actually looks
 obnoxious in a soft proof of a real photograph, to adjust the blue
 using LAB or RGB curves in soft proof mode.)

Can you tell us the Lab value of some of the colours you're trying to print?  I'd like to try the exercise on my Epson 7600 with custom profiles.  I'll report back.

Andrew.
___________________________________________________________________________

   Date: Mon, 07 Nov 2005 07:31:57 -0000
   From: "dmargulisnj"
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark Segal writes,

Dan, Thank you very much for the explanation of what may be happening.
Do you have any recommendations about how to fix it? (I suspect - given how
these Epson machines are individually hand-calibrated to a common
standard - that ordering custom profiles probably won't help much - though no
harm trying. Another option that occurred to me is that when the problem
actually looks obnoxious in a soft proof of a real photograph, to adjust the
blue using LAB or RGB curves in soft proof mode.)

Even supposing that a profile exists that will solve this particular problem it will simply substitute another in its place, that of differentiating duller blues from purer ones. So eventually you will need at least two methods to approach the Epson, just as you would need several methods to separate images with critical blues for press.

I would suggest experimenting with a couple of images with the Hue/Saturation command. The range of blues you wish to affect can be defined quite precisely, and then you can reduce saturation plus move hue away from magenta and toward cyan. If this turns out to be successful, you can save the setting and apply it to other images that have the same problem, and if that seems to work you can think about ordering up a second profile. But I find that batching up several commands as an Action without ever formally converting the file often gives better results than blind reliance on a profile.

Dan Margulis
___________________________________________________________________________

   Date: Mon, 7 Nov 2005 15:59:18 -0500 (EST)
   From: MARK SEGAL
Subject: Re: Skies (was 16-bit v. 8-bit)

Dan and John,
 
Thanks for these helpful suggestions I shall try them.
 
Mark Segal
___________________________________________________________________________

   Date: Wed, 9 Nov 2005 16:10:41 -0700
   From: Chris Murphy
Subject: ICC v4, was: Skies

The biggest reason why blues shift to purple is a problem at this point is not that the output profile is built incorrectly. While that remains a distinct possibility, the problem is a function of output profiles having a one-size-fits-all rendering. The gamut mapping is performed at the time the output profile is built, therefore it tries to do the best job it can with all source profiles, and this causes problems with all of them to varying degrees.

The solution the ICC has developed is largely in place now, but is missing one critical component.
v4 editing spaces. Once we have v4 ICC profiles for sRGB, ColorMatch RGB, Adobe RGB (1998), ProPhoto RGB, etc, there will be not only a colorimetric table but also a perceptual table. This will be used with the perceptual intent to compress images into an reference output medium which has largely been defined by the ICC. Next, v4 output profiles then have the same basis from which to predicate gamut compression on for the perceptual intent. Currently perceptual rendering can do a better job with respect to hue accuracy, but overcompensates gamut compression for a lot of colors. Plus there is no invertability, which is also possible in a v4 workflow.

So there's no exact date when the most common edit spaces will be available as v4 versions but it's looking like sometime in 2006. I suspect around then we should also see v4 output profiles from Adobe as well. We're about to see perceptual rendering take a monumental leap forward (finally).

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Wed, 9 Nov 2005 22:20:38 -0500
   From: "Mark Segal"
Subject: Re: Skies (was 16-bit v. 8-bit)

Andrew Haley,

Sorry for not replying sooner. I've been out of the country since you made this request and am only back this evening. The more intense portion of the blue bar is at or above L30, A66, B100+.

Mark Segal
___________________________________________________________________________

   Date: Thu, 10 Nov 2005 12:35:05 +0000
   From: "Andrew Haley"
Subject: Re: Skies (was 16-bit v. 8-bit)

Mark Segal writes:
 
Sorry for not replying sooner. I've been out of the country since
you made this request and am only back this evening. The more
intense portion of the blue bar is at or above L30, A66, B100+.

Are you sure about that?  I'm guessing that you mean 30, -66, -100. That would get you a rich blue, but it's outside monitor gamut.

Anyway, if 30, -66, -100 is what you mean, then my Epson 7600 custom profile made with GMB software produces a very different result with perceptual rendering:

  Custom profile:        44, -34, -56
  Epson canned profile:  30, -20, -51

But this colour is so far out of gamut that it probably requires tweaking by hand.

Andrew.
___________________________________________________________________________

   Date: Thu, 10 Nov 2005 14:00:58 -0500
   From: "Mark Segal"
Subject: Re: Skies (was 16-bit v. 8-bit)

Andrew,

Yes, thanks, I forgot to put in the correct signs. I think this may be the problem - the colours that don't get handled properly are way out of gamut and therefore most likely require hand-tweaking of the kind you and Dan suggested.

Mark Segal