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.
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.
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?
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…
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?
Can we get the similar negative reflectance values for date prior to 25 Jan 2022 (before baseline 4 changes) with some configuration or mathematical transformation.