Readme and Answers to anticipated FAQs

  1. What sort of input does mkhdr expect?
  2. What does it mean to recover the characteristics of an imaging system?
  3. Do I have to have a digital camera?
  4. What if the source distribution won't compile ?
  5. Who can I contact ?

What sort of input does mkhdr expect?

The general syntax for mkhdr is:  mkhdr [options] inputfile outputfile

where options include:

-w curvefile        writes the recovered response curve to curvefile

-c curvefile        build the high dynamic range radiance map using the response curve in curvefile

-fptiff                write out the high dynamic range radiance map in the floating point TIFF format

-d                    Writes out some matlab files useful for looking at the recovered curve etc.

                       The Matlab files are called points0.m points1.m points2.m B0.m B1.m B2.m and curve.m (if -w specified)

-l1                    Specifies "Lambda 1", which indicates how important the smoothness equations are relative to the data-fitting equations for the initial data-alignment phase.  Default value is 20, generally user should not need to change this.

-l2                    Specifies "Lambda 2", which indicates how important the smoothness equations are relative to the data-fitting equations for the second phase curve-fitting.  Default value is 1, generally user should not need to change this.

-v                     the algorithm works on "average pixel traces"--the -v option causes average pixel traces formed from data with high variance to be ignored.  This may make the algorithm more robust when objects have moved around from one image to the next.

inputfile is the name of a file containing one line for each input image

outputfile is the filename of the output high dynamic range image

The format for each line of the inputfile is as follows:

(imageFileName.ppm) (inverse of exposure time) (aperture) (gain) (neutral density)

For example, the input file for the example sequence on the main page looks like

img0076.ppm 1000 8.0 3 0
img0075.ppm 500 8.0 3 0
img0074.ppm 250 8.0 3 0
img0073.ppm 125 8.0 3 0
img0072.ppm 60 8.0 3 0
img0071.ppm 30 8.0 3 0
img0070.ppm 15 8.0 3 0
img0069.ppm 8 8.0 3 0
img0068.ppm 4 8.0 3 0
img0067.ppm 2 8.0 3 0
img0066.ppm 1 8.0 3 0
img0065.ppm 0.5 8.0 3 0
img0064.ppm 0.2666667 8.0 3 0
img0063.ppm 0.1333333 8.0 3 0
img0062.ppm 0.0666667 8.0 3 0
img0061.ppm 0.0333333 8.0 3 0

Gain is assumed to be in dB, positive means the signal has been boosted.

Neutral density (ND) is in log base 2, positive means light has been reduced.  E.g. 2 means that a neutral density filter cutting out 75% of the light was used.

The images specified in the sequence above vary only in shutter speed.  Although mkhdr accounts for aperture, gain, and ND filtering, these are all typically less accurate than shutter speed and are best left constant for a given shoot.  For example, changing aperture from f8.0 to f5.6 usually lets in only very roughly twice as much light, and in fact will often produce a different spatially varying brightness modulation (vignetting), particularly for wide-angle lenses.  It is, however, OK to recover a response curve under one set of constant aperture, gain, and ND filtering and to then use that response curve to construct radiance maps from images taken under a different set of constant aperture, gain, and ND filtering.  If circumstances demand or if aperture, gain or ND filtering is believed to be sufficiently accurate it may be OK to vary them while capturing a radiance map that will be built from a pre-existing response curve, but it is generally a very bad idea to vary them while taking a sequence that will be used to recover a response curve. 

Back to Top


What does it mean to recover the characteristics of an imaging system?

We consider a subsystem of the full imaging system, namely the subsystem that, for a given sensor (typically film or a CCD array), maps (sensor irradiance x time) to pixel values in the final digital image.  We assume that this is a valid map; for example, the same pixel value should result if the amount of light impinging on the sensor is halved while the exposure time is doubled.  We then want to find the inverse of this map, a map from pixel values to (sensor irradiance x time).  This will allow us, given digital images with known exposure times, to recover the sensor irradiances for each pixel.  It should be noted that care must be taken to assure the stability and predictability of the imaging subsystem.  If different images are taken on different film stocks, developed differently, scanned differently, color-corrected differently, or stored with different gamma, then no single inverse mapping will be valid.  For more details see Paul Debevec and Jitendra Malik's Siggraph 97 paper, Recovering High Dynamic Range Radiance Maps from Photographs.

 Back to Top

Do I have to have a digital camera ?

Our algorithm assumes that all images have been processed in the same way, and also that they are perfectly aligned with each other.  Digital cameras are thus the ideal image-capture devices for high-dynamic range applications.  For film cameras, the PhotoCD process is probably the best choice, although considerable care must be taken to assure all images are processed in the same way--for example, if the images span more than one roll of film it is critical that no automatic exposure or color-correction is used during processing.  The negative-scanning process often introduces considerable misalignment between different images; this will usually cause considerable problems for mkhdr unless the resulting digital images are re-aligned to each other.  (This re-aligning, generally referred to in the image processing literature as "image registration", may be taken care of automatically by future versions of mkhdr.)  Variation in the responses of different films and in the PhotoCD process typically necessitates recovering a new response curve for different shoots, while the response behavior of a digital camera can often be assumed constant over time.

Back to Top

What if the source distribution won't compile ?

The C source should be fairly stable. There is a definite possibility though that the LAPACK libraries packaged with the source code will not work on every SGI or Linux box. To build your own version of the LAPACK libraries, download the C version of the LAPACK distribution and compile the libraries for your machine. Modifiy the Makefile to point at the new libraries, and you should be ready to go.

Back to Top

Who can I contact ?

Haarm-Pieter Duiker and Tim Hawkins did the work of implementing the algorithms outlined in the Siggraph 97 paper. They are the ones to contact about the more prosaic, or glorious, details.

Back to Top

 

Author information goes here.
Copyright 1999, The Regents of the University of California.
Last Revised: August 21, 1999 .