Changes in band data after 25 Jan 2022 | Baseline 04.00 harmonizeValues | Sentinel 2 L2A | Snappy

Kind regards to all,

Using L2A products, after the update 04.00 ( there is a change in the data as stated in the entry:

Provision of negative radiometric values (implementing an offset): Similarly to Level-1C, the dynamic range will be shifted by a band-dependent constant, i.e. BOA_ADD_OFFSET. From the user’s point of view, the L2A Bottom of Atmosphere (BOA) reflectance (L2A_BOA) shall be retrieved from the output radiometry as follows:

  • Digital Number DN=0 remains the “NO_DATA” value
  • For a given DN in [1;2^(15)-1], the L2A BOA reflectance value will be: L2A_BOAi = (L2A_DNi + BOA_ADD_OFFSETi) / QUANTIFICATION_VALUEi

Due to this change, after 25 January of 2022, it can be seen that when extracting the values of the bands using snappy in the same way as before, these values are approximately 0.1 higher.
I attach an interpolated graph of the B2 band for the year 2021 and 2022

B2 Band 2021_2022

product = ProductIO.readProduct(file)
band = product.getBand("B2") 

After checking the forum, we see that this problem may be solved by a parameter called “harmonizeValues”.

The problem we are currently facing is how to get this “pre-corrected” data from each of the bands through snappy. How to introduce this parameter before the getBand, so that the values are given to us in the same way as before.

In the event that it would be resolved with harmonizeValues, we have seen that, for example, to introduce a resolution change parameter would be to add the targetResolution parameter to 60 and do a Resample operation.

HashMap = jpy.get_type('java.util.HashMap')  
parameters = HashMap()
result = GPF.createProduct('Resample', parameters, product)

For the harmonizeValues parameter, what kind of operation or process should be done or if there is anything else to take into account?

Thanks to all

@GSiesto! I have the same problem.

I hope someone here can help us.


1 Like

I found the solution in SNAP. To do this, you need to do the following:
Tools > Options > S2TBX >Sentinel-2 Reader > Check Add Negative Radius Offset
Is a SNAP configuration but, for Snappy, I can’t find a solution. I hope someone can help us

1 Like

Once this setting is set it should be applied to the data in Python too if you are using snappy for reading the data.
If you read the plain jp2 files you need to do the scaling your self.

1 Like

Thank you very much for the answers, I followed the procedure and found it to be effective. Following the steps would be :

  • Update SNAP to the latest version (at least version 8)
  • Change the software configuration as indicated by @acaballegn
    Tools > Options > S2TBX >Sentinel-2 Reader > Check Add Negative Radius Offset
  • Read through Snappy the original sentinel image.

Note: In case of opening an image that is not the original one, for example an image that has been previously processed by a previous version of SNAP (less than 8), such as a clipped image, calculated indicators, etc., it would not work, and you would have to do the same processing to the original image with the new version of SNAP).


was it somehow fixed??? got problem with harmonization or processing the right way… how do I use new data so it would be comparable to old one??? HELP!

Hi @marpet . How should we do the scaling using the plain jp2 files? I’ve tried this formula L2A_BOAi = (L2A_DNi + BOA_ADD_OFFSETi) / QUANTIFICATION_VALUEi but it didn’t work for me

It works quiet well vor me.
When I do the conversion on my own in SNAP with Band Maths, I get the same results.

Can you show an example calculation?

Thanks for the quick answer!

I am doing the same calculation but values do not match with the range I have for previous year for the same point. For example:


B2= 1069
B2_conversion= ( 1069 - 1000)/10000 = 0.01



I don’t know how to compare 0.01 with 234

For data from the time before Baseline 4 there was no offset.
There you only must apply the quantification value.

234 / 10000 = 0.0234


Dear @marpet

I am processing old (e.g., 2018, 2.06) L1C S2 data using the new Sen2Cor v2.10 to transform it locally to L2A. I noticed that in such produced L2A metadata, there are no new OFFSETS (BOA_ADD_OFFSET) present. Do I assume correctly that for old L1C products, that are being processed with 4.00 Sen2Cor v2.10, the backward capability is enabled and only division by 10.000 applies (QUANTIFICATION_VALUE)?

Do I also assume correctly, that with the new 4.00 data (after January), when you apply the new harmonization (L1C_TOAi = (L1C_DNi + RADIO_ADD_OFFSETi) / QUANTIFICATION_VALUEi) the values in JPEG2000 should be the same/comparable with old data? Do we need to clip negative values at 0 (as SentinelHub does) to make it even more comparable/the same?

Thank you for your reply!

Hi @ds2268,

I’m not a sen2cor expert or a developer, but what you write seems reasonable. I think this is how it should be.

Maybe @bdpg can confirm this

Thanks! That would be great if confirmation can be obtained.

I was confused because I noticed the same NODATA values over the water areas on such produced L2A products with the new Sen2Cor 2.10 (despite processing 2018 L1C products) - as mentioned in: No-data in the sea resulting from sen2cor 2.10.01 - #5 by bdpg.

My thinking was that this should not happen with older L1C products, despite being processed with the latest L2A 4.0 Sen2Cor.

The conversion is the following:

  • if Sen2Cor 02.10.01 processes L1C with PB < 04.00 then: L2A_BOAi = L2A_DNi / 10000
  • if Sen2Cor 02.10.01 processes L1C with PB >= 04.00 then: L2A_BOAi = (L2A_DNi – 1000) / 10000|

L1C with PB >= 4.0 are those generated after January 25, 2022.

If you find NODATA values over water on L2A products from Sen2Cor2.10 for “old” L1C data with PB < 0.00, then please provide us the L1C product you are using for detailed investigation.