Project Abstract

NOTE: Project Cancelled due to an outside conflict

Synthetic Aperture RADAR is an extremely versatile instrument used in remote sensing applications. The benefits of SAR are clear -- it is an active sensor, so it can operate without the sun; it uses reasonably long wavelengths, so it can see through weather systems to give scientists a perspective never thought possible before on storm systems, hurricanes, etc.

All good things seem to come at a cost in this world, and SAR is no exception. While LANDSAT, SPOT and similar platforms can return data that is interpretable almost immediately, SAR data requires significant processing post-acquisition.

One tool that does not exist as of now in an Open Source form is a SAR processor, which is what this project sets out to create, using GDAL as a 'base' for the I/O needed for such a project.

GDAL provides potential for access to SAR data -- both RAW data files and serializing processed data files. However, some enhancement to the CEOS driver (for example) will be required in order to properly read the raw data.

Architecture/Development Considerations

Development will take place on GNU/Linux, though attention will be paid to ensure that the code is functional on the BSDs and possibly Solaris.

Several pieces of essential functionality can be borrowed from other projects. For example, FFT/IFFTs can be done using fftw. This will greatly speed early development.

Early on the processor will be designed with RADARSAT-1 in mind, however, as the project progresses it will become less "platform" dependent.

Even initially during development, the SAR processor will be designed with strong consideration for memory usage. SAR data can be very large depending on the platform, the length of the scene and so forth. As such, an approach where memory [ab]usage is not taken into consideration will be make for nightmares later on.

Since the Range-Doppler algorithm is designed in stages, a pipeline-like design is appropriate for this project. As a part of processing an image, a pipeline will be defined by the user. This could be a "trivial" Range-Doppler pipeline or perhaps a more complex pipeline that also contains radiometric correction functionality or even georectifying stages.

The SAR Processor is going to be modular in design. This means that standardized data structures will exist to describe an image's state, as well as store information on the data in memory, as far as design goes. As well, any individual stage of the process is interchangeable, say with experimental variants of processor stages, or even variants optimized to work with specialized hardware (such as GPGPU). As well, this would mean that other algorithms could be implemented at a later time (such as omega-K) without the need for significant changes to the processor.

Implementation Timeline

• May 21, 2007 -- Establish data sanity tests/test plan. Establish licensing issues potentially present
• May 26, 2007 -- At minimum, establish mechanism for determining doppler centroid. As well, build library of platform-specific processing parameters to be used later in processing (from nominal published values)
• May 28, 2007 -- Have selected features to be drawn from other libraries (FFT, fast convolution), filter generation finished (kaiser window generation, chirp replica generation, matched FM filter generation)
• June 25, 2007 -- framework for application completed, file parsers finished
• July 23, 2007 -- Range Compression and Azimuth Compression algorithms finished
• August 13, 2007 -- Range Cell Migration Compression algorithm complete
• August 24, 2007 -- Data Validation and sanity checks mostly pass (defined earlier in term), continual debugging

Note: Some later dates are fairly tentative

External Links

• ​My blog, scanning the world of Open Source SAR, eventually.
• ​Original OSGeo Wiki Page on my project.