sentinel-hub/sentinelhub-py

Each pixel value of the Sentinel-2 image tiles clipped by SentinelHub is 1000 less than the original Sentinel-2 pixel values

geoexploring opened this issue · 4 comments

The main specific information, as shown in the Sentinel Hub subforum Each pixel value of the Sentinel-2 image tiles clipped by SentinelHub is 1000 less than the original Sentinel-2 pixel values.

Additionally, I found that changing the sampleType from INT16 to UINT16 does not affect pixel values.

However, when I attempted to crop Sentinel-2 True Color Image (TCI) data based on the ROI (specific evalscript information below), the resulting image had pixel values all set to 255. Changing sampleType to UINT16 produced correct output. This indicates that SentinelHubRequest does not correctly crop TCI images when the sampleType is UINT8, resulting in abnormal pixel values (all 255).

    # API query
    evalscript_tci_bands = """
    //VERSION=3
    function setup() {
        return {
            input: [{
                bands: ["B02","B03","B04"],
                units: "DN"
            }],
            output: {
                bands: 3,
                sampleType: "UINT8"
            }
        };
    }

    function evaluatePixel(sample) {
        return [sample.B04,
                sample.B03,
                sample.B02];
        }
    """

    # requesting from Process API
    request_all_bands = SentinelHubRequest(
        data_folder=dest_folder,
        evalscript=evalscript_tci_bands,
        input_data=[SentinelHubRequest.input_data(data_collection=DataCollection.SENTINEL2_L1C,
                                                    time_interval=(capture_date, capture_date),
                                                    mosaicking_order=MosaickingOrder.LEAST_CC,
                                                    )
                    ],
        responses=[SentinelHubRequest.output_response("default", MimeType.TIFF)],
        bbox=capture_bbox,
        size=capture_size,
        config=config,
        )

How can this issue be resolved? Thanks

Hi @geoexploring!

I believe what you're describing is expected. You request DN values, which are INT16 from cca 0 - 10k. But they you set the output type to UINT8 while keeping the values as they are (you don't rescale them), so SH clips them to the output dtype range, so it makes sense all are 255 because they are saturated.

If you set the output type to (U)INT16, then the values are in the right range and you get what you expect.

So perhaps the issue is in what you believe the sampleType does. This does a piece of code which is used by SH to scale the output, but is a piece of information provided by you so that SH knows what it's returning, because you as the user have control over what is being returned by the evalscript.

I hope that makes sense.

Cheers!
Matic

@mlubej , thank you for your prompt reply and accurate explanation!

I actually want to directly crop the Sentinel-2 TCI image, and it may be necessary to specify TCI explicitly in the evalscript_tci_bands. Let’s not consider this issue for now.

What concerns me most is that the pixel values of the SH cropped result differ by 1000 from the original Sentinel-2 L1C values. The detailed analysis is available in the Sentinel Hub subforum Each pixel value of the Sentinel-2 image tiles clipped by SentinelHub is 1000 less than the original Sentinel-2 pixel values. Is this an issue, or is my understanding incorrect?

Thanks

Hi @geoexploring,

What concerns me most is that the pixel values of the SH cropped result differ by 1000 from the original Sentinel-2 L1C values. The detailed analysis is available in the Sentinel Hub subforum

I wanted to keep the focus on the issue mentioned in the ticket body, as the issue that concerns you most is already addressed in the SH Forum, so let's continue the discussion related to this there, because it's not so clear what the issue could be.

Do you want to discuss the other minor issues here or can we close the ticket and focus on the topic mentioned in the Forum?

Cheers,
Matic

@mlubej , thanks. I have closed this issue.