To incorporate polarization signatures into the simulation, the user needs to run a simulation that includes polarized illuminates (provided by a polarized atmosphere model), polarizing surface materials and a way to capture the polarized radiation at the sensor. This section will explain how-to configure these components of the modeling chain.
At this time, DIRSIG4 utilizes the same look-up table (LUT) based atmospheric model that was used in DIRSIG3. These atmospheric databases (LUTs) where generated by a program called make_adb which would handle the running of MODTRAN and/or FASCODE to create the values needed for each entry in the look-up tables.
DIRSIG4 uses an updated version of the make_adb to support the generated of polarized atmospheric databases. As you can see in the usage statement below, this updated version of make_adb has several new options:
prompt> make_adb -help
Release: 4.0.6
Build Date: Jan 26 2006 22:56:08
usage: make_adb [options] <CFG file>
where [options] are:
-help Print this help message
-use_config <file> Use alternate configuration info
-config Print configuration info
-standard Run in standard mode
-fast_sky Use a single MODTRAN run for the sky dome
-fascode_sky Use FASCODE for downwelled sky dome
-max_inversion <alt> Set the max inversion altitude
-max_range <range> Set the max range for sensor paths
-polarized Create a polarized atmosphere
Once we have configured everything correctly, the user can simply supply the -polarized option to make_adb to produce a polarized atmospheric database. In the absence of this option, make_adb will operate as usual and produce an unpolarized atmospheric database.
Starting with Release 3.5, make_adb has used a centrally located configuration file that contains information about the location of the MODTRAN and FASCODE executables and supporting databases. The -config option will print the configuration defined by the default configuration file located in $DIRSIG_HOME/config. To created a polarized atmospheric database, we need to modify the configuration of make_adb to use MODTRAN-P instead of the conventional version. If make_adb has not be configured to use MODTRAN-P and the user tries to create a polarized atmosphere using the -polarized option, an error will be reported.
There are two ways to change the make_adb configuration. The first is to change the default configuration file located in $DIRSIG_HOME/config to point at MODTRAN-P. As a result, all the users running make_adb will use MODTRAN-P for both polarized and unpolarized simulations. The drawback to this approach is that it will force all users to use MODTRAN-P, and although MODTRAN-P should behave the same as MODTRAN4 for unpolarized simulations, this version of MODTRAN is very experimental and may have bugs that would affect users working on unpolarized simulations. If you are the only user of a specific installation, this is the easiest approach.
The second approach is to create an alternate configuration file for make_adb that we can use only when we want to use MODTRAN-P. That approach is supported by the new -use_config option. For example, if we create a MODTRAN-P specific make_adb configuration file and call it my_make_adb.conf, we can run make_adb with this configuration using the following command line:
prompt> make_adb -use_config my_make_adb.conf demo.cfg
In this example the -use_config option will look for the my_make_adb.conf file in the current directory. If this file is located in another location then the full path should be supplied. To have make_adb test this configuration, try the following command line:
prompt> make_adb -use_config my_make_adb.conf -config
This will cause make_adb to read your custom configuration file and then test and print the configuration. This basic test will check that the MODTRAN executable and the supporting DATA directory could be found in the indicated locations. The order of the -use_config and -config options shown in this example is important.
Once you have addressed the configuration of make_adb you can create a polarized atmospheric database using the -polarized option. If you used the first approach to utilize MODTRAN-P (you modified the default configuration file) your command line will look something like this:
prompt> make_adb -polarized demo.cfg
If you used the second approach (you created an alternate configuration file) your command line will look something like this:
prompt> make_adb -use_config my_make_adb.conf -polarized demo.cfg
If you receive the following error while make_adb is running in polarized mode then you should verify that you are correctly running make_adb with MODTRAN-P.
make_adb: MODTRAN ERROR
MODTRAN output is not polarized!
The -config option is useful for determining which executable make_adb is using for MODTRAN.
As we mentioned before, in DIRSIG4 any element (including internally generated elements) that is included in the radiometric model process is assigned a material. Each material is assigned a radiometry solver object which is a computational object that predicts the flux from a specific element under a specific set of conditions. Each radiometry solver can independently utilize a different approach to predicting the observed flux. For example, a different solver might be used on a scene element like water then would be used for an element like a grass field. To emphasize this approach, we point out that the atmosphere is incorporated into DIRSIG4 by a set of internally managed radiometry solvers that interface directly with the atmospheric model. When a ray intersects the sky dome or the Sun disk, the appropriate solver is run to predict the incident flux from that location in the sky or the Sun.
Different radiometry solvers can be assigned and reassigned to materials on-the-fly which provides DIRSIG4 with a very flexible and power radiative transfer engine.
At this time, there are only four different optical properties available that can be assigned to a material. They span the three primary properties (reflectance, emissivity and extinction) that can be assigned to a material:
The "ClassicEmissivity" property provides a backward compatibility to the emissivity and derived reflectance values used by DIRSIG3. This includes the ability to read the classic DIRSIG3 emissivity files (usually with a .ems extension) and to support the classic DIRSIG3 texture methodology. The computed emissivity and reflectances from this object are unpolarized.
The "ClassicExtinction" property provides a backward compatibility to the extinction and derived transmission values used by DIRSIG3. This includes the ability to read the classic DIRSIG3 extinction files (usually with a .ext extension). The computed transmissions from this object are unpolarized.
The "PriestGermer" property provides reflectance predictions using a parameterized BRDF model. It reads the BRDF model parameters from an external file and computes polarized reflectances that vary as a function of view and illumination geometry.
The "ShellBackground" property provides reflectance predictions using a parameterized BRDF model. It reads the BRDF model parameters from an external file and computes polarized reflectances that vary as a function of view and illumination geometry.
At this time, there are two different radiometry solvers that can be assigned to each material:
The "Classic" radiometry solver in DIRSIG4 was implemented to provide backward compatibility with DIRSIG3. Under the hood, this solver uses a similar ray-traced illumination loading approach that was used in DIRSIG3 for the BRDF (shape factor) calculations. Like the DIRSIG3 solution, this radiometry solver only allows the user to configure the "classic" emissivity and extinction properties and the number of background illumination samples and bounces are fixed.
The "Generic" radiometry solver in DIRSIG4 was implemented to be the next generation surface leaving radiance calculation. The "generic" solver was named such because it is very flexible by allowing the user to choose from a suite of optical properties that are used to compute the reflectance, emissivity and transmission properties of the surface. As more optical properties are added to the system, this solver will become an increasingly more powerful tool that users can utilize to model complex materials or mediums. However, unlike the DIRSIG4 "classic" radiometry solver or the DIRSIG3 calculation, the user has control over the amount of hemispherical sampling and the number of bounces used to solve for the flux reflected by the surface on a per-material basis.
To emphasize the flexibility in this radiometry architecture, we should point out that although each material may be using the same radiometry solver, the solver for each material can be configured with a different set of optical properties, input parameters and options.
The configuration of the radiometry solver and the related optical properties is defined in the material database file. Although the new radiometry architecture provides a high degree of flexibility, we have included a significant amount of backward compatibility to DIRSIG3 input files. For example, the entries of a DIRSIG3 material file contained references to an emissivity file and an optional extinction file for each material (see below):
MATERIAL_ENTRY {
NAME = Example Material #1
ID = 1
SPECIFIC_HEAT = 1.0000
THERMAL_CONDUCTIVITY = 0.0000
MASS_DENSITY = 1.0000
SPECULARITY = 0.0
SOLAR_ABSORPTION = 0.1000
THERMAL_EMISSIVITY = 0.1000
EXPOSED_AREA = 0.1700
THICKNESS = 0.1
EMISSIVITY_FILE = 75.ems
EDITOR_COLOR = 0.8200, 0.8200, 0.8200
DOUBLE_SIDED = TRUE
}
If the user provides DIRSIG4 with a DIRSIG3 material database file (usually with a .mat extension), DIRSIG4 will automatically assign the "classic" radiometry solver using the "ClassicEmissivity" optical property to all the materials in the scene. If a specific material entry also referenced an extinction file, then the "ClassicExtinction" property will be automatically configured for that material.
However to use the new Preist-Germer BRDF model and other optical properties that will be released at a later time, the user will want to use the new format of the material database file. The section below shows the format of a MATERIAL_ENTRY section that utilizes the new tags associated with a DIRSIG4 material file:
MATERIAL_ENTRY {
NAME = Example Material #2
ID = 5
EDITOR_COLOR = 0.8200, 0.8200, 0.8200
SURFACE_PROPERTIES {
EMISSIVITY_PROP_NAME = ClassicEmissivity
EMISSIVITY_PROP {
FILENAME = 90.ems
SPECULAR_FRACTION = 0.0
}
}
RAD_SOLVER_NAME = Generic
RAD_SOLVER {
INITIAL_SAMPLE_COUNT = 200
MAX_BOUNCES = 2
SAMPLE_DECAY_RATE = 10
}
TEMP_SOLVER_NAME = Therm
TEMP_SOLVER {
SPECIFIC_HEAT = 1.0000
THERMAL_CONDUCTIVITY = 0.0000
MASS_DENSITY = 1.0000
SOLAR_ABSORPTION = 0.1000
THERMAL_EMISSIVITY = 0.1000
EXPOSED_AREA = 0.1700
THICKNESS = 0.1
}
}
The same NAME and ID tags appear in the new format. The differences begin with the new SURFACE_PROPERTIES section which is where the user assigns radiational/optical properties to the material. The format of the various optical properties will be discussed later.
After the SURFACE_PROPERTIES section is the new tag RAD_SOLVER_NAME which allows the user to specify which radiometry solver they wish to use. At this point, the only valid solvers to request are the "Classic" and the "Generic" radiometry solver. After this tag is the RAD_SOLVER section which is parsed by the requested radiometry solver. In this example, the RAD_SOLVER section contains variables and sections specific to the "Generic" radiometry solver. When other solvers are available, this section will change on a per-solver basis reflect the options and inputs unique to that solver.
The first three tags in this example RAD_SOLVER section are options for this instance of the Generic Radiometry Solver assigned to this material. The INITIAL_SAMPLE_COUNT variable defines how many background rays will be traced by this solver when it is queried for a first generation surface (directly viewed by the sensor). The SAMPLE_DECAY_RATE defines how quickly the number of samples will decay for subsequent generations from the INITIAL_SAMPLE_COUNT. For example, if the initial sample count is 200 for a material called "grass" then 200 background rays will be traced when it is viewed by the sensor. If one of these 200 rays hits the same "grass" material (perhaps on a hill nearby) and the decay rate is 10, then only 20 rays will be traced from this second generation surface. On a third generation "grass" surface the sample count would be only 2 samples, etc. The MAX_BOUNCES variable is used to place a "hard stop" on the number of bounces that are modeled. If the maximum bounce limit is reached the surface will return 0 flux. In this example, the 2 samples computed for the third generation surface in this example will not be traced if the maximum bounce count is set to 2.
Since these variables can be different for each solver/material, it is entirely possible that the first generation surface in an arbitrary radiative transfer chain will be modeled by fewer samples then a second generation surface. In the future, these values may be automatically derived from the optical properties assigned to the solver, but for now they are user-defined.
The SURFACE_PROPERTIES section in the previous example uses the "ClassicEmissivity" optical property to model the emissivity and reflectance of the material it is assigned to. This was performed by assigning the name ClassicEmissivity to the EMISSIVITY_PROP_NAME variable. Once an instance of this object is created, it then parses the contents of the EMISSIVITY_PROP section (see below). Like we mentioned before, when other emissivity optical property models are created, each one will most likely have a uniquely formatted EMISSIVITY_PROP section.
EMISSIVITY_PROP_NAME = ClassicEmissivity
EMISSIVITY_PROP {
FILENAME = 90.ems
SPECULAR_FRACTION = 0.0
}
In this case, we see that the EMISSIVITY_PROP section for the "ClassicEmissivity" optical property contains two variables. The FILENAME variable points to a classic DIRSIG emissivity file that is compatible with DIRSIG3. The SPECULAR_FRACTION variable is analogous to the SPECULARITY variable that appeared in the DIRSIG3 material files.
The Priest-Germer BRDF model is a reflectance optical property and it is configured for use by the Generic Radiometry Solver for a specific material by supplying the name "PriestGermer" to the REFLECTANCE_PROP_NAME variable (see below):
REFLECTANCE_PROP_NAME = PriestGermer
REFLECTANCE_PROP {
PARAMETER_FILE = au-0075.TS.brdf
ENABLE_DHR = TRUE
ENABLE_SHADOWING_FUNCTION = TRUE
}
When the "PriestGermer" reflectance property is specified the REFLECTANCE_PROP section will look like the one featured in the above example. The PARAMETER_FILE variable points to a file containing the parameters for the BRDF model. The ENABLE_DHR variable is assigned a boolean value which enables the use of the internal directional-hemispherical reflectance (DHR) look-up table which is used to compute a spectral diffuse term. The only depolarizing contribution comes from the DHR estimation. If the DHR term is turned off the surface will be only polarize the reflected light. The ENABLE_SHADOWING_FUNCTION controls the internal self-shadowing from the microfacet distribution used to model the sub-surface.
The format of the BRDF parameter is simple. The first column is wavelength in microns. The second column is the surface roughness parameter. The third and forth columns are the n and k values for the complex index of refraction. The complex indices of refraction for many materials can be found in the CRC handbook. An example parameter file for aluminum:
0.53904 0.300 0.8260 6.2830
0.56354 0.300 1.0180 6.8460
0.61990 0.300 1.3040 7.4790
0.66678 0.300 1.7410 8.2050
0.77487 0.300 2.6250 8.5970
When the ENABLE_DHR variable is set to TRUE, an additional file named $DIRSIG_HOME/lib/data/DHR.500k.t00-90.s001-050.dat will be accessed. This file contains normalization factors for the direct hemispherical reflectance. Since the Priest Germer model interpolates solely on surface roughness and complex index of refraction, this normalization factor file is the same for all materials. A copy of this file comes with the DIRSIG4 distribution; it should not normally be necessary to customize it. If a custom table is desired, the format for the normalization file is:
5 # Number of theta values (i.e. columns of data)
4 # Number of sigma values (i.e. rows of data)
# list of zenith angles
Sigma 0 10 45 75 90
# data table
0.25 0.95 0.8 0.7 0.6 0.5
0.3 0.8 0.77 0.63 0.55 0.43
...
0.5 0.75 0.71 0.6 0.5 0.4
The Shell-Background BRDF model is a reflectance optical property and it is configured for use by the Generic Radiometry Solver for a specific material by supplying the name "ShellBackground" to the REFLECTANCE_PROP_NAME variable (see below):
REFLECTANCE_PROP_NAME = ShellBackground
REFLECTANCE_PROP {
EMISSIVITY_FILE = grass.ems
BRDF_FIT_FILE = grass.fit
}
The BRDF_FIT_FILE, described below indicates the file containing the fit parameters for the BRDF model. The EMISSIVITY_FILE indicates a DIRSIG emissivity file. The first curve from this file will be converted to reflectance and used by the model.
The fit file is composed of two section types. The variable names used in both cases are identical to those in the thesis. The first section type, SHARED_FIT_PARAMS, holds the wavelength-independent parameters.
SHARED_FIT_PARAMS {
RHO_0 = 0.075211
P1 = 1.9582E-03
P2 = 9.8206E-02
P3 = -6.6807E-02
P4 = 1.1251E-02
PF1 = 9.4574E-04
PF2 = 2.9314E-03
PF3 = -1.7853E-03
PF4 = 2.4078E-04
A = 0.119524
B = 0.503486
C = 0.002465
D = 0.009992
E = 1.252179
F = 59.918513
}
The second section type, FIT_PARAMS, holds wavelength-dependent parameters. Multiple instances of this section may be present in a fit file. The model interpolates between available measurements as described in [Shell 2005].
FIT_PARAMS {
LAMBDA = 0.550
RHO = 0.075211
K0 = 6.8702
K1 = 0.3881
K2 = 29.0824
}
A complete example of a "Shell Background" model fit file is found in the Polarization Tutorial section.
At this time, you can configure either a reflectance or emissivity property within one "generic" radiometry solver. You can pair either a reflectance or an emissivity property with the extinction property.
Once the user has correctly configured the inputs, running the model is as straight forward as it has been in the past. There are no command line options that enable the polarization because the DIRSIG4 radiometry engine will automatically switch into a polarized propagation mode when polarizing optical elements are encountered. In the future, there will most likely be an option that disables polarization altogether.
The following sections outline a few polarization related configuration options that appear in the DIRSIG simulation configuration file (usually denoted with a .cfg file extension).
At this time, DIRSIG4 does not support the direct modeling of polarization sensitive sensors. This support will be added in future directions as part of the advanced sensor modeling enhancements. For the time being, the model can produce spectral-polarimetric output that can be processed by external sensor models. When this output is requested, the resulting image data cube is essentially 4-dimensional with 2 spatial dimensions, 1 spectral dimension and 1 Stokes dimension. This image format could be called "Stokes interleaved by Band interleaved by Pixel" which means that the data is organized as such:
[Y0,X0,B0,S0], [Y0,X0,B0,S1], ... [Y0,X0,B0,S3],
[Y0,X0,B1,S0], [Y0,X0,B1,S1], ... [Y0,X0,B1,S3],
...
[Y0,X0,Bn,S0], [Y0,X0,Bn,S1], ... [Y0,X0,Bn,S3],
[Y0,X1,B0,S0], [Y0,X1,B0,S1], ... [Y0,X1,B0,S3],
[Y0,X1,B1,S0], [Y0,X1,B1,S1], ... [Y0,X1,B1,S3],
...,
[Y0,Xn,Bn,S0], [Y0,Xn,Bn,S1], ... [Y0,Xn,Bn,S3],
[Y1,X0,B0,S0], [Y1,X0,B0,S1], ... [Y1,X0,B0,S3],
[Y1,X0,B1,S0], [Y1,X0,B1,S1], ... [Y1,X0,B1,S3],
...
[Yn,Xn,Bn,S0], [Yn,Xn,Bn,S1], ... [Yn,Xn,Bn,S3]
Where Yi and Xi are the spatial X,Y pixel locations, Bi is the band/wavelength, and Si is the Stokes Vector index. The image data file elements are double-precision floating-point (native double) that is written in the native endian. An ENVI compatible image header file is automatically generated which should aid in the parsing of this file.
The user enables the creation of a spectral-polarimetric data cube by setting the RESPONSE_FILENAME variable in the BAND section to the keyword SPECTRAL-P (see the example below):
BAND {
NAME = Polarized Band #1
MINIMUM_WAVELENGTH = 0.5000
MAXIMUM_WAVELENGTH = 0.8000
DELTA_WAVELENGTH = 0.1000
X_PIXELS = 256
Y_PIXELS = 256
X_LENGTH = 12800.0
Y_LENGTH = 12800.0
RESPONSE_FILENAME = SPECTRAL-P
IMAGE_FILENAME = example.img
}
At this time DIRSIG4 does not support the myriad of truth images that were available in DIRSIG3. There are four (4) set of truth images that can be enabled via variables in the TRUTH_MAPS section:
The material truth maps are available through the MATERIAL_MAPS variable. This includes the first material, first non-transmissive material and first transmissive material maps.
The intersection truth maps are available through the HIT_MAPS variable. This information is gathered for the first surface encountered an includes the X, Y and Z hit point of the intersection,
The intersection truth maps are available through the HIT_MAPS variable. This information is gathered for the first surface encountered an includes the X, Y and Z hit point of the intersection, the U, V texture coordinates (used only for advanced texture mapping), the relative entry angle between the detector ray and the surface normal, and the thickness of the intersected surface.
The path angle maps are available through the PATH_ANGLE_MAPS variable. These two maps contain the zenith and azimuth angle of the detector ray.
The polarization maps are available through the POLARIZATION_MAPS variable. These maps include the degree of polarization (DOP), the degree of linear polarization (DOLP) and the degree of circular polarization (DOCP).