Camera response calibration

Asked by Torsten Bronger on 2013-01-08

I try to calibrate the camera response using Hugin. I did 5 exposures of the same scene (with a tripod) with 1.66 EV difference in exposure time. They contain both underexposed and overexposed areas. I converted them to linear TIFFs with "dcraw -o 0 -M -4 -T". In Hugin, I automatically detected CPs and calibrated the relative "Positions" of the images. Then, I optimised the camera response. Here are my questions:

1. Why do the parameters depend heavily on the subject that I photograph? I did two exposure series with the same ISO and got those EMoR values:

-9.30828 1.73149 0.73602 -0.84421 0.39533
-5.33008 -0.68035 2.57487 -1.4287 0.49794

2. Does the camera response depend on the ISO number?

3. If I also fit the EVs, I get a difference between the fitted EV and the EXIF data of 0.4 for an overall EV coverage of the series of 7 EV. Is the shutter speed of my camera really so inaccurate, or is it not a good idea to include the EVs into the fit?

4. If I look at the preview in the "difference" mode, I see significant signal at the overexposed areas. Ideally, the difference preview should be all black. Is this normal?

Question information

English Edit question
Hugin Edit question
No assignee Edit question
Solved by:
Torsten Bronger
Last query:
Last reply:
Torsten Bronger (bronger) said : #1

I solved item (4). If an image is overexposed, the correct irradiance of the overexposed parts cannot be recovered of course, so there must be a difference to the correctly exposed image.

tmodes (tmodes) said : #2

The EMoR response type is not intended to work with linear data.
Hugin is using the EMoR curve to convert the data to linear space. So using EMoR for linear data will not work. For linear data use linear response curve and not EMoR. With linear data the EMoR parameter are not used (and should not fitted).

To item (1): Both data sets describe more or less the same EMoR curve. But the main problem is the linear data - see above.

To (2): ISO should not matter for the response curve.

To (3): The problem is again the linear data and EMoR.

Torsten Bronger (bronger) said : #3

With "linear TIFFs" I mean "RGB data as raw as possible". In particular, no sRGB-gamma is applied. EMoR should work for that. The data is highly probably not fully linear because my camera sensor is not perfect. That's what I want to calibrate after all.

I know that most people will use Hugin with sRGB data. Then, the camera response Ra, Rb, Rc, Rd, Re will contain also the sRGB gamma, and possibly other non-linearity introduced by the RAW converter. But I want to do that after the stitching.

I've done further investigations. At you see my results for different scenes. To my surprise, the measurements on supposed-to-be linear data are indeed in agreement with each other. Hugin seems to try to fit a linear slope between 0 and 0.3, and then a plateau. This should not be. Instead, the slope should be over the whole interval. It looks as if the x axis 0...1 is shrunk to 0...0.3.

According to your advice, I also included sRGB data. The result seems to have the same problem with the shrunk x axis. The curve is steeper, as to be expected due to the sRGB gamma. Thus, the plateau starts even sooner.

Of course, EMoR has not been designed for that. I cannot model the plateau reasonably. So you get overshoots and dips.

Maybe Hugin can live with that because is first maps a y value to an x value, applies anti-vignetting, and back-transforms. If you carefully implement the inverse of this response curve, it would work as long as the x axis really is shrunk by a linear factor. However, you lose accuracy because EMoR cannot approximate such curves well.

Moreover, even with non-linear (sRGB) data, I see a massive malfitting of EV. My exposure series spanned EVs from 9 to 2.3. But after the fit, only 9 to 6.5 remained. My camera cannot be that bad. ;-)

So, the following questions remain:

1. Why does Hugin seem to use only the interval 0 to 0.3 on the irradiance axis?

2. Why does it fit the EVs so badly? Is it sensibly to fit them at all? (How does it do that, by the way? Via the histograms or via the response curves?)

I can provide you with the original TIFFs as well as with the Gnuplot sources and EMoR data files if you wish.

tmodes (tmodes) said : #4

Please provide the test images. I have an idea, but I can promise nothing .

Torsten Bronger (bronger) said : #5

I updated with an 8-bit sample. It looks slightly more reasonable but still very strange. Besides, it should also with with the full dynamic range in brightness.

I uploaded the TIFF (raw colour space, no gamma applied) to and

Both are scaled-down image sets with two different subjects. Thanks for your efforts!

Torsten Bronger (bronger) said : #6

I again updated

I added a measurement not based on an exposure series but a vignetting calibration of overlapping images. The response curve looks very reasonable.

However, it *is* possible to derive the response curve from an exposure series. The EMoR paper does exactly that. It should be even more accurate because it can cover much more dynamic range than a set of overlapping images by their vignetting.

tmodes (tmodes) said : #7

I had a look on the images.
I assume the optimizer get fouled by the big number of dark images. If I use only 4-5 images around normal exposure the camera response curve is fitted correctly. Then also the variation between different runs of the optimizer is small (Ra around 5, Rb-Rd around 0).
So I assume the big number of dark images results in a lot of dark sample points which dominate the optimisation. Also the images contains only less information in the middle brightness range (there are many dark and bright pixel, gamma corrected it is not so extreme).

In the paper they used also only 3 images: normal exposure e and 2e and 3e. And not so underexposed images.
So using less images with a better intensity distribution (more medium intensity in the histogram) may be better suited for the response calculation.

It may also be that the optimizer implementation in Hugin is not so well suited to calculate the true, absolute camera response. It is optimized to remove difference between (not fully) overlapping images (by using forward and backward EMoR curve, as you already mentioned). So to extract the true camera curve an other algorithm may be better suited.

In your provided test sets it also helps the optimizer, if you set the start parameters near a linear response. Starting from the standard EMoR curve it has more problems to find a linear solution.

PS: The camera response curve is used to calculate the ev values.

Torsten Bronger (bronger) said : #8

Thank you for your info!

I looked at it again and I also think that Hugin cannot find the proper camera response. Usually it doesn't get raw data, and even a mere white balance makes it theoretically impossible to find the camera curve. So even if I had the proper EMoR parameters, I would be forced to use green-tinted (i.e. non-white-balanced), linear RAW images.

One last question: Does Hugin apply the EMoR curve to the color channels separately, or to the intensity .21*R + .72*G + .07*B?

I think the camera response fitting in Hugin has two purposes:

1. It removes any gamma that has been applied, in most cases the sRGB gamma of 2.2.

2. It gives the least-square-fit further degrees of freedom to blend the images better. Effectively, you fit vignetting with additional parameters. These parameters depend of brightness instead of coordinate but if both are loosely correlated, it works nevertheless.

Torsten Bronger (bronger) said : #9

Forget my last question, I cannot work if Hugin applies EMoR not to each channel separately. Thank you again!