Are Sentinel-2 water vapour products useful ?

Atmospheric absorption: in blue, the surface reflectance of a vegetation pixel, as a function of wavelength. In red, the reflectance of the same pixel at the top of atmosphere. For a wavelength of 1.38 µm, water vapour totally absorbs the light that comes from the earth surface at sea level. At 0.94 µm (940nm), a weaker water vapour absorption band only partly absorbs the photons.


Sentinel-2B has two channels centered on water vapour absorption bands: channel 9 (940 nm) and channel 10 (1380 nm). Band 10 corresponds to a very strong absorption, strong enough to prevent any photon to reach ground from the Sun without being absorbed in the atmosphere. This band is intensively used to detect and correct high clouds.


In this blog, we discussed much less band 9 (940 nm) yet. Here, water vapour absorption is not strong enough to catch all the photons which reach the surface. The proportion of absorbed photons depends on the water vapour atmospheric content, and also on the viewing and solar zenith angles. We use band 9 for atmospheric correction, but it could be useful to study convection phenomena within the atmosphere too.

Continue reading

Des applications pour la vapeur d'eau observée par Sentinel2 ?

Absorption atmosphérique. En bleu, la réflectance de surface pour un pixel couvert de végétation, en fonction de la longueur d'onde, en rouge la réflectance au sommet de l'atmosphère pour ce même pixel. A 1.38 µm, la vapeur d'eau absorbe totalement la lumière provenant de la surface au niveau de la mer. Autour de 0.94 µm, une autre bade d'absorption de la vapeur d'eau est visible, mais l'absorption y est moins intense


Sentinel-2B dispose de deux canaux centrés sur des bandes d'absorption de la vapeur d'eau: la bande 9 (940nm) et la bande 10 (1380 nm). La bande 10 correspond à une très forte absorption, telle qu'en général, dans cette bande, les photons n'ont aucune chance d'atteindre le sol, et encore moins le satellite après réflexion sur le sol. Cette bande est utilisée pour détecter les nuages hauts.


Dans ce blog, nous avons jusqu'ici moins parlé de la bande d'absorption à 940 nm. Ici l'absorption des photons passant par la surface terrestre n'est pas totale, seule une forte proportion d'entre eux est absorbée, et cette proportion dépend bien sûr de la quantité de vapeur d'eau, mais aussi de l'inclinaison des directions solaires et d'observation. Cette bande nous sert à la correction atmosphérique, mais pourrait aussi, je pense, intéresser les spécialistes de l'atmosphère.

Continue reading

Machine learning for land cover map production - Follow-up on the TiSeLaC challenge

I discussed some important aspects to take into account when validating land cover maps in a previous post. In that same post I insisted on the fact that machine learning pipeline building using a blind optimisation of accuracy metrics can lead to unrealistic expectations about land cover maps produced using these approaches.


I cited as an example the TiSeLaC challenge, where 2 of the participating teams achieved FScores above 99%, which is an accuracy higher than the one we can expect from the reference data used for the validation.


I assumed that this unrealistic performances where due to over-fitting and the use of a validation set too similar to the training set. I have recently asked the challenge organisers about the procedure for splitting the reference data into train and test sets and they confirmed that the split was done at the pixel level and not at the polygon level. Therefore, nearly identical pixels coming from the same polygon could be used for training and validation.


Therefore, looking at the challenge results, one could expect that all the teams would have got similar high performances. Since this was not the case, I asked for references to the methods used. Two of the methods are published. I am assuming that these are the 2 winning methods.


One of the methods uses spatial nearest neighbour classification to decide the labels, that is, the class for a pixel is decided using the labels of the nearest pixels of the training set. Here, "nearest" means the closest in the image using an Euclidean distance on the spatial coordinates of the pixel. Indeed, the pixel coordinates where provided as a separate record, but I don't think they were intended to be used as features. And, yes, the best results are obtained if only pixel coordinates are used (no reflectances, no NDVI, nothing!). And 1 single neighbour works best than 2-NN or 10-NN.


This shows that indeed, neighbouring pixels were present in the training and test sets, and the fewer the information used (just the closest pixel) the better the result obtained.


To quickly check this, I ran a simple, out-of-the-box, Random Forest classifier using the coordinates as features and got 97.90% accuracy on the test set, while using the image features gives about 90%.


The second of the 2 winning methods (which is actually the first with an FScore of 99.29 while the method above obtains 99.03), uses 3 deep neural networks, 2 of which use temporal convolutions for each pixel. The third network is a multi-layer perceptron were the input features are statistics computed on all the pixels found in a spatial neighbourhood of the pixel to be classified. Different sizes of neighbourhoods between 1 and 17 are used. This is much more complex than using only the label of the closest pixel, but actually, contains the same information. Adding the information of the 2 first networks may allow to correctly classify the few pixels that the previous method got wrong. The performance difference between the 2 methods is less than 0.3%, which may probably fall within typical confidence intervals.


What can we learn from these results?


First of all, blind metric optimisation without domain knowledge can produce misleading results. Any remote sensing scientist knows that pixel coordinates only are not good predictors for producing a map. Otherwise, one could just spatially interpolate the reference data. Even when applying krigging, other variables are usually used!


Second, when organising this kind of contest, realistic data sets have to be used. The split between training and validation has to follow strict rules in order to avoid neighbouring pixels appearing in both data sets.


Third, map validation has to have a spatial component: are the shapes of the objects preserved, is there image noise in the generated map, etc. This is a tricky question which needs either to have dense reference data in some places or having specific metrics which are able to measure distortions without reference data. Obtaining dense reference data is very costly to and can even be impossible if some of the classes can't be identified by image interpretation (we are not tagging images of cats or road signs!). Developing specific metrics for spatial quality which don't need reference data is an open problem. Some solutions have been developed for the assessment of pan-sharpening algorithms, but the problem is rather different.


Finally, I hope that this critical analysis of the TiSeLaC contest will be useful for future contests, because I think that they may be very useful to get together the remote sensing and the machine learning communities.

MAJA V3.1 will be distributed this May

Example of cirrus cloud correction

We will start distributing MAJA V3.1 this May to replace MAJA V1 on CNES free software platform.


It is also in the pipeline of enhancements of Theia processing platform (MUSCATE), but this pipeline is quite full, so we will need to be patient (which requires a big effort for me, patience not being my best quality...)


MAJA V3 comes with a lot of enhancements compared to V1 :

Continue reading

ESA is making plans for a global Sentinel2 reprocessing in 2019 to enhance multi-temporal registration

A good piece of news, directly from ESA's S2 project manager: ESA is now making plans for a global reprocessing of Sentinel-2 archive in 2019. As explained here, Sentinel-2 data multi-temporal registration isn't perfect yet. It should be improved in the first quarter of 2019, thanks to the use of ground control points obtained via automatic matching, but the issue with the reprocessing of Sentinel-2 archive had not been addressed. It is now, but of course not before 2019.


I let you imagine the amount of processing required to do so for the complete 3.5 years archive of Sentinel-2 at that time, so it will be costly and require hard work, but yet it is indispensable. Let's thank ESA and Copernicus for considering this and letting us know !


The odds to find snow in St. Moritz

Did you know that the St. Moritz Casino is the highest in Switzerland? If you like gambling, I have a little game for you: what are the odds to find snow near St. Moritz?

Fortunately, I just finished the processing of 218 Sentinel-2 dates from 2015-Dec-04 to 2018-Apr-10 of tile 32TNS with our let-it-snow processor. I did this off-line production for a colleague because, as of today, Theia only distributes the snow products after July 2017 in this region of Switzerland (see the available products here).
A quick way to check the output is to compute a snow cover probability map: that is, for each pixel, the number of times that snow was observed divided by the number of times that the snow could be observed.
To compute this map we just need to know that the Theia snow products (LIS_SEB.TIF raster files) are coded as follows:
0: No-snow
100: Snow
205: Cloud including cloud shadow
254: No data
Here is a piece of script to do this:

# initialize snow.tif with zeros
# store in Byte because we have less than 255 dates
f0=$(find . -name LIS_SEB.TIF | head -1) --overwrite -A $f0 --type=Byte --calc=A*0 --outfile=snow.tif
# accumulate snow pixels in snow.tif
for f in $(find . -name LIS_SEB.TIF)
# snow is coded with 100 --overwrite -A $f -B snow.tif --type=Byte --calc="B+(A==100)" --outfile=snow.tif

# now do the same for clear.tif
# init --overwrite -A $f0 --type=Byte --calc=A*0 --outfile=clear.tif
# accumulate clear pixels in clear.tif
for f in $(find . -name LIS_SEB.TIF)
# only snow and no snow are coded with values lower than 101 --overwrite -A $f -B clear.tif --type=Byte --calc="B+(A<101)" --outfile=clear.tif

# Finally compute the snow probability in % (100.0* makes the calculation in float) -A snow.tif -B clear.tif --type=Byte --calc="(100.0*A)/B" --outfile=snowProba.tif

This is the output:

The images are scaled from 0 (black) to 100 (white). The units are number of days for snow and clear, percentage for snowProba.


From which you can map the odds to find snow near St. Moritz (click on the image to animate)!

[MUSCATE news] Early Sentinel-2B L2A images over France are available


MUSCATE sentinel-2 L2A counter just reached 80000 products, but a lot more products were processed these past weeks. Indeed, the MUSCATE team started processing the early Sentinel-2B images acquired from July to October 2017, which were missing on our catalog. Indeed. We only started Level 2A treatments in October 2017, in real time (a bit late, but before the ESA;)). We take advantage of this processing to reprocess Sentinel-2A data, since the quality of the products from MAJA improves with the repetitiveness of the observations. And since we replace old versions with new ones (v 1.7), the product counter is not affected by the reprocessing of S2A data.


The reprocessing of data on France and its overseas territories is finished, and the treatment of the other European zones is in progress. We will continue soon with the African zones then those of the rest of the world. If you are using the Sentinel-2 data acquired in the second half of 2017, we encourage you to download them again. We took advantage of this reprocessing to also produce snow products in the France area.






[Nouvelles de MUSCATE] Le traitement au niveau 2A des anciennes données Sentinel-2B sur la France est terminé

Le compteur de produits de Niveau 2A de Sentinel-2 de MUSCATE vient de franchir les 80000 produits, mais en fait, MUSCATE en a produit beaucoup plus. En effet, l'équipe d'exploitation (Joel, Raquel, Sylvie) a commencé à traiter les données de Sentinel-2B acquises de juillet à octobre 2017, qui manquaient dans notre catalogue. Nous n'avions démarré les traitements de niveau 2A qu'en octobre 2017, en temps réel (avec un peu de retard, mais avant l'ESA ;) ). Nous profitons de ce traitement pour retraiter les données Sentinel-2A, puisque la qualité des produits issus de MAJA s'améliore avec la répétitivité des observations. Et comme nous remplaçons les anciennes versions par les nouvelles (v 1.7), le compteur de produits n'est pas affecté par le retraitement des données S2A.



Le retraitement des données sur la France et ses territoires d'outre-mer est terminé, et le traitement des autres zones Européennes est en cours. Nous poursuivrons prochainement avec les zones Africaines puis celles du reste du monde. Si vous utilisez les données Sentinel-2 acquises au deuxième semestre 2017, nous vous encourageons donc a les télécharger à nouveau. Nous avons profité de ce retraitement pour produire également les produits neige sur la zone France.


Venµs captured the orange snow in the Pyrenees

Theia just published the first Venµs images today, including a beautiful view of the Pyrenees. Once you have dezipped/untared/unzipped the files you can make a true color composite using the command:

gdal_translate -b 7 -b 4 -b 3 -scale 0 300 0 255 -ot byte VE_VM01_VSC_PDTIMG_L1VALD_ES_LTERA_20180419.DBL.TIF myColorCompo.tif

I tend to focus on the snow so I stretched the colors between reflectances 0-1000 instead of 0-300:

gdal_translate -b 7 -b 4 -b 3 -scale 0 1000 0 255 -ot byte VE_VM01_VSC_PDTIMG_L1VALD_ES_LTERA_20180419.DBL.TIF mySnowColorCompo.tif

First, I was a bit puzzled by the orange shade in the northern part of the image. We inspected carefully the image with Olivier because at this stage radiometric calibration issues are still possible..
Continue reading