<div dir="ltr">Hi,<div>in the case of the driver solution, it could be used with gdal2tiles which is probably the next step of a RGB Terrain conversion.</div><div>Regards,</div><div>Fred.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le jeu. 8 janv. 2026 à 14:56, Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> a écrit :<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>Hum, if there are different underlying formats, then the
situation is not all that clear to me.</p>
<p>Both options would be reasonable</p>
<p>- as a driver:</p>
<p>gdal raster convert dem.tif rgbterrain.png --of terrainrgb --co
OFFSET=-10000 --co SCALE=0.1 [--co DRIVER=PNG]</p>
<p>- or a gdal CLI command:</p>
<p>gdal raster terrainrgb dem.tif rgbterrain.png --offset=-10000
--scale=0.1 [--driver PNG]</p>
<p>Perhaps the latter is slightly preferable ? I've some doubts
about the naming of the command though. There is a risk that "terrainrgb"
would make users believe it does what "gdal raster color-map
--color-map" does, that is create an hypsometric rendering of a
DEM. "encode-as-rgb" maybe ?</p>
<div>Le 08/01/2026 à 11:05, Lars Ahlzen a
écrit :<br>
</div>
<blockquote type="cite">
<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><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_-4881484238269565135">
<div>
<div>
<div id="m_-4881484238269565135style_17676496140889361257_mr_css_attr">
<div id="m_-4881484238269565135style_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>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</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>