I’ve always been a “nuts and bolts” sort of person, wanting to understand the specifics of whatever mechanism is placed in front of me. In their efforts to make the rather ungainly mechanism of digital photography accessible to most folk, a variety of insulating layers have been developed to facilitate such. I think sometimes these layers work at cross purposes, and as a result confound our understanding.
To attempt to lay-flat the mechanisms we’ve been discussing, here’s what I’d call the baseline processing needed to get to what is probably neutral in most of our understanding:
Of note is that this is a 14-bit raw, a somewhat technical tidbit we’ll talk about later.
So, if you look at the commands pane at the top left, the first thing in the chain is a group that contains all of the processing needed to get to a RGB image:
colorspace:camera,assign The first thing I do to any raw is to assign its color profile. One would think, oh no tone manipulation going on here, but indeed, what this assignment will be used for later is to convert the image to a gamut and tone suitable for display or output. Note the “CMS:display” at the bottom right, in the status bar; in my software this means that whatever tool you select for display will be converted to the display gamut AND tone, which is approximately a gamma curve of 2.2. More on this in a bit.
subtract:camera This is the simple subtraction of the camera-supplied value from each and every R, G, and B value of each pixel. Not all cameras have such a value in their metadata, this one’s is 1008.
whitebalance:camera Here’s the first place we really mess with the original measurements of light, each R, G, and B value in each pixel is multiplied by a camera-provided number, for this image those multipliers are 1.203125, 1.000000, and 2.121094 respectively. These numbers are what some previous mechanism determined it would take to make all three channels of a neutral pixel “neutral”, that is, R=G=B. Not strictly germane to the current tone discussion, but now the original measurements (well R and B, G was not really changed with 1.0) have lost their relationship to the presented energy.
demosaic:half This is my default demosaic for proofing. Normally I’ll change it to something better, but for this I’m leaving it as this particular demosaic does not change the R, G, and B values, it just uses them as-is in adjacent pixels.
Okay, now to the crux of the illustration. We’ve talked extensively about tone curves here, but not about the fundamental reason for doing them. That would be to put the camera’s notion of white at the value where the display or output will render it as such. The raw data, as 14-bit values, doesn’t align to any of these boundaries in current technology (most displays until recently have been 8-bit, as is the prevalent JPEG encoding), so, some kind of “normalization” is required. I usually do this here in the chain with a blackwhitepoint operator built for this purpose, but in this case I replaced it with a curve to graphically show the transform:
curve:rgb,0.0,0.0,53.0,255.0
Not “curvy” at all, this straight-line transform simply scales the data from its camera-defined limit to the upper end of internal data container in the software, which is used to anchor “display white”. The exposure tool in other softwares would do a similar thing, but you’d have to play with it a bit to get the highlights to just push up against “display white”. Interestingly, this operation doesn’t change what i think most consider the data’s “linearity”, as the relationships of the numbers are still such that one is “twice the size” or “half the size” of another, reflecting their original relationship with respect to the light energy.
So, to what we see here, how many manipulations of tone have happened? Well, in the toolchain, really none, ignoring the abomination that is white balance. At the conclusion of the curve, the data is scaled but still “linear” But, there’s one non-linear tone manipulation applied to get the displayed image, that being the camera → display profile transform. Here’s a graphic of such a tone curve:
This is not a “correct” gamma curve, I normalize it to top-off at white, but you should get this idea - the lower values of the image are lifted, and that lift tapers off for the upper values. After such a curve is applied to “linear” data, it’s no longer “linear”.
Okay, now to the crux of the matter, “Is it worthwhile struggling with input profiles?” Well, first off, they’re needed in order to assign the proper color characteristics to the camera’s raw data. But a profile has two sets of data, one for color, and one for tone. In the above illustration, the assigned camera profile says the data is “linear”. effectively has an “identity” tone transform, that is, one that doesn’t change the data. So all it does is provide the color information for later mapping gamut to the display or output. Later, that “linear” assertion is used to do the display transform. So, if you’re going to use such a camera input profile to change tone, you’re actually telling that later display/output transform that the data is something other than what it really is, which is “linear”. Not a very intuitive way to work with the data.
So, I think, most “camera look profiles” are actually meant to be applied after the original color/tone assignment. But, if you were to use a camera profile to also change the tone of the resulting image, you need to do so considering whatever other tone curves you might decide to apply later, such as automatch, filmic, or even a manual curve. To my mind, I’d rather do only one such tone curve, one that I can control through its entire range. And, I really only want to do one because the data analyst in me doesn’t like whipsawing data back and forth with multiple such operations.
The other thing to point out is that profile-based tone curves can also be LUTs, which don’t have to express a “nice” transform. That is, a LUT can do dis-continuous things between adjacent values. Heaven help us there…
Soooo, @obe, I haven’t done the histogram inspection of your images yet, will get to those later. I have been thinking of such an illustration of the raw processing chain for some time now, and it just seemed like this thread was ready for me to inflict it upon… 
Edit: sometimes we write things before we finish our coffee, note the strikeout…
? I would be better if the file names were displayed.
