Changes between Initial Version and Version 1 of SoCSignalProcessor


Ignore:
Timestamp:
Apr 12, 2007, 12:37:27 PM (17 years ago)
Author:
pvachon
Comment:

Created

Legend:

Unmodified
Added
Removed
Modified
  • SoCSignalProcessor

    v1 v1  
     1== Project Abstract ==
     2Synthetic 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.
     3
     4All 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.
     5
     6One 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.
     7
     8GDAL 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.
     9== Architecture ==
     10Development will take place on GNU/Linux, though attention will be paid to ensure that the code is functional on the BSDs and possibly Solaris.
     11
     12Several 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.
     13
     14Early on the processor will be designed with RADARSAT-1 in mind, however, as the project progresses it will become less "platform" dependent.
     15
     16Even 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.
     17
     18Since 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.
     19
     20The 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.
     21
     22== Implementation Timeline ==
     23 * May 21, 2007 -- Establish data sanity tests/test plan. Establish licensing issues potentially present
     24 * 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)
     25 * 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)
     26 * June 25, 2007 -- framework for application completed, file parsers finished
     27 * July 23, 2007 -- Range Compression and Azimuth Compression algorithms finished
     28 * August 13, 2007 -- Range Cell Migration Compression algorithm complete
     29 * August 24, 2007 -- Data Validation and sanity checks mostly pass (defined earlier in term), continual debugging
     30'''Note''': Some later dates are fairly tentative
     31
     32== External Links ==
     33 * [http://www.geoscan.info My blog], scanning the world of Open Source SAR, eventually.
     34 * [http://wiki.osgeo.org/index.php/GDAL_SoC_Ideas/SAR_Processor Original OSGeo Wiki Page] on my project.