Error adding mask as alpha channel

[cogeotiff]

Error adding mask as alpha channel

[vincentsarago]

👋 @a2hill sorry for this bug
I don't see a fix directly to the array_to_image function but to me it seems you could pass indexes=(1,2,3) to the main.tile function and then the mask return should be the alpha band.

Handling nodata/mask/alpha band is a tricky thing (I've worked on the matter all the week), maybe utils.tile_read could remove the alpha band from the data array directly ?

Edits:

buffer = utils.array_to_image(tile, mask=mask, img_format="webp", color_map=None, **options)

Here you are also passing the mask to the function, but the alpha band is already provided with your data, so you have two solution:

• uses indexes=(1,2,3)
• don't pass mask to the utils.array_to_image function

[a2hill]

@vincentsarago Yes we implemented additional check's for 4 band images and handle them differently. I think the older version of array_to_img used a has_alpha check, was that specific to PIL support?

[vincentsarago]

@a2hill where you able to have your code fixed ?
I'm going to close this issue, but feel free to re-open if you have more questions.

Note: I've added a note in #63 to add more documentation about nodata/alpha handling.

[vincentsarago]

@a2hill I'll need to check but maybe this

rio-tiler/rio_tiler/utils.py

Line 537 in 9aa45d6

img = Image.fromarray(arr, mode=mode)

was taking care of it because it forced the data to be 3bands.

I'm kinda happy/not happy about the situation but I do believe that using the new gdal based function let's the user do more thing (e.g enable to save GeoTIFF). But maybe we still could add a test for data that have more than 3 bands and not saved as 'GTiff'.

[a2hill]

I agree, I like the new gdal based image function as well. I think it is going to be a lot more helpful with single band images as well. Previously I was having to do linear scaling to convert my dem's from float to uint8 but it looks like I no longer will need to do that with the gdal based function? Thanks for the hard work!

[vincentsarago]

@a2hill well I think GDAL will throw an error if your data is not in uint8, before we had a test to cast the data to uint8 but again we removed it to let the user decide in their own implementation (mostly to support other format).

[a2hill]

Ah okay nevermind then! Related but kind of off topic, are you planning support to allow color_map files which use the GDAL color configuration syntax?

[vincentsarago]

@a2hill when I started working on the new function I tried to use the internal gdal method (https://github.com/mapbox/rasterio/blob/master/docs/topics/color.rst#writing-colormaps) but I couldn't get it to work (If I remember well my problem was that I had to first write the file to the disk before being able to see the colormap applied data.

I could have a second look later, but if you ever want to start a PR to update array_to_image or add a new function, please feel free.

Also I'm also happy to see how people use rio-tiler 😄

[a2hill]

@vincentsarago Thanks for pointing that out. I may have a look at that as I am currently looking into integrating support for colorbrewer2 palettes via palettable for DEM's. If I find a better way to apply the color maps I'll be sure to submit a PR.