OlmoEarth Studio now exports embedding vectors from satellite imagery as Cloud-Optimized GeoTIFFs, with three model sizes from 1.4 million to 89 million parameters S¹. The vectors are computed on demand for your chosen area and time, not pulled from a pre-built global cache. Why that delivery choice matters, and what it changes for anyone who works with satellite data, comes down to a detail in the export format.

My read: This is the first Earth observation embedding pipeline I've seen that ships as standard GeoTIFFs rather than API-only vectors or proprietary formats. The int8 quantization is a pragmatic trade: you lose floating-point precision but gain files that any geospatial tool can open. I'm skeptical of the "strong performance" claim S¹ because the post gives no actual benchmark numbers. What I'd watch is whether the open weights and standalone computation instructions S¹ draw enough usage to build real community traction around these embeddings.

What an embedding actually does here

An embedding is a list of numbers that captures what a model sees in an image. For satellite imagery, each pixel gets turned into a vector (say, 192 numbers) that summarises the model's reading of that location. Similar land cover produces similar vectors. A forest and a parking lot produce very different ones. OlmoEarth Studio now lets users compute and export these vectors for any area of interest and time range, at whatever resolution they choose S¹.

The downstream uses are concrete: similarity search (find every parcel that looks like this one), segmentation (group pixels into land-cover classes without labelled training data), and unsupervised exploration (cluster regions by their embedding signatures to discover patterns) S¹. If your application needs higher accuracy, Studio also supports supervised fine-tuning on top of the embeddings S¹.

Three sizes, four resolutions, two satellites

The embeddings come from three encoder variants S¹:

  • Nano: 128 dimensions, 1.4 million parameters
  • Tiny: 192 dimensions, 6.2 million parameters
  • Base: 768 dimensions, 89 million parameters

OlmoEarth encoder variants by parameter count

Spatial resolution options are 10, 20, 40, or 80 metres per pixel S¹. The imagery sources are Sentinel-2 L2A (optical), Sentinel-1 RTC (radar), or both combined S¹. The blog's own examples use the Tiny encoder at 40-metre resolution with Sentinel-2 composites S¹.

The size gap between Nano and Base is large: 89 million parameters versus 1.4 million. The dimension count jumps from 128 to 768. That means the Base encoder captures far more detail per pixel but produces files roughly six times larger per tile. The tradeoff is between richness and storage cost.

Why the format matters more than it sounds

Exported embeddings arrive as Cloud-Optimized GeoTIFFs, or COGs: a standard format that any modern geospatial tool can read without conversion S¹. Each COG contains one band per embedding dimension, so a 192-dimensional Tiny embedding produces a 192-band GeoTIFF S¹.

The vectors are stored as signed 8-bit integers, ranging from -127 to +127, with -128 reserved for nodata pixels S¹. That is a quantized representation, not raw floating-point. Anyone who needs full precision will have to dequantize the int8 values back to floats. An extra step, but one that keeps file sizes small and shareable S¹.

Everything is computed on demand rather than pulled from a pre-computed global archive S¹. You specify your area, time range, encoder, resolution, and imagery source through the Studio UI or API, and the system generates embeddings for that request S¹. Users can generate monthly embeddings to track seasonal changes rather than only annual snapshots S¹.

The open-weight angle

The source code and model weights for OlmoEarth are publicly available alongside the research paper S¹, and instructions exist for computing embeddings independently of Studio S¹. An arXiv paper describes the underlying approach as "stable latent image modeling for multimodal Earth observation" P⁵, and the training code lives in a public GitHub repository P³.

Studio is a convenience layer, not a lock-in. If you prefer to run the models yourself, you can. The trade is compute time and setup complexity versus the one-click export workflow Studio provides.

What to do about it

For a regional agriculture consultancy that monitors crop health across 50,000 hectares, the workflow looks like this: pull monthly Tiny embeddings at 40-metre resolution for your growing season, compute cosine similarity between consecutive months to flag parcels where the embedding shifted sharply, and ground-truth those anomalies with a field visit. You get a change-detection system without labelling a single training image.

The practical starting point: check whether you have Studio access. The blog post notes that embeddings are available for Studio users but adds "reach out if you're interested in gaining access" S¹, which suggests access may still be gated. If you do have access, try the Nano encoder on a small area first to verify the COG format works with your existing GIS pipeline before scaling up.

What we don't know yet

The post claims "strong performance in our own benchmarking and in independent evaluations" S¹ but provides no specific metrics or evaluation datasets. There is no quantitative comparison against other Earth observation embedding models. The int8 quantization's impact on downstream task accuracy is not discussed.

Studio access appears limited. The post invites interested users to reach out S¹, but the access model and pricing are not specified. Whether embeddings can be computed at scale for continental or global coverage, and how long on-demand generation takes for large areas, is unclear.

The next signal: a follow-up benchmark paper from the OlmoEarth team with quantitative scores on standard Earth observation tasks. We'll check the "strong performance" claim against it when it appears. If you want to catch that analysis, subscribe and we'll send it your way.

Sources: S1 — Introducing OlmoEarth embeddings: Custom embedding exports from OlmoEa · P2 — docs/examples/OlmoEarthEmbeddings.md · P3 — allenai/olmoearth_pretrain · P4 — allenai/olmoearth_pretrain · P5 — OlmoEarth: Stable Latent Image Modeling for Multimodal Earth Observati

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.