I write this to underscore the information in the Tables here
Processing Baseline - Sentinel Online and in the L1C and L2A Data Product Quality Reports - Sentinel Online
Along with several other evolutions, Processing Baseline 04.00 L1C (TOA) and L2A (BOA) products (TTO 25th of January, 2022) now contain an Offset in the metadata. This offset has been included to accomodate ‘noisy’ pixels over dark surfaces, that can sometimes present negative radiometric values at L1B and L1C.
Prior to PB 04.00, these negative values were clamped to a predefined range (e.g. [1-32767]), thereby leading to a loss of information. In order to avoid this, and following an analysis by expertise, a radiometric offset has been introduced which shifts the range. The conclusions of the analysis resulted in the following specifications for the Offset:
- At L1B, RADIO_ADD_OFFSET = -100
- At L1C, RADIO_ADD_OFFSET = -1000
- At L2A, RADIO_ADD_OFFSET = -1000
SNAP is User-configurable for this change; the Radiometric Offset can be added in SNAP by selection of the relevant radio button (Tools > Options > Sentinel-2 Reader > Add negative radiometric offset (L1C -L2A) ):
Additional information can be found in the [Sentinel-2 Products Specification Document (PSD)](Sentinel-2 Products Specification Document (PSD) - Sentinel Online .)
I hope this information is of benefit to you.
OPT-MPC S2 Technical Manager
I posted a question yesterday (Clamp negative reflectance to 0 (NODATA) for Baseline 04.00 with new OFFSET correction?) that perhaps you could help me with (pert of it repeated below).
While comparing images between the current Baseline 04.00 and earlier Baseline versions I subtract the OFFSET value Baseline 04.00 images depending on product. This sometimes leads to, as expected, negative values in the resulting raster.
My question is: What is the correct way to present these values if clamping them to a floor of 0? Should they be regarded as NODATA (value 0) - Implying missing or faulty data? Or should they be viewed as a minimum value (like 1)? The reasoning being that these have a registered value that is out of bounds, but assumed to be approximately 0.
I would suggest that they should be regarded as NO DATA (value 0). This would at least flag them as unreliable. This is based on my understanding of negative reflectance values being linked to the Atmospheric Correction processing step. And thus they are an unwanted contribution to the output. So making them 0 identifies them as non-nominal, and helps serve as an avoidance measure. Or a flag of doubt. Giving them a value of 1 would potentially attribute them some relevance, and may serve to confuse.
I hope this helps.
OPT-MPC S2 Technical Manager
Thanks for your swift response @Jan,
Is this perhaps something that could be clarified in the “Sentinel-2 Products Specification Document” or some related documentation?
No worries. We are currently undertaking a wholesale update of Sentinel Online, so I will suggest that the content is updated to reflect these changes.
As far as the PSD goes, it’s really more a description of the Product levels and their packaging (and associated schemas and metadata), so the specifics of the Radiometric Offset aren’t in that remit. But I’ll mention it to the L2A expertise to see if it can be included in the ATBD .
Hi Jan, I could not find this information elsewhere.
Is the RADIO_ADD_OFFSET value always the same for all bands or is it variable meaning it is mandatory to check the metadata for every scene and extract the exavt value.
The RADIO_ADD_OFFSET is fixed:
At L1B, RADIO_ADD_OFFSET = -100
At L1C, RADIO_ADD_OFFSET = -1000
At L2A, RADIO_ADD_OFFSET = -1000
In the L1C product it is available from the DS metadata at <Radiometric_Offset_List>
In the L2A product it is available from the DS metadata at <BOA_ADD_OFFSET_VALUES_LIST>
Page 444 of the [PSD] identifies its use in converting DN to physical values.
I hope this helps you.
Hello @Jan. I am working with using an NDVI threshold we identified via fieldwork to map bare ground. To be consistent with the previous years (prior to v0400 offset) I need to get the post-v0400 images to work with our threshold. I have tried loading a L2A scene into SNAP with the negative radiometric offset ticked and then exported the bands i need (4 & 8a) as TIFs but unfortunately it does not make any difference to the values in the images. What am I doing wrong here?
All the best,
Can you let me know the product details please? I’ll download it and try from this end.
Thanks in advance
Hi @Jan thanks for getting back.
The product i attempted this within SNAP was:
It would be good if you could share how this methodology is applied as I think that is where I might be going wrong.
I have since done a simple band calculation of -1000 to bands B04 & B8a and then changed any negative values to 0. Doing this I have achieved more reasonable NDVI responses but I am still unsure as to if this was correct or not. This was performed in ArcGIS PRO.
All the best,
Hi @Jan did you manage to take a look at this? It would be a great help for the work that we do to get a functioning methodology in place.
all the best,
I’m sorry for not getting back to you sooner. I have looked at profile plots over in your AOI for a couple of L2As and they both exhibit similar values. One thing I did not however, is that the built up areas are sometimes rendered as cloud shadow in the Scene Classification Layer (SCL) and this is also seen in the WVP quality layer too:
Hi @Jan great - thanks for the claification on this. This is the only place I have found that states that the values are fixed. I have seen a consistent value over many scenes, but was not sure if this was officially a static value.
I have two questions:
If the value is fixed, why is it not documented that way? From the documentation it seems that its variable by band and by product, for instance Copernicus Sentinel-2: Major Products Upgrade Upcoming - Sentinel Online . Is there a place where it is doucmented that this value is a constant?
It seems like the formula on page 444 of the PSD might be wrong. If I understood correctly it should be (DN + RADIO_ADD_OFFSET) / (QUANTIFICATION_VALUE), but its documented as DN + RADIO_ADD_OFFSET / (QUANTIFICATION_VALUE), which would not give the same result. Could you clarify which one applies?
Thanks in advance,
Hello Daniel @yellowcap
As I’m not the author of the documentation, I can’t give a hard and fast answer to your question. It may well be that it was done like that in order to enable a bit of freedom in the attribution of a value to the offset. A ‘Just In Case’ moment. I’m really not sure. All I can say is that the value (values for L2A) are referenced in the MTD_DS.xml
With regard to your second point, I presume you’re referring to the absence of brackets in the formula. I understand from colleagues that this would be a problem in writing code. I will raise it with my former colleagues. But it will probably have to wait for the next [PSD] version.
Great, thanks for the detailed answer @Jan !
Indeed I have seen these tables in the metadata xml files, and in all cases I have seen its
-1000. So I think its safe to assume that the value is constant for now. It would be great if that could be documented somewhere, but I understand that the authors wanted to leave the door open for more flexibility in the future. Thanks for the explanation.
For point two indeed it was about the brackets. Back to basic algebra I guess people will apply it the right way out of context, but would still be good to revise the docs. If you know a better place to report this issue let me know, happy to post a ticket or so somewhere else if useful.