I have been working on calibration for my Nikon D80 in camera raw for some time now. I have used all 3 of the scripts for ACR calibration. I have shot the colorchecker under various lighting, including studioflash, daylight and tungsten. The profiles Ive come up with have in my view improved the colors significantly in several ways.
But, and this seems impossible somehow, however I do it I seem to get too much magenta in skintones. I have observed this generally in my images with people and more specifically in the skinpatch on the colorchecker.
To put it simply There seem to be no circumstance under which I can shoot the colorchecker where sampling the skinpatch in CMYK-mode doesnt show more magenta than yellow (more importantly this is obvious to the eye on my calibrated screen also, but the numbers are better for reference), which as you know should be the other way around. This is with technically correct whitebalance. With or without the calibration. This is also true in Capture NX, Nikons own converter. I can get the right color on the skinpatch by changing the hue/saturation in photoshop, but that changes all the colors, which I dont want, the same goes for warming the image by changing the whitebalance. Is this too much to ask from my D80, or any dslr? I would be thankful for any input on this.

I am not saying I can help you with these problems, I have no idea what causes them. Still, I would like to see a raw file of the color checker shot, and if you happen to have a Stouffer wedge shot, that too.

The Rags Gardner scripts give you the option to use the ColorChecker "skin" patch as one of its calibration points. Have you tried that?

Of course when you do that it is possible that you will have greater errors in other, more saturated colors. In your case, however, it might be a decent trade-off since errors in more saturated colors could possibly be handled by the HSL sliders in ACR pretty well.

I'm no expert on ACR calibration, John, but I did some experimenting and I see what you mean. Fors, Gardner, and Tindeman all had problems with skin, even when I used the swatch weights (Rags/Tindeman) to try to give it priority.

I suspect what is happening is banging into the limitations of the ACR calibration algorithm (matrix?). One thing I tried was to do the calibration manually honing in particularly on the light skin patch. I was able to match 2 out of the three channels exactly with the other off by only one.

This did make skin tones look better but made the reds a little on the orange side. I think you might want to give it a try though. With a little more time it might be possible to hold the skin values and improve the other colors a little bit. If you could get the skin spot on with the errors primarily in saturated colors it might be a fair compromise since the HSL tab in ACR could be used to bring those saturated colors back in to line.

There is currently a fundamental tradeoff between the skin tone rendering and the rendering of deep saturated reds. For many individual images, this can be worked around using the calibration & HSL sliders. However, no single preset will tackle both issues generally (i.e., across several images). And for some images that contain both, there is no workaround at the moment.

Probably you have pushed a little to hard on the red hue slider toward negative direction and I think that the light skin patch is the most critical to the human eyes (or better to the human brain) but with an optimal calibration you can reach a very good compromise.

What setting do you have found?

If you want to load the target capture (and the reference Lab if is available) somewhere like http://www.megaupload.com/ we can take a glance.

It seems to be an Adobe color engine issue because I get this whether shooting jpeg or RAW in any lighting situation with two different camera's. And I also suspect the possibility digital camera's sensor's natural bias toward reds due to their sensitivity to the infrared spectrum is adding to this.

Has anyone seen this page on how Adobe's color engine addresses hue/saturation/lum in their tool sets?

I have seen the same behavior in ACR processing of skin tones. The resulting RGB file always shows an overly-light red channel with virtually no detail in the highlights - hence the "hot" look of skin tones.

I have developed two work-arounds:
1) Use Capture One. Their algorithm yields more detail in the red channel of skin tone areas, leaving you with something to work with (as opposed to the blank skin tone areas of the red channel out of ACR.) Post-processing can always enhance color if need be.
2) Process in ACR, then use various channel-blending strategies (a la Dan Margulis) to bring detail into the red channel. This is very effective, but cumbersome and impractical as an everyday workflow.

Question for Eric Chan:
When fine-tuning the ACR algorithm, was a conscious decision made to favor deep saturated reds over skin tones? (I'm not sure how that works.) It would seem that the current algorithm permanently damages the red channel when shooting light skin tones. If it's a matter of choosing one or the other, I would lean towards keeping detail in all channels.

>Hi Rick, can you please elaborate on your comment on damaging the red channel?

Hi Eric,

A little background info first (which is probably review for you!):
Good skin tones can best be assessed by Info Palette/CMYK (regardless of the color space you're working in.) The warmth of a Caucasian skin tone is conveyed by approximately equal values of M and Y, giving an orangey/pink. The texture and form of the skin is carried by the opposing color - cyan. Without any cyan in the skin tone, the effect is very neon/hot/garish/flat.

In an RGB file, the cyan info is carried by dark values in the red channel. FIles processed in ACR routinely produce a red channel that has little to no detail in flat (neither highlight nor shadow) skin tones which results in skin tones that have an accurate hue, but no depth or detail. I characterize the red channel as damaged because there is nothing that can be done to bring detail in (short of some rather cumbersome channel-blending moves.) As the saying goes - nothing from nothing leaves nothing.

If the flat skin tone area of the red channel had even a little detail (in the 230-240 range), then there would be something to work with. As it stands, the flat color area of a skin tone often exhibits a red value over 250.

The RGB relationship you should be really concerned about is the difference between red and green. Blue will and should be the lesser of the three unless they're albino viewed under midday sun.

If you're getting 240-250 red readings on caucasian skintones then you're probably over exposing your subject. I examined quite a few caucasian skintones over at Melvin Sokolsky's site under Beauty>Portraits and most of his studio shots of light complected subjects have an average green of about 220, red-230 and blue-200 on the brightest highlite on the bridge of the nose or near the browline in sRGB. The Celine Dione portrait in particular and she's very pale complected with makeup applied. The highest I sampled on one cream colored skintone was 245R, 234G, 225B from the shine on the bridge of the nose and there was no detail at all.

I found a causcasian skintone you seem to be discribing in this small review of Elements 4 that surprisingly has a simplified skin correction feature:

http://pcin.net/help/software/elements40.php

The red channel goes to 255 on the subject's forehead in the sample image and shows that plastic look you and Ramon have described. Somehow it looks normal though. Must be the neutrality of the scene that holds it together.

Just reporting back. I have been using the new DNG Profile Editor with my colorchecker shots. Finally! I get good skintones, on people as well as the light skin patch on the colorchecker. And this is without any manual adjustments, and it doesn't seem to compromise other colors either. Saves time indeed..

Glad to hear it, John. Obviously when this thread first surfaced back in March, I was itching to talk about the PE but we weren't ready to announce it yet. (I also didn't know anything about how the PE worked at that time, but anyways ...)