0

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

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

  • 2
    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. – szulat Oct 3 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. – szulat Oct 3 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? – Giammarco Boscaro Oct 3 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? – Michael C Oct 4 at 7:05
  • 1
    "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. – mattdm Oct 6 at 19:55
2

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)

(See also: 8bit monitor theoretical contrast)

  • 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? – Giammarco Boscaro Oct 3 at 13:14
  • anyone, I added a photo to try to explain better the problem – Giammarco Boscaro Oct 8 at 14:37
2

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. – Giammarco Boscaro Oct 4 at 8:28
  • 1
    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. – Michael C Oct 5 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. – Giammarco Boscaro Oct 5 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. – Michael C Oct 6 at 6:52
  • 1
    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. – Michael C Oct 6 at 6:54
0

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. – Giammarco Boscaro Oct 7 at 16:43
  • anyone, I added a photo to try to explain better the problem – Giammarco Boscaro Oct 8 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. – Steven Kersting Oct 8 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 – Giammarco Boscaro Oct 9 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. – Steven Kersting Oct 9 at 20:46
-2

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 – Giammarco Boscaro Oct 9 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. – Steven Kersting Oct 9 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. – Steven Kersting Oct 9 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 – Giammarco Boscaro Oct 10 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... – Steven Kersting Oct 10 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.