Since recently we noticed that this request returns 8-bit images instead of the expected Floats. Did something change, seems like a bug? Used to work correctly.
wcs_ndwi_request = WcsRequest(data_source=DataSource.SENTINEL2_L1C,
layer=layer_name,
bbox=bbox,
time=(acq_start, acq_end),
resx=‘10m’,
resy=‘10m’,
maxcc=cc,
image_format=MimeType.TIFF_d32f,
instance_id=instance_id,
data_folder=download_dir)
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?
(cc: @iovsn @maleksandrov)
sentinelhub version = 2.6.1
Hi @Tech,
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 [B04];
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 =).]
We have concluded the analysis and can report some more information about this issue:
We would also strongly recommend to read our post on migration of scripts to EVALSCRIPT V3.