Hi @YUEWONHUI,
Thanks for this contribution to detect an issue with MAJA. We indeed need to account for this problem of the Cirrus mask, when the water vapour amount is very low. However, we have a huge list of improvements to add, and we will not be able to add this one quickly, which requires tests with our prototype to determine how to implement it.
Regarding your case, in order to mitigate it, did you test changing the value of the threshold permanently on the tiles prone to low water vapour content ? It might degrade a little bit the detection of thin cirrus clouds, but other cloud tests can provide a compensation.
Best regards, Sophie
The cost function must be computed with the squares.
In MAJA specification, it is written : “Some libraries require an error vector, and the sum of squares is computed within the library (case for GSL), other libraries (Matlab) require to compute the sum of squares within the cost function. The description below is in the case of GSL.”
Is the sum of the squares computed within the library used by MAJA ?
Hello,
Some additional investigations regarding the issue of false cloud mask positive for the following products :
S2A_MSIL1C_20221229T042201_N0509_R090_T47SLD_20221229T061134.SAFE
S2B_MSIL1C_20221203T031109_N0400_R075_T50TMP_20221203T040802.SAFE
They are due to false cirrus cloud detection.
In the deep water absorption band B10, the photons coming from the surface are absorbed by the water vapour. And the signal that appears in this band comes from photons that did not go through all the atmosphere, like the one of cirrus or mountains. To detect cirrus, we compare the signal in band B10 to a threshold which depends on the altitude. Our modelization would be more accurate if it would have taken into account the water vapour content but it does not.
The two products correspond to scenes with extremely low water vapour content : 0.1 g/cm2 for the image of 2022/12/03 and 0.06g/cm2 for the one of 2022/12/29 (water vapour data information come from ERA5 ECWMF reanalysis). So there is not enough absorption. We see the surface and the signal does not only come from cirrus.. It is a very particular case of extremely low water vapour content. For these two images, do not consider the cloud mask. If the false cloud mask is problematic, you can reprocess the two images and change value in the Sentinel-2A and Sentinel-2B L2COMM GIPP <Cirrus_Mask_Threshold_Offset>0.007</Cirrus_Mask_Threshold_Offset> by <Cirrus_Mask_Threshold_Offset>1</Cirrus_Mask_Threshold_Offset>, it will desactivate the cirrus masking.
I hope it helps, Best regards,
Coustance (7d951b00) at 11 Feb 13:05
modify VENUS cloud mask configuration to come back to the parameter...
Coustance (47cb2167) at 11 Feb 12:21
modify VENUS cloud mask gipp params to come back to the ones used i...
Bonjour @jbrossar,
Désolé, je réponds en français pour ce message, Je ne suis pas sûre pas sûre d'avoir bien compris votre commentaire.
La valeur nodata est bien 0 dans les L1C que je vous ai fourni. On obtient bien cette valeur :
C'est plus gênant d'avoir une valeur nodata à 0 pour un L2 que pour un L1 car les valeurs de réflectances sont plus petites dans les L2 suite à la correction des effets des aerosols et on risque de flagguer à nodata des valeurs qui ont en fait une reflectance de surface proche de 0.
Dans l'histogramme des L2, il y a en effet bcp de valeurs à -10000, mais celle ci ne sont pas considérées comme des nodata dans le produit. Car la valeur de nodata fourni par gdalinfo est de 0.
Hello @jbrossar, you should have the permissions right now. Regards, Sophie
Bonjour,
J'ai déposé sous "/work/OT/maccs/MACCS/01_Contextes-FT/FA_gitlab_241_Incorrect_NodataValue_for_Venus" les produits L1C complet (L1C_UNH_C) et distribué (L1C_UNH_D). Je ne sais pas lequel vous utilisez habituellement pour générer des L2 Venus.
qitheia@visu01:/work/OT/maccs/MACCS/01_Contextes-FT/FA_gitlab_241_Incorrect_NodataValue_for_Venus $ ll total 3 drwxr-xr-x 4 qitheia qitheia 4096 May 31 07:57 VENUS-XS_20190915-155724-000_L1C_UNH_C_V3-0 drwxr-xr-x 4 qitheia qitheia 4096 May 31 07:57 VENUS-XS_20190915-155724-000_L1C_UNH_D_V3-0 drwxr-xr-x 4 qitheia qitheia 4096 May 25 08:14 VENUS-XS_20190915-155724-000_L2A_UNH_C_V3-0
Cordialement, Sophie
FA obtenue lors de la QO Muscate 2.9.1 intégrant MAJA V4.2
Sur les images Venus, les bandes B5 et B6 présentent des valeurs anormalement hautes, cela se voit dans les quicklooks que je génère qui utilisent la bande B5 pour la bande rouge de la composition colorée. Ces images sont donc trop rouges. Cela ne se voit pas sur les quicklooks générés par MAJA qui utilisent une autre bande pour la bande rouge. Les produits Venus que j’ai généré avec MAJA V4.2 sans CAMS ne présentent pas cette anomalie.
FA otenue lors de la QO Muscate V2.9.1 intégrant MAJA V4.2
Le masque d’eau de S2 présente beaucoup de faux positifs qui n’étaient pas présents dans les produits traités avec MAJA V3. Or le paramétrage du masque d’eau dans les GIPP n’a pas évolué. Sous “/work/OT/maccs/MACCS/01_Contextes-FT/FA_QO_Muscate_2.9.1” se trouvent un exemple de quicklook sur Lacrau et Ouarzazate pour des L2 obtenus en production avec MAJA V3 et en QO avec MAJA V4. On constate une détérioration du masque d’eau. Ces faux positifs sont aussi présents sur Venus et Landsat-8.
In Venus L2 products the nodata value is 0 instead of -10000.
The command "Gdalinfo –stats" gives : NoData Value=0 Metadata:[..]
0 is a likely value (or is close to a likely value) for surface reflectance, thus it should not be used as nodata value.
Bug found in operational Qualification of Maja V4 with Muscate 2.9.1