It appears that the resampling method used to generate the internal overviews of the SCL products is not correct. The overviews have values that are not present in the SCL legend.
For example for product S2B_MSIL2A_20200502T085549_N0500_R007_T34NCJ_20230509T154254 when reading the SCL data at 80m, the overview shows values up to 14:
This causes unexpected behaviors in processing chains accessing the data at lower resolution.
It appears that the resampling was CUBIC, while it should be MODE or NEAREST.
Is this known? was it fixed already? I couldn’t find information on that.
Thank you for your message regarding the L2A SCL layer.
Firstly, we would like to inquire about the origin of the L2A product you mentioned. How did you access it? Was it through the Copernicus Data Space Ecosystem, a DIAS, or from another source?
We ask this question because the SCL within L2A Core Products is not encoded in COG but in JPEG2000, a format that does not support the proper configuration of overview generation. Additionally, in the Sentinel-2 operational ground segment, JPEG2000 encoding module is common to L1C processing and is not performed by the Sen2Cor software.
In Sen2Cor version 2.11, there is an option to generate the SCL in COG format:
--sc_cog: Export SCL image in COG format instead of JPEG_2000
However, it’s important to note that this option is not activated by default for operational production. If you decide to explore this option, please be aware that internal overviews are created with the resampling=“MODE” and the following resolutions for SCL at 20 m:
main resolution: 20 m
Overview 1: 60 m
Overview 2: 120 m
Overview 3: 360 m
This non-standard pyramidal resolution layout is designed to maintain optimal geometry and compatibility between Sentinel-2 bands with different native resolutions (i.e., 10 m, 20 m, 60 m).
We understand that this information may not be entirely helpful if your interest lies in processing data directly at lower resolutions.
Coming back to our initial question, if you found the data in COG format then the question is to understand how it was generated and by which team.
Thanks for the reply. I downloaded the product from the Copernicus Data Space Ecosystem, so this is an original L2A product and indeed it’s not a COG, sorry for the confusion, it’s a JP2000 product.
Thanks for the comprehensive feedback, just to further clarify and see if I understood, you are saying that it is expected that the JP2000 overviews of the SCL layer are not correct because you cannot customize the overview resampling method when producing them?
The difference is that for Cloud-Optimized-GeoTiff (COG) the different overviews exist. When creating a COG, you have the option to utilize default settings or control the organization of overviews according to your preferences, including the number, resolution, and resampling method. In contrast, for the JPEG2000 Format, overviews are inherently part of the JPEG2000 encoding process, based on wavelet transforms. There is no possibility to control them, create them, or using a different resampling method; those “overviews” are an internal part of the JPEG2000 compression that some readers are able to access. Furthermore, in the original L2A products, JPEG2000 encoding is conducted externally to the Sen2Cor software, using the Kakadu software within an external compression module…
