Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

change in the NDVI value when compared to sentinel hub #349

Closed
krishnaglodha opened this issue May 23, 2024 · 14 comments
Closed

change in the NDVI value when compared to sentinel hub #349

krishnaglodha opened this issue May 23, 2024 · 14 comments

Comments

@krishnaglodha
Copy link

Hi, I'm trying to create NDVI based on sentinel-2-l2a , bit I see difference in values on pixels when compared with sentinel hub

Here is the image from sentinel hub
Screenshot 2024-05-23 at 3 29 33 PM

we can see that it ranges from 18 to 61 i.e. 0.07 to 0.23 ( divided by 255 )

and here is the image from planetary
Screenshot 2024-05-23 at 3 28 02 PM

where values are ranging between 0.04 to 0.15

my code looks like

catalog = pystac_client.Client.open(
    "https://planetarycomputer.microsoft.com/api/stac/v1",
    modifier=planetary_computer.sign_inplace,
)
time_range = f"{start_date}/{end_date}"
collection = "sentinel-2-l2a"
geometry = polygon["features"][0]["geometry"]
search = catalog.search(
    collections=[collection], intersects=geometry, datetime=time_range
)  # bbox=tas_bbox   
print(search.get_all_items())
data = load(
            search.items(),
            geopolygon=geometry,
            chunks={},
            resolution=1,
            projection="epsg:3857",
        ).isel(time=0)
dc = data.rio.clip([geometry], crs="epsg:4326")
index_xarray = ms.ndvi(dc.B08, dc.B04)
index_xarray.rio.to_raster("planet_scope.tif")
@TomAugspurger
Copy link

.Looks like a few variables in your snippet aren't defined, so I can't reproduce it (start_date, end_date, ms)

Do you know offhand whether the values from Sentinel Hub are L1C or L2A, and which processing baseline it's using? It might be better to compare just the raw values (from before the NDVI calculation).

@krishnaglodha
Copy link
Author

here are the variables

polygon = {
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "coordinates": [
          [
            [
              79.06776796168413,
              19.043044385618458
            ],
            [
              79.06776796168413,
              19.041761558038218
            ],
            [
              79.06973122024931,
              19.041761558038218
            ],
            [
              79.06973122024931,
              19.043044385618458
            ],
            [
              79.06776796168413,
              19.043044385618458
            ]
          ]
        ],
        "type": "Polygon"
      }
    }
  ]
}

start_date = '2024-01-01'
end_date = '2024-01-06'

@krishnaglodha
Copy link
Author

PS: I also tested out result in comparison with agromonitoring.com , and got similar differences
Screenshot 2024-05-24 at 9 43 56 AM

vs microsoft
Screenshot 2024-05-24 at 9 44 06 AM

@krishnaglodha
Copy link
Author

krishnaglodha commented May 24, 2024

.Looks like a few variables in your snippet aren't defined, so I can't reproduce it (start_date, end_date, ms)

Do you know offhand whether the values from Sentinel Hub are L1C or L2A, and which processing baseline it's using? It might be better to compare just the raw values (from before the NDVI calculation).

when we download raw data from pc the range is between thousands, whereas sentinel-hub data range is betweek 0-255, what might be going wrong ?

In terms of data, we are using L2A everywhere

@TomAugspurger
Copy link

when we download raw data from pc the range is between thousands, whereas sentinel-hub data range is betweek 0-255, what might be going wrong ?

That might be to the baseline or units I mentioned in #350 (comment).

@krishnaglodha
Copy link
Author

when we download raw data from pc the range is between thousands, whereas sentinel-hub data range is betweek 0-255, what might be going wrong ?

That might be to the baseline or units I mentioned in #350 (comment).

how do we use this units ?

@krishnaglodha
Copy link
Author

I tried replicating same results with 'https://earth-search.aws.element84.com/v1' and surprisingly I got correct result ( similar to sentinel hub ) with earth search STAC link.

@TomAugspurger
Copy link

how do we use this units ?

Sorry, I don't understand the question.

I'm not an expert, but my understanding is that bands like "B04" are provided as "digital numbers" and are typically in the range 0-4000.

@krishnaglodha
Copy link
Author

I tried replicating same results with 'https://earth-search.aws.element84.com/v1' and surprisingly I got correct result ( similar to sentinel hub ) with earth search STAC link.

@TomAugspurger , what is your comment on this ?

@TomAugspurger
Copy link

TomAugspurger commented May 27, 2024 via email

@brendancol
Copy link

@TomAugspurger @krishnaglodha For things that are specific to xrspatial.multispectral.ndvi happy to help as we have this issue that was setup..makepath/xarray-spatial#802

@jessjaco
Copy link

Just a thought, the other sources might be applying the offset automatically, see #134. Maybe try a date before the offset was added and see if the values match?

@mhungen
Copy link

mhungen commented Jul 10, 2024

I tried replicating same results with 'https://earth-search.aws.element84.com/v1' and surprisingly I got correct result ( similar to sentinel hub ) with earth search STAC link.

They seem to apply the offset to there COG assets. I ran into a similar problem and documented it. here

the confusing part is that they use the STAC raster extension to provide the values for offset and scale.

"raster:bands": [
    {
        "nodata": 0,
        "data_type": "uint16",
        "bits_per_sample": 15,
        "spatial_resolution": 10,
        "scale": 0.0001,
        "offset": -0.1
    }

However the offset is still "-0.1". IMHO it should be "0" since the values are already harmonized. but this is another story....

the deviations you have observed can also be caused by the other DEM used by PC

@ghidalgo3
Copy link

Closed due to inactivity, feel free to reopen if you would like to continue this discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants