Digital imaging photometry with ``non-scientific'' cameras offering raw data formats

At the start, such photometry used a programme dcraw152j modified by me from the outstanding dcraw, to produce pgm files with raw data. (Another option was to use unmodified decompress, but this works just for Canon cameras.) The other input is from jhead. See David Coffin's page for sources of standard versions of the programmes.

From their output, a photometric table is computed using my raw2lum. Since Feb 10, 2005 its version 1.0 is available, which is no more confined to three camera types).

Tabular and overlay outputs

To help working with the table, a PostScript overlay is computed as well, showing the tiles of the photometric table and some of its values. Namely, medians of the upper green pixels within the Bayer grid of the chip (or of any pixels at this place) and, if the exposure is known, the median luminances (or average luminances or brightnesses of the tiles) as well.

If dimensions match, the overlay may be shown over the original image by a command like
composite -compose Multiply $1.jpg $1.eps ${1}g.png

Colour-coded luminances

Early 2004, a supplementary output has been developed, coding the luminances by a colour scale.

In 2005, the scale has been extended one order of magnitude downwards, repetition of colours avoided, scale (shown at the right side of the images) made with the largest luminance up instead of down. The scale spans a range of 1 : 1e9, going by default from 3.18e-5 nt to 3.177e4 nt.

Luminance scale / 1
  cd/m<sup>2</sup>
Logarithmic luminance scale (the unit is candela per square meter) – intensities of snow illuminance in lux would be obtained by multiplying the numeric value of luminance by 3.6. For asphalt, such a coefficient is between 20 and 40 (or much less, for specular reflections of distant lamps)

The sequence of colours therefore is

(Let's remember that nit is an alternative name for candela per square metre.)

Within each colour, five shades are used, coding luminances with borders at 0.318, 0.504, 0.798, 1.264 and 2.000 of the corresponding order of magnitude (rounded values 0.3, 0.5, 0.8, 1.3 and 2 are easier to remember). The luminances corresponding to the centres of these intervals are, taking an example of red colour, 0.4 nt (exactly), 0.63 nt, 1.005 nt, 1.59 nt and 2.52 nt (or 0.4, 0.6, 1.0, 1.6 and 2.5).

There is a -BL option to change this scale; then the output gets a black line inside the scale at the right of the image, to remind that this is not the default scale.

Luminance calibration

The calibration of luminances for Canon EOS D60 is still rather preliminary, based at first just on a couple of defocused images of sunlit and moonlit snow in February and of Capella in zenith (Sun has been rather low in the sky and the times for the Moon images are doubtful). Then some images of summer sunlit white paper had been made in 2003 and a better calibration obtained. It may be easily 30 % off for non-gray scenes lit by sodium light.

Calibration for Fuji S5000 is more reliable, being based on using luxmetres as well. For sunlight and scenes which are not very coloured, its uncertainty is about five per cent only (well, for the single camera I've used).

A more adequate linear combination of R, G and B could be used, what may be important for sodium lights. Taking a couple of images of solar spectra in summer might solve this problem, for each camera individually. For S5000 it has been done so (see ev. a poster g_camer within http://amper.ped.muni.cz/noc/english/canc_rhythm/ directory).

Another source of uncertainty, not over 10 %, are the exposures (focal ratios or even exposure times which are not perfectly matching the reported values).

Some results

The images and *.tab contain some old results. Pixel values over 3980 seem to mean overflow for D60 -- even if overflow is 4095, some spillage to another pixels can proceed.

A mess of processed newer images is available in http://amper.ped.muni.cz/noc directory and elsewhere (in my lectures, aurora images etc.).

Any more comprehensive text about the issue is yet to be written in English (there is some in Czech).

New versions

On Apr 25, 2005 I've downloaded raw2lum version 1.06. It handles Fish-eye geometry and YCGM colour system of Nikon 990 properly. Since May 13, version 1.07 is without a cosmetic bug in colour-coded images and has two options (-nh and -nr) added. Since Sep 04, version 1.08, computes probable SQM reading; overfull pixels are coded as white or according to the new -o#:#:# option. Sep 07, ver. 1.10 can write a correct luminance / ang. radius table. Sep 11, ver. 1.11 compares jpeg values with raw ones.

Jan 20, 2006 a new adaptation of current dcraw.c (v. 7.94) was here, to work with cameras included into dcraw after its 1.52 revision (v. 5.19). To be used as
 dcraw794j -9 -v -4
to produce something equivalent to dcraw152j (not a pgm, but a ppm to be converted after editing the third line to 65535). Since September 2006, dcraw has an option -D, which together with -4 (and -j for Fuji) produces a raw pgm as well (still, dcraw152j might be preferred for Fuji S5000 and perhaps others, having diagonal matrix). raw2lum version 1.16 accepts dcraw -v -i output instead of jhead output (tested on Olympus E300 files, see e300.sh within scripts directory).

A series of images from London has been added, taken 2003 by Fuji S5000. See directory london. A report on ski slope lighting in Giant Mts. has been made in 2006, based on the same camer. A problem of this (and surely many other cameras) had been identified and partly solved (there is no fully satifying solution): darkframes and very low-exposed images have up to one half of the pixels with zero values. Such pixels carry no information, and simple darkframe subtraction as usual is not fully adequate for such cameras. Read about it, eventually, in low_exp.htm (Luminance measurement in underexposed regions of Fuji S 5000 images) within http://amper.ped.muni.cz/noc/krnap/2006/ directory.

zero pixels problem...

Nikon D50 and D70, if not all *.nef (and all *.raf) files suffer from the same problem: readouts have no sufficient positive constant added, or some positive value is even subtracted, so that just one half of darkframe pixels is not zero. This makes faint light photometry difficult, less sensitive and less accurate. I'll ask the manufacturers for a better firmware, which would not discard the needed information. Meanwhile, try to use just such cameras for photometry, which have at least 99 per cent of darkframe pixels above zero.

Jenik Hollan, update on August 2006.