<div dir="ltr"><div>Hi</div><div><br></div><div>Independently of the convenience of making a new driver or adding it to gdaldem, I am curious about the initial question:</div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Perhaps the same thing could also be achieved using the
raster calculator (gdal_calc), but that seems far from trivial for most
users.<br></pre>Is it easy to use a formula to read it? Via a virtual file? Or the new CLI commands?</div><div><br></div><div>Thanks.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 8 Jan 2026 at 11:05, Lars Ahlzen via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Good points.</p>
<p>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.</p>
<p>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?</p>
<p>If the latter, could the existing MBTiles driver be used for
direct DEM -> RGB tiles (.png/.webp/...) -> .mbtiles
generation?</p>
<p>- Lars</p>
<div>On 06/01/2026 08:40, Andrey VI wrote:<br>
</div>
<blockquote type="cite">
<div>
<div>Hi all.<br>
<br>
<span lang="en"><span><span>It would be great to have RGB DEM
support in GDAL.</span></span></span></div>
<div> </div>
<div><span lang="en"><span><span>Some considerations.</span></span></span></div>
<div><span lang="en"><span><span>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.</span></span></span></div>
<div> </div>
<div>2. <span lang="en"><span><span>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].</span></span> <span><span>In my opinion, the WEBP
format is preferable.</span></span> <span><span>For
example, Maptiler uses it for Terrain RGB and Ocean RGB
datasets [6].</span></span></span></div>
<div> </div>
<div><span lang="en"><span><span>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).</span></span></span></div>
<div> </div>
<div> </div>
<div>[1] <a href="https://www.mapzen.com/blog/terrain-tile-service/" target="_blank">https://www.mapzen.com/blog/terrain-tile-service/</a></div>
<div>[2] <a href="https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium" target="_blank">https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium</a></div>
<div>[3] <a href="https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding" target="_blank">https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding</a></div>
<div>[4] <a href="https://maplibre.org/maplibre-style-spec/sources/#encoding_1" target="_blank">https://maplibre.org/maplibre-style-spec/sources/#encoding_1</a></div>
<div>[5] <a href="https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86" target="_blank">https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86</a></div>
<div>[6] <a href="https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0" target="_blank">https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/</a></div>
<div> </div>
<div>
<blockquote style="border-left:1px solid rgb(8,87,166);margin:10px;padding:0px 0px 0px 10px"><span>Tuesday,
January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via
gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>>:</span><br>
<div>
<div id="m_6027539952494478488">
<div>
<div>
<div id="m_6027539952494478488style_17676496140889361257_mr_css_attr">
<div id="m_6027539952494478488style_17676496140889361257_BODY_mr_css_attr">On
05/01/2026 19:47, rayg wrote:<br>
> Strange encoding, -10000 meters isn't deep
enough for the Marianas<br>
> Trench. You could borrow another 10 km from
the 1.6 million meters<br>
> still available on the positive side.<br>
><br>
> Scaling by 0.1 also means a 10 cm vertical
resolution., which is<br>
> useless for some use cases. The 24 bits per
pixel could be much better<br>
> allocated.<br>
<br>
I kind of agree with both points, but I guess
the format is what it is.<br>
<br>
I don't think it's supposed to be a
general-purpose storage format. It's<br>
encoding just enough data to do good enough
real-time visualization of<br>
elevation, like hillshading or hypsometric
tints, client side.<br>
<br>
Looks like at least rio-rgbify [1] allows
setting a custom base value<br>
and interval. That might be something we want to
emulate as well,<br>
perhaps as creation options (if a raster format
driver) or command line<br>
options (if part of gdaldem).<br>
<br>
- Lars<br>
<br>
[1] <a href="https://github.com/mapbox/rio-rgbify" target="_blank">https://github.com/mapbox/rio-rgbify</a><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<div>--<br>
Andrey</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>