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
<[email protected]>:
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Andrey
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
