What is integrated mass enhancement (IME) in methane plume quantification?
If you've pulled a quantification report off a plume detection and seen a number in kg/hr with a wide error bar attached, that number almost certainly came from the integrated mass enhancement method. IME is the standard way retrieval teams turn a column of excess methane sitting over a pixel grid into a single flux rate you can put in a disclosure or an MRV workbook.
The math in plain terms
A hyperspectral or multispectral sensor measures column-averaged methane enhancement at each pixel in the SWIR band, usually reported in ppm-m, a path-integrated signal showing how much extra methane sits in the air column above that pixel compared to background.
IME sums that enhancement across every pixel the algorithm flags as plume, weighted by pixel area, to get a total excess mass in kilograms. Call that the integrated mass enhancement. On its own it tells you how much gas is sitting in the air at the moment of overpass. It doesn't tell you a rate.
To get from mass to a flux rate, you divide by how long it took that mass to accumulate, which depends on wind speed and an effective plume length scale. The common form is:
Q = U_eff × IME / L_eff
where U_eff is an effective wind speed (often 10m wind pulled from a reanalysis product like ERA5, adjusted for boundary-layer conditions) and L_eff is a length scale derived from the plume's size and shape. Get the wind wrong and the flux estimate moves with it, point for point. This is the part analysts underestimate when they first start reading quantification outputs: the retrieval can nail the mass enhancement and still hand you a bad flux number because the wind input was off for that hour.
Why MRV teams care about the input assumptions
For an MRV analyst reconciling a quantified plume against an operator's own leak detection and repair log, the IME number is only as trustworthy as three things behind it:
The background subtraction. Whatever method pulled "excess" methane out of the scene had to define a background first, and a bad background (cloud edge, water body, varying surface albedo) inflates or deflates the whole mass estimate before wind even enters the picture.
The plume mask. If the detection algorithm draws the plume boundary too tight, you lose mass at the edges where the enhancement signal falls below the noise floor. Too loose, and you're integrating background noise into your flux number.
The wind field. You need site-level wind for this calculation, something finer than a basin-level average. A reanalysis grid cell covering 25 km² doesn't know that the stack on this pad sits in a wind shadow from a ridge a half-mile over.
None of this makes IME a bad method. It's the one with the most published validation behind it, and it's what most quantification products you'll see cited actually run under the hood, whether they say so on the label or not. A flux number without its underlying wind assumption and mask parameters stated is a number you can't audit, and if you're reconciling site-level emissions for a disclosure, you need to be able to audit it.
Reading quantification outputs without getting burned
When a vendor hands you a kg/hr estimate, ask what wind source fed the IME calculation and what effective length scale the algorithm used. If neither is disclosed, treat the number as directional, not something to drop straight into a reconciliation spreadsheet.
For an MRV team working day to day, what settles the "which site" question is whether the plume ties back to a specific site boundary fast enough to act on. That's the gap Methane Plume Map is built to close: a per-site view that tells you a particular pad or facility is showing a plume today, not a basin advisory three weeks after the fact.
If you're tired of waiting on a regional bulletin to tell you which of your sites to call, it's worth seeing what a daily, site-attributed plume map looks like for your own footprint.