# Domain Adaptation for Satellite-Borne Multispectral Cloud Detection
## 2 Related Work
### Cloud Detection in EO Data  
A multi/hyperspectral imager produces, for each \"capture\", a data cube consisting of two spatial dimensions with as many channels as spectral bands in the sensor. Cloud coverage diminishes the information content of a data cube. Since 66-70% of the Earth's surface is cloud-covered at any given time [14; 15], dealing with clouds in EO data is essential. Two major goals are as follows:  
* Cloud detection, where typically the location and extent cloud coverage in a data cube are estimated;
* Cloud removal [16; 17; 18], where the values in the spatial locations occluded by clouds are restored.  
Since our work relates to the former goal, the rest of this subsection is devoted to cloud detection.  
Cloud detection assigns a _cloud probability_ or _cloud mask_ to each pixel of a data cube. The former indicates the likelihood of cloudiness at each pixel, while the latter indicates discrete levels of cloudiness at each pixel [19]. In the extreme case, a single binary label (_cloudy_ or _not cloudy_) is assigned to the whole data cube [5]; our work focusses on this special case of cloud detection.  
Cloud detectors use either _hand-crafted features_ or _deep features_. Early cloud detectors use hand-crafted features such as the normalised difference cloud index (NDCI) [20] and Function of mask (Fmask) [21]. For example, a pixel with an NDCI value between two fixed thresholds, under additional conditions, can be classified as a cloudy pixel [22]. However, fixed thresholds are empirically determined and may suffer from local biases [23]. Consequently, cloud detectors using fixed thresholds tend to have location-dependent performance and do not generalise well [24].  
Cloud detectors using deep features are of particular interest because the methods have shown state-of-the-art performance [25; 26], outperforming threshold-based methods for areas with complex surfaces [23]. The deep features are extracted from data via a series of hierarchical layers in a deep neural network (DNN), where the highest-level features serve as optimal inputs (in terms of some loss function) to a classifier, enabling discrimination of subtle inter-class variations and high intra-class variations [27]. The majority of cloud detectors that use deep features are based on an extension or variation of Berkeley's fullyconvolutional network architecture [28; 29], which was designed for pixel-wise semantic segmentation and demands nontrivial computing resources. For example, [30] is based on SegNet [31], while [14; 25; 26; 32; 33; 34] are based on U-Net [35], all of which were not designed for onboard implementation.  
Onboard cloud detectors can be traced back to the thresholding-based Hyperion cloud cover algorithm [36], which operated on six of the hyperspectral bands of the EO-1 satellite. [PERSON] et al.'s onboard cloud detector [15] uses hand-crafted features, but no experimental feasibility results were reported. Arguably, the first DNN-based onboard cloud detector is CloudScout [5]. Table 1 compares CloudScout with other more recent onboard cloud detectors. All of these detectors use the Intel Myriad 2 VPU, but none of them perform domain adaptation. Basing our work on the original CloudScout [5] rather than the newer version [6], which has lower capacity, enables us to process higher resolution tensors and be less susceptible to adversarial attacks [37].  
Relevant to onboard processing but not cloud detection, [PERSON] et al. [42] experimented with histogram matching but settled on offline retraining for supervised domain adaptation (see Section 2.2).