Estimating flare volume from flame size: what satellite imagery can and can't tell you
Flare volume reporting still runs mostly on operator-submitted numbers. For a regulator checking a quarterly filing, or an ESG analyst trying to sanity-check a company's emissions disclosure, that leaves a gap: there's no independent read on what's burning at a given well pad or terminal on a given night. Satellite imagery doesn't close that gap entirely, but it gives you something operator self-reports don't: a physical signal tied to the flame itself.
Why flame size is a proxy, not a measurement
A flare's thermal signature in night-time or SWIR imagery scales with how much gas is combusting, but the relationship isn't a clean lookup table. What you're actually measuring is flame radiative power (FRP), the rate at which the flame emits energy, derived from the brightness and spectral shape of the hot pixel against a cold background. FRP correlates with the mass of hydrocarbon being burned, and from there, analysts back into an estimated gas volume using combustion efficiency assumptions.
Each step in that chain adds uncertainty. Flare efficiency varies with wind, flare tip design, and whether the gas is wet or dry. A pixel at coarse resolution, 250 meters or more, often captures one flare stack cleanly, but at a busy pad with multiple burn points close together, the thermal signal can blend into a single blob. That's why serious flare analysis treats flame size and FRP as a proxy for production activity, not as a volumetric measurement you'd put in a compliance filing on its own.
What a nightly read actually gives you
If you're tracking a monitoring area over time, consistency matters more than precision on any single night. A flare that shows up bright and steady for six months, then drops to a faint flicker, is telling you something regardless of the exact cubic-feet number behind it: production changed, a connection came online, or reporting and reality have started to diverge. For a regulator, that pattern is often the trigger for a site visit or a records request, not the final word. For an ESG fund analyst, it's a way to flag a portfolio company whose flaring intensity doesn't match what they filed, before the next ESG disclosure cycle makes it official.
The practical workflow looks like this: pull a nightly pass over the monitoring area, flag the pixels that register as flares (sustained thermal anomalies distinct from background heat), and log count and relative size night over night. Compare that log against the operator's reported flaring volume or production figures. A sustained gap between the imagery-derived trend and the self-reported number is the thing worth escalating, not the raw flame-size estimate by itself.
Where this method runs into limits
Coarse-resolution thermal imagery can't distinguish a flare from other hot sources in cluttered industrial areas without some care in how you set up the monitoring area. Cloud cover blocks a night's read entirely. And because combustion efficiency assumptions vary by flare type, two facilities burning the same volume of gas can produce different FRP readings. None of this makes the method useless. It makes it what it is: a proxy good at catching trend and anomaly, not a replacement for metered volume data.
Flare Monitoring builds on this approach with a nightly count and relative size read across a defined monitoring area, using night-time and SWIR imagery as an input alongside operator reporting rather than instead of it. If you're trying to build an independent flaring log for a region or a portfolio, that nightly cadence is the piece most self-reporting-only workflows are missing.