Frequently Asked Questions

The name DIRSIG is an acronym for "Digital Imaging and Remote Sensing Image Generation". The first part of the formal name comes from the Digital Imaging and Remote Sensing (DIRS) Laboratory at the Rochester Institute of Technology (RIT) where the model was created.

The DIRSIG model is a complex synthetic image generation application which produces simulated imagery in the visible through thermal infrared regions. The model is designed to produce broad-band, multi-spectral and hyper-spectral imagery through the integration of a suite of first principles based radiation propagation sub models. These sub models are responsible for tasks ranging from the bi-directional reflectance distribution function (BRDF) predictions of a surface to the dynamic scanning geometry of a line scanning imaging instrument. In addition to sub models that have been specifically created for the DIRSIG model, several of these components (MODTRAN and FASCODE) are the modeling workhorses for the multi- and hyper-spectral community. All modeled components are combined using a spectral representation and integrated radiance images can be simultaneously produced for an arbitrary number of user defined bandpasses.

The DIRSIG software is developed at Rochester Institute of Technology by the "Modeling and Simulation Group" within the Digital Imaging and Remote Sensing Laboratory.

No. The software has been developed over the course of two decades under funding from a variety of commercial and government sponsors. Furthermore, RIT has invested a significant amount of it's own resources into the development of the software. As a result, the source code is the property of RIT and the model is distributed in binary form only.

Since RIT does hold the rights to the source code, we are commonly asked why we don't make it available to the users. Without any mechanism that forces users to propagate contributed changes back to RIT, the concern of both RIT and our primary government users is that the code will fracture into numerous customized versions. The government wants to know that if two users submit their results on a given task where DIRSIG was used, that the same model was used. When multiple versions evolve, verification and validation also must be questioned. Therefore, RIT does not plan to make the source code generally available.

However, we do publish very frequently in open literature (conference papers, journal papers, and student theses) exactly how various calculations are performed. In some cases, if a user really wants to see or understand a specific calculation, then we will reveal that portion of the code. Finally, we continue to open up run-time interfaces within the model so that DIRSIG can be better integrated into other modeling workflows.

The DIRSIG software is supported on the major UNIX/Linux platforms and the Mac OSX platform (another UNIX-based operating system). Below is the list of platforms that release builds are created for:
- Sun Microsystems Solaris 9/10 on UltraSparc processors
- Linux 2.4 kernel distribustions on 32-bit Intel/AMD processors
- Linux 2.4 kernel distribustions on 64-bit Intel/AMD processors
- Apple Mac OSX (Tiger and Leopard) on PowerPC/Intel (Universal)

Starting in the Fall of 2008, DIRSIG will also be supported on the Windows platform.

The user experience on all platforms is the same. The DIRSIG user interface is written using the Qt Developer API which allows us to create robust user interfaces with native look and feel from the same code base.

DIRSIG is distributed only to users that meet the following requirements:
- The user must be an employee of a U.S. Government organization or contractor.
- The user must have attended a DIRSIG "Basic Training Course". This training course is offered roughly on a quarterly basis at a cost of $2,000. More information can be found on the Training webpage.
- Completion of the "DIRSIG Software Agreement" which is available on the Agreements webpage.

The software is currently free to qualified users. The only cost is the attending the "DIRSIG Basic Training Course" (which is required for new users).

DIRSIG leverages the U.S. Air Force's atmospheric radiation code "MODTRAN". Although there are ways to run the model using empirically based atmospheric contributions, this is strongly advised against for use in rigorous studies. The MODTRAN software is currently distributed by ONTAR Corporation. The DIRSIG model can also be used with the USAF FASCODE atmospheric radiation code.

The output image data created by the model is easily read into the ENVI image processing and analysis package. However, the most common output data is a simple, double precision floating-point, band interleaved by pixel format that can be easily read into most packages.

The DIRSIG model is primarily used to model systems that operate in the visible through the long-wave thermal infrared (LWIR) or 0.4 to 20 microns. Under the hood, the model is operating on a spectral basis which allows the user to simulate broad-band, multi-spectral and hyper-spectral sensors. The ultimate spectral resolution of the model is limited by the available resolution of the optical properties (reflectance, emissivity, absorption, etc.) and the atmospheric model (MODTRAN4 is limited to 2 wavenumbers and MODTRAN5 to 0.2 wavenumbers).

The model could be used for UV simulations (down to 0.2 microns), however, optical characterizations of materials at these wavelengths are not common and the development team is not aware of this being attempted.

Yes, the DIRSIG model's internal radiometry engine automatically adjusts to propagate polarized fluxes when the need arises. If the sources of illumination (Sun, Moon, Sky, user-define sources, etc.) are polarized, or if the surface or volume optical properties are polarized then the model will shift to a full Stokes Vector and Mueller Matrix based calculus automatically.

The DIRSIG software can be used with MODTRAN4-P (an experimental, polarized version of MODTRAN4) and has several built-in polarized BRDF models.

The model can output fully spectral-polarimetric radiances for processing by external sensor models.

Yes. The DIRSIG model is one of the most sophisticated active laser scene simulations available. Several other LIDAR scene simulation tools simply ray-trace a range to the scene and apply image processing techniques to introduce beam related effects (speckle, etc.). What is generally unique to the DIRSIG modeling approach is that it performs a propagation of the beam into and out (down and up or out and back) of the scene. Unlike the simplified range measurement approaches, this approach allows the DIRSIG model to introduce multiple-bounce and/or multiple-scattering effects. In complex scenes or applications (e.g. foliage penetration, dense urban canyons, etc.) the delayed returns of these multiple scattered photons can create false or ghost returns that can impact data utility.

The DIRSIG model is primarily a radiometry engine that creates a spatial x spatial x time cube of returned energy. This allows the model to be used to simulate a wide variety of detector systems including linear mode, full waveform digitizer, Gieger-mode avalanche photo detectors (GmAPD), etc. Documentation for parsing the LIDAR output is available so that custom back-end detector models can be implemented by the user. The DIRSIG model ships with a GmAPD post-processing tool that converts the photon arrival cube to range triggers and geo-locates them using the platform location, orientation and pointing ephemeris data that is also generated by the model.

None. Although the DIRSIG model is primarily used for "overhead" or "downlooking" geometries, the platform location and orientation model allows the user to point the simulated sensors in any direction (up, down, slant, etc.).

Yes. The DIRSIG model supports both dynamic scene content and dynamic platform positioning, platform orientation and platform relative pointing (e.g. scanning). The user can create dynamic scene content such as moving vehicles, spinning helicopter rotors, etc. through the scene motion mechanisms. The platform model is inherently dynamic and allows the user to supply platform location and orientation as a function of time. The sensors are attached to the platform via "mounts" of which several mount models are available including many that scan as a function of time (whisk scan, user-defined scan, etc.). The clocks for all the scene motion, platform motion, mount motion and focal planes can be synced to a central clock to make scripting of a complex collection easier.

The simulated data collection is controlled by the user specifying time windows during which the simulated system collects data. By specifying a time window, the simulated focal planes will collect sequences of images (based on the focal plane clock rate) which can be externally combined to make movies.

The model has a flexible model that allows the model a virtual collection "platform". Attached to that platform at various user-defined locations and orientations are "instrument mounts" where instruments or sensors can be attached. Each mount can be either static or dynamically oriented relative to the platform as a function of time. Each instrument or sensor is attached to its corresponding mount using a user-defined location and orientation specification. Within each instrument, the user can create a set of virtual focal planes with various dimensions (number of pixels), pitches (individual pixel size), offsets (array to array offsets) and clockings. Each focal plane can have one of many available "capture method" models assigned to it. These capture models allows the user to model the spatial and spectral responses of the associated focal plane.

Using this flexible description, the user can simulated a variety of different types of different sensors. This includes, but is not limited to, the following:
- A fixed, broad band, 2D array camera (e.g. an LWIR camera).
- A ground vehicle based 2D array video camera.
- An airborne 2D Bayer pattern (structured filter array) camera on a UAV (e.g. a surveillance camera).
- An airborne or space-based, multi-spectral "pushbroom" (1D array) instrument.
- An airborne, whisk-broom scanning, hyper-spectral instrument (e.g. AVIRIS).
- An airborne platform with a "cow's udder" array of cameras, each pointing in a different direction relative to the platform.
- An airborne hyper-spectral "pushbroom" instrument with an RGB video "context camera".
- An space-based, multi-spectral "pushbroom" instrument with separate, modular RGB arrays and a separate, modular high resolution pan array.
- An airborne Geiger-mode APD LADAR/LIDAR system.
- A vehicle mounted, side-looking linear-mode LADAR/LIDAR system.
- A Michelson Fourier Transform Spectrometer (FTS) on a tripod.

The material description sub-model is very flexible. The top most classification of materials is broken into "surface" and "volume" descriptions. The only difference between these two classes is the type of optical descriptions associated with them.

Most "hard target" or "background" materials fall into the "surface" materials. A surface material can have a reflectance model, an emissivity model or both associated with it. Both the reflectance and emissivity models are responsible for providing spectral coefficients for supplied geometries. There are several reflectance models including directional hemispherical reflectance (DHR) and Bidirectional Reflectance Distribution Function (BRDF) models. There are also a handful of emissivity models. In the event that the reflectance is known but the emissivity is not, the later will be computed from the former for the requested geometry. If the emissivity is known and the reflectance is not, the computed reflectance is assumed to be diffuse (Lambertian).

Materials like gas plumes, clouds, water, etc. fall into the "volume" category. These materials have absorption, scattering and/or extinction properties associated with them. Like with surface materials, if two of the three properties are know, the third will be computed. For example, if the scattering and extinction are known, the absorption will be computed. If the scattering is the unknown quantity, then the computed scattering is assumed to be isotropic.