GDAL SoC Ideas/SAR Processor

From OSGeo
Jump to: navigation, search


Synthetic Aperture RADAR (SAR) data requires significant processing after acquisition. Since SAR tends to be a very specialized field, there are very few open source applications that specialize in manipulating processed data, much less processing raw data. The goal of this project then would be:

  • Create as generic as possible a SAR Level 0 product processor using the Range-Doppler Algorithm
  • Enhance and extend GDAL's capabilities for reading Level 0 (only) products from a variety of platforms (one point worth investigating is some airborne platforms such as the CV-580)
  • Use GDAL to serialize the resulting image data, be it a GeoTIFF or some other format desired (COSAR, JPEG, who knows, with GDAL there is lots of flexibility)

There are presently no open source applications that are capable of processing Level 0 products, and this is something people have indicated they would desire in the past.

Proposed Schedule

This is subject to change

  • 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

Implementation Details

Initial Goals

  1. Establish a library providing basic mathematical functionality needed: Fast Fourier Transforms, certain types of filter kernel generation, matrix operations, interpolations, chirp generation, etc... as needed (and as can be borrowed from elsewhere)
  2. Ensure that GDAL is up to reading Level 0 SAR data for RADARSAT-1 (this will be the initial test platform) data.
  3. Design a system that is flexible and modular so that a variety of processing algorithms can be implemented in the future such as Omega-K and SPECAN.

Range Doppler Algorithm

  1. Implement the majority of the Range Doppler Algorithm, both documented in Ian Cummings and Frank Wong's book, as well as in a variety of technically significant papers.
  • Range FFT/matched filter generation
  • Azimuth FFT
  • Range Cell Migration Correction
  • Azimuth Compression
  • Look combination

Image Processing Toolkit

  • If time permits, provide a set of tools designed for manipulating SAR data, such as tools for assisting in anomaly detection, perhaps as functionality to be added to GRASS (for example).


The SAR processor itself is a standalone application from GDAL, since the interest is specialized in this field. However, there are several changes that have to be made to GDAL's handling of, for example, CEOS Level 0 products for, for example, RADARSAT. Since RADARSAT International/SPAR Aerospace originally defined auxillary frame data to be piggybacked on top of the CEOS file format, as well as the existence of housekeeping data at the beginning of each Data Frame (also a non-CEOS specified component), changes need to be made to the GDAL driver to account for this. As well, handling of specific metadata for processed SAR data serialization needs to be addressed.

Benefits of this Project

Presently, purchasing a raw SAR processor is an expensive and often challenging task -- the software either has performance issues, has bugs or just simply doesn't hit the right niche for your application. A benefit of an open source SAR processor being available is that the software can be easily modified to suit specific purposes and for experimentation with processing algorithms. As well, supporting new platforms would be easy since the processing pre-requisites would already be completed and easily accessible to all!

People Who Might Be Interested

  • There has been talk for years within Defence Research and Development Canada of the potential for an Open Source SAR processor.
  • Canada Centre for Remote Sensing
  • Commercial users (the cost of a SAR processor as it stands is significant)


The SAR Processing functionality (currently nicknamed OpenSAR) will be licensed under the GNU General Public License v2. Components to be contributed back to GDAL will be licensed under the MIT/X style license used by the project. Any code contributed back to additional projects will fall under the license of that project, however, projects contributed to will fall under the GPL, BSD-style or MIT/X-style licenses only.

Who Am I?

I am an undergraduate student at Carleton University. I am very interested in Synthetic Aperture RADAR from both a processing problem perspective and an applications perspective. I'm very interested in computer sight and have done several experiments involving facial recognition and creating new colour spaces, for example those based on Log Opponents for the purpose of facial identification. As well I've done some work on computer vision applications with regards to Captchas, most recently work on the captchas for MySpace and Digg. My love for SAR and image processing applications can probably be traced back to the fact that my father has been doing research in this field as long as I remember. I suppose apples don't fall far from the tree... With regards to SAR I have done some work on my own library for reading RADARSAT-1 (and generic) Level 0 products, which can be found on my homepage. As well, I have started work on OpenSAR, however, due to time constraints I have been unable to work on it as much as I would have liked to.

As far as programming languages, I am fluent in C[++], Java and Ada. I'm fairly familiar with Lisp, OCAML and Haskell, but I still like to write with those languages while keeping a detailed reference by my side. As well I can muddle my way through most other programming languages given time.

Being very interested in image processing applications, it seems appropriate that I'm an avid photographer. However, unlike the work I enjoy doing in my spare time on computer sight, I prefer to take a more old-fashioned approach and still trust my Nikon FM2n (135 format) and my Bronica SQ-A (medium format) film cameras more than I trust a digital camera. Some of my photos can be found on my Flickr site, however, it has been awhile since I updated it (and I really need a new scanner!).

this is still a work in progress