Landsat Thermal

Hi,
Landsat 8 Thermal is indeed based on B10 band. It’s not DN, but it’s already transformed to temperature in Kelvins based on the formula you provided on your link. If you use product THERMAL.INDEX you can get temperature directly into TIF file.

Great to know, thanks for answer!
However, I strugle to download Index values. I use configurator and when I use “INDEX” script, it is empty. Grayscale visualisation works normally. Do you have idea where the problem is?
Thanks!

I have the same issue, when using the Thermal Index script all pixels have the same value 147

Can you provide one such example call, so that we look into it?
Do mask the instance ID when providing the answer.

I am using the sentinel-hub python api. with the polygon that is a the end of this text and the landsat thermal index default configuration and querying for this date 2015-02-01. the request is a WcsRequest with alpha layer and clipping to polygon… When a one date request is performed and there are overlapping images the WcsRequest returns only one instead of two, the returned image has all its thermal pixels set to 147. If one performs a search for a range including the date of interest (±1 day) the WcsRequest returns two images one with the faulty pixels and another with correct values. Same happens if a quality layer “return [decodeLs8Qa(BQA).cloudConfidence*0.33];” if queried.
I am guessing that the faulty images come for the tile where the polygon is at the limit of the tile where some landsat bands do not overlap perfectly
Is it there any possible solution?

Kind regards!
{
“type”: “Polygon”,
“coordinates”: [
[
[ -64.34896908689133, -33.826251918035908 ],
[ -64.339746933410339, -33.826199618488758 ],
[ -64.339642334316039, -33.835090541504464 ],
[ -64.349248017809472, -33.835195140598763 ],
[ -64.349143418715173, -33.834741877856786 ],
[ -64.34896908689133, -33.826251918035908 ]
]
]
}

We would need an actual Sentinel Hub request to dive into this.
E.g. something like
https://services.sentinel-hub.com/ogc/wcs/6121c5eb-3b26-MASKED?coverage=TRUE-COLOR-S2-L1C&request=GetCoverage&crs=EPSG%3A32736&bbox=241797.55233011098%2C10008521.64536119%2C251721.8032413172%2C10018416.847597253&format=image/png&maxcc=100&resy=10m&version=1.1.2&resx=10m&transparent=False&showlogo=False&service=wcs&time=2018-09-30/2018-09-30

If you are not able to get an example, you can try the following:

• create a new instance in Configuration utility
• use this instance only for the problematic example
• send us the first two blocks of the instance ID
  (this will make it possible for us to check the logs)

Here is the wcs request

https://services-uswest2.sentinel-hub.com/ogc/wcs/{INSTANCE-ID-FOR-LANDSAT}?SERVICE=WMS&REQUEST=GetCoverage&VERSION=1.3.0&TIME=2019-03-21&COVERAGE=THERMAL&RESX=10m&RESY=10m&CRS=EPSG:4326&TRANSPARENT=1&FORMAT=image/tiff&GEOMETRY=POLYGON((-33.826273%20-64.339695,-33.826309%20-64.348842,-33.835132%20-64.349164,-33.834972%20-64.339716,-33.826273%20-64.339695))

The “THERMAL” layer / coverage is the default configuration for Landsat-8 thermal index. In this case as the request is different form the one I do at the python api, all values are 65535 instead of 147

Thank you. Looking briefly it seems there might be a bug on our side. We will check and come back.

Just a few additional comments (not impacting this issue, but in general):

• TIME parameter should be “FROM/TO”, e.g. in this area there is no image on 2019-03-21, there is one on 2019-03-16, which is used as you only set “TO” part of the time range
• Thermal band has resolution of 100m so it does not make much sense to use 10m resolution.

Thanks for the reply, I just saw that the date was not the one I meant (2015-02-01), but nice you could work it out anyway. Thanks for the 10m advice, the url was from another request and I just modified some important parameters.

Do you have any resolution time for that bug?

Kind regards!

Not for the moment as the bug needs to be analyzed. It (probably) is a bug and bugs usually have high priority in our workflow. However, it seems to be a very specific bug, affecting extremely small part of our users…
I will inform you, once we have more information.

You can avoid this issue by using 32-bit format ( FORMAT=image/tiff;depth=32f) for now.
We will update this thread once it is fixed for others as well.

Hi,
we have finally found time to analyze this (sorry for a delay, but lots of other critical things).
This issue is related to the way how OGC services try to stretch values:
https://www.sentinel-hub.com/faq/how-are-values-calculated-within-sentinel-hub-and-how-are-they-returned-output

In case of thermal band val is a temperature in K, so around 300. As this is more than 1, all the values in the returned index will be 1.

You therefore have to divide the value before passing it to the output, e.g. with 400 or so to be certain it is below 1.

Even better, we suggest you use our latest version of the API, which does not do these auto-stretching anymore.
https://docs.sentinel-hub.com/api/latest/

Hello @gmilcinski, that request solves the problem with the wcs request in the browser, but it does not in the sentinelhub-py wcs request.

Is it any workaround for that?

The request I do using sentinelhub-py has this parameters, if you check the values of the first image returned on the list (corresponding to day 2015-01-16) you will see that all returned values within the polygon are 147.51712.

wfs_iterator:{
base_url:‘https://services.sentinel-hub.com/ogc/’
}
layer:THERMAL
bbox:-64.275065,-33.005537,-64.260992,-32.995863
time:(‘2015-01-07’, ‘2015-04-17’)
data_source:DataSource.LANDSAT8
maxcc:0.7
image_format: MimeType.TIFF_d32f
service_type: ServiceType.WCS
size_x: 30m
size_y: 30m
custom_url_params :{
<CustomUrlParam.GEOMETRY: ‘Geometry’>: shapely polygon**,
<CustomUrlParam.TRANSPARENT: ‘Transparent’>: True
}
**shapely polygon wkt is POLYGON ((-64.275065 -33.002974, -64.27294999999999 -32.995863, -64.260992 -32.998138, -64.26277 -33.005537, -64.275065 -33.002974))

Hello,

I see that this discussion is quite old but I did not find another one related to my question…
Actually I would like to write a custom script which used B10 and B11 from Landsat8 images but my script dos not return what it is supposed to do.
Ideally I would need a 8-bits value (or a 16-bits one) but it seems that it is not the case for B10 and B11 as it is for the other 9 bands. Could you confirm it please ? And let me know what is the value contained in B10 and B11 or how to convert it ?

Thank you very much for your help

Hi,

Hopefully I can try and help you but I’m not exactly sure what you want to extract? Are you willing to share the custom script or explain in a little more detail what you wish to do in the script?

In the meantime, we recently added some examples for Landsat 8 in the documentation that can be found here:

docs.sentinel-hub.com

Examples for Landsat 8-9

Use these CURL and Postman examples to access Level 1 Landsat 8-9 data with Sentinel Hub API.

You can parse these examples into the Request Builder site and then adjust the custom script in there to your requirements.

apps.sentinel-hub.com

Requests Builder

Request Builder for Process API, Sentinel-Hub

Also, a new feature if you toggle on the Data Product option in the custom script box you can find some other examples of thermal visualizations that maybe useful to you 🙂

Hope this all helps, and if you have anymore questions, I’ll be happy to help

Thank you for you reply,

Actually I see here (https://docs.sentinel-hub.com/api/latest/data/landsat-8/) that values for B10 and B11 are in Kelvin. Can you confirm it ?
If it’s true, can you tell me how to convert B10 and B11 values into 16bits reflectance values please? Indeed, since my script is the result of a machine learning model that has been trained on 16-bits reflectance values, for all Landsat8 bands, I need to apply it on this type of value to get the good prediction.

Thank you very much again for your help

Hi,

Yes I can confirm that the B10 and B11 values are in Kelvin.

Unfortunately, I don’t think it is possible within the platform to use reflectance values as we only provide the Kelvin value. To do this would require metadata coefficients that aren’t stored by us. I will try and confirm this with another member of the team but if I understand what you’re trying to do, I don’t think it is possible at the current time.

Best

indeed based on B10 band. It’s not DN, but it’s already transformed to temperature in Kelvins based on the formula you provided on you

Hi, Would you please confirm the equation used to convert from B10 to degrees C as is displayed in EO Browser?

I use the following equation (taken from https://www.usgs.gov/faqs/how-do-i-use-a-scale-factor-landsat-level-2-science-products):
Temperature in degrees celsius = B10 * 0.00341802 + 149.0 - 273.15

When I compute this myself on the image that EO Browser references (e.g., s3://usgs-landsat/collection02/level-2/standard/oli-tirs/2023/035/033/LC09_L2SP_035033_20230608_20230610_02_T1/
LC09_L2SP_035033_20230608_20230610_02_T1_ST_B10.TIF) my results are consistently 0.17 degrees C lower than the values extracted with the “Statistical Info” tool in EO Browser.

Are you using a different equation to convert from DN to temperature in degrees C?
Thank you!

Hi,

If you click on the small edit button of the layer in the EO Browser, you can see the Evalscript and thus the formula that is used for the Statistical tool (see the red circle in the figure below).

The conversion here is: B10 - 273, which explains the differences that you get with the formula you apply (the difference should be 0.15 not 0.17). If you want to apply your formula, you can edit the Evalscript (line 35) and hit the Refresh button.

Thank you for the quick response, Maxim!

The source data (the ST_B10 tif at s3://usgs-landsat/collection02/level-2/standard/oli-tirs/2023/193/030/LC09_L2SP_193030_20230611_20230613_02_T1 in the case shown above) is stored as digital numbers (DN).

Would you please confirm the process used to convert from digital number of the source data to K as available in the browser? The K to C conversion is easy enough to find in the Evalscript as you point out, but I do not see any documentation on how you convert from DN to K. Your confirmation of the equation would be appreciated, thanks!

Hi,

I guess you mean Kelvins with K? If so, then an example of this can be found here.

Hi!

Yes indeed, K = Kelvin.

I understand how you retrieve data through your API, thank you for providing the link.

What I am trying to understand is how and at what point you convert from Digital Number to Kelvin. The data available on the commercial data access bucket referenced in the EO Browser (s3://usgs-landsat/collection02/level-2/standard/oli-tirs/2023/193/030/LC09_L2SP_193030_20230611_20230613_02_T1) is stored as Digital Number (see screen shot below).

USGS EROS provides the following process on converting from digital number to Kelvin, here: https://www.usgs.gov/faqs/how-do-i-use-a-scale-factor-landsat-level-2-science-products.

Can you verify 1) that you use the data stored in the s3://usgs-landsat/collection02/level-2/standard/oli-tirs S3 bucket/prefix for the Landsat 8-9 L2 Thermal data in EO Browser, and 2) how you process these data to convert from digital number to Kelvin.

Thank you!
 

Hi,

1. Yes, that is the data that we use.
2. The formula used is DN * 0.00341802 + 149 this is based upon this guide from USGS.

We hope that this information answers your questions 🙂

Yes! Thank you so much for sticking with me on this thread. With a wide (and growing) range of access points to multiple versions of data, it is critical that we know and understand all of the steps used to pre-process the data available though end points like EO Browser. Thank you!