Sentinel-2 processing baseline changes and harmonizeValues

Hi Users,

As some of you might be aware, ESA will be updating the Sentinel-2 processing baseline in January 2022. One breaking change is the definition of digital numbers (DN) in the source files. Negative reflectance values will be possible and DNs before and after the change are shifted and will no longer be comparable.

To keep this transition as smooth as possible, we are introducing the harmonizeValues parameter. This optionally goes is in the input.processing section of your request.

The default value is true and this means that without needing to do anything, you will get data exactly as before.

harmonizeValues can be true (default) or false, and it’s behavior depends on the units:

  • REFLECTANCE:
    • harmonizeValues = true: negative reflectance values are clamped to zero. In other words, pixels with negative reflectance return zero reflectance instead.
    • harmonizeValues = false: negative reflectance values can be returned.
  • DN:
    • harmonizeValues = true: DN values are harmonized so they are comparable with data from previous baselines. Therefore it still holds that DN = 10000 * REFLECTANCE. In addition, negative values are clamped to zero.
    • harmonizeValues = false: DN values are exactly as provided in the source files themselves. The “true” DN value, you could say. Don’t forget that values have different definitions with different processing baselines, careful with mosaicking!

So if you are happy with the way things are, there is no need to do anything. However, if you would like to benefit from negative reflectance introduced in the new procesing baseline, consider adding harmonizeValues=false to your request.

2 Likes

Hi Users,

Data from the new processing baseline will start being available on January 25, 2022.

See the above for more information.

Note that today the new baseline processing products started to be disseminated. First example here.

Hi @gmilcinski I am getting exact same values while requesting sentinel-2-l1c product for my AOI dated 2022-01-27 with harmonizeValues set to True and False in input.data.processing.
Is this a possible scenario? I was expecting some DN values changes with True/False settings but no such difference appeared in the response.

2020 or 2022?
harmonizeValues will make a difference only for products published with PB 4.0, so after 25.1.2022. Note that there might still be some products processed with old version - this is not within our control.

Yes it is 2022. So in order to observe the changed is seems like I have to test the same on more AOI and dates after 25.1.2022.

A post was split to a new topic: MTD_DS.xml or MTD_MSIL1C.xml

A post was split to a new topic: Impacts of changes of the processing baseline

Does this change affect the jp2 files in the Sentinel Hub S3 bucket?

The data in the S3 bucket is replicated “as it is”, without any changes. Therefore yes, when ESA changed the processing baseline, the values in the (new) JP2 files changed as well.
The “harmonizeValues” option only works when accessing the data via Sentinel Hub.

Okay, thanks. Are the RADIO_ADD_OFFSET and QUANTIFICATION_VALUE parameters that are needed to compute the reflectances available in any of the metadata files in the S3 bucket?

Sure they are, i.e.
sentinel-s2-l1c/products/2022/2/7/S2A_MSIL1C_20220207T101201_N0400_R022_T32TPL_20220207T122038/metadata.xml

As you wrote, there should be no changes in reflectance values if the parameter will stay as defalut, but I noticed that NDVI calculated on data acquired starting from 25 January has much lower values compared to earlier images. Do you know what this could be due to?

Can you pass some example of the request prior and after 25.1., to demonstrate these changes? Otherwise it is difficult to guess what is the reason in your case, as there are lots of parameters that might impact the processing…

Sorry, I didn’t apply RADIO_ADD_OFFSET (I am using S2MSI1C products) and that was the reason of low values of NDVI.

Thanks @gmilcinski! Does it mean that, in order to get the values that we would previously expect, we will have to apply the following formula (example for a B08.jp band on the AWS bucket)?

(B08 + RADIO_ADD_OFFSET) / QUANTIFICATION_VALUE

Where in all cases that I’ve checked so far:
RADIO_ADD_OFFSET = -1000
QUANTIFICATION_VALUE = 10000

What about the L2A collection? Should I use BOA_ADD_OFFSET and BOA_QUANTIFICATION_VALUE instead?

3 posts were split to a new topic: How to get S2 L2A data harmonised through time