hariri.ch
Prenez contact

Actualités Tech

OlmoEarth : comprendre les embeddings pour analyser les données satellite

6 min de lecture

Une vue abstraite de régions terrestres observées par satellite se transformant en couches de vecteurs numériques colorés.

Des images satellite aux représentations numériques

Les embeddings d’OlmoEarth transforment des données d’observation de la Terre en vecteurs numériques compacts. L’objectif n’est pas de produire directement une carte ou une prédiction, mais de fournir une représentation exploitable par d’autres méthodes d’analyse, comme un classifieur ou une comparaison temporelle.

Selon le dépôt du projet, OlmoEarth constitue une famille de modèles de fondation multimodaux et spatio-temporels dédiée à l’observation de la Terre. Son préentraînement s’appuie sur trois modalités satellitaires — Sentinel-2, Sentinel-1 et Landsat — ainsi que sur six cartes dérivées : OpenStreetMap, WorldCover, USDA Cropland Data Layer, SRTM DEM, WRI Canopy Height Map et WorldCereal.

Le jeu de données de préentraînement décrit par le projet contient 285 288 échantillons correspondant à des régions de 2,56 km sur 2,56 km. Ces échantillons proviennent de différentes zones du monde, même si certains ne comprennent qu’une partie des dates ou des modalités disponibles.

Ce qu’OlmoEarth Studio permet d’exporter

Présenté le 12 août 2026, OlmoEarth Studio ajoute la possibilité de calculer et d’exporter les vecteurs produits par les modèles de fondation OlmoEarth. Le service peut être utilisé depuis son interface ou via une API. L’utilisateur choisit une zone d’intérêt, une période, une variante d’encodeur, une résolution spatiale et les sources d’imagerie.

Les périodes couvertes vont de 1 à 12 mois. Les sources proposées sont Sentinel-2 L2A, Sentinel-1 RTC, ou les deux. La résolution peut être fixée à 10, 20, 40 ou 80 mètres par pixel. Le résultat est livré sous la forme d’un Cloud-Optimized GeoTIFF (COG), un format adapté aux traitements géospatiaux et à l’accès partiel à des données stockées à distance.

Cette sortie est importante pour les équipes qui ne veulent pas reconstruire toute la chaîne d’inférence. Elles peuvent récupérer les représentations, les stocker dans leur infrastructure et les intégrer à un pipeline existant, sans traiter chaque image satellite comme une entrée brute à chaque étape.

Choisir entre Nano, Tiny et Base

Le choix de l’encodeur détermine la taille du vecteur et le volume de paramètres du modèle. Studio propose trois variantes :

  • Nano : 128 dimensions et 1,4 million de paramètres ;
  • Tiny : 192 dimensions et 6,2 millions de paramètres ;
  • Base : 768 dimensions et 89 millions de paramètres.

Une représentation plus courte réduit généralement le volume de données à manipuler, tandis qu’un vecteur plus large conserve davantage de dimensions pour les traitements en aval. Le choix doit donc être lié à la contrainte opérationnelle et au niveau de détail recherché, plutôt qu’à l’idée qu’une variante serait systématiquement préférable.

La documentation de rslearn ajoute une précision utile pour les utilisateurs qui exécutent le modèle eux-mêmes. Elle liste aussi une dimension Large de 1 024 composantes. Son exemple configure le modèle OLMOEARTH_V1_BASE, avec une taille de patch de 4, et produit 768 bandes float32 pour la variante Base. Il faut distinguer cette configuration de la liste des variantes actuellement exposées dans Studio : les formats et les options dépendent du chemin d’utilisation choisi.

Un GeoTIFF où chaque dimension devient une bande

Dans les COG exportés par Studio, chaque dimension de l’embedding est stockée dans une bande distincte. Un vecteur Base comporte donc 768 bandes, tandis qu’un vecteur Nano en comporte 128. Les valeurs sont enregistrées sous forme d’entiers signés sur 8 bits, entre -127 et +127. La valeur -128 est réservée aux pixels sans données.

Cette représentation compacte ne correspond pas à une simple conversion linéaire documentée comme un stockage flottant. La fonction de quantification standard du dépôt applique une transformation par racine carrée, multiplie le résultat par 127,5, limite les valeurs à l’intervalle -127 à +127, les arrondit, puis les convertit en int8. Pour revenir à une représentation numérique, la fonction de déquantification redimensionne les valeurs par 127,5 et applique une puissance de 2 tout en conservant leur signe.

Cette étape doit être prise en compte dans les outils en aval. Un pipeline qui lit directement les bandes sans respecter la procédure de déquantification risque de travailler sur des valeurs mal interprétées. À l’inverse, le format int8 réduit la taille des exports par rapport à des vecteurs stockés en précision flottante.

Quels traitements deviennent possibles ?

Les exemples publiés illustrent deux usages distincts. Dans un scénario de segmentation en few-shot, l’article consacré aux embeddings indique qu’une régression logistique entraînée sur 60 pixels annotés a obtenu un score F1 pondéré de 0,84. Ce résultat est une affirmation rapportée par l’article source, dans les conditions de son exemple : il ne constitue pas une garantie générale pour toutes les zones, classes ou résolutions.

Pour la détection de changements, l’article rapporte une comparaison entre des embeddings Sentinel-2 mensuels calculés sur une même région en septembre 2023 et en septembre 2024. La distance cosinus pixel par pixel a notamment permis de repérer la cicatrice de l’incendie Park Fire. Ici, l’intérêt vient de la comparaison de représentations produites à des dates différentes, plutôt que d’une analyse limitée aux différences de couleur entre deux images.

Le dépôt fournit également une réduction de dimension par ACP. Celle-ci ajuste l’ACP sur les embeddings d’entraînement, puis applique la même transformation aux embeddings de validation et de test lorsqu’ils sont fournis. Cette séparation est essentielle pour éviter qu’une étape de prétraitement ne tire indirectement parti des données d’évaluation.

Ce que les équipes doivent vérifier avant adoption

OlmoEarth Studio simplifie l’accès aux représentations, mais plusieurs décisions restent à la charge de l’équipe data ou géospatiale : période d’observation, sources Sentinel utilisées, résolution, variante du modèle et traitement des pixels nodata. Ces paramètres peuvent modifier la comparabilité des exports entre zones ou entre dates.

Il faut aussi documenter la variante retenue et le format numérique utilisé. Un export Studio en int8 ne se manipule pas exactement comme une sortie float32 produite dans un workflow local avec rslearn. Les étapes de déquantification, de normalisation éventuelle et de réduction de dimension doivent être intégrées explicitement au pipeline.

Enfin, le dépôt indique que son code est distribué sous l’OlmoEarth Artifact License. Les conditions de cette licence doivent être examinées avant une redistribution ou une intégration dans un produit. Pour les développeurs et les équipes d’observation de la Terre, la nouveauté principale reste néanmoins opérationnelle : les embeddings deviennent un artefact géospatial exportable, réutilisable et compatible avec des traitements spécialisés.

À retenir

  • OlmoEarth Studio exporte des embeddings sous forme de Cloud-Optimized GeoTIFF depuis une interface ou une API.
  • Les paramètres couvrent la zone, une période de 1 à 12 mois, les sources Sentinel, la résolution et la variante d’encodeur.
  • Les COG stockent une bande par dimension en int8, avec -128 réservé aux données manquantes.
  • Les exemples publiés couvrent la segmentation avec peu d’annotations et la détection de changements temporels.
  • Les workflows locaux doivent distinguer les sorties float32 de rslearn des exports quantifiés de Studio.

Sources