[gdal-dev] Support for Terrain-RGB

[Lars Ahlzen]

I think either "rgb-dem" or "encode-rgb" could work. While not strictly 
limited to RGB or DEMs, at least that's their typical and intended use.

Sounds like a raster driver, rather than a new raster DEM mode, would be 
advantageous. I imagine creation options might include:

- OFFSET (or BASE, as known in the terrain-RGB spec)
Defaults to -10000

- SCALE (or maybe STEP, to not to confuse it with any required scaling 
of the input?)
Defaults to 0.1

- DRIVER
Raster driver to output encoded image, e.g. PNG, WEBP, GTiff. Inferred 
from the output extension if omitted.

- BANDS
Order of raster bands to encode values into, most significant first. 
E.g. "RGB", "RGBA", "BGR", "RG".
Defaults to "RGB". If A is not included in the bands, the A channel can 
be used for alpha.

For ease of use, perhaps an ENCODING option (or similar) could provide 
preset values for the above, such as:

--co ENCODING=TERRAIN_RGB
would be equivalent to
--co OFFSET=-1000 --co SCALE=0.1 --co BANDS=RGB

-co ENCODING=TERRARIUM
would be equivalent to
--co OFFSET=-32768 --co SCALE=0.00390625 --co BANDS=RGB

This driver would allow things like:

  gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co ENCODING=TERRARIUM

  gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co ENCODING=TERRAIN_RGB

  gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co BANDS=RGB --co OFFSET=-10000 --co SCALE=0.1

  gdal raster convert dem.tif rgb.png --of encode-rgb --co DRIVER=PNG 
--co BANDS=BG --co OFFSET=-1000 --co SCALE=1

  gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
DRIVER=PNG --co ENCODING=TERRARIUM dem.tif rgb-tiles/

  gdal raster tile --min-zoom 5 --max-zoom 15 --format ENCODE_RGB --co 
DRIVER=WEBP --co LOSSLESS=YES --co BANDS=RGB --co OFFSET=-10000 --co 
SCALE=0.1 dem.tif rgb-tiles/

Certain creation options, like LOSSLESS=YES in the last example, may 
need to be passed on from the ENCODE_RGB driver to the actual output 
driver. Is that possible in general, or would it have to be handled as 
special cases for different formats?

- Lars

On 09/01/2026 07:02, Andrey VI via gdal-dev wrote:
> Why not just "rgb-dem", i.e. "RGB encoded DEM"?
>
>     Friday, January 9, 2026 3:16 AM +03:00 from rayg via gdal-dev
>     <gdal-dev at lists.osgeo.org>:
>     Maybe call it "scalar-rgb"? Because ultimately what the encoding
>     does is use the color channels to hold a single value. It doesn't
>     even have to be for elevations at all.
>     Could also add swizzle options in case BGR or some other order is
>     used. And include the alpha channel just in case, but also let
>     alpha be alpha if needed. If e.g. "A" is left off from the swizzle
>     option, then it's an actual alpha channel.
>     More general would be scalar encoding of any multichannel
>     (multiband) file, e.g. YCbCr, HSV, CMYK, etc.
>     Ray
>
>
>     On Thu, 8 Jan 2026 at 1:13 PM Even wrote:
>
>         >
>         > There's nothing especially terrain (or topography) about this afaics, 
>         > and utility seems like the right approach rather than creating a 
>         > format variant.
>
>         Actually Frédéric's intersting remark abou potential usage with "gdal
>         raster tile" would actually make the driver approach a better
>         choice....   unless we would extend "gdal raster tile" to accept a
>         pipeline to go to create a final tile from a 'raw' one, like 'gdal
>         raster tile --tile-pipeline="read ! encode-rgb --offset=-10000 ! write
>         --of PNG" --extension png  in.tif out_directory' .
>
>         But a ENCODE_RGB driver approach is more simple than implementing that.
>
>         Even
>
>         -- 
>         http://www.spatialys.com
>         My software is free, but my time generally not.
>
>         _______________________________________________
>         gdal-dev mailing list
>         gdal-dev at lists.osgeo.org
>         https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
> Andrey
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260112/de48c186/attachment-0001.htm>