| 604 |
|
\f[I]definitions\f[R]. |
| 605 |
|
Once a function or variable has been defined, it may be used in later |
| 606 |
|
definitions, along with predefined functions such as \f[C]sin(x)\f[R] |
| 607 |
< |
and \f[C]cos(x)\f[R] and constants such as PI \**. |
| 607 |
> |
and \f[C]cos(x)\f[R] and constants such as \f[C]PI\f[R]\**. |
| 608 |
|
.FS |
| 609 |
|
TBD - There once was a footnote here |
| 610 |
|
.FE |
| 799 |
|
.RE |
| 800 |
|
.LP |
| 801 |
|
The following are sometimes defined, depending on the program: |
| 802 |
< |
.IP "\f[B]PI\f[R]" 3 |
| 802 |
> |
.IP "\f[B]\f[CB]PI\f[B]\f[R]" 3 |
| 803 |
|
The ratio of a circle\[cq]s circumference to its diameter. |
| 804 |
|
.RS 3 |
| 805 |
|
.RE |
| 1972 |
|
differ from standard computer graphics images inasmuch as they contain |
| 1973 |
|
real physical data, namely radiance values at each pixel. |
| 1974 |
|
To do this, it is necessary to maintain floating point information, and |
| 1975 |
< |
we use a 4-byte/pixel encoding described in Chapter II.5 of Graphics |
| 1976 |
< |
Gems II [Arvo91,p.80]. |
| 1975 |
> |
we use a 4-byte/pixel encoding described in Chapter II.5 of |
| 1976 |
> |
\f[I]Graphics Gems II\f[R] [Arvo91,p.80]. |
| 1977 |
|
The basic idea is to store a 1-byte mantissa for each of three |
| 1978 |
|
primaries, and a common 1-byte exponent. |
| 1979 |
|
The accuracy of these values will be on the order of 1% (±1 in 200) over |
| 2018 |
|
.IP "\f[B]\f[CB]FORMAT\f[B]\f[R]" 3 |
| 2019 |
|
A line indicating the file\[cq]s format. |
| 2020 |
|
At most one \f[C]FORMAT\f[R] line is allowed, and it must be assigned a |
| 2021 |
< |
value of either \f[C]32- bit_rle_rgbe\f[R] or \f[C]32-bit_rle_xyze\f[R] |
| 2021 |
> |
value of either \f[C]32-bit_rle_rgbe\f[R] or \f[C]32-bit_rle_xyze\f[R] |
| 2022 |
|
to be a valid \f[I]Radiance\f[R] picture. |
| 2023 |
|
.RS 3 |
| 2024 |
|
.RE |
| 2067 |
|
or override old ones. |
| 2068 |
|
.RS 3 |
| 2069 |
|
.RE |
| 2070 |
< |
.LP |
| 2071 |
< |
\f[C]PRIMARIES\f[R] The CIE (x,y) chromaticity coordinates of the three |
| 2072 |
< |
(RGB) primaries and the white point used to standardize the |
| 2073 |
< |
picture\[cq]s color system. |
| 2070 |
> |
.IP "\f[B]\f[CB]PRIMARIES\f[B]\f[R]" 3 |
| 2071 |
> |
The CIE (x,y) chromaticity coordinates of the three (RGB) primaries and |
| 2072 |
> |
the white point used to standardize the picture\[cq]s color system. |
| 2073 |
|
This is used mainly by the \f[B]ra_xyze\f[R] program to convert between |
| 2074 |
|
color systems. |
| 2075 |
|
If no \f[C]PRIMARIES\f[R] line appears, we assume the standard primaries |
| 2076 |
|
defined in \f[C]src/common/color.h\f[R], namely |
| 2077 |
|
\f[C]0.640 0.330 0.290 0.600 0.150 0.060 0.333 0.333\f[R] for red, |
| 2078 |
|
green, blue and white, respectively. |
| 2079 |
< |
.PP |
| 2079 |
> |
.RS 3 |
| 2080 |
> |
.RE |
| 2081 |
> |
.LP |
| 2082 |
|
As always, the end of the header is indicated by an empty line. |
| 2083 |
|
.SH 4 |
| 2084 |
|
Resolution String |
| 2171 |
|
.IP "\f[B]New run-length encoded\f[R]" 3 |
| 2172 |
|
In this format, the four scanline components (three primaries and |
| 2173 |
|
exponent) are separated for better compression using adaptive run-length |
| 2174 |
< |
encoding (described by Glassner in Chapter II.8 of Graphics Gems II |
| 2175 |
< |
[Arvo91,p.89]). |
| 2174 |
> |
encoding (described by Glassner in Chapter II.8 of \f[I]Graphics Gems |
| 2175 |
> |
II\f[R] [Arvo91,p.89]). |
| 2176 |
|
The record begins with an unnormalized pixel having two bytes equal to |
| 2177 |
|
2, followed by the upper byte and the lower byte of the scanline length |
| 2178 |
|
(which must be less than 32768). |
| 2206 |
|
\f[C]luminance(col)\f[R]. |
| 2207 |
|
.PP |
| 2208 |
|
If the \f[C]FORMAT\f[R] string indicates XYZ data, then the units of the |
| 2209 |
< |
Y primary are already lm/st/m\*{2\*}, so the above conversion is |
| 2209 |
> |
Y primary are already lm/sr/m\*{2\*}, so the above conversion is |
| 2210 |
|
unnecessary. |
| 2211 |
|
.SH 3 |
| 2212 |
|
\f[BI]Radiance\f[B] programs |
| 2588 |
|
Here are the relevant calls for reading and copying information headers: |
| 2589 |
|
.IP "\f[B]\f[CB]int checkheader(FILE *fin, char *fmt, FILE *fout);\f[B]\f[R]" 3 |
| 2590 |
|
Read the header information from \f[C]fin\f[R], copying to |
| 2591 |
< |
\f[C]fou\f[R]t (unless fout is \f[C]NULL\f[R]), checking any |
| 2591 |
> |
\f[C]fout\f[R] (unless fout is \f[C]NULL\f[R]), checking any |
| 2592 |
|
\f[C]FORMAT\f[R] line against the string \f[C]fmt\f[R]. |
| 2593 |
|
The \f[C]FORMAT\f[R] line (if it exists) will not be copied to |
| 2594 |
|
\f[C]fout\f[R]. |
| 2722 |
|
.RS 3 |
| 2723 |
|
.RE |
| 2724 |
|
.IP "\f[B]\f[CB]scanlen(rs)\f[B]\f[R]" 3 |
| 2725 |
< |
Macro to get the scanline length from the \f[C]RESOL\f[R]U structure |
| 2725 |
> |
Macro to get the scanline length from the \f[C]RESOLU\f[R] structure |
| 2726 |
|
pointed to by \f[C]rs\f[R]. |
| 2727 |
|
.RS 3 |
| 2728 |
|
.RE |
| 2732 |
|
.RS 3 |
| 2733 |
|
.RE |
| 2734 |
|
.IP "\f[B]\f[CB]fscnresolu(slp,nsp,fp)\f[B]\f[R]" 3 |
| 2735 |
< |
Macro to read in a resolution string from \f[C]f\f[R]p and assign the |
| 2735 |
> |
Macro to read in a resolution string from \f[C]fp\f[R] and assign the |
| 2736 |
|
scanline length and number of scanlines to the integers pointed to by |
| 2737 |
|
\f[C]slp\f[R] and \f[C]nsp\f[R], respectively. |
| 2738 |
|
This call expects standard English-text ordered scanlines, and returns |
| 3137 |
|
access routines in \f[C]src/common/portio.c\f[R] for reading and writing |
| 3138 |
|
portable binary data. |
| 3139 |
|
The information header is handled by the routines in |
| 3140 |
< |
s\f[C]rc/common/header.c\f[R], similar to the method described for |
| 3140 |
> |
\f[C]src/common/header.c\f[R], similar to the method described for |
| 3141 |
|
\f[I]Radiance\f[R] picture files. |
| 3142 |
|
Here are the main calls from \f[C]src/rt/ambio.c\f[R]: |
| 3143 |
|
.IP "\f[B]\f[CB]putambmagic(FILE *fp);\f[B]\f[R]" 3 |
