DIRSIG

We are often asked what programs can view DIRSIG's image outputs and how to import the raw DIRSIG image data files into other tools for further processing. For basic image viewing, DIRSIG-4.4.0 now includes a very simple viewing tool. Launch it from the main simulation editor window by selecting the "Start image viewer" option from the "Tools" menu. If you run your simulation from the GUI simulation editor, new image files are automatically added to the list in the image viewer as they are generated. If you want to manually add files to the list, simply select the "Open" item from the "File" menu or the toolbar. Here is a screenshot of the main image viewer window. The top part contains the list of currently opened files and the bands within those image files. To view a single band as a gray-scale image, choose "Single Band Display" from the combo box and then click on the image band that you want. Finally, click "Load Band...

Included in the DIRSIG-4.4.0 release candidate is a new "warehouse" scene. As shown below, this scene features a fairly high amount of geometric clutter. The scene includes stacks of wood palettes and crates, steel I-beams, piles of corrugated steel panels, steel pipes, shipping containers, concrete barriers and other "cultural clutter" objects that might be found at a site like this. The scene was created with roughly a 0.10 [m] GSD in mind. It includes full spectral coverage in the visible, NIR, and SWIR. This will be extended to the MWIR and LWIR in the future. Placement of geometry and material attribution was done using Blender together with some DIRSIG I/O python scripts. The material database was manipulated using the "mat_edit" tool. The material map over the terrain was originally drawn as a vector layer using Inkscape and then cleaned and converted to its final PGM version using Gimp . In addition to adding LWIR coverage, we would like to i...

We are pleased to announce a "release candidate" for DIRSIG 4.4.0 has been posted to myDIRSIG. A "release candidate" is a preview of the next release of DIRSIG. This version of the software is produced when we feel the software is well tested and ready for release, but we would like some last-minute user feedback. We are very excited about this release as it packs in a bunch of new features and performance improvements: New User Interface Tools Graphical simulation preview Basic image viewer Component browser SGP4 Orbiting Platform Motion Wizard Geometry Improvements Added affine transform INFO option to ODB Ray-trace optimization for dynamic (moving) scene geometry Support for vertex normals (normal "shading") on OBJ input geometry Atmosphere Added the GUI for the built-in "uniform" atmosphere model User-defined MODTRAN profile support (make_adb config file) in GUI for "classic" (ADB file based) and "threshold" (run-time MO...

Niek started this blog 4 years ago, but then let it go dormant. We recently decided it would be a good thing to have some sort of way to publicly show each other and the user community some of the fun, cool and helpful things we are working on from time to time. So please stay tuned in the future for news, tips, tricks, etc. about the DIRSIG model.

The next release of DIRSIG will feature two major internal optimizations. One which will significantly speed thermal runs. The other which will speed unpolarized radiometric calculations--especially noticeable in hyperspectral cases. New functionality includes a user-configurable interactive mode, which allows for a user-specified ray/solid angle to be traced and for arbitrary data to be extracted from the solution. The output can be either easily-parsable XML or human-friendly plaintext.

The Urban (Hawkeye) scene will soon be made available with secondary sources enabled. For now, these secondary sources can only be rendered using DIRSIG3. Support for this feature is planned for DIRSIG4, but there is no fixed implementation date.

The DIRSIG-4.0.7 build is now available off the myDirsig website. Besides a bunch of smaller bug fixes, the key improvements are to the LIDAR and Polarization models. This is also the first release in which Voxelized Grids can be reliably used ( demonstration ). This release also marks the first time that the DIRS Laboratory has put out an x86-64 based Linux build. Assembled on Fedora Core 5, it takes advantage of the additional registers and instructions added to the 64-bit x86 CPUs. Unfortunately, many of the libraries are dynamically linked, making it difficult to use portably across different Linux platforms. Future releases will feature more static linkage. Note that this version has undergone extensive testing; it is used across our internal compute cluster.

The DIRSIG4 codebase now contains a make_dem tool, outputting either ascii or ENVI image digital elevation maps. Gnuplot can visualize the ascii output (via the splot command). ENVI or Freelook can be used to render the image output. The tool currently requires a .cfg file as input, an annoying limitation. This is due to a design issue in the geometry subsystem; it will be addressed in the future.

According to the webpage, DIRSIG4 is currently only supporting Solaris/SPARC 2.9+ and Linux/x86 2.4 kernels. The next set of releases (dirsig-3.6.5 and dirsig-4.0.7) will come with experimental support for the x86-64 platform. Internally, we have a cluster of Athlon64 machines running Fedora Core 5. The added registers on the 64-bit x86 architecture give a significant speed boost over the 32-bit counterpart. The biggest issue with supporting new platforms is packaging the end product. Solaris is a particular pain because users are poor at keeping their installations up to date. There are still people out there using Solaris 8 when the current OS version is Solaris 10. Another issue is which version of LAM MPI to use for the Linux builds. The key contenders are 7.0.6 and 7.1.2. Most of our userbase tend to have older OS setups, so we will probably use the former.

It occurred to me that the ODB instancing can be used on both solid geometry and voxelized grids. Among other things, this means that grids no longer need to be axis-aligned. Simply stick the solid geometry or grid in a separate ODB file and instance it using the technique discussed in Instancing ODBs .

Another feature coming in DIRSIG 4.0.6 is support for regular voxelized grids. The advantage of these structures is that they allow for extremely fast intersections of regularly spaced boxes. The backend code for implementing these grids is also used by DIRSIG to implement support for the QUIC concentration map outputs. In the ODB file: REGULAR_GRID { INSERT_POINT = 0,0,0 DELTA_X = 20 DELTA_Y = 10 DELTA_Z = 25 GRID_FILENAME = niek.grid } The INSERT_POINT indicates a grid extent, the point with the smallest x,y,z coordinate values. DELTA_X/Y/Z indicates the size, in meters, of each voxel. The GRID_FILENAME indicates where the voxel data is stored. Note that the .grid extension is not required. The contents of the .grid file are as follows: 10 10 10 9 9 0 13 230 0 9 8 0 13 230 0 9 7 0 13 230 0 The first line indicates the number of boxes in the x, y, and z direction. For ...

The DIRSIG team is working with Los Alamos National Laboratory (LANL) to integrate the Qwick Urban industrial Complex (QUIC) plume model in to DIRSIG. Starting with version 4.0.6, the functionality to read in a QUIC gas concentration output will be available. The functionality is currently experimental, and the syntax is liable to change in future DIRSIG revisions. An example of an NH 3 plume: PLUME { QUIC_INSTANCE { CONCENTRATION_MAP = quic.dat MOLECULAR_WEIGHT = 17.03 MATERIAL_ID = 5 RELEASE_TEMPERATURE = 550 INSERT_POINT = 0,0,0 GRID_OFFSET = 3,3,0 DELTA_X = 1.0 DELTA_Y = 1.0 DELTA_Z = 1.0 } } The CONCENTRATION_MAP indicates the QUIC output file. The MOLECULAR_WEIGHT allows DIRSIG to convert from the [g/m 3 ] used by QUIC to the [ppm] used by DIRSIG. The MATERIAL_ID gives the entry in the materials database supplying the radiometric and thermal properties of the gas. The RELEASE_TEMPERATURE, in kelvin, is a hack, compensa...

A helpful hint if you are using PGM images with DIRSIG maps. It is orders of magnitude faster to load a binary (aka "raw") PGM than an ASCII one. The difference is especially visible when loading large images, such as 4k by 4k textures in Microscene1. You can check the PGM format by opening the .pgm file in a text editor. If the first characters in the file are "P2", then you have an ASCII image (notice that all the digital counts are stored in ASCII further down the file). If it says "P5", then it's already binary, so there is nothing left to do. To convert from ASCII to binary PGMs, you can use the freely available image tool GIMP ( www.gimp.org ). Simply open the image, select "Save As" and choose "Raw" when it queries about data formatting.

The current development version of DIRSIG4 supports ODB instancing. Like object instancing, the same ODB can be used multiple times via an affine transformation. This also gives a quick way to rotate entire ODB files. Here's the new syntax: OBJECT { ODB_FILENAME = ./foxbat.odb UNITS = METERS INSTANCES { INFO = 0.00, 0.00, 0.0, 1.00, 1.00, 1.00, 0.00, 0.00, 0.0 INFO = 0.00, 0.00, 0.0, 1.00, 1.00, 1.00, 0.00, 0.00, 90.0 } } This functionality should become available in the next release of DIRSIG4.

In many DIRSIG installations (including the one at the DIRS lab), the included sample scenes are placed into read-only directories. What happens when you want to add additional materials and geometry? This post discusses a neat trick that can help. The obvious, brute-force, method copies scene contents to a writable location (via cp -R). This is clearly a poor solution for complex scenes, such as Megascene1 which takes several gigs of disc space. Furthermore, copies may end up out of sync with any patches and updates applied to the read-only version. Another approach reconstructs the scene directory in a writable location using symbolic links (UNIX ln command), making local copies only of files which need to be changed. This technique can be a pain to set up for complex scene directory layouts. Again, a local copy of the material database can become out of sync with the read-only one. Alternatively, we can take advantage of the INCLUDE_FILE directive. For a material database, we'd ...

I'm one of the three core developers on the DIRSIG project. This blog is simply an experiment in information dissemination. It's intended for both power users and developers. Hopefully, it will make our development process a bit more transparent.