The point of the Raw Tone Curve (?)


Posting rules: It shouldn't need saying, but... play nice. Please keep your discussions civil. You can disagree, just don't be disagreeable. And, of course, all of the usual stuff like no spamming. Tex adds: I'll be rigorously enforcing this as we go along. We're probably going to be a small community in a little lifeboat, so we can't have members at each others' throats. This is for the sake of the project as a whole. So when you post, pretend you're speaking in person with your very wealthy auntie who has always treated you wonderfully and currently lists you prominently in her will. I won't be tossing anyone out of the forums because we are all in this together (except spammers: immediate membership cancelation), but I'll delete suspect posts right away.


9 posts / 0 new
Last post
Doug
The point of the Raw Tone Curve (?)

Reto commented to me about how a Raw Tone Curve isn't always "one size fits all." We've already seen that with the Panasonic GF2, where the in-camera JPEG processing uses a very different tone curve.

That got me to thinking about what the Raw Tone Curve is doing, and why. I can't say that I've come up with a definitive answer, so I'm looking for anyone else's thoughts on the matter.

The Raw Tone Curve adjusts what in film is called the D-logE curve: the relationship between the amount of light received during exposure and the resulting tone in the image. As implemented by the random sample that I made of the ones supplied by Light Crafts, and therefore as implemented in the ones I've been making (except for the "softer" GF2 curve), the Raw Tone Curves try for a linear 1:1 D-logE curve, but there tends to be a roll-off at the "shoulder" and "toe". The softer GF2 curve is a lot more roll-off and a lot less linear; this gives more definition in the highlights and shadows, at the expense of apparent contrast.

But, but, but... a digital sensor element already has a constant photons-to-level response, which means that the D-logE curve is already 1:1 except that it goes flat at "empty" and "full". So why do we need a Raw Tone Curve to take our Raw sensor data and give it a 1:1 D-logE response?

My guess is that the answer lies somewhere in LightZone's proprietary de-mosaicing algorithm. If you didn't know, since version 1.5 LightZone has done its own de-mosaicing. The original reason for that is speed; I don't know if that was the final reason. No matter the reason, the point is that LZ does Raw de-mosaicing in a unique manner.

I believe that LZ's demosaicing process does something that significantly affects the brightness in the resulting RGB data. Not only is the result no longer a 1:1 D-logE curve, the data doesn't reach all the way to black nor all the way to white. Here's another clue that points that way: the Browser side of LZ uses dcraw to do the de-mosaicing. When you're looking at your images in the LZ Browser, they look fine — the blacks are black, the whites are white, and the contrast is reasonable. If you then open that same image in the Editor part of LZ (which uses LightZone's de-mosaicing algorithm), unlock the Raw Tone Curve and uncheck it, what you'll see is a relatively flat image. The standard "1:1" Raw Tone Curve typically pushes the highlights way up, the shadows way down, and in the process stretches the midtones to have much higher contrast. Fortunately, we're working with 16-bit data and the original Raw data is usually only 12 or 14 bits, so we have some room to push the tone curve around without losing subtle detail from the image.

Is this intentional? Does LZ's de-mosaicing intentionally use a tone mapping that emphasizes detail in the highlights and shadows? Maybe so; the Relight tool certainly could take advantage of that. On the other hand, Relight is usually placed above the Raw Tone Curve in the tool stack, so it's working with data that's been re-adjusted back to something close to a 1:1 D-logE curve.

Another puzzler for me is that the Raw Tone Curve is different for different sensors. That suggests to me that the LZ de-mosaicing process is very dependent on the color matrices being used.

tex
Huh, that's pretty fascinating...

...and a good catch on that post from Fabio. While I have nothing intelligent to say about LZ's proprietary de-mosaicing, I'll add this on the browser and the zonemapper curves: 1. I always thought the browser used the embedded jpg that a raw has attached for preview purposes (for instance on the camera's own lcd screen for after shot chimping). Is this not correct? I thought I got that from LC. 2. Yes, I have seen some bizarre raw Zonemapper settings. The Oly E-500 was one of them, and we had a thread in the old forums from an E-500 user that had harsh highlight clipping as a result of this raw Zonemapper setting. I've seen a couple of other very odd looking settings with my own cameras, Oly and Sony.

SFA
I'm with tex on the use of

I'm with tex on the use of the emedded jpg for the preview of the RAW file.

I have an elderly (by digital standards) Canon Pro1 that uses 'unsupported' CRW RAW files. The preview looks just like a jpg but open the file and a Tone Curve profile is plucked from somewhere as a default (nothing in the RAW tools for that one) and the coloours come across sort of OK but rather different.

I have played with other Tone Curves to get a better initial opening colour and contrast balance but there seem to be a couple of 'flip' points where things suddenly change. The screen handling I have available does not seem to offer enough adjustment resolution to make the fine adjustments required. Either that or it's just not possible with that camera - though I have seen similar results with other sensors from time to time.

Good work on the site people. I'm hoping it will keep us going for quite some time.

Grant

Doug
Use of embedded preview

I've looked into this, and from the code it appears that the embedded preview is indeed used for the thumbnails in the browser, but that the large preview image in the browser is created by dcraw set to sRGB output. The image in the Edit window is created by LightZone demosaicing, although for certain cameras with unusual sensor designs, LZ can have dcraw do the demosaicing.

I've updated the github wiki dcraw page to document the dcraw parameters used by LightZone.

SFA
Hmm, that's interesting. It

Hmm, that's interesting. It sort of explains what one can see as things change during image selections and loads.

What happens to jpgs during the edit? I assume that they are simply opened as they are with more or less resolution/compression according to the currently set screen size. However if the original was stored as AdobeRGB (for example) does it get converted to sRGB for display or is it left as it is but edited in sRGB mode?

Grant Perkins

SFA
Some more observations and questions re. Raw Tone Curves.

I recently obtained a Canon S90 and a G11, both of which offer RAW capability. The S90 is a 2 year old technology device and the G11 about the same based on launch dates. I didn't give it much thought until just now but having now run off a few hundred frames on each and tweaked some of them with LZ .... the RAw Tone Curve looks to be OK. But, given the age of the devices and the paucity of updates from around the time of launch, what are they using as their defaults? Did they just sneak in to the last batch of official updates? I guess I will have to go digging in the windows folders ....

Another question that comes to mind is about the difference between Luminosity Mode and RGB nmoe in the Zone Mappers and notable the use of RGB mode in the RAW Tone Curve.

The differences seem to be very subtle and I have always assumed that the use of the RGB curve is basically a means of balancing the colour response curves from the sensor. This woould be in line with options for Curve tools in other applications. However that seems a bit simplistic and as such the visible controls seem to lack the breadth of adjustment possibilities available elsewhere.

Maybe that is intentional? Is the underlying code smart enough to be able to set boundaries to constrain adjustments. Applications based oin 'traditional' graphics editors would (and still do) allow wild adjustments of curves but LZ seems to constrin the excesses and I seem to recall that LightRoom also constrains its adustment boundaries when using curves. It's sensible to do so for photos - LZ was the first application I discovered that seemed to be able to prevent a would be picture editor's over-exuberance with a curve tool.

However I'm not at all asure that I understand the difference between Luminosity and RGB modes well enough to get the best out of the feature Zone Mapper or RAW Tone Mapper feature.

Grant

Doug
Gah.

Oh, <expletive>. Grant's right: the raw tone curves are supposed to be in RGB mode, and I forgot that on a few that I did. I've had to fix them.

The difference between Luminosity mode and RGB mode is fairly straight-forward. The Luminosity mode is what you'd normally use; it adjusts the pixels to give a different brightness level without affecting the color. The RGB mode adjusts each of the colors in the pixels separately.

Suppose we have a ZoneMapper that takes 100->200, 50->50, and 25->10. It's increasing the contrast over that range. Now let's look at a purplish pixel with RGB=(50,25,100). If we adjust this in Luminosity mode, LightZone will need to calculate the luminance of that pixel. Assuming it's using Rec. 709 coefficients, we'll end up with a luminance of 36 or so. (Just for example's sake) we'll say that 36->28, so that's a reduction by a factor of 2/9. The resulting pixel will be (39,19,78), which will be the same color but darker.

But if we do the transformation in RGB mode, each color channel is transformed separately. The resulting pixel will be (50,10,200), which has a luminance of 32 instead of 28, and is a more saturated purple with a larger blue component.

So for ordinary purposes, we want to use the Luminosity mode. That gives us the expected adjustment in brightness without a color shift.

For the Raw Tone Curves, though, we want to use RGB mode. The raw tone curves are compensating for a tonal transformation that was applied separately to each color channel, so we need the compensation to be applied separately to each color channel. Or at least, that seems to be the case.

AdrianP
Grant is right!

Doug very kindly built the Panasonic GF2 curve for me the other week then, even more kindly, rebuilt a softer, more aesthetically pleasing version. The contrast characteristics were fine but the colours were a fair bit washed out. In fact, I spent quite a bit of last week downloading studio raw files for other cameras and measuring the RGB and saturation levels of colour patches with the sample tool. In short, the GF2 measurements where characterised by much less saturated colours than every other raw file that I measured. Having read Grant and Doug's post above, I re-tried this with the GF2 raw tone curve now set to RGB instead of luminosity and wow, what a big improvement. There seems to be no contrast shift at all but the colours both look and measure as being much more saturated.

I've now saved the new RGB settings into the default GF2 raw tone curve. Doug, is it simply a matter of changing mode the saving or does the actual curve need to be re-calculated? Either way, Grant's revelation has hit me like a thunderbolt and has helped me get my GF2 images much closer to my liking right out of the box. So many thanks to both of you!

Adrian

Doug
Luminosity, RGB, and my messed-up Raw Tone Curves

Adrian, switching to RGB mode is all that should be needed. The Raw Tone Curves are determined by looking at gray-scale data, so there were no color-sensitive effects introduced during production.