This is not a new bug: In fact, it was already present in Lightroom 2. However, since it’s still unfixed in LR 3.5 I decided to put it on the blog anyway. Surprisingly few users know about the bug, so it might help someone.
If you are using the Local Adjustment Brush or Gradient tool in Lightroom 2 or 3 with any kind of exposure correction (even a negative value!), you might be in for a surprise: No matter where you brush, highlights will clip in the entire image.

Example

Here’s an image, straight out of the camera, Adobe defaults applied, except that I’ve set “Camera Neutral” as DNG profile. Note that parts of his temple are not quite blown.

Here’s the image after I applied a local adjustment of -0.32 exposure (Default “Burn” setting in LR3) to the lower left corner: Entire temple area blows out big time.

The Local Adjustment Brush didn’t even come near the face:

The workaround

… is actually quite simple: Do not adjust “exposure”, but use “brightness” instead in the Local Adjustment Brush.

Like this:

The final image, with added brightness as a local adjustment applied to the face:

Not unknown

Adobe is aware of the issue, but it’s taking them a very long time to fix: It was a known issue already in 2009. Let’s hope LR4 and ACR7 finally get this bug fixed…

Another old bug

The other bug (not a big issue in my opinion in LR3) is that in PV2003 the noise reduction is broken, possibly affecting the dark area’s on some images: If you apply any color noise reduction using PV2003, your black clipping will change. In some (very specific) cases this might leave you with “blotchy” blacks.

Before:

Same image, only difference is the setting of the Color Noise Reduction slider: It went from 0 to 10.

The solution

Easy: Don’t use PV2003. It sucks anyway compared to PV2010. Obviously, if you are using LR2, this might be another reason to upgrade to LR3.

Final image:

In my previous post, I wrote about Firefox 3.5 “better wait for version 3.5.1″
That version was released today, and I’m sorry to say, It still has its problems:
For one thing, it still doesn’t support ICC V4 profiles.
For another, by default it color manages like Safari does: Wonky: Only images with embedded profile are managed. So you could get problems as described on this page: The image looks different from the background.
On my Mac, it didn’t. What the heck? I hadn’t changed it from the default setting…
No matter what I set in the “gfx.color_management.mode”, it looked like the thing kept managing everything (except when setting “0″ off course). No way to get the images on that page to look different from the background. “Here be dragons” indeed.

But wait, there’s more

The background looked different from the background of the same page opened in (fully colormanaged) Flock 2.5. In fact, the background looks like the page opened in Safari. Yet there was no change on the images with and without profile. Another “what the heck”? I’d already checked that images with embedded profile were color managed…
At first I thought that FF 3.5.1 might be doing a perceptual rendering for screen. That would explain why for instance on my laptop the image I used in the previous post doesn’t clip in FF3.5.1, but clips like mad in Flock 2.5. It should clip; it’s way out of the laptops gamut. However, a perceptual rendering should not be possible from an sRGB V2 profile, and even if it were, it would probably be visible on series of the same image with different color spaces: the Perceptual rendering would be different for each color space… Yet the tagged images here all looked the same. (And all undersaturated)

What’s going on then?

Then I found out (using the OSX DigitalColor Meter) that the image in FF3 measured the exact value of the sRGB original in Photoshops info palette. So here’s what I think was happening:
FF 3.5.1 converts tagged images (so that part is color managed), then doesn’t use the monitor profile (byebye color management). Manually setting the correct display profile didn’t help either.

Cause of the problem

Since it looked like the problem was related to my Monitor Profile, I tried calibrating anew. Bingo! FF 3.5.1 does work as expected as long as I create a “standard” (Matrix based) monitor profile: My previous profile was created using the setting “Create Table-Based (3D) Profile” of my Monaco Optix XR-Pro software, since that gave more accurate results… No idea why FF 3.5.1 won’t use it. This is a V2 profile as far as I know.
Needless to say, there’s a bug report on the way…

In my previous blog post about the subject, I mentioned a workaround for the bug, and also said I didn’t like the idea of converting to GenericRGB somewhere in the process since it might clip colors…

Gave it a quick try today, and yeah, it does clip “somewhat”…

Same image as last time. Original is AdobeRGB. In this image, some purples and dark blues are out of gamut for the R2880, using Epson Premium Glossy paper. Admittedly, not your “average” color palette, but one that does show problems if they are there.

Softproofed

Let’s start by showing the original converted to sRGB;
(again: all screenshots converted to sRGB for web display)

Nice and colorful. Not that big a difference from the AdobeRGB original. (It’s only slightly out of sRGB gamut in the shadow areas.)

When softproofing for the Epson Glossy Paper profile, you see a difference, but about what’s expected. Purples turn a bit blue-ish. Not a huge problem in this case I’d say. Not worth a screenshot. If it were a problem, I’d correct it while softproofing.

Okay, so far so good.

Now apply the workaround: Convert to the paper profile. No change obviously, since I was already softproofing. Then assign Generic RGB. Totally whacked colors. Also to be expected and also not worth a screenshot.

If the workaround were without drawbacks, the image would be sent to the printer and be converted from paper profile to GenericRGB somewhere along the lines. But since we  “compensated” for that by assigning the GenericRGB profile beforehand, you’d expect the results to be the same: The printer gets the right “numbers” sent… But are the numbers the same?

Timeline, step by step.

This is what the image goes through:

1. Open original in PSCS4. Softproof & edit as needed
2. Convert to printer profile (workaround step 1)
3. Assign GenericRGB (workaround step 2)
4. Press “print” in PSCS4
5. Convert to printer profile (by PSCS4s print engine)
6. Convert to GenericRGB (done by OSX because of this bug)
7. Assume printer profile. (by the R2880, because it knows nothing about color management, and just prints the data it gets)

The problem lies in step 6: (For those interested: It’s easily reproducible by doing the same steps manually in Photoshop.)

The image after step 5 is massively out of the GenericRGB gamut, as shown here:
The funky colors are the result of assigning GenericRGB in step 3 obviously.

This results in clipping. Big time.

The result…

…is a print that is way less saturated then it should have been: Top left would be like printed from PSCS4 using the “workaround”, bottom right is the print that PSCS2 would produce:

I hope that this bug gets fixed pronto. I know I’ll keep using PSCS2 for printing in the meantime… Which sucks is a bit of a drawback quite frankly.
(Again: Apple and Epson: Are you reading this?)

When testing my Epson R2880 on PSCS4, it was quite obvious that something was off; The print came out looking nothing like the softproof on screen.

To give an indication of what it looked like: Here is a splitscreen: Top left is the softproofed image, bottom right is what the print looked like:
(screenshot converted to sRGB for web display: The difference is bigger in print)

The same image printed from PSCS2 was a perfect match to the softproof. Very weird.
I remembered that another photographer had complained to me about similar issues, and showed me some pdf files in preview. (In OSX you can preview a print as pdf file in Preview).

So I tried that. What a surprise: pdf generated when printing from PSCS2 was entirely different from the one using PSCS4. Same printer driver, same settings in Photoshop, same everything.
Neither of the pdfs looked even remotely like the respective prints by the way. The PSCS4 pdf looked like the softproof (as did the PSCS2 print).

Getting weirder by the minute.

A search on the net only brought up a “Double profiling” issue in OSX 10.5.something. Not what I was experiencing. Also, I’m running 10.4.11.

So, I decided to investigate further.
The pdf generated when printing from PSCS2, has an AdobeRGB1998 profile embedded. No idea why, since it is obvious the wrong profile (should be the paper specific profile for the R2880 I’d think, but that also isn’t the case)
Even weirder, the PSCS4 pdf, had a GenericRGB profile. What? Why on earth… That one has an even slightly smaller gamut then sRGB as far as I know…

Workaround

Some messing about testing with profiles followed.
It turned out that converting the PSCS2 pdf to GenericRGB, then assigning the paper profile, gave two identical images (easier to compare that way around, since the pdf coming out of the PSCS2 print path was very saturated and weird looking because of the wrong profile). Both were now again looking like the softproof in Photoshop.
So, doing the reverse (Convert to paper profile, assign GenericRGB) should give a decent print out of PSCS4. (at least, looking at the pdf. Haven’t wasted any paper on it yet).

So far for a workaround, now for the explanation…

Including “GenericRGB” in the search term proved to be a good idea. On the Adobe Forums I found a thread about grayscale printing (no wonder I hadn’t found it earlier).
In that thread Eric Chan explains how OSX Leopard will convert the image data to Generic Gray or Generic RGB before handing it off to the driver. So, yeah. That’s likely to screw things up…
I’m still not sure why or where the PDF out of PSCS2 gets an AdobeRGB profile. Seems rather silly if you ask me.

I might use the workaround when in PSCS4, or print from PSCS2 until this issue gets fixed… I think I’ll mostly use the latter, since I don’t like the idea of converting to GenericRGB somewhere in the process; it might clip colors without me having any control…
Have to compare a few prints, to see if there are differences.

Edit: The workaround does have its drawbacks: See my next blog post.

(Apple and Epson: Are you reading this?)