Hm, this is strange.

Can you provide more information?

Which instance ID you are using (first 3 blocks will be sufficient)

When did you notice this?

d026c463-d9fa-430d-a56a-MASKED

I checked the logs on our side and I see that the data coming back is float32…
Might it be that the Python package converts this into 8-bit? Which version are you using?
 

sentinelhub version = 2.6.1

Hi,
I think I have identified the issue and hopefully implemented a work-around on NDWI layer of this instance.
Can you please try on your side as well?

I have also asked our engineers to check, what is the root cause of this.

Sorry for the inconvenience.

NDWI works now, Txs!

Hi! I am encountering this same issue, I believe it started sometime between April 10-15 but I just now noticed. I too am using sentinelhub-py, I tried both version 2.6.1 and version 3.0.2 and the same thing happened. Instance ID e847e6a9-c4cf-44ec-9524-************, haven’t checked whether the problem happens for all the layers but it definitely happens for layer B04.

The issue seems to be connected to //VERSION=3 EVALSCRIPTs in a combination with WCS request.

We are looking into what has caused this issue and will come back with the findings and, hopefully, a solution very soon.

The workaround is pretty simple - convert the EVALSCRIPT back to the “simple” one.

E.g. use this in the Configuration utility:

return uB04];

Okay, thank you! That seems to work.

I hadn’t explicitly written the EVALSCRIPT, I just selected “reflectance” from the “visualization options” and it filled in some Javascript functions. Why doesn’t it just use the “simple” one to begin with?

VERSION=3 scripts have been designed to allow users to define very precisely, what they want/need.

Simple scripts leave it to our system to “auto-magically” figure it out, whether you want reflectance or DN or… With most of our users wanting to have full control over how the data is processed, simple approach was no longer good enough.

So… we have recently converted all the past scripts of our default products to VERSION=3 as a first step of the progression to the “better world” (note that the users’ scripts were left as they were). We have tested significantly for backward compatibility, but it seems some cases slipped…

It is impossible to avoid some errors when improving the service, but we certainly hope this has not caused too much of inconvenience.

Ah, okay. Well thank you for working on the improvements!

I see on the website that there is a newsletter, is that what I should sign up for to hear about when changes like this are planned to happen? [EDIT: I found the announcement in the archived April newsletter .]

Yes indeed, newsletter is usually summarising all important notices. Here on how to subscribe.

We have concluded the analysis and can report some more information about this issue:

While working on the upgrade of our system, we have made a premature upgrade, which might have impacted you. We are sincerely sorry about that.
With this notice, we would like to transparently explain what happened, what impacts it might have had, and how to fix any remaining issues.
What happened?
As part of the migration to evalscript version 3, we have converted old versions of evalscripts used in our data products to evalscripts version 3.
While the conversion itself was throughout tested…

We would also strongly recommend to read our post on migration of scripts to EVALSCRIPT V3.

Why we’re doing it (reasons and benefits)
Currently we have four different types of scripts. Simple, V1, V2, V3. It is confusing, hard to maintain, and for older scripts limits available features. V3 scripts do everything the previous versions can and add numerous useful functionalities. These include dataMask, units, data fusion, mosaicking selection ability, precisely defining the output, etc. After the change only V3 and simple scripts will remain; we are keeping simple scripts for the reason…