# How to correctly calculate the Dynamic Range of an image

I'm trying to compare the dynamic range of a correctly exposed LDR picture with the dynamic range of the HDR image obtained with 3 LDR pictures.

Right now I'm calculating the DR as:

`````` stops = log2(max) - log2(min);
``````

Where

``````max = maximum pixel value found in the image
min = minimum pixel value found in the image
``````

The reference correctly exposed image is an 8 bits Jpeg, so the dynamic range is always 8 stops, since the values goes from 0 to 255. The HDR image is an RGBe radiance map, so the values are 32 bits floating point.

I was wondering a few things:

1. Is this the correct way to calculate the dynamic range from a picture?
2. All jpg files have pixel values from 0 to 255, so every correctly exposed jpg will have the same dynamic range. Is this right?
3. Sometimes the calculated dynamic range of the HDR image is lower than the original. How is this possible?

Thank you for your help

EDIT: adding an image to better explain my reasoning

Left: standard correcly exposed image - Right: HDR image blended from 3 bracketed photos

• re 2: all jpegs using the full 0..255 range have the same dynamic range but not all real world images have so much dynamic. therefore, no, not every jpeg has the same dynamic range. Oct 3 '19 at 12:26
• as for 3, this obviously depends on the processing. you can artificially increase or decrease (tonemapping) at will. if, however, the goal of the LDR image stacking is to faithfully represent the real world luminance and the resulting HDR dynamic range is lower than LDR source images then something must have gone wrong. Oct 3 '19 at 12:31
• In the end, I'd like to calculate how much the dynamic range is increased after the HDR blending. I feel like it should always be greater, but sometimes it's not and many times is just a little bit greater but that's it. I feel like I'm doing something wrong. So I was wondering, how would you guys do it? Because that formula I'm using may be good for calculating the DR of the sensor knowing the noise voltage and the full well capacity voltage, but maybe it's not when you just have pixel values. What would you guys do?
– gbos
Oct 3 '19 at 13:19
• Do you want to calculate the DR of the contents of the 32-bit floating point file? Or the DR when it is displayed on your screen in 8-bits? Oct 4 '19 at 7:05
• "The reference correctly exposed image is an 8 bits Jpeg, so the dynamic range is always 8 stops, since the values goes from 0 to 255." is an incorrect premise in several ways. Oct 6 '19 at 19:55

First, regardless of the particular dynamic range definition, calculating "anything vs zero" luminance is not useful, because then the ratio becomes infinite. Your:

``````log2(max)-log2(0)
``````

is another way of saying:

``````log(max/0)
``````

and we can't divide by zero (and log2(0) is undefined)

So let's forget the 0 for now (zero means the image is not well exposed anyway because you can't have any detail at level 0), then, indeed:

``````log2(255)-log2(1) = ~8 (EV)
``````

But this is not the dynamic range either, because in JPEG (and sRGB in general) pixel values are not pixel luminance.

Taking the proper gamma formula into account, we finally get:

``````log2(1)-log2(1/3294.6) = ~12 (EV)
``````

• yeah obviously I don't do log(0), if the min is 0 I just put 1. Anyway, is 12 EVs the screen dynamic range?
– gbos
Oct 3 '19 at 13:14
• anyone, I added a photo to try to explain better the problem
– gbos
Oct 8 '19 at 14:37

The end result of High Dynamic Range Imaging (HDRI) is not to produce an image with dynamic range as high as the scene it attempts to reproduce. We do not have display technology available that can do that. At least not practical ones.

The aim of HDRI is to take a very high dynamic range scene and reproduce it in a way that we can see the very bright and the very dark details in the actual scene using our limited display technologies that have a much more limited dynamic range.

It's not a whole lot different than when Ansel Adams used the zone system to capture up to 14 stops of dynamic range on his negatives and then squeeze all of that information onto papers that were capable of only 6-8 stops of dynamic range.

In other words, we're fitting the high dynamic range of a scene into our low dynamic range display technologies. Thus the end result of HDRI is a low dynamic range image that includes as many details as possible from a high dynamic range scene.

• But it's also true that in an HDR you can see more details on the shadows or highlights. This means that you were able to reproduce more DR than with a single photo. I'd like to calculate this improvement.
– gbos
Oct 4 '19 at 8:28
• You're not reproducing more dynamic range. You're reducing the dynamic range between the brightest and darkest parts of the image. You're still bound by the limits of your display technology's dynamic range. Oct 5 '19 at 8:52
• yes sure, but I'm not talking about the display dynamic range. I'm talking about what the photo can capture more. If a HDR photo have more details both in shadows and highlight (that were clipped in the original photo), this means that there's some more data in that photo, that I could capture more details of the scene in one time. I was wondering how to quantify this.
– gbos
Oct 5 '19 at 9:03
• If an HDR photo has more details that can be recovered, it wasn't clipped in the original image(s), it was clipped when that raw data was converted to a viewable image. How to quantify this? You test the camera and see how many stops of DR it is able to capture between the noise floor and full well capacity. There are plenty of online resources that have already done that for many cameras. You then use a light meter with a very narrow angle to meter the brightest and darkest details in a scene you wish to capture, and compare that to the results of the sensor/camera test. Oct 6 '19 at 6:52
• This will tell you if you can capture it with a single raw exposure, or if you will need multiple exposures and if so, over what total dynamic range. Oct 6 '19 at 6:54

Firstly, an 8bit jpeg is 24bit color; 8bits per color. Your 32bit HDR is also 8bit per color plus an additional 8bit shared channel (Alpha).

Secondly, not every correctly exposed image will have values from min (black/0) to max (white/255). HDR is rewriting values to fit w/in the display/reproduction capability... if in that process it eliminates any true blacks or whites that exist in the original then the result will be a reduced DR.

You are not wanting to measure the difference between min/max, that will always be the same due to the limitations of reproduction/display. What you want to measure is the difference in the number of steps/values that exist in between min and max.

I.e. an image that only has black and white values only contains two stops of dynamic range. Whereas an image that has black, white, and mid grey has three stops (values) of DR displayed within the image; even though black and white are equally as far apart. The greatest increases in displayed DR occur in the darkest parts of an image, where small differences in tonal values still equals a stop of luminance.

• When I calculate the HDR dynamic range I use the original radiance map, where every pixel value is the actual luminance. I'm not using a tonemapped image. But sometimes the DR still decreases.
– gbos
Oct 7 '19 at 16:43
• anyone, I added a photo to try to explain better the problem
– gbos
Oct 8 '19 at 14:37
• What tool are you using to measure the luminance values? In any case, you can only measure the luminance values as recorded; and in no case can they ever be more/less than what the camera sensor is capable of. I.e. you shift and blend exposures so that the scene's DR fits w/in the limited DR capability of the sensor and display... you are compressing the scene's DR. Oct 8 '19 at 16:16
• yeah I compress the DR when I tone map the radiance map to an RGB photo. But a radiance map contains an higher dynamic range than a tone mapped HDR photo and also more than a single exposure photo
– gbos
Oct 9 '19 at 14:06
• The radiance map is generated from the recorded images, and the recorded images cannot contain more DR than the sensor is capable of recording. So the combined image cannot contain more DR than the sensor is capable of recording. Your darkest exposure records brighter areas w/o clipping, but drives more dark areas below measurable (clipped black). And the opposite is true of you brightest exposure (more areas clipped white). There is never a difference between the min and max recordable/displayable... what you are doing is increasing the number of steps in-between. Oct 9 '19 at 20:46

Ok I think I found a solution by myself. I'll try to explain it here, let me know what you people think about it.

INPUT: 3 grayscale 8 bit images

OUTPUT: 1 HDR radiance map (single precision)

So, to compute the HDR image I use the Devebec algorithm

This algorithm outputs the radiance map computed from the 3 (or more) input photos. Every pixel value represent the relative illuminance (irradiance actually) of the corresponding point in the scene. I can then calculate the dynamic range simply by using the max and min pixel value from this matrix:

``````stops = log2(max) - log2(min);
``````

It's not important that the irradiance values are not the absolute one, because we are computing a range:

``````absolute_value = scale_factor + relative_value

range = absolute_max - absolute_min = (relative_max + scale_factor) - (relative_min + scale_factor) = relative_max - relative_min
``````

To blend the images the algorithm need to recover the camera response function. This function relate the pixel values to the relative illuminance of the scene. This means that once I have the camera response curve, and the maximum and minimum pixel value in the original image (in this case 0 and 255) I can retrieve the relative irradiance values of the original image too:

``````exp(g(255)-ln⁡(dt) ) = E_max
exp(g(0)-ln⁡(dt) ) = E_min
``````

where

``````g = inverse of camera response function (calculated by the script)
dt = shutter speed used on the original image
``````

I can then compute the actual dynamic range of the original image and compare it to the HDR image dynamic range.

Yet, seems like some images lose DR when blended together. So I'm a little confused. For example, these images once blended have narrower DR than before.

• I like that people are downvoting this without giving an explanation of what they don't like about this reasoning
– gbos
Oct 9 '19 at 13:32
• Assuming the resulting image has some values that are at both min and max (0-255), and that the script determines the response curve based upon the visible image as displayed, then the formula is essentially taking DXO's Tonality measurement for the sensor (DR corrected for noise) and adding the exposure shift. I.e. for the A7RIII at base ISO the sensors capability is ~ 9bits (stops) + a 3 stop exposure shift between images for two additional images (6stops) ='s a 15stop calculated DR. Oct 9 '19 at 21:11
• If instead your min value is 10 (which still appears black) you will have lost ~4 stops of DR in the resulting image. Oct 9 '19 at 21:11
• Well if my min value is 10 and I've lost 4 stops that's ok, if it's actually what happened in the image. About DXO mark they use another equation to calculate the DR: they use the black noise level (taken from the left black band on Canons) and it's standard deviation. Also this is done with the RAW picture
– gbos
Oct 10 '19 at 11:48
• DXO's Tonality measure is corrected for noise, their DR measure is not. It's the difference between what others call "photographic/usable DR" and "engineering DR." Everything starts from the raw data... Oct 10 '19 at 14:51