Process API - TIFF transparency

Hello

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

        }\n\n

        function evaluatePixel(sample) {\n  

            return nsample.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?

Page 1 / 1

Clarification

Running

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

  Mask Flags: PER_DATASET ALPHA

Band 2 Block=864x2 Type=Byte, ColorInterp=Green

  Mask Flags: PER_DATASET ALPHA

Band 3 Block=864x2 Type=Byte, ColorInterp=Blue

  Mask Flags: PER_DATASET ALPHA

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.

Hello,

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

while reading 14-band tiff files downloaded by executing get_data(save=True) method for sentinelhub.WcsRequest object. The ColorInterp is undefined for each band except for the 1st one which is Gray. I suppose that is the reason of the warning.

Is it possible to change the colorInterp during downloading/saving data to disk?