Our models often mention “chip-level embedding”. What exactly is a "chip," and why does it matter? Today, we explain how LGND’s AI "sees" our planet.

What is a Chip?

In geospatial machine learning, a chip is a small, square sub-section of a larger satellite image. Instead of asking a model to digest a massive 10,000 x 10,000-pixel scene all at once, we break it into manageable bites—standard sizes like 128 x 128 pixels. While chip sizes can technically be any size, we typically do not recommend generating chips with dimensions less than 24-40 pixels for the Clay Foundation model. 

Any single embedding will encode the visual information within a single chip’s boundary into an embedding. For this reason, the chip size used for any analysis should be informed by the size of what you’re looking for, i.e. it should be as large if not larger than the typical size of the semantic.  

Chip-Level vs. Pixel-Level

The distinction between chip-level and pixel-level embeddings comes down to context.

• Pixel-Level Embedding: Every single pixel gets its own mathematical signature allowing for precise analysis. Sometimes such high-resolution may miss the forest for the trees.
• Chip-Level Embedding: The entire square is compressed into one signature. This captures spatial relationships. A chip-level model doesn't just see green or beige pixels; it recognizes the pattern of "farm orchard" or "suburban neighborhood."
• Footprints: Pixel and chip level models will both tell you if the respective units of measure contain a semantic (e.g. airplane, forest, lake). To extract the precise footprint of a feature of interest, “segmentation heads”, such as Meta’s Segment Anything Model are needed.

Note that pixel level embeddings can be aggregated up to a chip level. LGND does this for Google’s  Alpha Earth Foundation model embeddings that we host. All the 64-d pixel embeddings within a chip are averaged to create a single 64-d embedding, allowing for seamless intercomparison and combination. You can also start with a broad search using chips and leverage pixel precision once you’ve identified the bounding box for a feature of interest.

Which should I use?

Pixel-Level: Imagine you are a city planner calculating impervious surfaces to predict flash flooding. You need to know exactly how many square meters of concrete exist. Because a 10 meter pixel rarely contains more than one land cover type, it will be easiest to classify land cover using the pixel-level embeddings and then aggregating all pixels that match your criteria. 

Chip-Level: Imagine you are an NGO looking for illegal logging across the Amazon. Processing billions of individual pixels is computationally intensive and may yield false positives. Using chip-level embeddings reduces computation given large spatial coverage per embedding. You also may observe improved accuracy by accounting for contextual cues, such as an adjacent road. 

On the API

When using the LGND API, you set the chip size when you create a collection (POST /v1/tenants/{tenant_id}/collections). It lives in the tiling object, under the chip_size_m field.

One thing worth flagging: chip_size_m is specified in meters of ground distance, not pixels. While the discussion above is framed in pixels, the API asks how many meters on the ground each chip should span — and the pixel dimensions follow from your imagery source's resolution:

• NAIP (~1 m/pixel): chip_size_m: 128 → ~128×128 px
• Sentinel-2 (~10 m/pixel): chip_size_m: 1280 → ~128×128 px

If you leave chip_size_m unset, LGND defaults to a 128×128-pixel chip (128 m for NAIP, 1280 m for Sentinel-2). Since the right chip size depends on the size of the feature you're after, chip_size_m is the main knob to reach for: larger values capture more context per embedding; smaller values pin down finer features that require more embeddings in your collection.

Chip Size and Embedding Count

Because LGND generates one embedding per chip, chip_size_m also determines how many embeddings a collection produces. Over a fixed area of interest, chip count scales with the inverse square of chip size: halve chip_size_m and you get roughly 4× as many chips — and 4× as many embeddings; double it and you get about a quarter as many. Smaller chips give you finer spatial detail but more embeddings to generate, store, and index, which means more processing time and cost. The practical rule of thumb: pick the largest chip size that still resolves the features you care about.

Try It Yourself

The fastest way to build intuition for chip size is to generate a few collections and compare the results side by side. Create an account and spin up a test collection or two — try the same area of interest at a couple of different chip_size_m values and see how the embeddings and search results shift. The API docs walk through create_collection end to end.