Hi Javier,

For me VRT with pixel functions  
https://gdal.org/en/stable/drivers/raster/vrt.html#derived-bands-pixel-functions
 feels somehow natural. Now just waiting for someone to show a working example.

Reading the RGB encoded values back to meaningful values would require also 
metadata about the applied formula if people are willing to use several 
different/arbitrary  encoding schemas.

-Jukka Rahkonen-

________________________________________
Lähettäjä: gdal-dev <[email protected]> käyttäjän Javier Jimenez 
Shaw via gdal-dev <[email protected]> puolesta
Lähetetty: Torstai 8. tammikuuta 2026 12.20
Vastaanottaja: Lars Ahlzen <[email protected]>
Kopio: gdal-dev <[email protected]>
Aihe: Re: [gdal-dev] Support for Terrain-RGB

HiIndependently of the convenience of making a new driver or adding it to 
gdaldem, I am curious about the initial question:Perhaps the same thing could 
also be achieved using the 
raster calculator (gdal_calc), but that seems far from trivial for most 
users.Is it easy to use a formula to read it? Via a virtual file? Or the new 
CLI commands?Thanks.On Thu, 8 Jan 2026 at 11:05, Lars Ahlzen via gdal-dev 
<[email protected]> wrote:Good points.Given these and other comments, it 
sounds to me like we should support different RGB raster formats, as the 
storage format really is independent from the encoding. Also, supporting Mapbox 
Terrain RGB, Terrarium RGB, and custom encodings would be desirable. I believe 
these are all variants of the same thing anyway, with a base (offset) and a 
scale for each of the R, G and B channels.Even, you probably know GDAL 
internals quite well, what are your thoughts? If we were to support arbitrary 
RGB raster formats, would an implementation elsewhere (like gdaldem) be more 
suitable than a new raster driver, or could a raster driver support different 
actual file formats?If the latter, could the existing MBTiles driver be used 
for direct DEM -> RGB tiles (.png/.webp/...) -> .mbtiles generation?- LarsOn 
06/01/2026 08:40, Andrey VI wrote:Hi all.It would be great to have RGB DEM 
support in GDAL. Some considerations.1. It makes sense to add support not only 
for Mapbox Terrain RGB, but also for Mapzen Terrarium RGB [1][2] encoding. 
Mapbox and Maplibre support both encodings, the latter also supports custom 
encoding [3][4]. Therefore, support for custom encoding will also be useful. 2. 
I don't quite understand why only PNG format is being discussed here. It is 
possible to encode a DEM into any raster RGB image format. Moreover, PNG isn't 
the most optimal of them [5]. In my opinion, the WEBP format is preferable. For 
example, Maptiler uses it for Terrain RGB and Ocean RGB datasets [6]. 3. 
Ideally, the output should be not just an encoded image, but tiles ready for 
use in Mapbox/Maplibre/etc., including in the form of data sets (MBTiles, 
PMTiles).  [1] https://www.mapzen.com/blog/terrain-tile-service/[2] 
https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium[3] 
https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding[4] 
https://maplibre.org/maplibre-style-spec/sources/#encoding_1[5] 
https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86[6]
 https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/ Tuesday, 
January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via gdal-dev 
<[email protected]>:  On 05/01/2026 19:47, rayg wrote:> Strange 
encoding, -10000 meters isn't deep enough for the Marianas> Trench. You could 
borrow another 10 km from the 1.6 million meters> still available on the 
positive side.>> Scaling by 0.1 also means a 10 cm vertical resolution., which 
is> useless for some use cases. The 24 bits per pixel could be much better> 
allocated.I kind of agree with both points, but I guess the format is what it 
is.I don't think it's supposed to be a general-purpose storage format. 
It'sencoding just enough data to do good enough real-time visualization 
ofelevation, like hillshading or hypsometric tints, client side.Looks like at 
least rio-rgbify [1] allows setting a custom base valueand interval. That might 
be something we want to emulate as well,perhaps as creation options (if a 
raster format driver) or command lineoptions (if part of gdaldem).- Lars[1] 
https://github.com/mapbox/rio-rgbify_______________________________________________gdal-dev
 mailing 
[email protected]https://lists.osgeo.org/mailman/listinfo/gdal-dev--Andrey_______________________________________________gdal-dev
 mailing 
[email protected]https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to