Terminus NITF SDK

A NITF SDK for modern Computer Vision applications.

The National Imagery Transportation Format (NITF) is the most complex and robust image format for geospatial image processing. This format brings enormous challenges for software developers given the breadth of capabilities it supports, coupled with the depth and specificity of each supported header or Tagged Record Extension (TRE).

Terminus NITF SDK solves this by creating a C++ API (with other language bindings) that allows developers to handle it in 2 ways: the highly granular and custom interface, or a general image format that can be “used and abused” like GeoTiffs.

Denver Civic Center Park, US Geological Survey, 2015

Our goal is to allow an intern or entry-level software engineer to take a “raw-pointer” of bytes, combined with a healthy dose of INS/GPS information, and generate actionable JITC-compliant NITF imagery within 2-months of using our API. We will deliver this with a combination of robust documentation, detailed and descriptive code samples, plus an API that knows how to convert position information into accurate IGEOLO, ICOORDS, SENSRA/B, and RPC00A/B data. Lastly, our math APIs can help solve difficult problems such as computing Rational Polynomial Coefficients (RPCs) from either Ground-Control-Points or a Camera-Model and INS/GPS data.

Emerald Bay, CA, USDA NAIP, 2022

Terminus NITF Software Development Kit

For Geospatial Image-Processing, we use the Geospatial Data Abstraction Library (GDAL)[LINK] as the gold standard. GDAL supports nearly every format, with the ability to read and write data. GDAL, while impressive, does not offer the ability to create new NITFs from a combination of imagery and metadata. Furthermore, libraries like NITRO [LINK], do not support the diversity of capabilities that allow non NITF-experts the ability to build the standards-compliant imagery expected by JITC and the NGA.

Standards-Compliant

Imagery created with our SDK is going to be compliant with all published NGA and JITC specifications to include the core format, Tagged Record Extensions (TREs), and supported imagery profiles (J2K, JPEG, etc).

  • MIL-STD-2500C_CHG-1 - Base NITF 2.1 definition

  • BPJ2K01 - BIIF Profile for JPEG 2000

  • NGA.STND.0044_1.3_MIE4NITF: Standard for MIE4NITF

  • RSM - Replacement Sensor Model

  • More as necessary

Robust and Adaptable

We provide OpenJPEG bindings for J2K support. Our driver model makes it easy to replace with alternative implementations such as Kakadu.

The API exposes optional callbacks for reading and writing operations such that when a field changes, the rest of the document can remain synchronized. This is vital for redundant sections involving time, position, and projection data.

Feature-Complete

The API currently supports the core NITF Specification and a few TREs. We are actively developing additional TREs as we need. Primary TREs in development are related to RSM, projection data, and MIE4NITF. For unsupported TREs, our API exposes a direct interface to modifying byte arrays.