What is DIRSIG?
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.
Who develops DIRSIG?
Is the DIRSIG software open source? Is the source code available?
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 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.
Is the DIRSIG software export controlled?
RIT has self-imposed a policy that the DIRSIG model is to be used within the U.S. in support of U.S. interests. Although the software has not been officially marked as "export controlled" by the Department of Commerce, RIT requires that users work for U.S. government agencies or supporting organizations.
Doesn’t the DIRSIG model fall under ITAR control?
RIT does not believe that the software itself should be ITAR controlled. However, the DIRSIG model can be used to simulate systems that would fall under ITAR control. RIT believes that end users should not "launder" away ITAR controls by faithfully simulating data from a sensor that would be ITAR controlled in the real world.
RIT has also found that interpretation of the ITAR policies varies greatly from organization to organization. Therefore, the Software Agreement explicitly places the responsibility on the end user to interpret and resolve ITAR control issues.
Access and Requirements
How do I get the DIRSIG Software?
DIRSIG has been developed over the course of over two decades through a combination of internal, commercial and government funding. In agreement with our past and current government partners, 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.
This includes all NSF, NASA, DoD and Intelligence community contractors including universities doing research for these organizations.
The user must have attended a DIRSIG training class (a course fee is involved)
Agree to the DIRSIG Software Agreement
Why am I required to take training in order to have a copy of DIRSIG?
DIRSIG is a complex software code. The Basic DIRSIG Training class will prepare users on the operation and uses of DIRSIG. Our experience is that most new users without training will require some level support causing us to get inundated with questions for which we are not equipped or funded to answer. This only leads to frustration by both parties.
What are the costs associated with the DIRSIG software?
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.
What computing platforms is the DIRSIG software available for?
The DIRSIG software is supported on Windows, the Linux platform and the Mac OSX platform (another UNIX-based operating system). Below is the list of platforms that release builds are created for:
Microsoft Windows XP, Windows Vista, and Windows 7 and Windows 8 on Intel/AMD x86 processors (64-bit only).
Linux 2.6 kernel distributions on Intel/AMD x86 processors (64-bit only).
Apple MacOS X (10.4 and later) on Intel processors (64-bit only).
The user experience on all platforms is the same. The DIRSIG user interface is written using the Qt Developer Framework which allows us to create robust user interfaces with native look and feel from the same code base.
Consult the Installation Guide for more detailed hardware and software requirements.
Is DIRSIG multi-threaded, parallelized, GPU-accelerated, etc.?
The current DIRSIG4 code base was originally architected in 2001 before multi-core CPUs and general purpose graphical processing units (GPUs), etc. were on the market. As a result, the DIRSIG4 code was not parallelized at the micro-scale (using multi-threading to take advantage of multiple cores on a single computer) or at the macro-scale (using the Message Passing Interface (MPI) to take advantage of multiple computers). At the training course, we discuss several strategies for breaking large simulations in a a set of smaller ones that can be run separately (and in parallel) and then recombined. There are no plans to add parallelization or other accelerations to the DIRSIG4 code base.
The new DIRSIG5 code base (made available to users in 2019) is multi-threaded and a MPI-enabled Linux build is also available. A GPU-accelerated version has been under investigation for some time, but notable increases over the CPU versions have not yet been realized. The GPU acceleration effort focuses on the optimizing the ray-tracing component of the calculation, which accounts for about 60% of the run-time. Do to the complexity and extent of the code, it is impractical to reimplement the entire model as a GPU code. For more information on multi-threaded and multi-node execution, consult the DIRSIG5 Migration Manual and the DIRSIG5 MPI Manual.
What is the size of the DIRSIG user base?
There are currently 750 registered users of the software. The active user population is estimated to be about 1/2 to 2/3 of that number based on software release downloads.
How often is the DIRSIG software updated?
Updates to the software are release 3-5 times per year, depending on development schedules and reported problems from the user base.
What kinds of formal development policies are employed?
The DIRSIG model is developed by 2-3 full time staff members that have been involved with the project for nearly 30 years combined. Internally, DIRSIG is revision controlled with Subversion. Individual releases are tagged for historical record keeping. Major releases are copied from the main development trunk. Minor releases are manually patched from the previous tag. Software testing is accomplished via an extensive set of unit tests, internal end-user testing and beta testing by the external user base for each release.
The DIRSIG5 code base leverages buildbot for continuous integration (CI). Code changes trigger a basic level of testing that provide the developers feedback within 15-20 minutes. Every night the CI environment does from scratch builds of the software and runs an extensive set of unit and integration tests.
How do users report problems?
What third party software is integrated with DIRSIG?
A variety of third party libraries and tools have been integrated into DIRSIG.
These elements are incorporated and distributed in compliance with their
individual license terms. A complete listing can be found by viewing the
licenses via the DIRSIG software (for example, using the
in the command-line interface).
What other software is required to use DIRSIG?
DIRSIG leverages the U.S. Air Force’s atmospheric radiation code "MODTRAN", which is developed by Spectral Sciences, Inc. 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 available from the MODTRAN website.
What other software is convenient (but not required) to use DIRSIG?
The DIRSIG software comes with a basic image viewer, but the output image data created by the model can be directly read into the ENVI image processing and analysis package. Using ENVI is not a requirement, but does provide advanced image analysis options. The DIRSIG output data is a simple, double precision floating-point, band interleaved by pixel format that can be easily read into most data analysis and visualization packages (including Matlab).
How is DIRSIG development funded?
The DIRSIG model has been funded by a combination of government and commercial organizations during its lifetime. This includes a significant investment by RIT.
What long-term contracts support software releases, etc.?
None. RIT self-funds general development and software releases.
Can my organization fund DIRSIG development?
Yes. The DIRS laboratory is a research contract driven entity. Please contact us if you are interested in sponsoring research, especially research that can involve students.
How do new features get added to DIRSIG?
RIT is constantly taking feedback from the current and potential user base regarding needs. If RIT has the resources, then RIT will self-fund the development of a new feature. Alternately, RIT can establish contracts with users to fund development.
If I fund a new feature, does everyone get to use it?
Yes, there is only one version of DIRSIG. This is the funding model that has made DIRSIG what it is today. Every user is leveraging the investment of others. However, new features are not made public until they have reached a certain level of maturity (robustness, supporting documentation, etc.). Therefore during a development project, the funding organization has the advantage of shaping the implementation and gains valuable insights and experience using that new feature well in advance of other users.
Can I buy a support contract?
Yes and a support contract is strongly encouraged for relatively new users or for experienced users applying DIRSIG on a unique application. The support contract will enable RIT to answer questions, evaluate modeled results, or make small modifications to the code. We typically sell support contracts in 40 hour increments and notify you when you are out of support hours. Contact us for more information.
What wavelengths, modalities, etc. can be simulated with DIRSIG?
The DIRSIG model is primarily used to model systems that operate in the visible through the long-wave thermal infrared (LWIR) or 0.2 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 1 wavenumbers and MODTRAN5 to 0.1 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.
What general classes of sensors can be simulated with DIRSIG?
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.
This list is not intended to be complete but rather convey that the model is very flexible and can model a wide variety of systems.
What limitations are there on the direction a sensor can look?
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.).
Can my sensor look up at an exo-atmospheric object?
RIT has been working on the "Space Situational Awareness" (SSA) application area. Although this application area is not as mature as others, RIT is very interested in supporting this research. The SSA Handbook outlines the current capabilities of the model and some of the proposed work RIT is interested in pursuing.
Can DIRSIG model a polarized system?
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. Additionally, the model has support for configuring user-defined spectral-polarimetric filters on a per-channel (per-band) basis.
Can DIRSIG model a LIDAR/LADAR system?
Yes. Consult the LIDAR Modality Handbook for more information.
Can DIRSIG model a real and/or synthetic aperture RADAR system?
Yes, but this capability is still in development. Consult the RADAR Modality Handbook for more information.
Virtual Scene Content
What 3D geometry formats are supported?
The model will read the Alias OBJ file format directly, but it also supports a custom format that can be created via authoring tools supplied with the model. Other geometry formats can be readily exported to the Alias OBJ format for importation into a DIRSIG scene. Note that geometry used with the DIRSIG model must be associated with DIRSIG specific material descriptions that support the multi-modal nature of the model.
What kinds of materials can be modeled?
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.
Can "dynamic" data can be simulated with the DIRSIG model?
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.