Optional gamma correction parameter

[biserhong]

This PR adds gamma correction functionality to the /singleband and /rgb endpoints. It is requested by adding an optional gamma_factor parameter.

An important observation about enabling this functionality is that the exponential function preserves the relative percentile ranges in the [0, 1] interval. So the computed percentiles in the metadata can be carried through after gamma correcting a tile.

[dionhaefner]

Thanks for the implementation. Can you say a bit more about the use case for this? Any reason why this can't be done offline (during preprocessing) or using /compute?

[biserhong]

Thanks for the implementation. Can you say a bit more about the use case for this? Any reason why this can't be done offline (during preprocessing) or using /compute?

We use terracotta to display images customers purchase at SkyFi. For true colour 3-band composites, rendering the data linearly does not provide a representation that is similar to what the human eye would perceive. Applying a gamma correction between 1.6 and 2.2, on an otherwise linear colour space makes for something that is a lot closer to a “natural colour composite”. We also want the preview on the map to be as close as possible to the png previews we send customers along with the raster, to which gamma correction is applied.

Regarding the option of doing it offline, we would like to offer users the ability to adjust min/max and gamma factor on the fly. The /compute endpoint also only outputs a single band image and cannot use the precomputed metadata for color stretching.

I also think gamma correction would be a good addition to the capabilities of terracotta since it’s a standard and common processing technique, and its implementation doesn’t really affect any other functionality.

[vincentsarago]

FYI in rio-tiler/titiler we use https://github.com/vincentsarago/color-operations (fork of mapbox/rio-color), Just sharing if you want to support more color operations in the future ;-)

https://github.com/cogeotiff/rio-tiler/blob/dd5ce03f8f463ec93f3a8787d7155d318397cd7c/rio_tiler/models.py#L524-L536

[dionhaefner]

Thanks @vincentsarago! I like this a lot, and a feature like this has been on the roadmap for a long time: #23.

I'd strongly prefer an implementation that doesn't assume a specific color transformation like gamma, and instead implements support for a range of transforms (like the ones provided via color-operations / rio-color). @biserhong do you think that would be feasible?