Different values for EVI from SentinelHUB and get_data()

You might first want to read this FAQ, explaining how output values differ based on which output format you are using.
Also, “configuration instance” might have EVI configured to show “visualized” values rather than actual values - you can check this in the Configuration utility.
Which “metainfo” are you referring to? The resolution coming from Sentinel Hub depends on the request you use to get the data. If you use “RESX=10m&RESY=10m” (instead of WIDTH and HEIGHT), you should get 10m resolution.
In terms of “smoothing” - there are various down- and up-sampling methods possible, NEAREST (nearest neighbor), BICUBIC, BILINEAR. You can check, which one is applied in Advanced parameters for the layer (default is NEAREST).

Generally though there are no changes in the value applied, except of those configured for each individual layer.

To dive a bit deeper in your problem, we would need to get some actual examples, including:
-request URLs (you can mask instance ID except for first few chars)
-your observation on value differences

Hello,
basically I compare output of SentinelHUB browser (EVI in custom script + manually download button) with scirpt and values are not same. In both cases I am using INDEX values, not visualisations and I am tring with both products L1C and L2A.
FAQ brings clarity. I understand it that (32-bit float) should be clamped to 0-1 values, however I find minus values in both outputs. (?)

Second, when I open output in QGIS, pixel size of both downloads is different. Browser download seems to be 6.5 m? How it is possible?

Index values for L1C are considerably lower when using utility instance with the use of full ATMCOR.

Instance url is: https://services.sentinel-hub.com/configuration/v1/wms/instances/c730e265-5fc2-xxxxxxxx

Do you have idea where I am doing mistake?

Hi,

can you please provide full request URLs, so that we can see, what is actually happening? Not just the instance (this one is OK, including the masked part), but actual requests, which you use to download the data.
And please do share with us the outputs, e.g. GeoTiffs, so that we can analyse these as well.

One note - ATMCOR is not the same as L2A. Check:
https://www.sentinel-hub.com/faq/what-kind-atmospheric-correction-available
https://www.sentinel-hub.com/faq/what-difference-between-atmospheric-correction-filter-and-l2a-data-source

Hi,

here is full req:
’https://services.sentinel-hub.com/ogc/wcs/c730e265-5fc2-xxxx?SERVICE=wcs&BBOX=50.0868%2C14.3775%2C50.1208%2C14.4701&FORMAT=image%2Ftiff%3Bdepth%3D32f&CRS=EPSG%3A4326&VERSION=1.3.0&RESX=10m&RESY=10m&COVERAGE=EVI-L1C&REQUEST=GetCoverage&TIME=2018-08-17T10%3A10%3A24%2F2018-08-17T10%3A10%3A24&MAXCC=10.0&AtmFilter=ATMCOR&Transparent=False&ShowLogo=False’

and I attache 4 files (wcs download of L1C with NONE and ATMCOR corrections, L1C and L2A download from SentinelHUB browser).

Question/uncertanities are:

• wcs downloads are spatially a bit shifted/squized - compared to browser downloads (this are correctly placed). Is there some mistake in EPSG transformation? Is it possible to work with transformation using sentinelhub-py?
• resolution of browser downloads is better (some kind of downscaling is used?) How can I achieve same results with automated download?
• values with ATMCOR are considerably lower than with NONE, thus more diverse from L2A. I had expected it other way round - L1C corrected to be closer to L2A than non-corrected. Is it wrong assumption or I have mistake in processing chain?

Thank for having a look 🙂

examples are here:
https://drive.google.com/drive/folders/1gS6iwQXTNOXZxIoyWaPBfH1CgvKAO9e-?usp=sharing

Q: wcs downloads are spatially a bit shifted/squized - compared to browser downloads (this are correctly placed). Is there some mistake in EPSG transformation? Is it possible to work with transformation using sentinelhub-py?

A: Some distortion should be expected anytime reprojection is done. Original data are stored in UTM projection and if you want to avoid any error, you should use this one. What probably happens in your case is that you export in EPSG:4326 (via WCS) and then you look at this in QGIS with EPSG:3857 setting, so reprojection is happening twice, therefore errors are so much more visible.

We are pretty certain that there is no (additional) mistake done in a reprojection, with the exception of normal inaccuracy of the reprojection (as mentioned).
However, we will check once again on this specific example, just to be sure.
If you want to use EPSG:3857 in WCS, this should be easily done. You simply change the
CRS=EPSG:4326
to
CRS=EPSG:3857
and also pass BBOX parameters in EPSG:3857
(I am not certain, where this is done in sentinelhub-py, but it should not be too difficult).
As mentioned above, if you want to have best quality of the results, you should use UTM projection.

Q: resolution of browser downloads is better (some kind of downscaling is used?) How can I achieve same results with automated download?

A: I am not sure, which setting you have used in EO Browser, but EO Browser is using the same WCS as you are using from sentinelhub-py, so you should be able to get exactly the same results.
If you want to get “better” resolution, set e.g. RESX=5m&RESY=5m&DOWNSCALING=BICUBIC
That being said, be aware that Sentinel-2 data are in 10m resolution (in UTM projection), so any rescaling will produce artificially “better” results.

Q: values with ATMCOR are considerably lower than with NONE, thus more diverse from L2A. I had expected it other way round - L1C corrected to be closer to L2A than non-corrected. Is it wrong assumption or I have mistake in processing chain?

A: When using ATMFILTER=ATMCOR, you are using our “statistical” atmospheric correction (see the FAQ mentioned above), which is not as accurate/detailed as “official” L2A.
Now as the L2A is available globally, we certainly recommend using L2A data source (make sure you do not use any ATMFILTER on L2A data)

We are pretty certain that there is no (additional) mistake done in a reprojection, with the exception of normal inaccuracy of the reprojection (as mentioned).
However, we will check once again on this specific example, just to be sure.

Our engineers checked this and their take is:
The results in both cases look OK. The difference is primarily the handling of the output resolution/pixel size. WCS with the resolution set to 10m targets 10m in UTM, and the pixel size for this is correct.
The EOBrowser WGS84 pixel size actually uses 10m in webmercator (for consistency of the user experience). This gives a notably larger image.

The “shifts” when comparing both results are caused by nearest-neighbor interpolation. Since the WCS resolution is about equal to the native pixel size it creates these “jumps”.