Shooting Raw - Histograms & ETTR

[spidermike]

BJamnes - my reference to bit depth was that (or, more exactly, my assumption that) the greater bit depth in raw data led to the raw data having more headroom than the jpeg suggested: so when the jpeg data (and its associated histogram) showed the image was blown the raw data allowed you another stop or so before detail was unrecoverable.

But my first post was asking more that how can you have a 'raw histogram' - you need to interpret the raw data to have a histogram and that 'interpretatoin' is the jpeg file on which a histogram is based.

[spidermike]

• Optimise exposure for JPEG - pretty much as is
• Optimise exposure for RAW - giving me a choice of parameters that I can choose / set so that I can realise my vision

Optimising or raw relies on  you knowing from experience how the raw data relates to the jpeg data. On one camera model you will learn that you can expose so that the extreme of hte histogram si just touching the right hand edge, but on another camera you know that you can take it a tad further and still be OK with the raw data. But even then you still need to know how to interpret the histogram to know what you are looking at - for example if there is a small blip at the right hand ege is that specular highlights (reflections off turbulent water) or is that important detail (white feathers of a coot).


But I repeat my earlier question: is there anything such as a 'raw histogram'? How does a 'raw histogram' differ from a 'jpeg histogram'? Raw data needs to be interpreted into a picture to make any sense regards exposure and that is precisely what the jpeg picture does - and by changing the in-camera profile you change the histogram.

[Bart_van_der_Wolf]

But I repeat my earlier question: is there anything such as a 'raw histogram'? How does a 'raw histogram' differ from a 'jpeg histogram'?

Hi,

A Raw histogram shows the Raw data, i.e. before White Balancing which might push some values into clipping (e.g. Red flowers). The Raw data histogram then tell us that the clipped values are purely the result of post-processing, and can therefore be completely restored with proper scaling in linear gamma space, before White Balancing. For example, RawTherapee does allow such corrections to be applied before demosaicing.

Cheers,
Bart

[bjanes]

But I repeat my earlier question: is there anything such as a 'raw histogram'? How does a 'raw histogram' differ from a 'jpeg histogram'? Raw data needs to be interpreted into a picture to make any sense regards exposure and that is precisely what the jpeg picture does - and by changing the in-camera profile you change the histogram.

The raw data do not need to be demosaiced or otherwise interpreted in order to calculate a raw histogram. One can work directly with the raw channels, but frequently the values are binned into a number of levels which are shown in a frequency distribution (e.g. Rawdigger), but at least one program (Histogrammar) allows direct plotting (1:1) with no binning.

Bill

[torger]

I tried uniwb once with my Canon but I think it's a bit messy to have a crazy white balance in the preview so I did not think it's worth it. Instead my approach is to make some tests and see how the histogram statistically relates to raw exposure. Getting the feel for the histogram and how much you can clip in various conditions one can expose well anyway.

ETTR may not be as important with cameras equipped with the low noise Sony Exmor, like the D800, but for my Canon and my MF backs is still rather important. In any case a raw histogram and raw highlight blinkies would not hurt to have as a setting for advanced users so I find it a bit frustrating that manufacturers are so clueless about this. I don't know of any camera with a properly designed raw histogram, out of the box.

We will probably never get it either, as sensors get less and less noisy it will be less and less important with ETTR and thus we'll care less about raw histograms, the exposure new standard will be like it was with slide film - if the preview looks good then the exposure is good (and that's been the thinking all along with the manufacturers).

In most cases the histogram is conservative, ie clips before the raw clips. But in some conditions it can be the opposite, ie the raw clips despite there's no clipping in the histogram and that's not good. For example if the histogram show luminance and there's a bright red color this can happen.

[digitaldog]

BJamnes - my reference to bit depth was that (or, more exactly, my assumption that) the greater bit depth in raw data led to the raw data having more headroom than the jpeg suggested: so when the jpeg data (and its associated histogram) showed the image was blown the raw data allowed you another stop or so before detail was unrecoverable.

Yes and no. Yes, there’s more bit depth, more data for editing the data before we may see damage (posterization) but no in terms of DR which is an attribute of the capture system. The JPEG looked blown out because the rendering from raw was incorrect. The raw allowed us to fix that issue but that data was there, no matter the bit depth. The JPEG is one (incorrect) answer from the raw data, bit depth not at that point being the factor.

[spidermike]

Thank you again for clarifying it, guys.

[dwswager]

So if setting up a 'ETTR program' to work with raw data in camera, what is the limit - one pixel that excees the 'well threshold limit'? Or 1% of pixels? Or 10%? Do you base it on that 10% pixels being contiguous or scattered anywhere on the sensor? 
By the time you have sorted that out you may as well fire off a set of backeted exposures and pick the one that suits your desired output.

Yes, the ETTR case is the hard case.  And all of what I think is missing is highly dependent on processing and onboard power; two very real constraints.  And I certainly agree from a practical standpoint, shooting a bracketed set of exposures is probably going to be the best option in most cases.  But the JPEG has a gamma correction applied while the RAW data is nominally linear.  That is, the RAW data is already being manipulated by the processor.  What I am asking a new mode of manipulation at the RAW level.  And of course, some sort of setpoint needs to be decided.  Since the case for ETTR is based on a situation where the scene is within the DR of the camera and over exposing to pull detail out of the shadow region where very few data bits are used up to a higher level where more data bits are utilized, we should be looking at no to very minimal highlight clipping.  Maybe in ETTR mode, Expose Compensation on the camera acts as a 'gross' adjustment to the clipping setpoint. 

[mouse]

The raw data do not need to be demosaiced or otherwise interpreted in order to calculate a raw histogram. One can work directly with the raw channels, but frequently the values are binned into a number of levels which are shown in a frequency distribution (e.g. Rawdigger), but at least one program (Histogrammar) allows direct plotting (1:1) with no binning.

Bill

If I understand the process correctly, analog data from the sensor must, in all cases, be "binned" at the point where the A/D converter writes the data to a (digitally encoded) file.  I believe Rawdigger allows one to adjust the size of the bins, while Histogrammar uses bins at the maximum resolution of the bit depth used to write the raw file.

Please correct me if I am wrong.

[Guillermo Luijk]

RAW data are not binned in any way, and can be read 'unbinned', i.e. as a single value corresponding to one RAW channel for every sensel in the CFA (R, G1, G2, B).

In fact one day I started to improve Histogrammar to differentiate the G1 from the G2 green subchannels (some sensors like the old Panasonic's for some reason suffer from G unbalancing and I wanted to study that), but got a bit mad to build all the possible colour combinations needed for a beautiful colour histogram. For 3 channels this is trivial but 4 require quite a lot of extra effort.

BTW the RAW histogram + Auto ETTR story seems a lost battle. ETTR will loose all interest before camera makers decide to look at it:

http://www.luminous-landscape.com/forum/index.php?topic=33267

Regards!

[mouse]

Guillermo-

I think perhaps that I have a different (perhaps incorrect) understanding of "binning".  I would like to resolve that issue but don't wish to hijack this thread in that direction.  I have taken the liberty of sending you an e-mail.

Regards,
Mike.

[dwswager]

Guillermo-

I think perhaps that I have a different (perhaps incorrect) understanding of "binning".  I would like to resolve that issue but don't wish to hijack this thread in that direction.  I have taken the liberty of sending you an e-mail.

Regards,
Mike.

'Binning' is exactly the process of building a histogram...how many in this interval tells the height of the histogram at that interval.   Hence, I don't think it is hijacking, but clarifying.

[Guillermo Luijk]

Guillermo-

I think perhaps that I have a different (perhaps incorrect) understanding of "binning".  I would like to resolve that issue but don't wish to hijack this thread in that direction.  I have taken the liberty of sending you an e-mail.

Regards,
Mike.

Sorry Mike I thought by binning you meant the mixing of the G1 and G2 RAW channels. I wanted Histogrammar to have the possibility to go up to 1:1 zoom as Bill explains. You can produce histograms 65536 long.

I also kept all the 'bins' at every lower zoom level as power of two containers, so that the shape of the histogram never leads to confusion (in log mode some peaks can arise specially in the deep shadows though, but this is expected due to level quantization).

[fdisilvestro]

Hi,

A Raw histogram shows the Raw data, i.e. before White Balancing which might push some values into clipping (e.g. Red flowers). The Raw data histogram then tell us that the clipped values are purely the result of post-processing, and can therefore be completely restored with proper scaling in linear gamma space, before White Balancing. For example, RawTherapee does allow such corrections to be applied before demosaicing.

Cheers,
Bart

Hi,

White balance is not the only issue with non-Raw histograms which can show clipping. Color space encoding is another factor, responsible of the majority of the "Red blown channels" complaints.

RAW channels: luminance values of each photosite
JPeg or TIFF: RGB values (a coupled combination of luminance, hue and saturation)

If you have a clipped raw channel, it means you have exceeded the maximum value of luminance that the sensor can handle (excesive exposure)
If you have a clipped RGB channel, you don't know if it is because of excesive exposure or due to saturation, which could be caused by using a small color space such as sRGB.

If the issue is saturation, reducing exposure is the wrong approach to solve the problem. Additionally, you might have saturation clipping of some colors that do not show as clipped channels in RGB; for instance, a saturated cyan is represented as a zero value in the red channel. Now, how do you know if a zero value in the red channel is because of a deep shadow or a clipped cyan?

[Guillermo Luijk]

Additionally, you might have saturation clipping of some colors that do not show as clipped channels in RGB; for instance, a saturated cyan is represented as a zero value in the red channel. Now, how do you know if a zero value in the red channel is because of a deep shadow or a clipped cyan?

But these saturations (I mean the ones making some RGB channel get clipped to zero after the colour profile conversion), are irrelevant in the histogram accuracy exposure.

The dangerous is the opposite case: a RAW channel is clipped but after the colour profile conversion (typ. linear combination of all three channels) that particular RGB value is not clipped in the JPEG. I think this is the main source of false negatives when using UniWB.

Regards.

[bjanes]

ETTR may not be as important with cameras equipped with the low noise Sony Exmor, like the D800, but for my Canon and my MF backs is still rather important. In any case a raw histogram and raw highlight blinkies would not hurt to have as a setting for advanced users so I find it a bit frustrating that manufacturers are so clueless about this. I don't know of any camera with a properly designed raw histogram, out of the box.

We will probably never get it either, as sensors get less and less noisy it will be less and less important with ETTR and thus we'll care less about raw histograms, the exposure new standard will be like it was with slide film - if the preview looks good then the exposure is good (and that's been the thinking all along with the manufacturers).

I agree that with the Exmor sensors ETTR is less critical than with older designs. However, shot noise predominates in all but darkest shadows, and it is still important to maximize SNR by collecting as many photons as possible. The main advance with the Exmor is in reducing read noise, but shot noise is inherent in the light before it hits the sensor and the Exmor can not do anything about this.

Bill

[fdisilvestro]

But these saturations (I mean the ones making some RGB channel get clipped to zero after the colour profile conversion), are irrelevant in the histogram accuracy exposure.

The dangerous is the opposite case: a RAW channel is clipped but after the colour profile conversion (typ. linear combination of all three channels) that particular RGB value is not clipped in the JPEG. I think this is the main source of false negatives when using UniWB.

Regards.

100% Agree.

The point I was trying to make is that making exposure decision based on RGB histograms might be wrong. In any internet photography forum there are people complaining about blown out reds and often the proposed solution is to reduce exposure, which I consider wrong. The same issue with cyan goes completely unnoticed (the majority of images with a blue sky in them in sRGB have clipped cyan) and nobody would even think to solve an issue where a channel is zero (Red in the case of clipped cyan) by reducing exposure.

A RGB histogram, even with uniWB, is an unreliable tool to determine exposure

[Bart_van_der_Wolf]

I agree that with the Exmor sensors ETTR is less critical than with older designs. However, shot noise predominates in all but darkest shadows, and it is still important to maximize SNR by collecting as many photons as possible. The main advance with the Exmor is in reducing read noise, but shot noise is inherent in the light before it hits the sensor and the Exmor can not do anything about this.

I fully agree with Bill, ETTR is about optimizing the amount of captured photons. All the rest is post-processing, scaling the channel responses in Linear gamma space to avoid irreversible data loss as much as possible. Post-processing with floating point number math is IMHO indispensable for that. For example RawTherapee does that, and that immediately opens up lots of possibilities.

Cheers,
Bart

[mouse]

Sorry Mike I thought by binning you meant the mixing of the G1 and G2 RAW channels. I wanted Histogrammar to have the possibility to go up to 1:1 zoom as Bill explains. You can produce histograms 65536 long.

I also kept all the 'bins' at every lower zoom level as power of two containers, so that the shape of the histogram never leads to confusion (in log mode some peaks can arise specially in the deep shadows though, but this is expected due to level quantization).

Guillermo,

Thanks for your reply.  My notion of "binning" is simply the process of converting the analog (voltage) values as they are read from the sensor to digital values which are written to the raw file.  I assume this occurs in the A/D converter whereby the total range of analog values are divided (binned) into equally spaced voltage intervals; the number of such intervals being determined by the bit depth of the converter.  Thus, for example, a 14 bit pipeline will allow the recording of 16683 discrete intervals (or bins) each of which is identified by an unique digital integer.  The histogram then graphs the total number of pixels (sensels) falling within each of those intervals.

If I correctly understand your Histogrammar (a program I have happily used for several years), you elect to expand the number of bins to 65535 (regardless of the bit depth of the raw file); which means that it will display the data from every fourth bin from a raw (14 bit) file containing 16683 such intervals.

Any corrections to my admittedly very basic understanding will be gratefully received.

[Guillermo Luijk]

Histogrammar only plots histograms from 16-bit TIFF image files. How can it plot RAW histograms then? thanks to DCRAW's -d and -D commands, that put undemosaiced data values from any RAW file as gray levels into a 16-bit monochrome TIFF following the camera CFA:



Histogrammar's RAW mode simply interprets each gray level as R, G1, G2 or B according to its position in the grayscale image and plots the histogram. The -D command specifically just takes the RAW numbers and puts them in the TIFF file. The -d command allows to obtain the RAW data at EV intervals since it normalizes the RAW data to the 0..65535 range.

E.g. this is a Canon 5D RAW histogram showing how the camera saturates at 3692. The histogram runs up to 65535 but all levels beyond 3692 are empty:



Of course I'd find Rawdigger today much more user friendly.