TerraTorch

repository·main·Indexed 21 days ago

https://github.com/torchgeo/terratorch

A PyTorch-based domain library for fine-tuning and using Geospatial Foundation Models. Built on PyTorch Lightning and TorchGeo, it provides a framework for image segmentation, classification, and pixel-wise regression. It features a multi-level model abstraction system, support for multitemporal and multimodal data, and embedding workflows to decouple feature extraction from downstream training.

Tokens
69.9K
Snippets
167
Records
258
Agent score
73%

What's inside terratorch

  1. Overview of TerraMind in TerraTorch

    main

    TerraMind is a multi-modal, generative foundation model developed by IBM and ESA. It is integrated into TerraTorch and supports several key task types:

    • Standard Fine-Tuning: Adapting the model to specific downstream tasks.
    • Thinking-in-Modalities (TiM): A specialized capability to improve downstream performance.
    • Generation Tasks: Using the generative versions of the models.

    For more information, visit the official TerraMind website.

  2. Overview of TerraMind foundation models

    main

    TerraMind is an any-to-any generative foundation model designed for Earth Observation, developed by IBM, ESA Φ-lab, and the FAST-EO project.

    Within the terratorch repository, this module provides access to:

    • Encoder and Decoder code: Located in the model directory.
    • Tokenizers: Located in the tokenizer directory.

    For full code examples and detailed implementation, refer to the official TerraMind GitHub repository.

  3. Overview of TerraTorch capabilities

    main

    TerraTorch is a PyTorch domain library built on PyTorch Lightning and TorchGeo. It provides a flexible fine-tuning framework for Geospatial Foundation Models through several key components:

    • Modelling Tools: Flexible trainers for Image Segmentation, Classification, and Pixel Wise Regression; Model factories for combining backbones and decoders; and ready-to-go datasets/datamodules.
    • Foundation Model Access: Easy access to backbones like Prithvi, TerraMind, SatMAE, ScaleMAE, Satlas, DOFA, SSL4EO, and Clay.
    • Decoder Integration: Support for SMP and mmsegmentation.
    • Execution Modes: Fine-tuning tasks can be launched via CLI, configuration files, or Jupyter notebooks.
  4. Available embedding workflow examples

    main

    TerraTorch provides several example notebooks and YAML configurations for different embedding use cases:

    • Embedding Generation: Use embedding_generation_burnscars.ipynb and its associated YAML to generate embeddings from raw data.
    • Embedding-Based Downstream Task: Use downstream_segmentation_burnscars.ipynb and its associated YAML to perform a segmentation task using precomputed embeddings.
    • Manual Embedding Extraction: Use embedding_generation_manual_backbone_registry.ipynb to learn how to use the Backbone Registry to build a custom pipeline and extract embeddings manually.
  5. Serving TerraTorch models with vLLM

    main

    TerraTorch models can be served using the vLLM engine.

    Supported Tasks

    Currently, only models using the following tasks are compatible with vLLM:

    • SemanticSegmentationTask
    • PixelwiseRegressionTask

    Serving Modes

    1. Tensor-to-tensor mode: This is the default mode and is natively enabled by vLLM.
    2. Image-to-image mode: This mode allows processing and generation of data in any modality (e.g., geoTiff). It utilizes vLLM's IOProcessor plugins. TerraTorch provides pre-defined plugins for this purpose.
  6. Understand the TerraTorch ecosystem and dependencies

    main

    TerraTorch is built upon several key open-source libraries for geospatial AI. Understanding these dependencies helps in managing your environment and data workflows:

    • Training & Inference: Uses Lightning (for GPU allocation, logging, etc.) and PyTorch.
    • Geospatial Data Modules: Built on TorchGeo. Because of this, any TorchGeo datasets are directly compatible with TerraTorch.
    • Multidimensional Data: Uses Xarray for lazy loading and multidimensional data handling, often paired with rioxarray for .tif file I/O and CRS management.
    • Vector/Table Data: Uses GeoPandas for handling geospatial polygons and tables.
    • Model Backbones: Integrates directly with timm (PyTorch Image Models) and SMP (Segmentation Models PyTorch) via meta registries.
  7. What is a Factory in Terratorch?

    main

    A Factory is a class designed to organize the instantiation of a complete model architecture (typically following a backbone-neck-decoder-head pattern).

    Instead of manual assembly, a Factory class receives lists and dictionaries containing the necessary arguments and returns a fully instantiated model instance ready for use.

  8. How TerraTorch architecture works

    main

    TerraTorch is designed to facilitate fine-tuning geospatial foundation models by decoupling the backbone, decoder, and head. The architecture relies on several key abstractions:

    1. Tasks: These are LightningModule instances that act as coordinators for training and inference. They abstract away training steps, metric computation, and inference logic. Instead of defining models directly, Tasks use Model Factories to instantiate models.
    2. Model Factories: Classes (like EncoderDecoderFactory) responsible for searching a registry and instantiating models. This promotes composition over inheritance and allows different tasks to reuse the same model construction logic.
    3. Models: Any torch.nn.Module that implements the Model interface. Models are expected to provide freeze_encoder(), freeze_decoder(), and a forward() method.
    4. ModelOutput: The forward() method must return a ModelOutput object. This object contains the main head's output and any auxiliary outputs. Auxiliary output names are matched with auxiliary loss names.
    5. Glue (LightningCLI): TerraTorch uses LightningCLI to instantiate models, datamodules, and the Lightning Trainer from configuration files or the command line.

    This modularity allows users to plug together different encoders, decoders, and necks using the EncoderDecoderFactory while maintaining compatibility with existing TorchGeo datasets and PyTorch Lightning functionality.

  9. How the model architecture is constructed

    main

    The TerraTorch model factory builds an object detection model by combining two components:

    1. Backbone: The feature extractor (e.g., TerraMind, Prithvi, or a timm backbone) that converts tiles into feature maps.
    2. Framework: The detection head and loss logic (e.g., Faster R-CNN or Mask R-CNN) that predicts bounding boxes, labels, and (optionally) masks from the backbone's features.
  10. Model requirements for the Segmentation IOProcessor Plugin

    main

    The plugin requires the model to accept two specific parameters for inference:

    1. pixel_values: A torch.Tensor containing the raw image data extracted from the input TIFF.
    2. location_coords (optional): A torch.Tensor containing geospatial coordinates for the image.

    While you can adjust the tensor shapes to match your model's requirements, the field names (pixel_values and location_coords) must remain unchanged.

    "input":{
        "target": "pixel_values",
        "data":{
            "pixel_values":{
                "type": "torch.Tensor",
                "shape": [6, 512, 512]
            },
            "location_coords":{
                "type":"torch.Tensor",
                "shape": [1, 2]
            }
        }
    }
  11. Modeling approaches for multitemporal data

    main

    TerraTorch provides two primary architectural patterns for handling temporal dimensions:

    1. Temporal backbone: Use a model designed with native temporal modeling capabilities (e.g., Prithvi).
    2. Non-temporal backbone + TemporalWrapper: Take any standard TerraTorch backbone and wrap it using the TemporalWrapper. This allows you to perform temporal aggregation within the latent space.