In this document there are many words used with respect to polarization. For this document, the word unpolarized implies that the light is not polarized or is randomly polarized. The term depolarize implies a process that converts light from a current state of polarized towards unpolarized or randomly polarized, however, this process may not remove all polarization.
The DIRSIG4 code base is written in C++ and is extremly object oriented. The DIRSIG support for polarization is built into the model at the lowest levels of the code. The CDSpectralVector object is used to store spectral data of various types. In some cases, the spectral data type is the CDStokesVector object which is the implementation of a Stokes Vector. This object can be used to store fluxes including radiances, irradiance, radiant intensities, etc. In other cases, the spectral data type will be instances of the CDMuellerMatrix object which is an implementation of a Mueller Matrix. This object can be used to store the properties of participating media like scattering coefficients, extinction coefficients, transmissions, reflectances, emissivities, etc.
Both the CDStokesVector and the CDMuellerMatrix object have Polarized and Unpolarized states. In the Unpolarized state, both objects can be thought of as simply a scalar value. These two principle objects have a specific set of mathematical operations that have been implemented so that basic radiative transport can be supported. The CDSpectralVector object allows these operations to be performed on spectral data.
The polarized fluxes predicted by the DIRSIG model arise from a variety of sources. The surface illumination from the environment may be initially polarized if a polarized atmospheric model is used. Surfaces within the scene may polarize incident light if the surface reflectance or emissivity properties are polarizing. It should be pointed out that unpolarized incident energy reflected by a polarizing surface will be polarized, so using an unpolarized atmospheric database will still result in predicted sensor reaching radiances that are polarized, however, they will not be as accurate as the results from a propagation that used polarized light as the source illuminant.
On of the sources of polarization is that the illumination in the scene is polarized. The primary sources of illumination are the sun, the moon and the sky (which arises from scattered sunlight). The solar, lunar and sky radiation loads in the DIRSIG model are handled by the atmosphere sub-models. In most cases, these sub-models use the AFRL atmospheric radiation propagation codes. The primary code used by DIRSIG is the AFRL MODTRAN (the MODerate resolution TRANsmission) model.
MODTRAN-P is a polarized version of MODTRAN4. The model can be run in both a polarized and unpolarized mode. As was stated at the beginning of this chapter, the MODTRAN-P model is available only to a select beta-testing community. If you are not already a part of this user community, it is unlikely that you will be able to gain access to this modeling tool.
When the polarization modeling is enabled MODTRAN-P, the radiances produced by the MODTRAN model will be spectral Stokes Vectors (S0, S1, S2 and S3) and a polarization angle. The source of polarization within MODTRAN-P is the scattering phase functions which predict scattered radiances that are polarized. By defintion, the directly transmitted terms (direct solar and lunar) are not polarized since they are not scattered. The model can be used to predict polarized path radiances between the sensor and the scene and to predict a polarized sky.
The DIRSIG4 model supports the MODTRAN-P atmospheric model through a modified version of the classic DIRSIG3 make_adb utility. The configuration and use of this utility for polarization will be discussed later. In DIRSIG4, the atmospheric modeling is handled by an atmosphere sub-system that is defined by a specific internal interface. DIRSIG4 has a growing number of unique atmospheric models that the user can choose from at run-time. At one end of the spectrum is the "simple atmosphere" model which has harded coded solar irradiance, lunar irradiance, and sky irradiance curves. This model is useful for testing purposes because a rigorous atmospheric database does not to be constructed for each simulation. More exotic atmospheric models are under development which support spatially inhomogenous properties but which require more input data and run-time resources.
The polarized atmospheric databases produced by the DIRSIG4 version of make_adb are handled by the "classic atmosphere" model in DIRSIG4 which implements the same treatment of the atmosphere that appeared in DIRSIG3. Polarization support will be added to the new DIRSIG4 atmospheric models as they near completion.
The DIRSIG model currently supports two internal sources of polarization. One source is an implementation of the polarized version of the classic Torrance-Sparrow BRDF model described by Priest and Germer in their paper ``Polarimetric BRDF in the Microfacet Model: Theory and Measurements'' [Priest 2000]. This parameterized BRDF model relies on user-supplied a spectral complex index of refraction and surface roughness metric. In practice, the surface roughness is usually treated as a spectral property to acheive better fits to measured data. The second source is an implementation of the polarized background BRDF model described in Jim Shell's PhD thesis [Shell 2005]. Additional polarized BRDF models are being developed and evaluated by other organizations and more models will be incorporated into DIRSIG at a later time.
The DIRSIG4 radiometry model is a significant redesign of the radiometric modeling used in DIRSIG3. Every object in the DIRSIG simulation has a material assigned to it including internal elements like the sun, moon, sky and the bulk atmosphere. Each material has a radiometry solver assigned to it. A radiometry solver is an object that predicts the flux from an element under a specific set of conditions and using a specific set of material properties. The radiometry solver sub-system is defined by an interface to these computational objects. The most common radiometry solver is the "classic" solver which implements the same surface reflected radiance and emitted radiance algorithm that was used in DIRSIG3. The "classic" solver makes assumptions that each material has a surface emissivity description that can be used to compute the reflectance (assuming that Kirchoff's Law holds and the reflectance can be computed as 1 minus the emissivity). When the user supplies DIRSIG4 with a DIRSIG3 simulation configuration, scene materials are automatically assigned the "classic" solver. To use other radiometry solvers, the user needs to make changed to the material database, and that process will be discussed in later sections.
The next generation radiometry solver is the "generic" radiometry solver which is a very flexible solver with which the user can assign various surface and bulk optical properties (reflectance, emissivity, scattering and extinction properties) to. These optical properties are defined against defined internal interfaces which allows various optical properties to be abstracted and thus allowing the "generic" radiometry solver to use a very flexible set of surface and bulk optical properties.
In the current version of DIRSIG4, the user has a limited set of optical properties to assign to the "generic" radiometry solver (however, DIRSIG3 had only one). The "classic emissivity" property can be used to model the surface emissivity. This property reproduces the unpolarized emissivity and reflectance support that was modeled in DIRSIG3 (including the classic texture methodology) using the same emissivity files that DIRSIG3 utilized. As an alternative, the user can use the "Priest-Germer" or "ShellBackground" BRDF properties to model a polarizing surface reflectance.
The details of configuring the "generic" radiometry solver and the material's associated surface properties will be discussed in Polarization How-To.