cogeo create and erroneous values for certain 16bit datasets

I’m opening this to document my findings, I’m not sure it’s even a problem with rio-cogeo per-se, it seems to go down all the way to rasterio (1.1.0) and perhaps GDAL (2.4.3).

Input (5 bands + alpha 16bit GeoTIFF): odm_orthophoto.zip

Band 1 Block=512x512 Type=UInt16, ColorInterp=Red
Band 2 Block=512x512 Type=UInt16, ColorInterp=Green
Band 3 Block=512x512 Type=UInt16, ColorInterp=Blue
Band 4 Block=512x512 Type=UInt16, ColorInterp=Gray
Band 5 Block=512x512 Type=UInt16, ColorInterp=Gray
Band 6 Block=512x512 Type=UInt16, ColorInterp=Alpha

Command:

rio cogeo create odm_orthophoto.tif out.tif

Output:

Band 1 Block=512x512 Type=UInt16, ColorInterp=Gray  Overviews: 1000x845, 500x423
Band 2 Block=512x512 Type=UInt16, ColorInterp=Undefined  Overviews: 1000x845, 500x423
Band 3 Block=512x512 Type=UInt16, ColorInterp=Undefined  Overviews: 1000x845, 500x423
Band 4 Block=512x512 Type=UInt16, ColorInterp=Undefined  Overviews: 1000x845, 500x423
Band 5 Block=512x512 Type=UInt16, ColorInterp=Undefined  Overviews: 1000x845, 500x423
Band 6 Block=512x512 Type=UInt16, ColorInterp=Undefined  Overviews: 1000x845, 500x423

Raster values seem to have been downscaled (?) or overflowed (?) in the process:

Alpha band is out of whack too, but I won’t worry about that for now.

I’ve narrowed this down to https://github.com/cogeotiff/rio-cogeo/blob/master/rio_cogeo/cogeo.py#L210. Once the WarpedVRT object is created, read operations on the virtual raster return erroneous values (they seem scaled down, eg. 24933 --> 97, which seems linear from 65535 to 255, but other values are still in the 65535 range, so it makes little sense). The data types are correct, although we’ve lost ColorInterp information (perhaps another problem).

This might be a problem with rasterio, or even GDAL? If I find a solution I will open a PR.

[vincentsarago]

you should use nodata instead of alpha when creating the file. Setting nodata value to 0 might have unexpected results when user provide an alpha band so I guess we should try to pursue this into GDAL/Rasterio to have a proper fix there

[vincentsarago]

thanks @pierotofy this is an interesting finding and yes might be a rasterio one, I’ll have a look!