Exposure control in a raw developer: misnomer?

Started Jan 30, 2013 | Discussions thread
Detail Man
Detail Man Forum Pro • Posts: 16,688
Re: Absolutely correct.

gollywop wrote:

gollywop wrote:

Detail Man wrote:

gollywop wrote:

panos_m wrote:

gollywop wrote:

Well, there is a distinction to be made. In the earlier days of ACR, Exposure was basically an ISO slider that essentially multiplied all values by a given amount, altering all values in the same proportion (and quite able to blow out highlights). The "brightness control," by contrast, boosted the mids while holding the ends fixed; it was more nearly like taking a "curves" and lifting the center.

Raw converters like RPP have a Compressed Exposure slider that multiplies the exposure values up to a point, but compresses the highlights in the top, say, 2 EV to keep the highlights from clipping.

Nowadays, ACR doesn't have a "brightness" control in the sense of above, but you can achieve the same end in a number of ways.

So, rather than call the "exposure" control Rendered Brightness, I'd rather see it called ISO, or gain, or Exposure Multiplier. It clearly increases the brightness of the image (and doesn't in any way affect the image's actual exposure), but it doesn't protect the highlights, which is what a "brightness" control ought to do.

LR4s (and I assume latest ACR) exposure slider is not a linear adjustment. So it is still some kind of curve - brightness adjustment control. So it cannot be called a software ISO control.

This is true. But the current LR/ACR exposure control still affects all levels, more or less proportionately, except that there is a bit of a roll-off at the high end to provide some (but by no means complete) protection of the highlights. ISO still comes closer than "exposure," but I would still prefer Exposure Multiplier.

Have you tried testing it using the DNG RAW-levels test-chart that exdeejjjaaaa recently posted:

http://forums.dpreview.com/forums/thread/3371122

Well that's interesting. Scalar Badness may well be the proper term.

I took the exdeejjjaaaa chart and scaled it in ACR using the point curve to make sure the luminances incremented at 5 units. It required a base scalar badness of -1 EV to fit the chart fully into ACR's scope using Adobe RGB (which is, as I recall, what exdeejjjaaaa indicated was the proper profile). I was then able to follow the luminance reading of any square as I incremented the scalar badness slider.

If you take any one of the squares and follow its luminance (0-255) as the scalar badness increments in 1 EV steps (from -5 EV to + 5 EV), you get a progression like 14, 22, 33, 49, 70, 96, 131, 174, 216 241, 252, 254, 255. There are more than 11 figures here because I measured the progression on several levels of luminance. They tracked just about exactly where they overlapped.

That makes luminance increments of 8, 11, 16, 21, 26, 35, 43, 42, 25, 11, 2, 1, increasing up to roughly middle grays (130-174), then decreasing and getting squeezed to clipping. This is definitely non-linear with considerable compression going on above roughly middle gray and eventually getting pushed over the edge. The middle gray square (130), for example, clips at + 4.3 EV of scalar badness.

Beyond 4.3 EV of scalar badness, the cliff edge comes quickly. At 5 EV of scalar badness, the top 30 squares are clipped, the next 5 are at 254, and the next 4 are at 250-253. That leaves only the bottom row below 150.

So, if you're interested, the relation between scalar badness (sb) and luminance level roughly follows a cubic:

lum = 174.89 + 34.03sb - 1.40sb^2 - 0.45sb^3

A fourth power, also negative, is of marginal significance and begins to get confounded with the lower-order powers. R^2 = 0.996 and the SER is 7.3. The errors in the shadows are fairly high, but those toward the high-end tail are smaller than I would have expected. The errors are

{-7.07418, 5.36264, 7.52897, 4.1049, -2.22952, -8.79421, -8.90909, -0.894106, 8.93082, 7.24575, -0.269231, -5.93407, 0.931319}

Regarding "hue-twisting", referring to our previous conversation (when you were using CR 6.x at the time), I take it that your color-profiles being used are all (deliberately) "untwisted" (using "DCPtool) ?

http://dcptool.sourceforge.net/Introduction.html

http://forums.dpreview.com/forums/post/41424601

You (in the above post) predicted that CR 7.x would continue to apply similar "hue-twists". A fair bet? As the twisting occurred when using CR 6.x "Highlight Recovery", I have wondered if the same behaviour (relative to "untwisted" color-profiles) now also applies to all of the various tone-level control-sliders that have functionally replaced the "Highlight Recovery" control-slider in CR 7.x ?

Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow