Appendix G — Cloud masking methods for optical data
Cloud and cloud-shadow detection is the single most consequential preprocessing step for any optical workflow that operates on individual scenes rather than aggregated composites. The choice of method involves a trade-off along three axes: detection quality (does it correctly flag thin cirrus, cloud edges, and cast shadows?), computational cost (can it run at archive scale on available infrastructure?), and operational availability (is it pre-computed and shipped with the product, or must it be run separately?). No single method dominates on all three axes, and the appropriate choice depends on the use case: a global mapping pipeline running monthly composites has different requirements from a single-scene change-detection workflow where every false negative becomes a visible artifact.
Table G.1 compares the methods in current use. We distinguish the algorithmic family (rule-based, classical ML, or deep learning), the form of the output (binary mask versus continuous quality score), and the practical considerations that govern whether a given method is realistic to deploy at scale.
| Method | Family | Output | Pre-computed |
|---|---|---|---|
| SCL [1] | Rule-based | Multi-class label | ✓ |
| Fmask [2] | Physics-based and ML | Multi-class label | × |
| Cloud Score+ [3] | Deep learning | Continuous probability | ✓\(^*\) |
| s2cloudless [4] | ML | Continuous probability | ✓\(^{\dagger}\) |
| KappaMask [5] | Deep learning | Multi-class label | × |
| CloudSen12 [6] | Deep learning | Multi-class label | × |
| OmniCloudMask [7] | Deep learning | Multi-class label | × |
A few practical considerations are worth highlighting. The SCL layer is the path of least resistance: it ships with every L2A product, requires no additional compute, and is sufficient for the dominant use case of cleaning cloudy pixels before median compositing. Its known weaknesses — conservative cirrus detection, missed cloud edges, occasional confusion between bright surfaces and clouds — become problematic when working with single scenes or when the application is sensitive to false negatives in cloud detection. Fmask, originally developed for Landsat, offers a more physics-informed and well-validated alternative, but is slower than SCL and must be run separately. s2cloudless occupies the opposite end of the efficiency spectrum: it is lightweight, fast on CPU, and widely used in operational pipelines.
Cloud Score+ [3] occupies an unusual position because of its continuous output. Rather than committing to a binary mask, it returns a per-pixel quality score that the downstream user can threshold according to the sensitivity of the application. This is convenient when the same archive must serve multiple workflows with different tolerances. The principal limitation is operational: Cloud Score+ is exposed natively only through Google Earth Engine, so workflows running outside that ecosystem cannot use it directly. CloudSen12, trained on hand-labeled patches stratified across biomes, and OmniCloudMask address the same need with self-hostable models at the cost of having to run inference oneself.
The deep learning methods (KappaMask, CloudSen12, OmniCloudMask) generally outperform the rule-based and classical-ML alternatives on hand-labeled benchmarks, but the magnitude of the gain depends on the region, the scene composition, and the specific failure modes the benchmark is designed to expose. Wright et al. [7] report computational efficiency for OmniCloudMask against several alternatives on an NVIDIA RTX 4090, providing a useful reference point for relative throughput on consumer-grade hardware. Whether the accuracy gain justifies the additional compute and infrastructure complexity is a judgment that should be made against the requirements of the specific mapping task: for global-scale composite-based workflows, the marginal benefit over SCL is often modest; for single-scene applications or studies in cloud-prone regions such as the humid tropics, it can be decisive.
Landsat
The methods in Table G.1 are tuned for Sentinel-2, but the lineage runs the other way: Fmask was developed for Landsat first, and its C implementation is what produces the operational Landsat mask. Collection 2 ships a bit-packed QA_PIXEL band generated during Level-1 processing and carried unchanged into the Level-2 package — a structural difference from Sentinel-2, where the SCL is an output of the Level-2 processor and therefore exists only at Level-2. Its design also sits between the two families in Table G.1: alongside high-confidence binary flags for cloud, cloud shadow, cirrus, snow and water, it carries a dilated-cloud bit that provides a buffer around detected cloud, and two-bit confidence fields for cloud, cloud shadow, snow/ice and cirrus. A user can therefore threshold on confidence rather than accept a binary verdict, which is the flexibility that makes Cloud Score+ attractive for Sentinel-2, available here without leaving the operational product. Level-2 adds further layers: SR_QA_AEROSOL for Landsat 8 and 9, SR_CLOUD_QA for Landsat 4 to 7, and ST_QA, which reports per-pixel surface temperature uncertainty in Kelvin. One trap is specific to long archives: the QA_PIXEL bit assignments are not identical across Landsat generations, so a pipeline spanning Landsat 5 through 9 must decode the band per sensor rather than apply one bit mask throughout.
Finally, none of these methods is sensor-agnostic by default with the exception of OmniCloudMask. Methods originally developed for Sentinel-2 can be retrained on other optical sensors, but doing so requires either a labeled dataset for the target sensor or a sufficiently large labeled Sentinel-2 dataset together with a domain adaptation strategy. Practitioners working across multiple optical missions should weigh this carefully, as the cost of maintaining one cloud-masking pipeline per sensor can rapidly exceed the cost of the inference itself.