This content has been marked as final. Show 26 replies
This is very likely a gamut problem. Try the shadow/highlight tools and they should show where the problem areas are in the image. If they are in color areas, you have your answer.
Which color space do you have selected? Generally, sRGB is the smallest, aRGB is slightly larger. If you change to ppRGB (temporarily at least), the problem may go away. Actually, the camera has a larger gamut than even ppRGB so I have seen a few cases where gamut problems are still present.
Just for diagnostics you can try reducing saturation. When you know what colors are giving you issues, you can fiddle with the selective HSL sliders. Assuming it is a gamut concern, there are numerous ways to deal with it in ACR or Photoshop.
Cheers, Rags :-)
Clipping a single channel in the deep shadows/blacks isn't really a big deal...as Rags says, it's more likely a gamut clipping than a tone clipping issue. But the odds of useful and important data being in the 1, 2, 3, 4, 5 range is pretty low.
The question you should be asking is how does the image LOOK? Clipping (either gamut of tone) is really only important if it has an undesirable result in the image.
>Sometimes reducing Blacks to 0 (from default 5) takes care of it, but adding any Clarity or Vibrance makes it shoot right up. Bringing the image into PS, I see the same spike in the histogram. Any suggestions as to what is causing this and possible remedies?
Because of read noise, the darkest pixels in any digital camera image range from zero to some small value. For example here is a histogram of dark frame taken with the Nikon D200 at ISO 100 with the lens cap on and at maximum shutter speed. Data are shown for the green channel. Most pixels are zero, but some range from 1 to 5 ADUs in the raw file
If you render this dark frame into sRGB with a linear tone curve and the black slider set to zero and view the histogram in Photoshop, you will see spikes on the left representing this read noise:
Read Noise Histogram
At the default ACR black point of 5, these values are clipped to zero and the spikes disappear completely.
Here is a real image with an abundance of dark tones, again with a linear tone curve in ACR and the black slider at zero. You will see a spike at the left representing these dark tones. The space is sRGB
Actual image, black = 0
Now, if you move the black point to 5, the spike is markedly diminished, because the dark values are clipped to zero. It does not get larger.
Actual image, black = 5
If you render into ProPhotoRGB, with a black point of zero, the spike at the left actually gets larger, but is eliminated by setting the black point to default.
ProPhoto, Bl = 0
These spikes are not caused by clipping, but by the lack of clipping. I don't think the gamut of the working space has anything to do with the issue, since the gamut of sRGB and ProPhotoRBG both include R=B=G=0. Should you post the raw file, perhaps someone can comment further.
Thanks, guys, for the detailed information and suggestions. Yes, it does appear to be a gamut issue. I normally have ACR set to open images as aRBG; if I change that to ProPhotoRGB the end spikes go away. However, I am mostly preparing images for stock agency submissions and they keep saying they don't want anything at either end of the histogram. They also want aRGB, and if I convert the image from ProPhoto to aRBG, the spike appears. The images look great on the monitor, but I'm concerned about how they will reproduce in print (offset and inkjet).
I have tried fiddling with the HSL sliders and find that reducing yellow saturation will get rid of the blue spike, but I have to reduce it so much (~-50) that all the warmth goes out of the picture.
I have not had this problem in the past, so surmise that it is either something that changed with the latest version of ACR and how it interprets D2X files, OR, I wonder if it might be because on my last couple of trips I have been shooting NEF+JPG with camera settings for sRGB and high sharpening. I thought ACR would ignore those settings when I opened the NEFs, but maybe I'm mistaken about that. Guess I need to do some more testing to check that possibility.
Thanks again for the help.
Apparently you did not read my post or take it into account. If the issue is important to you, why don't you post a sample image? It would seem to me that a black point setting would eliminate the spike.
With gamut confirmed, you can ignore the incorrect exposure implications. This becomes a color management issue. So I will add two cents from my own experiences.
It took me a while to recognize this at first, but I can assure you I have seen it with several cameras and well before ACR V4. Bright yellows and oranges seem particularly vexing. But I find it in less than 5% of my images. Most important, this is not a crisis. It merely means that the out of gamut colors have been placed at the gamut edge for the color space. No further action is necessarily needed. Two examples:
A portrait with a bright pale yellow logo on a shirt. I simply opened it in aRGB. There was no discernible loss of texture or color. Fiddling with HSL controls or using ppRGB and perceptual color conversion simply bollixed up skin tones and other areas of the image. I think this is similar to your experience.
An image of a sunset with lots of bright yellows and oranges. This required a combination of starting with ppRGB followed with some HSL adjustments. Ignoring the gamut issues caused undesirable color shifts, blocking, and banding in the final prints.
Be aware that what is in gamut in aRGB may not be in gamut in the printer profile space. So gamut clipping can be introduced even in the final output stage. That is what color management and the soft proofing tools are all about.
Frequently it is the levels and curves that we apply that introduce the gamut issues. ppRGB and Lab will both allow us to define colors that are outside the human gamut. In fact, more than 50% of the Lab values represent what are called imaginary colors. All color values will display something visible on your monitor, even if they are out of gamut. This is why we need soft proofing tools.
Your camera settings such as color space, sharpening, and contrast are applied only to the JPG image. They wind up in metadata in the raw image that some raw editors look at (NX) and some dont (ACR).
Your lab should understand that there is a big difference between 245,245,0 (yellow) and 0,0,0 (black).
The Hitch Hiker's Guide to the Galaxy: Dont Panic
Cheers, Rags :-)
I did read your post, and very much appreciate the detailed information and the time your took in trying to help me. I need to review both what you say and the screen shots to make sure I understand fully.
I am also not sure how to post an image here, I didn't see anything about that in a quick check of the forum home page. Should I upload an image file to my website and then put a link to it in a post here? If so, do you want to see the full 12MP NEF file, or should I do something like a screenshot showing the photo when I bring it into ACR?
You gave as an example:
>> A portrait with a bright pale yellow logo on a shirt. I simply opened it in aRGB. There was no discernible loss of texture or color. Fiddling with HSL controls or using ppRGB and perceptual color conversion simply bollixed up skin tones and other areas of the image. I think this is similar to your experience.<<
Yes, this is very similar to my experience. Most of the images I'm having this problem with are scenics and details of Fall color, with lots of yellow.
>> Your camera settings such as color space, sharpening, and contrast are applied only to the JPG image. They wind up in metadata in the raw image that some raw editors look at (NX) and some dont (ACR).<<
I was pretty sure that ACR ignores all camera settings, but I haven't had this problem in the past when I shot NEF only and had the camera set to aRGB, no sharpen, and auto WB.
>The images look great on the monitor, but I'm concerned about how they will reproduce in print (offset and inkjet).
If it looks great on the monitor it is very likely to be perfectly fine in print. To check, you can soft-proof for CMYK and see if it still looks good. If so you're probably fine for both offset and inkjet. It is not as ideal as going to ppRGB, but hey if they don't know what they are doing, don't try to upset the balance.
P.S. In general, offset and inkjet are much better at reproducing yellows (they actually have a yellow ink!) than displays. CMYK is wider at yellow than sRGB (i.e. a typical display), so if your yellows look good on screen, you should be able to print them.
>I am also not sure how to post an image here, I didn't see anything about that in a quick check of the forum home page.
Yes, you can upload an image to your own web site and provide a link--in line images are against forum policy. Or you can use Pixentral, which is a free picture sharing site that provides a thumbnail view in the post.
For larger files, such as NEFs, you can use YouSendit or eSnips.
Can someone point me to the Forum policy against inline images? I wonder if that is out of date. I think that inline images are an important part of the way the forum works. But we do ask that you limit them to a maximum of around 600 pixels wide.
or to save you the bother of reading through the long list of Do... Don't...
>Don't include graphics or files in your forum posts. We ask that you do not post attachments with your posts, regardless of whether your newsreader or web forum supports them. Most users don't want to download a file when reading your post for time and security reasons, and attached files are not available for users connecting with newsreader software. For those that have high connect costs, your post can become quite expensive. Please explain your point in writing and include a URL to the file in your post so others can view and/or download it only if they wish to.
Thanks, Ian. Those do need to be updated. They are from the FuseTalk forums (that don't even support inline images). I still think that smallish (600x400 pixel) images should be OK inline.
To think I learned volumns in this RAW converter thread to help me edit color in scans of negatives.
Thanks, Jeff, for confirming that the preview is more important than a clipped channel. I've been basing my edits working in Lab space on some difficult scans and how they'ld clip setting my Proof Color to sRGB in the info palette instead of trusting the Soft Proofed preview. Now I can push the saturation levels and clipping be damned.
I've seen quite a few gorgeous shots of flowers on the web where the photographer clipped every channel at both ends of the tonal scale trying to squeeze saturation levels into sRGB to get the effect he wanted. Donald Peterson's shots of New Mexico Rio Grande Botanical Gardens comes to mind.
Now the level of clipping his shots would sustain converting to CMYK I'ld think would be of legitimate concern to any stock agency. I mean flowers are still pretty even considerably desaturated but that doesn't guarantee they won't still turn into flat blobs of color on a press.
Just wish Greg's stock agency would define image quality based on Soft Proofing rather than stray channel clipping. I never realized the level of restrictions existed in agencies like this to where it seems too much technical information in the wrong hands could affect someone's livelihood like this.
Bill et al,
Here are screen shots of a sample photo in ACR.
http://www.gregvaughn.com/photos/ then select blueclip.jpg
The top image shows the photo brought into ACR with Adobe's default settings and WB set to Daylight. There's a small blue spike on the left edge of the histogram.
In the bottom image I've adjusted the WB to what I consider the default for my camera and tastes, and I've added Clarity and Vibrance. The blue spike is significantly higher. I often start with those Clarity and Vibrance amounts based on what I got from tutorials by Jeff Schewe and Matt Kloskowski, I find that when using amounts in that range I usually don't have to do any further global curve or saturation adjustments in Photoshop and the photos look good on screen as well as in inkjet prints.
From what several people are saying here, it sounds like I should just stop worrying about the spike as it really isn't affecting image quality.
I get a "Forbidden" error message on that link.
>> I get a "Forbidden" error on that link <<
Sorry, I didn't get the URL right. Try it as in my corrected post:
http://www.gregvaughn.com/photos/ then select blueclip.jpg
>> Just wish Greg's stock agency would define image quality based on Soft Proofing rather than stray channel clipping. I never realized the level of restrictions existed in agencies like this to where it seems too much technical information in the wrong hands could affect someone's livelihood like this. <<
Not to go off on a tangent, but... Getty, Alamy and other agencies specify having all values between about 4 and 248, saying that doing so will prevent pure black shadows and no dots at all when printed offset.
They also tell you not to do any sharpening, and don't differentiate between capture sharpening and output sharpening.
I think I am just going to take Jeff and Rags' advice: if it looks good on the monitor and it prints well, that's what really matters.
I see what you mean. The right part of the histogram appears vacant. What if you increased exposure a bit?
I've had clipping similar on neg scans of backlit intense green leaves where all I had to do is go into blue channel in curves and isolate the blue by locking down every point on the curve above 10 and raise the 0 point until blue output read at least 5 and had no noticeable change to the preview.
That should satisfy the agency.
After considering the topic further and re-reading Jeff's excellent revision of Real World Camera Raw (p 161), I realized that one must distinguish saturation clipping from luminance clipping. In my previous post, I was considering the latter, and the color space makes no difference since there is no significant difference between sRGB and ProPhotoRGB.
However, for saturation clipping there is a marked difference. If one looks at 3D gamut plots of the two color spaces, they collapse at very high and very low luminances, and have the widest gamut in the mid luminance ranges as shown in the gamut plot below. Luminance is on the Y axis, and near L = 0 (black) sRGB has a very small gamut, whereas ProPhotoRBG is much better, especially in the blues. The wire frame is ProPhotoRGB and the solid plot is sRGB.
3D Gamut Plot
These shots of the cyan patch of a Macbeth Color checker illustrate saturation clipping in the red channel. With normal exposure and rendering into ProPhotoRGB, there is no clipping.
Rendering into sRGB results in clipping of the red channel and setting the black point has little effect.
sRGB with clipping
However, if one increases the exposure, the red luminance increases and one is operating higher on the sRGB plot, and the clipping is eliminated.
sRGB with Plus Exposure
My question to Greg is does the clipping you experienced disappear when you use ProPhotoRGB and does increasing the exposure in the case you posted eliminate or improve the clipping?
> My question to Greg is does the clipping you experienced disappear when you use ProPhotoRGB and does increasing the exposure in the case you posted eliminate or improve the clipping? <<br />
Yes, changing to ProPhotoRGB eliminates the clipping. This seems like the obvious solution, except that stock agencies want AdobeRGB files, and when I convert from ppRGB to aRGB the clipping is back.
Increasing the exposure does not eliminate or improve the clipping, just shifts all other tones and makes everything lighter, which is undesirable. I could be interpreting it wrong, but it seems to me that in the example
sRGB with Plus Exposure
the histogram may look better, but all the colors have changed.
Tim's suggestion in reply #20 seems to work well (on two tested images, anyway), and there is no discernible change to the colors as seen on the monitor.
>Tim's suggestion in reply #20 seems to work well (on two tested images, anyway), and there is no discernible change to the colors as seen on the monitor.
The problem is that sRGB and aRGB can not encode saturated colors at low luminance. So to make the image fit into the gamut, you can increase luminance to a higher value where the *a and *b components can be encoded.
Whereas my example raised the luminance of the entire image, Tim used the red channel to raise only the low values and locked the higher values in place. He made the changes only where necessary, and that is why his method is better. If the image is too dark, raising the luminance a bit might help. In raising the luminance, the hue does not change appreciably, but the saturation does
I don't know which Tim you were referring to but I edited the blue channel not the red.
The thing that primarily causes this clipping is the luminance tied to saturation issue as Bill pointed out. There is no HSL editing space or tools except what's been indicated in ACR and I don't know how that behaves.
Even adjusting the luminance channel in Lab space induces the same clipping outputting to a much smaller gamut space. Another alternative is to do a saturation mask discussed frequently on the web but there's still no guarantees on that technique not causing clipping either.
The image of the green leaves clipping the blue channel I posted here at Adobe forums a while back had another odd behavior that ties in with this luminance/saturation clipping issue. The main cause for my posting this image was to point out that to get the blue channel zero point readout to show a change required editing this channel at the 20-30 level in curves. Just pushing the zero point up didn't do anything.
The explanation I was given was that the exact location of the blue channel data as read by PS tools is actually an averaging of all channels to establish luminance for the composite RGB channel-if my memory serves me. The back lit leaves were quite bright so the blue channel even though it read 0 in this area had to be adjusted higher up the curve to affect a difference in the number readout.
In my example there was clipping in the red channel, which could be eliminated by a curve to the red. For your case, you would edit the affected channel, which was blue as I recall.