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
