Why pansharpening fails on some satellites — and how to fix it
Pansharpening fuses a sharp panchromatic band with lower-resolution colour bands to produce high-resolution colour. It usually works. When it doesn't, the failure is specific and diagnosable — and the standard tools can't fix it because they assume something that isn't true.
Two failure modes we hit on Cartosat data
First, a colour cast. Some panchromatic sensors respond into the near-infrared, so vegetation is bright in PAN but not in the visible bands. A naive fusion over-boosts those pixels and vegetation turns cyan. The fix is to include the NIR band in the intensity model so the synthetic panchromatic tracks the real one, then output only red/green/blue.
Second — and more stubborn — chromatic fringing along every building edge. Measuring the offset between PAN and the multispectral bands revealed a ~4 m (14-pixel) shift. These are RPC products, not orthorectified, so the two rasters are simply not co-registered.
The offset isn't uniform
A single global shift removed most of the error but left residual fringing. The reason is geometry: on an off-nadir acquisition, relief and parallax displace PAN and MX differently across the scene. One shift can't correct a spatially-varying offset.
The fix is a dense local warp. Estimate a per-pixel displacement field between the real panchromatic and a synthetic panchromatic built from the colour bands (both broadband, so brightness-constancy holds), smooth it lightly, warp the colour bands onto the PAN grid, then fuse. Residual misregistration dropped from ~14 pixels to a fraction of a pixel, and the fringing cleared.
The takeaway
Before fusing, measure the PAN-versus-MX shift. If it's more than about a pixel, align first — and if the product is off-nadir, expect the offset to vary across the frame and use a local warp, not a global shift. Off-the-shelf pansharpening can't correct a geolocation offset between its own inputs.