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) ):
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.
Hi @Eddie
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.
Thanks for your swift response @Jan,
thats great!
Is this perhaps something that could be clarified in the “Sentinel-2 Products Specification Document” or some related documentation?
Hi @Eddie
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.
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.
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?
Hi @Jan thanks for getting back.
The product i attempted this within SNAP was:
S2B_MSIL2A_20230119T112309_N0509_R037_T30UWC_20230119T125155
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.
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?
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.
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.
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.