Forums

Gialandra,

>>> I have heard that the best way to find the right exposure on white patch for the calibration is using DCraw (with options -3 -m -k 0)

The dcraw m option says not to convert the camera RGB space. Thus, unless you know the characteristics of the camera RGB space, you dont know the precise meaning of the values.

In addition, setting exposure based on the white patch is not very reliable. The neutral 5 patch is photographic middle gray (18%). This works out to 127 for Adobe RGB or sRGB or to 110 for ProPhoto or ColorMatch RGB. Middle gray is the basis of photographic exposure metering and ISO settings. Neither black nor white is specifically defined in terms of density on the CC chart.

The camera color space (after ADC) is typically gamma 1 (a so-called linear space). Thus the values would have lower numbers than in a 1.8 or 2.2 gamma color space. The image is darker.

Maybe you should consider posing your question wherever you saw this suggestion.

Cheers, Rags :-)

Gialandra,

>>> Why Adobe don't write a FAQ on this very confused treatment?

Profilemaker and dcraw are not Adobe products.

Bruce Fraser has several books on ACR, Color Management, and RAW processing. There are lots of others. These forums are for discussion of Adobe products. So you shouldnt expect much expertise on other products.

I have several technical articles on my own website. These include calibration topics, exposure metrics, and light measurements if you are interested. The conclusions are based on extensive research but not everyone agrees with them. Then again, even the color science experts have disagreements.

Cheers, Rags :-)
http://www.rags-int-inc.com/

> In addition, setting exposure based on the white patch is not very reliable. The neutral 5 patch is photographic middle gray (18%). This works out to 127 for Adobe RGB or sRGB or to 110 for ProPhoto or ColorMatch RGB. Middle gray is the basis of photographic exposure metering and ISO settings

I had to abandon "middle-grey" measurements for digital capture. I used that approach, and incident metering, successfully for a long time when I shot film. But my consistent experience with digital SLRs (Canon's) has been that incident readings and reflected "18% grey" readings often produce underexposure, sometimes to an unpleasant degree. I don't understand what the problem is in theoretical terms, have stopped caring about that, and got over worrying that my equipment was somehow defective. I've seen what I've seen and I've had enough of underexposure problems.

An incident reading might be effective with "below average" subject-matter, meaning an unusually flat scene. That kind of shot is probably salvageable during raw conversion even given underexposure. Different story with subject-matter containing a longer range of tonalities. Failure to hit the exposure right on the money is liable to produce blown diffuse highlights that would otherwise have been rendered correctly (at least on film). In those situations, "18% grey" just plain doesn't cut the mustard.

Yes, it's possible to do highlight recovery with a raw converter. But I keep encountering deliberate underexposure in the camera for that purpose, or making a second raw conversion with the EV slider cranked way down, producing color shifts that must then be compensated-for in Photoshop. Not doing so produces a "highlights-only" layer with a noticeable difference in color balance -- not acceptable. It's an unpleasant problem and I don't yet know how to deal with it.

The only metering technique that I find to work well with real-world images, as opposed to theoretical images referred to via numbers alone, is to meter the brightest diffuse highlight in which I want detail, then make whatever adjustment is needed to render as a diffuse highlight. IOW: an unscientific variation on the Zone System theme. I began getting consistently more accurate exposures out of the box when I stopped relying on incident metering and began spot-metering highlights. (If I go by an incident reading and it gets me "there," I consider myself merely lucky.)

>The only metering technique that I find to work well with real-world images, as opposed to theoretical images referred to via numbers alone, is to meter the brightest diffuse highlight in which I want detail, then make whatever adjustment is needed to render as a diffuse highlight. IOW: an unscientific variation on the Zone System

Mike,

This matter was discussed extensively in a previous thread:

Bill Janes, "Exposure to the right and tone placement" #90, 12 Nov 2005 11:44 am

Two resident experts, Bruce Fraser and Jeff Schewe, recommended just your approach. To make full use of the dynamic range of the sensor, it makes sense to place the non-specular highlights as far right in the histogram as possible and the highlight reading allows this.

Most cameras are calibrated for 12% reflectance and you could use a Kodak gray card and give 0.5 EV more exposure and reach the same result with the Color Checker calibration. In the field however, it is difficult to select the proper 12% gray from which to meter.

A reading from a mid gray would give a result similar to an incident light reading. Ansel Adams himself discouraged the use of incident meters since they do not take the dynamic range of the subject into account. When they became available, he used a 1 degree spot meter and took readings from the highlights and shadows.

I agree with Rags that the basics of exposure have not changed that much over the years.

Interesting discussion for sure. I can certainly relate to the Canon underexposure issue!

But folks need to be aware of the thread I have posted on the main Photoshop forum regarding ACR and CS2 (Color Mis Management in Windows). I won't repeat details here but there is a significant color management bug in an as yet undetermined location. I strongly suspect it is actually a CS2 issue but we'll see what the engineers come up with.

FWIW, I used the Fors script successfully with ACR 2.3 and CS(1) but until Adobe comes through with a patch for the Windows version of CS2 and/or ACR 3.2, calibration is a non issue from a practical standpoint.

Does anyone know if there is a way to tweak the calibration script in a way to produce a profile that matches the color scheme of Canon diverse "picture style" settings?

my idea is the following: i take two Pitures with my 5D of the gretag color chart - one as a jpeg with canons picture style "portrait", the other as RAW.
then i open the jpeg in photoshop and measure all color values of all patches of the chart and replace the values in ColorChecker() in the script.
afterwards i start the script on the RAW file.

has anybody already done something like this before?

i'm asking, because i don't own a gretag color chart and it's quite expensive, so i thought, i'd ask first, before buying it and be disappointed because it doesn't work...

Manfred,

In a single word, the answer would have to be no.

Tom posted the ACR 3.3 update to his Calibrator script today, V3.7

http://fors.net/chromoholics/download/

Les and Manfred,

If you are having trouble with Tom Fors script and the manual methods, you might want to have a look at my version of a calibration script ACR_Calibrate_Rags.

There are some differences in the basic approach and lots of options for those who need or want to try alternatives.

Toms script and Bruces approach are nothing short of excellent. But sometimes it is useful to have alternatives. If you want to modify the target values to match a unique target look you might find my version easier to do that with. I assume you have a fundamental knowledge of JavaScript.

As Julio notes, there is difference between calibration for some level of accuracy and adjustments to suit your aesthetic taste.

Cheers, Rags :-)

I have tried an experiment. I would appreciate the opinion of the experts here about the value of this experiment.

I've just recalibrated my camera in ACR 3.3, using Thomas Fors' latest script. I wondered what the result would be if I printed it, so I did, (with an extra method noted below). Then I wondered whether a "round trip" method might be a good way of fine-tuning the calibration.

I have just tried the following, using the results of this latest calibration:

1. Photograph GretagMacbeth Color Checker, convert with ACR 3.3, and print as "Print-1".

2. Photograph "Print-1", convert with ACR 3.3, and print as "Print-2".

3. Photograph "Print-2", convert with ACR 3.3, and print as "Print-3".

My assumption is that errors will amplify or accumulate, (as a sort of positive feedback), and not self-correct, (as a sort of negative feedback). So problems clearly visible in Print-3 will be indicative of problems already subtly present in Print-1. (I know of an error in this logic, see below).

Does this make sense?

Results:

Print-1 was a much more credible copy of the GretagMacbeth Color Checker than I expected. It wasn't just a "representation". It appeared at first sight to be a credible substitute. The initial impression was perhaps that the Blue patch (R3C1) was slightly dark. And, as result of the later prints, it was perhaps already apparent that "Light Skin" (R1C2) was slightly too "pink". (In fact, I think it was actually slightly too "magenta").

Print-2 exaggerated the problems with Print-1. And now it was becoming clear that "Moderate Red" (R2C3) was too magenta. And Neutral 3.5, the dark grey (R4 C5) next to the Black, was becoming a bit brown. (I suspect this is the result of the printer profile error).

Print-3 was not very good! There was no doubt what it was a print of, but the above problems were even more apparent. Some of the patches were still credible: "Blue Sky" (R1C3), "Foliage" (R1C4), "Blue Flower" (R1C5), and even "Bluish Green" (R1C6), were still plausible. So were some on R2, and even "Green", "Red", "Yellow", and "Magenta", (R3C2 to R3C5), were plausible. But they wouldn't fool an expert for a second!

By Print-3, the RGB values were typically way off, except for the R4 White/Grey/Black patches. But this demonstrated that some colours are subjectively more resilient to RGB errors than others. The numerical error in "Light Skin" (R1C2) in Print-1 was less than that in some other patches, but the result was more obvious. We appear to be sensitive to skin colours in a way that we are not to foliage colours.

"Extra method":

For this to work, I needed to get the tonal balance of each print right. (The calibration tries to get the relative colours right, not the tonal balance). So I downloaded "Macbeth_ColorChecker_LAB.tif", (which I think was developed by Bruce Fraser), and converted it to Adobe RGB 1998, my normal working profile. This gave me target RGB values for the 6 White/Grey/Black patches on R4 of the GretagMacbeth Color Checker.

Each time round, I used control-click on the 6 R4 patches to make 6 points in the ACR "Curve" tab, and used the up & down arrow keys to make the ACR "color samples" of these patches match those target RGB values. In other words, I should each time have a conversion into Photoshop that would match R4 of Bruce Fraser's "Macbeth_ColorChecker_LAB.tif". (If I have the theory right!)

"Error in this logic":

My printer profile for the paper & ink I used is slightly "warm". It might be supposed that this error would accumulate each time round. But with each raw conversion, I first set the white balance, using the typical light grey (R4C2) patch, and this therefore corrected for any warmth in that patch. So this appears to be one error that doesn't accumulate with this method.

Views?

>If you are having trouble with Tom Fors script and the manual methods, you might want to have a look at my version of a calibration script ACR_Calibrate_Rags.

Rags, I am experiencing similar issues with your script even after tweaking the many options. But I did notice something interesting when running the accompanying color checker script.

The target values specified by the script do not match the values specified in the Lindbloom (ProPhoto) chart I downloaded. The difference is most significant for the red value on the red patch (115 vs. 122). I don't know if this may be an issue with Tom's script, as well.

Are target values potentially different for Mac vs. Windows? Info. Palette readouts in CS2 confirm the values provided in the Lindbloom chart.

Nonetheless, I've dialed things in extremely close using the Lindlbloom chart as a guide (assuming the chart is correct?) for all patches doing things manually. My largest error is +7 for the R value in the red patch (+14 according to the script, though) with values for all other patches being within 3 or 4 of the targets at worst (again, the script reports slightly different errors due to differrences in assigned target values).

I should add that your suggestion to save the initial brightness and contrast settings as defaults for ACR has proven extremely helpful. Thank you! I've added the shadows and global saturation settings (used to fine tune the calibration tab) to the default mix, as well. Results thus far look promising.

Now if only Adobe could incorporate noise reduction features into ACR that are equivalent to those used in RawShooter.

Rags Gardner wrote
>> I firmly believe we need the spectral response data from the sensor manufacturers for accurate color matching. <<

Yep. Also I would like to see a ranking of cameras regarding their gamut and which one already comes closest to a matrix geometry (at given light conditions) means that the spectral response of Bayer filters corresponds to XYZ weighting functions resp. linear combinations thereof afik.

Further, its still unclear for me to what extend said unit-to-unit deviations of cameras really exist. Or, if ACR calibration more compensates for the differences of the different calibration procedures compared to the profiling software used by Adobe to create both generic profiles.

ColorChecker comparisons before vs. after calibration seem to me quite complex as soon as a saturation-changing tone curve comes into play. It requires to make an assumption (by purpose or not) how Adobe meant the colors to look after passing through the default tone curve from Shadows, Brightness & Contrast settings.

Please keep us informed on new insights!

Best regards, Peter

--

Rags, your posting are always educational. Thank you very much for your continued efforts.

OK folks, here goes.

I am not an expert in color science or chip manufacturing, but my background (40 years in the computer industry) should allow me to express some opinions.

Unit to unit differences should be minimal. When you pay $3000 or more for a camera you should expect quality control. Maybe not true for a $150 point and shoot camera.

If someone wants to help prove this, please contact me offline. What we need is controlled CC shots from different units of the same model camera. Nikon, Fuji, or Canon will do. Studio flash properly exposed would be the preference. Daylight can change too fast.

The spectral accuracy at one nanometer increments would be 300 or 400 data points for each of four channels. Most of the color science stuff uses interpolation from 5 nm tables (60 data points). This would not bloat the metadata. This would improve color accuracy by significant orders of magnitude. And we still have the existing tools and options to achieve any aesthetic look we desire.

I asked Fuji about this at Imaging USA. The answer came today. Sorry Charlie. They claim it is trade secret information. Nonsense! This data has been published for pro film for years. Frequently, its included in the box. If it were publicly published, it wouldnt even have to be in the metadata. Some sensor makers (Dalsa for one) already publish it, but it is in graphic form rather than table form. An independent body with the proper equipment (very expensive) could instrument and report this for all the popular sensors.

The ISO metadata tags do exist, but no one is using the spectral information tags or the real white balance tags. DNG does accommodate something similar. I prefer the open ISO solution over any vendor owned solution. I have an article on some standards research on my web site.

It is impossible to design any sensor that realistically matches CIE XYZ or CIE RGB. These are derived color matching functions based on human psychological responses (psychophysics), not a sampling of physical devices.

Shooting RAW puts the darkroom on your desktop. We need the same tools we had with the wet processes. There are several good tools for camera profiling, but they depend on rendered images under repeatable conditions. Phase One seems to me to offer the best solution for true raw calibration so far. But they dont support my cameras so I havent actually tried their tools.

IMHO, the answer is open standards. ISO TIFF/EP is the horse I want to ride. There needs to be a standards compliance reporting or enforcement body in place. The ISO does neither. Until the affected users understand what true open standards can deliver, chaos shall reign.

Unfortunately, OpenRAW is focused on all encompassing documentation instead of the real solution, standards compliance. Surveys and mass mailings to the vendors seem to be the order of the day. This will never fly.

Yes, there seems to be a bit of voodoo mixed in with true science. Sometimes the voodoo becomes group think.

Cheers, Rags :-)
www.rags-int-inc.com

>Yes, there seems to be a bit of voodoo mixed in with true science.

Yes, and perhaps a bit of science to the voodoo, as well!

It would be helpful to understand just how Adobe goes about profiling our cameras in the first place. I've also found that lenses can make a substantial difference to a color profile - particluarly Canon's L vs consumer lenses.

>Unit to unit differences should be minimal.

Agreed. This makes me think that perhaps the influence of various lenses could be the voodoo element of this discussion.

Peter,

Chris was refuting a statement from Bruce Fraser. Bruces comment was similar to mine. Chris referred to some colorimeter filters. Colorimeters can and do use XYZ metrics. But to imply they use optical filters that match XYZ is a bit of a stretch. I dont think we need to go into the fundamental differences between a colorimeter and a camera, so I will still simply agree to disagree.

BTW, a spectrally calibrated and high quality camera could be used as a reflected light colorimeter. You would need an ACR option to select Lab mode as your color space instead of RGB. The Lab values could be easily converted to XYZ or the PS Info panel could offer an XYZ display option.

I do find Thomas Knolls comments to be on target. If I understood him, the math and matrices he refers to would be the CIE color matching functions that depend on spectral data about the sensor. Mapping the sensor data to XYZ coordinates (chromacity) is the fundamental objective of color matching. The data can be vendor provided, measured by another vendor (or the consumer), or simply a WAG. This is what could be in the ISO TIFF/EP tag or simply published.

As Tom states, the data is not a linear combination of the cone responses. Thats what color matching algorithms and tables address.

I assume, because Adobe tells me so, that some kind of calibration is done for each ACR supported model. I dont know what the steps are or how thorough it is because Adobe doesnt tell me. I am disappointed when I experience the effort required on my part to calibrate something that logically should already be close at least.

Cheers, Rags :-)

>Seems like Adobe is now behaving much like the camera vendors themselves!

I would modify this to read: Seems like Adobe is now behaving much less like the camera vendors themselves!

Adobe is not an open standards body, nor should they be. However Adobe--unlike the camera makers-- would support an open standards body much like the camera makers once did when they didn't own the film.

Rags Gardner wrote:
>> Chris was refuting a statement from Bruce Fraser. Bruces comment was similar to mine. Chris referred to some colorimeter filters. Colorimeters can and do use XYZ metrics. But to imply they use optical filters that match XYZ is a bit of a stretch. I dont think we need to go into the fundamental differences between a colorimeter and a camera, so I will still simply agree to disagree.

> I do find Thomas Knolls comments to be on target. If I understood him, the math and matrices he refers to would be the CIE color matching functions that depend on spectral data about the sensor. Mapping the sensor data to XYZ coordinates (chromacity) is the fundamental objective of color matching. The data can be vendor provided, measured by another vendor (or the consumer), or simply a WAG. This is what could be in the ISO TIFF/EP tag or simply published. <<

Rags,

I like to see it quite simple: IF the absorption spectra of Bayer R/G/B filters just have the same shape as any linear combination of the XYZ matching functions, then any RGB combo released from Bayer interpolation automatically refers to a matrix space. No rendering tables and no further effort would be required as just to determine the right matrix primaries via profiling.

In agreement with Thomas Knolls statement, thats not perfectly given with todays cameras. Using a matrix space to describe the input gamut will leave some rest-errors across all colors. Using a Lut-type input profile, like other Raw converter do, bears its own set of problems; but thats a different discussion.

>> I am disappointed when I experience the effort required on my part to calibrate something that logically should already be close at least. <<

Provided that unit-to-unit deviations play a subordinate role, ACR calibration cannot outperform the original profiling ref. to the sum of deviations across all colors (*). A redistribution of said rest-errors with a focus on memory colors can make sense; however, if a cameras gamut is too far away from matrix it doesnt rectify the situation in principle.

(*) Famous comparisons before vs. after / calibrated state vs. simulated target can create the polite fiction of an improvement via calibration. It ignores the side effect from tonal changes on color saturation. IMO, its more reasonable to assume that Adobes profiling software aims to balance the whole coloring hue and saturation - under consideration of the default tone curve from Shadows, Brightness and Contrast settings.

In short: where can I buy a matrix camera :)? Seriously, it would be kind if Adobe would give us a hint concerning the cameras which behaved best when both generic profiles were built (lowest rest-error).

Cheers, Peter

--

>(*) Famous comparisons before vs. after / calibrated state vs. simulated target can create the polite fiction of an improvement via calibration. It ignores the side effect from tonal changes on color saturation. IMO, its more reasonable to assume that Adobes profiling software aims to balance the whole coloring hue and saturation - under consideration of the default tone curve from Shadows, Brightness and Contrast settings.

Peter, good point. But I've found that saving one's initial tonal calibrations as a new default (along with color calibration) effectively overcomes this problem. Indeed, running Rags' (and Tom's)script(s) gave substatntially different color profiles depending upon the initial exposure and tonal settings. Clearly, tonal changes do have an effect on color with ACR, especially saturation.

I now leave shadows, contrast, saturation and curves at their new defaults (0,15,-9 and linear for my Canon 300D and 17-40 lens, for example) when applying the new color calibration(s). These values were obtained via an initial neutral patch calibration process. Occasional tweaks to white balance, exposure and brightness are now generally all that are needed prior to conversion using ACR.

I used to rely heavily on a time consuming process using curves and hue/saturation in PS to achieve correct color balance for routine work but now all that is generally needed (aside from the usual sharpening and occasional shadows/highlight adjustment) is a slight curves tone adjustment (in luminosity mode) to get things "right" in order to balance tone with accurate color. Noise problems for certain images have been substantially reduced, as well. And "default" skin tones are truly awesome for a change!

I have found that the further a given file deviates from the white balance used to shoot the color chart (5200K in my case) the more that hue or curves color adjustments are needed but it does appear that the reasonably accurate range for this given calibration temperature is from 4800K up to 5600K or so. Outside of this range corrections become increasingly necessary but still far short of that needed when using an uncalibrated RAW conversion.

Color (and tone) calibration has proven to be a substantial time saver for me even though I struggled to figure things out initially. But selectively using bits and pieces of advice from both Rags and Bruce Fraser in particular have been extremely helful. I'm also finding the ongoing technical discussion quite informative, as well.

It certainly would be beneficial if Adobe would provide more information so that others might profile their cameras/lenses more easily. It can be an intimidating process but I am beginning to suspect quite strongly that perhpas the outcome of Adobe's calibration process we see in ACR's initial defaults may simply represent an average for all cameras supported.

nunatak, I think your distinction between the data and the process is key here.

Presumably the profile used by ACR is the same as the profile held in a DNG file. We know what the formats of the latter is. (Transformation matrices that convert between CIE XYZ values and reference camera native color space values). And, for any particular camera model, it would be possible to examine a DNG file and see what the profile values actually are in that case.

So what appears to be lacking is a description of what Adobe do, from when they obtain suitable camera(s), to generate those transformation matrices. How much does it matter that we don't have this information?

>The point is that Camera Raw is probably not meant to work that way (at the side of Adobe). Theres a quite demanding test which can shed some light on this claim: Set ACR to camera default and whitebal the second gray, patch #20, of the target capture. Process the Raw-file at different Exposure settings from 4 EV up to +EV, just before clipping. Repeat the test with Shadows, Contrast and Brightness set to zero. For *every* processed image calculate the deltaHSB-Hue and Saturation compared to the simulated target (for every single color patch, to build the total amount then).

Interstingly, this is exactly what I've done to verify the effects on the color patches. I also used four different inital camera exposures of the same color chart for even more fun! Some authors have suggested exposure and tonal settings have no effect on calibration but I began to doubt this given my initial lack of success. My findings are that exposure has little impact but the opposite is true for tonal adjustments in ACR. But I've not done this experiment for all supported cameras by any means!

>My best guess is that the total error over all color patches will reach a minimum when Shadows, Brightness and Contrast are set to camera default, and Expose is set to (2 +/-1) EV.

Peter, I'm not sure what you mean by camera default but with your permission I will presume for now you mean that set by Adobe.

For my camera this didn't turn out to be the case. Exposure itself seemed to have no effect on *relative* color balance (ie proportion of RGB values) or relative tonal values. The tonal adjustments alternatively had a significant effect on the absolute and relative values for not only the neutral patches but color patches, as well. Obviously, white balance effects the relative values within a given patch so this, too is essential to do first using the second patch as you suggest.

Exposure of course has an effect on the absolute color values but I've found the relative values to be of primary importance. My *adjusted* camera (tonal) defaults work fine under any **reasonable** exposure adjustment but if I apply even a slight ACR curve or tweak shadows, contrast, saturation, etc. while using any given color profile, relative color values diverge significantly. I've confirmed this while keeping the Lindbloom chart open and using ACR and/or opening the adjusted image in PS.

>Also, theres a CurveTool-plugin for download which allows to realize tonal settings in PS without distorting hue & saturation again.

Making curves adjustments in luminosity mode does the same thing as far as I can tell (perhaps the plug in automates or improves upon this setting?). The plug in might be particularly useful if applied to the curve function in ACR, which significanlty affects color saturation AND relative color values (seems even more so than PS curves in normal mode) - not good.

Now some cameras may profile better with a certain curve set in ACR -an example of how Adobe could help out (even though it may be "illogical fallacy" to think they would be so cooperative). But for my particular camera, only a linear setting along with values previously posted would allow correct tonal calibration with the neutral patches. Your mileage may vary!

Indeed, I could not get the relative values for the RGB patches to get close enough until I made relative color corrections with the appropriate tonal adjustments in place.

I'm actually stunned that the new values have come so close to the Lindbloom chart and I'm certainly not complaining. But I don't pretend to understand why this is so from a technical standpoint. To be honest, I arrived at an acceptable calibration through lots of experimentation, mathematical calculation and persistance!

>you can (mostly) thank Ronald Reagen for that.

Nunatak, careful you don't fall off that big horse of yours, pardner! RAW formats are patentable, too. Seems a little cooperation from everyone would be to our mutual benefit.

Les,

Very good post, very clear. Let me try to comment:

>> Exposure itself seemed to have no effect on *relative* color balance (ie proportion of RGB values) or relative tonal values. The tonal adjustments alternatively had a significant effect on the absolute and relative values for not only the neutral patches but color patches, as well. <<

Afaik, the Exposure slider in Camera Raw simply executes a so-called linear scaling; it acts as a multiplier on all RGB data like a Levels-highlights slider. Therefore it should have no influence on the intensity ratios of R:G:B which are decisive for HSB-hue and saturation.

BUT, big but, this math happens before the tone curve comes into play. Its like a layer structure with the tone curve on the top. As you say, Shadows, Brightness and Contrast have a significant side effect on color saturation. And ref. to Adobes presets this side effect is not constant along the tonal scale.
Therefore, moving the Exposure slider left or right places the colors / RGB data beneath different sections of this tone curve. With a well-exposed ColorChecker, color saturation goes form high (at Exposure setting) to low at (at + Exposure setting, close to clipping). In-between, theres a quite stable range. Please check.

When you eliminate the tone curve by setting Shadows, Brightness and Contrast to zero, the Exposure slider should work truly linear again as described above.

>> Making curves adjustments in luminosity mode does the same thing as far as I can tell <<

Nope, I dont think so. Luminosity blend mode can often be better than plain RGB, e.g. regarding blackpoint setting or left-curved curves. But, just try a one-point brightening curve and color saturation will decrease Luminosity blend mode refers to a proprietary version of the HLS color model wherein the Luminosity is computed as a weighted average of G, R and B. In many aspects its close enough to Lab to share its advantages, but also its downsides. Whereas Simons CurveTools truly maintain the ratios of R:G:B.

>> Indeed, I could not get the relative values for the RGB patches to get close enough until I made relative color corrections with the appropriate tonal adjustments in place. <<

Interesting! This raises a basic question which I havent addressed carefully enough so far: Lets assume for a moment that a cameras native gamut would be a perfect matrix space. Would it still be possible to describe it as a matrix space based on colors which have already gone through a saturation-changing tone curve? I thought the latter would be Adobes strategy, to coordinate the preset tone curve with somewhat correct color. In your case, this seems to fail. That said, it has to be emphasized that such reverse-engineering always bears the risk to bark up the wrong tree. So it seems that I have to get clear on this point by some more experimentation, mathematical calculation and persistence. Thanks a lot for making me aware of this!

>> -an example of how Adobe could help out (even though it may be "illogical fallacy" to think they would be so cooperative). <<

To my knowledge, the only Adobe-official paper which mentions ACR calibration is this excellent article by Jeff Schewe. In my eyes, the chapter on ACR calibration has a certain reluctant touch.
http://www.adobe.com/digitalimag/pdfs/ps_workflow_sec2.pdf

Peter

--

The following calibration details will hopefully be useful to some and lead to further experimentation/refinement with color profiling. I am a botanist by training and not a color scientist so this information is striclty observational in nature!

I followed Bruce Fraser's methodology, in part, described in his article on the creativepro site. http://www.creativepro.com/story/feature/21351-1.html
Assuming folks are reasonbly familiar with the basic requirments of a properly exposed GretagMacbeth color chart and so forth, one begins by using the exposure slider to match the color values for the brightest patch of your capture with the values of the target. It's a good idea to check white balance first and make necessary corrections using the second lightest patch. See Bruce's article for more detail.

The brightness slider is then used to match the middle grey patch. Bruce continues to instruct how to use the contrast slider to get the second lightest and second darkest patches to match and finally use of the shadows slider to match the darkest patch is described. One word of caution. In the end, don't worry about the brightest patch after initial exposure adjustment. Just nail the other five neutral patches.

At this point I diverged from Bruce's suggestion to use the saturation slider to make the green value of the green patch match the target. For me this resulted in a nearly grey scale image and much frustration! So, I used the global saturation slider to adjust the red value for the red patch, green for green patch and blue for the blue patch so that they were all equally divergent from the target values (started out that red and blue patches were way off relative to green). Rags describes a similar approach on his website, as well.

I then saved everything thus far (except exposure) as the basic default settings for this particular camera.

At this point I calculated the fractional difference(s) between, for example, the R value relative to the G value for the target green patch, same for the B value for this patch. I did this for the red and blue patches, as well. Recognizing I would unlikely get the actual values to exactly match the target values, I surmised that the relative proportions of R,G and B for each patch were perhaps more important to nail down. Turns out this guess was correct and in the end the absolute values came in suprisingly close, as well (but only if I left ACR tonal values at their new defaults).

One can adjust the values of say the R and B values relative to G for the green patch using the hue and saturation sliders in the color calibration tab. The saturation slider (green for the green patch, for example) will move the R and B values for this patch further or closer to/from one another as needed (use the calculation done earlier to determine target values relative to the displayed value of the primary color) whereas the hue slider moves both values up or down equally relative to the G value in this example. Same for the other two color patches. I found it helpful to use the saturation slider first and then "slide" things into place with the hue adjustment.

It took only two iterations to get the "non-primary" values to match proportionately the calculated references from the GM color chart. For example, the ProPhoto version of the chart provides values of 85,123,67 for the green patch. Rather than try to match the absolute numbers, I strived to get the R and B values to be proportionate to the G value of the green patch on my captured file, which was 129 if I recall correctly. Simple calculation yielded 89 (as opposed to the target value of 85) for the green patch R value (85/123 x 129 = new R value = 89) and so forth (use same process for all threee patches). A couple of passes with the saturation slider to get the right "spread" and hue slider to move it all into the right "range" got things very close and also coincidentally moved the red and blue patches much closer in absloute terms than they were previously (couldn't do this when I tried this as my objective, though!).

Well, for what it's worth this is my attempt at reverse engineering Adobe's reverse engineering of the camera vendors stuff for at least one particular camera. Results so far are reasonably consistent and acceptable as long as I don't attempt tone corrections using ACR (after having set the new defaults) beyond exposure and brightness. Generally, any further corrections needed in Photoshop are relatively minor (and non destructive) unless particular creative goals are desired.

Les,

I think the touchstone for any existing or new calibration procedure is to risk an unbiased numerical comparison with Camera Raws native state. It requires to process the captured target in two different ways:

1.) in any preferred way which represents your new calibration.

2.) whitebal the second gray, set Exposure to minus 1, stay with the preset tonecurve from Shadows, Brightness and Contrast (shipping default, without auto-correction), Saturation 0, Luminosity curve linear and all Calibration tab sliders in their zero position.

After Raw processing, run a moderate Gaussian blur to average noise. Then, measure & calculate the difference to Bruces chart, respectively, in terms of deltaHSB-hue and deltaHSB-saturation for every single color patch. Take care to have everything in the same working space.
Key indicators are the sum of all deviations (ignoring +/-) as well as the number of patches which deviate by 5 steps or more; the troublemakers.

Would you like to support your proposal by adding the results of this test?

To be clear, I have no doubts that more pleasing results (observational in nature) can be achieved by a fortune redistribution of all color errors involved. Also, ACR calibration allows you to rededicate the coloring to a different tonal state (tonality and color are intimately connected with each other).
However, the core question is, if batch deviations of cameras can occur to a measurable extend, so that ACR calibration would effectively lead to a reduction of the total error.

Peter

--

Les,

If you will send me a text table of the RGB values you want to match to, I will send you a customized version of both of my scripts. Please dont just say Bruce Frasers or Bruce Lindblooms, I need the numbers you have selected. .

As to the precision, I would like to point out that any of these scripts are going to read the image patch values with a histogram. The histogram is limited to 256 levels (essentially 8-bit precision). This means that any given RGB measurement can be off by plus or minus one. Even if it is right on target in 16-bit mode. This is a limitation of the scripting interface.

It is a good idea to slightly defocus the target image shot. The best materials and lenses will still produce small specular reflections within the image. This and the selection sample size will smooth this out a bit. Otherwise you will see substantial pixel to pixel variations.

The color checker is purposely designed to occupy less than the dynamic range of a typical camera. So it should not reach either end of the histogram when properly exposed. That is why it is good to use a neutral mid tone for the background. And why contrast should be set with the equally distant mid tone patches (3.5 and 6.5) after the center point has been set based on the mid tone (0.5) patch.

In addition, a color checker should not contain any colors that are out of gamut for any color space being tested. This is basically true with this CC and the measured target values at illuminant D65. In sRGB with any other illuminant, there are some target colors that wind up out of gamut. With illuminant A (tungsten) all but ppRGB have some out of gamut colors.

That said, if you calibrate under ppRGB but your workflow is primarily aRGB, sRGB, or cmRGB you may find that your calibration yields out of gamut (clipped) CC colors anyway. I am putting a simple test for this in my next script update.

After calibration if the ends of the histogram have changed substantially you probably have some gamut concerns. This is why you want a mid tone background. Color values outside the range of the black and white patches should be suspect. The yellow tones seem to be particularly vexing in this respect.

If youre out this way, try some Rahr & Sons from Fort Worth.

Cheers, Rags :-)