Hitting the Perfect Skin Tone?

[Jack Flesher]

Holy cow , I did not realize this myself. i just loaded all the tools I normally use under ONE tab. This is awesome and makes it much faster to get around without jumping tabs

Menus can get a little "long" on the laptop though   I nuked the histo on the "Q" tab and added levels to replace it -- which of course also has a histo.

[bcooter]

You can do that.

In 4.5.2 you can add or remove any tool from any of the tabs simply by right clicking on the tab and selecting which tool to add or remove. You can also drag any tool from the tabs and make it float simply by grabbing and dragging the tool. With a standard retouching setup with two moderately sized monitors this means every single tool in the program can be available at any time, and more usefully that every tool that you want to be on the screen can be. With the ultra-useful Apple-B and Apple-T shortcuts you can quickly jump to full screen viewing or back to the standard tool-browser-viewer setup.

All sorts of neat tricks like that will be covered in our Web-Based Capture One classes.

Doug Peterson,  Head of Technical Services
Capture Integration, Phase One & Canon Dealer  |  Personal Portfolio

Thanks,

I found this option later, after I posted and it's better, though  4.5.2 has some bugs or hang ups.

I really didn't want to load 4.5 until I was positive all the issues were worked out but started working in 4.1.whatever and even with updates realized it didn't read some of the Nikon files like the d700 so went to 4.5.2.

It processes well, but like 4.5 the noise, (color and luminance) sliders are way, way too sensitive.  It goes from high iso noise to blur at just a small movement and not just on Nikon or Canon files, it reacts the same with Phase files.  

And unless I'm missing something there is no single channel corrections like Raw Developer or Lightroom.  I find myself spending a lot of time with the color editor and once again maybe I'm missing something but the color editor seems to be non responsive at times, same with the batch processor and I'm running a new 8 core macpro with plenty of ram and a terabyte of drive space so I don't think it's the machine.

Again, it does process well and fast, actually in many ways more natural than lightroom in the final look, but the interface on phase software always seems unintuitive.  I can learn it, I will learn it, but the learning curve is much higher than it should be, considering lightroom takes about 10 minutes to get up to speed.

For final processing though there seems to be some kind of strange almost there look with all the 3rd party processors compared to the manufacturer's software, with the exception of Raw Developer.  

Lightroom really is a roll your own system where you need to start from scratch and c1 seems closer to Canon and Nikon converters, but not exactly there, almost there.  Also the previews in c-1 are much better than 3.78 but not as clear and natural as the previews in DPP and Nikons nik software.  Even fully rendered they can look crunchy or kind of rough unless you take them up larger and i'm running a 30" monitor so it's not like there is not enough room.

Why are the previews in 4.5 so much different than DPP and NIK.  is it Java or is it just that C-1 reads the files differently.

I really wonder if Canon and Nikon give out all their information, or if the software guys just make it up.

Maybe that's it because 4.5 reads the phase files very well and looks much more natural than the Canon, Nikon and Leica files.

I guess it is just asking too much but I would love to have a software that had the interface of lightroom, the processing speed of c-1 4.5, the color look (especially in skin tone) of dpp and nik and the previews of dpp, oh yea and the drag and move features of I-view.

[David Grover / Capture One]

has phase (or any medium format company for that matter) taken their equipment and shot 12 different ethnic skin tones with strobe, then hmi, then tungsten, then window light then daylight, then soft shadows with ambient fill, then . . .?

have they done this next to the canons and nikons and film. does any medium format maker ever shoot their digital backs next to film.

I've done it, though not specifically for profiles but for projects and I can tell you with all honesty all the the medium format backs I've used and owned are way way  too color sensitive and depending on the subject and the light source can go from the best in the world to the worst just by switching a modifier or a cloud going overhead.  The best I've seen on skin was a hd 39 prototype using the old flex something color but I wouldn't attempt to batch correct 5,000 files in flex something color software so that wrapped up that thought.

maybe focus is a better software, I don't know, but I do know that really beautiful skin profiles are not going to come from a manufacturer shooting color charts, vegetables and raw meat.

James,

Yes we did shoot a number of different skin tones under different lighting when we first changed our color processing engine.

Natural out of the box skin tone from the H3D39 was one of the many goals.  

Phocus is a better software of course.  Perhaps you could point me in the direction of the Hasselblad Vegetable/Meat/Colour Chart testing chart because I have not seen this in my seven year career at Hasselblad.  You could of course base your assumptions on current software and hardware.

Gone are the days of a few of us standing in the studio going ermmm.. make it a bit less red.  The people behind the calibration processes, colour management and colour algorithms are way ahead of what we could achieve even four years ago and we can already see this with improved calibration techniques.

The work is ongoing and more improvements will come in 2009.

Best,



David

[csp]

James,

Yes we did shoot a number of different skin tones under different lighting when we first changed our color processing engine.

Natural out of the box skin tone from the H3D39 was one of the many goals.  

Phocus is a better software of course.  Perhaps you could point me in the direction of the Hasselblad Vegetable/Meat/Colour Chart testing chart because I have not seen this in my seven year career at Hasselblad.  You could of course base your assumptions on current software and hardware.

Gone are the days of a few of us standing in the studio going ermmm.. make it a bit less red.  The people behind the calibration processes, colour management and colour algorithms are way ahead of what we could achieve even four years ago and we can already see this with improved calibration techniques.

The work is ongoing and more improvements will come in 2009.

Best,



David

yes, phocus / H does indeed a nice  job on skin tones.  

[bcooter]

The work is ongoing and more improvements will come in 2009.

Best,



David

Danny,

That's great and appreciate the reply.

Glad to see your color engineers photographed some people instead of raw meat, but don't forget there are some raw meat photographers out there who need color accuracy also.

Can't wait to see what Hasselblad has for us in 2009.

All the best,

bc

[David Grover / Capture One]

Danny,

That's great and appreciate the reply.

Glad to see your color engineers photographed some people instead of raw meat, but don't forget there are some raw meat photographers out there who need color accuracy also.

Can't wait to see what Hasselblad has for us in 2009.

All the best,

bc

 

I think Raw Meet issues were put to bed in 2003 but Ill make sure it is checked out.  

Danny.

[CaptainHook]

A perfect example and a base to go by is Even in RGB R should be more than G and G should be slightly more than B depending on how warm you want the skin tones to be.

I've found that by comparing well known, quality files of various ethnic groups, that is, files I know output well, that if R is about 8-10% higher than G, and G again about 8-10% higher than B, you get a good ratio (ie 80%/70%/60%). But you still need to use your eyes and brain, a calibrated display and spice to taste.

Hilarious. You're both essentially saying the same thing but don't realize..?

The CMYK by the numbers "technique" is pretty bogus (its based on some undefined press condition which has nothing to do with what you're editing).

In my opinion it's the same as as your RGB method. It's based on ratios in CMYK by reading the numbers
but still needs use of your eyes, brain, a calibrated display/printer/workflow, and some spice to taste.
You're just reading the RGB numbers instead of the CMYK ones from the info palette.

[digitaldog]

Hilarious. You're both essentially saying the same thing but don't realize..?
In my opinion it's the same as as your RGB method. It's based on ratios in CMYK by reading the numbers
but still needs use of your eyes, brain, a calibrated display/printer/workflow, and some spice to taste.
You're just reading the RGB numbers instead of the CMYK ones from the info palette.

Big difference. The RGB is BASED on the actual color space you're editing the data in, the CMYK technique is hugely dependent on the CMYK output color space. CMYK is a highly output dependent color space with all kinds of differences based on GCR/UCR specifications let alone the colorant.

Load half a dozen CMYK profiles, you'll get half a dozen CMYK ratio's and values.

[Peter_DL]

The ratio method is interesting, but even if the ratios are correct, the saturation may be wrong. I presume that this could handled by a saturation adjustment. Another approach is to use LAB, where color and luminosity are separated.

R:G:B  "="  HSB-hue & saturation

Peter

--

[hubell]

I do not work with skin, but those that do may want to have a look at this interesting piece of software for fine tuning skin that was just released. It works within Aperture and Lightroom, but probably not with the raw data.

http://www.imagenomic.com/pt2.aspx

[CaptainHook]

Big difference. The RGB is BASED on the actual color space you're editing the data in, the CMYK technique is hugely dependent on the CMYK output color space.

If you're working within a calibrated workflow, so what?
With the RGB based numbers one has to take into account the output destination
just like with cmyk. Many times CMYK values are read while in RGB anyway and
at the end of the day, the ratios work as starting points from both IN PRACTICE.
That's why retouchers still do it. It works. Who cares if technically it shouldn't?
It DOES. Time and time again.

[digitaldog]

If you're working within a calibrated workflow, so what?
With the RGB based numbers one has to take into account the output destination
just like with cmyk. Many times CMYK values are read while in RGB anyway and
at the end of the day, the ratios work as starting points from both IN PRACTICE.
That's why retouchers still do it. It works. Who cares if technically it shouldn't?
It DOES. Time and time again.

No, one doesn't have to take the output destination into account, certainly at this stage. You're editing in an RGB working space (an editing space). That's the master archive of which all the heavy lifting should be accomplished. In a Raw converter, you've got RGB, simple as that. You can view the numbers based on that actual processing working space without worrying about any other color space.

The old technique may "work" (once someone actually specifies the CMYK space which has absolutely no relationship on the current editing), but there's little reason to teach new users such a convoluted and complex process.

Its like trying to communicate with someone who only understands English. Instead of just speaking that language, you instead speak German, then write subtitles as you go. What's the point? Ultimately, something might be lost in translation, its far more complex and totally unnecessary. Now if you want to sound like you're some macho retoucher and love to jump thorough hoops, by all means, state that up front. But if your goal is to teach a process to someone, why go out of your way to make it far more difficult and steer from the most direct approach to editing numerically?

The entire idea here is to specify some rough ratio of color numbers. It could be in any color space or color model. Why on earth use a scale that's not based on anything you're doing? Ad another number into the mix, use a scale that's based on something you'll never use? And based on a color model that's highly device dependent and nearly never defined in the so called process? Might have been a decent idea in 1993, now, its simply silly.

[bjanes]

No, one doesn't have to take the output destination into account, certainly at this stage. You're editing in an RGB working space (an editing space). That's the master archive of which all the heavy lifting should be accomplished. In a Raw converter, you've got RGB, simple as that. You can view the numbers based on that actual processing working space without worrying about any other color space.

Does the above statement mean that you now consider the raw file to have a color space?

[digitaldog]

Does the above statement mean that you now consider the raw file to have a color space?

Nope. I consider the Raw processor to have a color space used for its processing pipeline. In the case of ACR/LR, that's ProPhoto RGB with a linear TRC Gamma.

[bjanes]

No, one doesn't have to take the output destination into account, certainly at this stage. You're editing in an RGB working space (an editing space). That's the master archive of which all the heavy lifting should be accomplished. In a Raw converter, you've got RGB, simple as that. You can view the numbers based on that actual processing working space without worrying about any other color space.

Nope. I consider the Raw processor to have a color space used for its processing pipeline. In the case of ACR/LR, that's ProPhoto RGB with a linear TRC Gamma.

I find these statements to be a bit confusing. When one is working in ACR, he/she is really dealing with three color spaces: the raw space, which is converted to the internal working Melissa space and then to the ACR working space such as ProPhotoRGB. The only RGB numbers that are accessible are the final working space numbers. The destination workspace must be taken into consideration when interpreting the RGB output numbers.

[digitaldog]

I find these statements to be a bit confusing. When one is working in ACR, he/she is really dealing with three color spaces: the raw space, which is converted to the internal working Melissa space and then to the ACR working space such as ProPhotoRGB. The only RGB numbers that are accessible are the final working space numbers. The destination workspace must be taken into consideration when interpreting the RGB output numbers.

As to the three possible color spaces, I'm not the least bit interested in the so called "Raw color space" since that's not provided to me in either product. And I don't want to go down that endless rabbit hole about "does Raw have a color space". That leaves ProPhoto RGB linear TRC or ProPhoto 2.2 (Melissa) the latter is the only set of numbers I'm provided in LR. For the task of working skin tones numerically, doesn't matter.

ACR provides the 0-255 values based on the encoding color space you select in workflow options. Nice because you now see the numbers you'll get in Photoshop. Not as nice for this topic in terms of not having percentages (which make working numerically with skin really easy). Also not so great because its not on parity with Lightroom (and vise versa).

LR provides you those nice percentages. It is based on Melissa RGB, the differences between it and the actual Raw processing color space being simply the TRC (2.2 instead of 1.0). Again, very useful in this context for numeric skintone work due to the percentages.

So we have two identical Raw processing pipelines. Each has an advantage in terms of the numbers provided, neither provides BOTH advantages (which would be really, really nice).

Advantage ACR: numbers match encoding color space you end up with in Photoshop. But ACR expects you to select this from the get-go and will provided a rendered image as soon as you're done. LR doesn't work this way, it doesn't know when (or if) you'll render the data into Photoshop (you may never, you might print directly, or upload a web gallery without ever opening Photoshop).

Advantage LR: percentages while working. Too bad we can't now use the same percentages once we're in Photoshop but alas, the RGB info palette doesn't allow this.

In both ACR and LR, you're pretty much expected to do as much global tone and color work as possible for reasons that should be obvious to anyone here. In a prefect world, both product would allow us to toggle the scale.

Note that you can build a Melissa RGB working space in Photoshop's custom RGB color settings. Then you could take a Macbeth LAB generated doc, convert it to ProPhoto RGB and then Melissa RGB. You'd see that while the numbers are of course different, the ratio's are nearly the same (within a few values).

In the grand scheme, all three varieties of "Pro Photo" all work equally well for this discussion, assuming you get percentages because those percentages vary a tiny amount. Melissa RGB is kind of useless compared to the other's IMHO because its not based on anything "real" but its close enough. I'd prefer if we'd just get a 1.8 TRC and just call it ProPhoto RGB or even better, just show us the 1.0 TRC values. But the chromaticity values are the same.

So I wish Adobe would allow ACR and LR to share the same processing color space using the same scales as an option, then allow Photoshop users to do the same (add percentages based on the working space to the info palette). But in the end, short of not providing absolute exacting values, LR.'s percentages make correcting skin tone numerically very easy. Personally, I'd prefer to just LOOK at the image on a calibrated display. But I recognize some users just have to have a numeric road map. I think that map should be spelled out using something that at least has some basic hook to the processing color space. In LR that's far, far closer than some arbitrary CMYK color space by a mile.

[CaptainHook]

If you're in one of the 3 most common RGB spaces (ProPhoto, aRGB, sRGB), the cmyk percentages from
the info palette (following the guidelines to be tweaked by eye) generally result in pleasing skin color.
And for skin i can convert from ProPhoto down to sRGB and the CYMK percentages from the info palette
remain generally the same. The numbers relate in that i know they work for the editing spaces i'm often in
(which for the heavy lifting and this kind of thing is usually ProPhoto) and always using the same
US SWOP v2 profile. I know the effect of these numbers when in my RGB editing space.
There's no conversion or translation i concern myself with.

The CMYK readout is right next to the RGB one. Except the CMYK readout is in percentages, and the RGB in
numerical values (0-255). I find it faster to read percentages than work out the math on the RGB numbers as
you suggest. And it's just a starting place anyway. No hoop jumping compared to reading RGB numbers to me.
But that's in photoshop, not the raw convertor.

I think this is down to workflow. Yes, i would look at the RGB numbers in the RAW convertor, but once
in photoshop i start to refine and i turn to the CYMK percentages in the info palette cause it's faster and
easier for me (like you said about percentages). And many moves are localized anyway. Not global
like in the raw convertor.

My original point was, Snook also mentioned reading the RGB numbers. With which you agree. As do i.
I just also think reading CYMK values while editing in an RGB editing space is equally useful and actually
faster/easier when in photoshop.

I get the feeling you think the CMYK percentages are read while in a CMYK profile? Maybe some do this,
but i assume they've worked out what numbers work for them in each profile as some kind of proofing
has to happen if it's going there anyway. Or sRGB. I agree the heavy lifting should be done in a larger space.
Some would rather edit in the destination space. I don't agree but each to their own.

[Snook]

Amazing how much BS you all can talk about.. and for so long is quite disturbing also..

Snook

[digitaldog]

I get the feeling you think the CMYK percentages are read while in a CMYK profile? Maybe some do this,
but i assume they've worked out what numbers work for them in each profile as some kind of proofing
has to happen if it's going there anyway. Or sRGB. I agree the heavy lifting should be done in a larger space.
Some would rather edit in the destination space. I don't agree but each to their own.

No, the CMYK percentages are based on whatever CMYK "profile" happens to be setup in the Photoshop Color settings, based on the rendering intent, BPC, GCR/GCR etc. Its based on something that's not at all locked down, can change depending on if a user is working with the Classic CMYK engine or not (SWOP isn't the same in each case). Its based on something that has absolutely no relationship to the data you're editing where the RGB values always do. And of course, the CMYK values depend on the RGB working space, making even more possibilities that someone will get differing values. And in this context, you're NOT editing in the destination space. And you shouldn't. Master editing whereby you may have multiple output destinations is done in the RGB working space. You even want to output for a destination while viewing a duplicate image with the soft proof on in the master (and build those output specific edits, in the master working space on adjustment layers in a layer set specified for the output).

[digitaldog]

Sorry Guys.. have no more comments...
Going to hang out in the Aptuss 22 VS. 5DII thread for a while..
Just made some Pop Corn cuz it might get exciting over there..
Someone Challenged Frank DoofusDorf (Sp?)  about his photographic knowledge!!!

Snook

Amazing how much BS you all can talk about.. and for so long is quite disturbing also..

Snook

Its really a shame you can't keep your promise, keep your mouth shut and actually go hang out elsewhere. Apparently we have a troll named Snook.