Process API - TIFF transparency

I’m trying to produce GeoTIFFs using the Process API
Here is my request

    "input": { "bounds": { "bbox": [ 23.29236, 43.51969, 23.40291, 43.62068]},
        "data": [{
            "type": "S2L1C",
            "dataFilter": { 
                "timeRange": {"from": "2021-01-01T00:00:00Z", "to": "2021-02-10T23:59:59Z" }
    "output": {
        "width": 892.3812847931883,
        "height": 1124.2155375213686,
        "responses": [{ "identifier": "default", "format": { "type": "image/tiff" } }]
    "evalscript": "//VERSION=3\n\n
        function setup() {\n  
            return {\n    
            input: [{ bands: [\"B02\", \"B03\", \"B04\", \"dataMask\"] }],\n    
            output: { bands: 4 }\n  };\n
        function evaluatePixel(sample) {\n  
            return [sample.B04, sample.B03, sample.B02, sample.dataMask];\n

I’m getting the next TIFF displayed in QGIS

for which gdalinfo reports next:

Band 1 Block=864x8 Type=Byte, ColorInterp=Gray
Band 2 Block=864x8 Type=Byte, ColorInterp=Undefined
Band 3 Block=864x8 Type=Byte, ColorInterp=Undefined
Band 4 Block=864x8 Type=Byte, ColorInterp=Undefined

with the next warning:

TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.

Question - is this an expected behaviour?



gdal_translate in.tiff out.tif -b 1 -b 2 -b 3 -b 4

solves the issue - gdalinfo doesn’t report any warnings, the bands look like:

Band 1 Block=864x2 Type=Byte, ColorInterp=Red
Band 2 Block=864x2 Type=Byte, ColorInterp=Green
Band 3 Block=864x2 Type=Byte, ColorInterp=Blue
Band 4 Block=864x2 Type=Byte, ColorInterp=Alpha

I am not sure if you managed to solve the problem or not.

As far as I know, tiff does by default not support transparency. The request you have used, creates a 4-th band, which shows the data mask. And you can then configure the visualization in a way that uses this 4th band (data mask) as an alpha channel for rest of the bands. I imagine this is what you did in the second step.

Sentinel Hub does not really work with transparency, it simply produces the band outputs based on the “recipe” you provide. How these data are then used further on, is up to the user. With PNG there is a bit of a “hack” as there is a “rule” that 4th band in PNG defines the alpha channel. Therefore, if you want to integrate the API in a web-application, you can use PNG and it will work “out of the box”.

I wouldn’t call it a solution, but a workaround - I had to apply an additional step calling gdal_translate to “fix” downloaded raster.

I believe producing transparent TIFFs is a common task among people working with TIFFs, just like specifying GDAL’s nodataValue
It would be nice to see TIFFs with proper “ColorInterp” flags assigned. If we have a “hack” for PNG, why wouldn’t we have a properly tagged TIFFs?

Well, with PNG you are simply outputting 4-bands into a 3+1 band format and it auto-magically works, because this is how PNG is set.
There is nothing similar for GeoTiff. Also, people commonly create 1-band, 3-band, 4-band (RGB+NIR), 50-band TIFFs. Transparent TIFF is just one of many options.
We will certainly consider this idea, but cannot promise, when it would be added. It also depends on the demand from the rest of the users.