# ISCE2 is the framework NASA funds to turn radar into interferograms

> ISCE2 is the Interferometric Synthetic Aperture Radar Scientific Computing Environment, a research framework that turns raw satellite and airborne radar data into interferograms, with a component framework underneath and a long list of supported sensors. It ships as source you build with SCons, under research code terms with export control attached.

**isce-framework/isce2** — InSAR Scientific Computing Environment version 2

- Repository: https://github.com/isce-framework/isce2
- Stars: 674 · Forks: 312
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/isce-framework-isce2

## Research code, funded by NASA, with export paperwork attached

ISCE stands for Interferometric synthetic aperture radar Scientific Computing Environment, and the repository makes its nature clear in the first paragraph. Initial development was funded by NASA's Earth Science Technology Office under the Advanced Information Systems Technology 2008 programme, and the project is currently funded under the NASA-ISRO SAR project, the mission partnership behind the NISAR radar satellite.

The funding lineage explains the engineering style. This is research software, built by scientists and engineers for a scientific community, and the README says so bluntly: it is provided as is with no warranties of correctness, and you use it at your own risk.

The licence and the export classification are the two things an organisation has to read carefully. The software is open source under the terms of the Apache License, and the repository carries a LICENSE file, a LICENSE-2.0.txt and a LICENSE-2.0.html, so the Apache grant is the base. On top of that, the export classification is EAR99 NLR, which the README says entails some restrictions and responsibilities. That is a compliance obligation attached to the code, and it is the reason the project is a poor fit for a product team that wants a clean open source dependency and nothing else to think about.

The project also states that the framework aspects were designed as a general software development framework and may have utility for building other kinds of software packages, which is an invitation to read the code as a platform rather than as a script collection.

## The sensor list is the honest feature list

The README says ISCE supports data from many spaceborne satellites and one airborne platform, and that the number of supported sensors keeps growing. The current list is: ALOS, ALOS2, COSMO_SKYMED, ENVISAT, ERS, KOMPSAT5, LUTAN1, RADARSAT1, RADARSAT2, RISAT1, Sentinel1, TERRASARX, UAVSAR and SAOCOM1A.

That list is the real specification for an InSAR practitioner, and it is worth reading against your own archive before anything else. It covers the long time series missions such as ERS, ENVISAT, ALOS and RADARSAT, the modern Sentinel1 and TERRASARX, COSMO_SKYMED and SAOCOM1A, the smaller RISAT1 and KOMPSAT5, and UAVSAR as the airborne case. A mission absent from that list is a mission the framework does not read, and no amount of configuration will change that.

Interferometry is the specific capability here. The framework is built to process InSAR data, meaning it produces interferograms and the downstream products that come from them, rather than doing generic image processing.

Two auxiliary capabilities show up in the dependency list rather than in the feature list. There is mdx, an image visualisation tool, and there is a DEM story, since curl is listed as a basic dependency for automatic DEM downloads and there is a section on digital elevation models in the README's contents. Automatic DEM retrieval is the kind of detail that matters operationally, because a processing chain that silently fetches terrain data is a chain with a network dependency in the middle of it.

## A dependency list that grows with the features you enable

The basic requirements are modest for a scientific codebase: gcc 4.8 or later with C++11 support, fftw 3.2.2 or later with single precision support, Python 3.5 or later with 3.6 preferred, scons 2.0.1 or later, curl for automatic DEM downloads, and GDAL with its Python bindings at 2.2 or later.

The optional dependencies are where the real shape of the project appears, because each one maps to a capability.

For a few sensor types you need hdf5 1.8.5 or later and h5py 1.3.1 or later, which covers COSMO-SkyMed, Kompsat5 and the Generic sensor. That last detail is useful, since a Generic sensor reader with the HDF5 libraries gives you a way to bring in data from a platform that is not on the supported list at all.

For the mdx visualisation options you need the Motif libraries and include files, plus ImageMagick for producing kml files and grace for producing colour tables and line plots. Both are described as advanced features, so they are optional in the strict sense.

The unwrap 2 stage option needs RelaxIV and Pulp. RelaxIV is a minimum cost flow relaxation algorithm in C++, and the README is specific about where its files go: they must be placed in contrib/UnwrapComp/src/RelaxIV so that ISCE compiles it properly. Pulp can be installed with easy_install or pip, and its path must be on PYTHONPATH, which the README says should already be the case with either installer.

Finally, splitSpectrum and the GPU modules need cython3 with an executable of that name, using a symbolic link if necessary, plus cuda for GPUtopozero and GPUgeo2rdr and opencv for split spectrum. In other words, the unwrapping and the spectral work are where the exotic dependencies live.

## Getting dependencies in with conda, and the python3 convention

Two dependency routes are documented. The conda route is a requirements file, and the README gives its contents:

```bash
cython
gdal
git
h5py
libgdal
pytest
numpy
fftw
scipy
basemap
scons
opencv
```

You put that in a text file named requirements.txt and install it with:

```bash
> conda install --yes --file requirements.txt
```

There is one manual step afterwards, and the README calls it out because it is easy to miss: you need to create a link in the anaconda bin directory for cython3. That executable name matters because the splitSpectrum and GPU modules require an executable called cython3.

The Macports route is a list of ports instead, assuming gcc7 and python36, and it is much longer, including the Motif and openmotif packages, both fftw variants, the netcdf family in three languages, postgresql95 with its server, proj, cairo, scons, opencv, ImageMagick, a gdal port with a long list of options, and the numpy, scipy, matplotlib, basemap, h5py and gdal Python ports. The Macports list carries version tags such as +gcc7 and +python36, which is a good sign of how old and how tightly coupled the dependency set is.

The python3 convention deserves attention because it bites people. The project follows the convention of most package managers, using the executable python3 for Python 3.x and python for Python 2.x, so that Python code can be turned into an executable command by naming the right interpreter in the shebang line. But not every package manager creates the python3 executable, macports being the one the README calls out, so you may need to place a soft link on your path yourself. The payoff is that an ISCE application such as stripmapApp.py can then be invoked directly rather than through an explicit interpreter path.

## Configuration lives in an SConfigISCE file, not in a config directory

The recommended build system is SCons, and the configuration control is unusual enough to be worth reading twice. SCons requires configuration information to be present in a directory specified by the environment variable SCONS_CONFIG_DIR. You create a build configuration file called SConfigISCE and place it in that directory, and the file records the paths the build needs:

```bash
# The directory in which ISCE will be built
PRJ_SCONS_BUILD = $ISCE_BUILD_ROOT/isce

# The directory into which ISCE will be installed
PRJ_SCONS_INSTALL = $ISCE_INSTALL_ROOT/isce
```

The README stresses that locations vary from system to system and that the ones shown are illustrative, so this file is a template rather than a copy and paste answer. It also has to describe the location of libraries such as libstdc++ and libfftw3.

The practical consequence is that a build here is not self configuring. You are asked to state your build root, your install root and your library locations before a single target is compiled. For a research group that builds this once on a cluster and then rebuilds for years, that is a perfectly good trade. For a team that wants reproducible builds across many machines, it is friction you have to wrap in your own tooling.

CMake is listed as an alternative in the contents, and it is labelled experimental, while SCons is the recommended path. The repository has both a SConstruct and a CMakeLists.txt, plus a .cmake/ directory, so both build systems are present in the tree.

The repository layout follows the same structure. There are applications/, components/, contrib/, library/, configuration/, defaults/, schema/, setup/, test/, examples/, docs/ and docker/ directories, plus scons_tools/ and support files such as license.py and release_history.py.

## Running it: a command line, an interpreter, and steps

The README's contents list three ways to run ISCE, and the distinction between them is the thing to take away.

The first is from the command line, where an ISCE application is an executable script. The second is inside the Python interpreter, which matters for anyone who wants to drive the processing from a notebook or a script of their own rather than from a shell. The third is running ISCE with steps, which is a more granular mode.

The repository also links a separate README for the stack processors under contrib/stack, and a section on notes on digital elevation models, plus a section on input files. A section on component configurability describes how components are named by family and instance, where their configuration files live, and how priorities between configuration sources are resolved, and a further section covers component configuration help. Those are the mechanics that decide what actually runs when you invoke a workflow.

The repository layout explains how that configurability is implemented. The components/ directory holds the processing steps, applications/ holds the runnable programs, defaults/ holds default configuration, configuration/ holds the configuration machinery, and schema/ holds the structured descriptions of the configuration. A separate test/ directory and an examples/ directory with applications and input files sit alongside them, and a docker/ directory is present for container based use.

The community support is a forum thread linked from the contents, and the CI badge points at a CircleCI configuration, so the project is exercised in continuous integration even though the source distribution is the primary artefact.

## Building from source against a container image

The alternative to compiling ISCE yourself is to use the container route, and the repository has a docker/ directory for it. The difference in approach is the one that matters for a research pipeline.

Building from source gives you the component framework compiled against your own libraries, your own GDAL, your own Python, and a copy you can patch. The SConfigISCE file is the price of that freedom, and the long dependency list is the second price. You end up owning the toolchain, which is the right answer when you need to modify a component, tune a processor, or build against a sensor the stock image does not know about.

A container image removes the toolchain from the equation. The dependencies are fixed when the image is built, the python3 and cython3 conventions are handled for you, and the environment is identical on a laptop and on a cluster node. The cost is that you inherit the image's build choices, and a customisation that is not in the image has to be layered on top of it.

For most users of this framework, the deciding factor is not the build system at all. It is whether the sensors you need are in the list, whether the unwrapping and spectral options you want are enabled, and whether the export control obligations attached to EAR99 NLR are acceptable for your organisation and your distribution model.

One thing the README does not document is a rollback or a supported upgrade path between versions, and the release history shows a long gap between 2.6.3 in 2023 and 2.6.4 in 2025, with 2.6.5 following in 2026. The last push was on 2026-06-30, the same day as the 2.6.5 release, so the source tree is the place to read what changed.

## Conclusion

Adopt ISCE2 if you are processing interferometric SAR data from the sensors it supports, you are prepared to work inside a research oriented component framework, and export control obligations are acceptable to your organisation. Do not adopt it for a product that needs a supported SLA or a plain Apache 2.0 grant without the export paperwork, since the project is provided as is with no warranty of correctness and carries an EAR99 NLR export classification. Before you build, confirm your sensor is in the supported list, install the dependencies the README names for your platform, and set SCONS_CONFIG_DIR with an SConfigISCE file that records your build and install paths.

## FAQ

### What is ISCE2 used for?

ISCE2 is a framework for processing Interferometric Synthetic Aperture Radar data, turning radar observations into interferograms. It supports spaceborne sensors including ALOS, Sentinel1, TERRASARX, RADARSAT and COSMO_SKYMED, plus the airborne UAVSAR platform.

### How do I install the ISCE2 dependencies?

The README documents a conda route using a requirements.txt file with cython, gdal, h5py, numpy, fftw, scipy, scons and others, installed with `conda install --yes --file requirements.txt`, after which you must create a link in the anaconda bin directory for cython3. A Macports list is given as an alternative.

### What is SConfigISCE and where does it go?

It is the SCons build configuration file for ISCE. The README says SCons requires configuration information in a directory named by the SCONS_CONFIG_DIR environment variable, and the file records the build directory, the install directory and library locations.

### Can I use ISCE2 commercially?

The software is open source under the Apache License, but the README states it is provided as is with no warranties of correctness, and that its export classification is EAR99 NLR, which entails some restrictions and responsibilities. Read LICENSE.txt and LICENSE-2.0 files and check the export obligations with your organisation before use.

## Sources

- [isce-framework/isce2 on GitHub](https://github.com/isce-framework/isce2)
- [Issues](https://github.com/isce-framework/isce2/issues)
- [README](https://github.com/isce-framework/isce2/blob/main/README.md)
- [Releases](https://github.com/isce-framework/isce2/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/isce-framework-isce2