[gdal-dev] gdaldem color-relief -exact_color_entry results in RGB 000

Tue May 18 08:47:10 PDT 2021

A guess; the tiff is actually stored as 32 bit float so the values have decimals, and thus don’t exactly match the colour table. Maybe the Qgis layer is set to report without decimals?

Hmm, maybe not. Something similar was reported in GIS stack a few years ago:
https://gis.stackexchange.com/questions/197660/gdaldem-exact-color-matching-fails

Matt
Geomatics Analyst | Environment | T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.

From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of paul.malm at lfv.se
Sent: May 17, 2021 12:24 AM
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] gdaldem color-relief -exact_color_entry results in RGB 000

*** External email: Do not click on links or attachments except from trusted senders. ***

******************************************************************************************

Hi list, I’ve tried to use exact_color_entry on a DEM-tif file.
gdaldem color-relief 55.tif colornr.cpt 55_colrel.tif -of GTiff -exact_color_entry -co COMPRESS=LZW -b 1
Resulting in a blank rastefile (0 0 0).
I’ve picked (info) the colors in QGIS and there are a lot of pixels in the span of the color table below and QGis is presenting the values as integers.

It works fine with Nearest_color_entry.
Any ideas?
Kind regards,
Paul

colornr.cpt looks like this:
40 0 255 255
41 0 255 255
43 255 255 0
44 0 255 255
45 255 0 0
46 255 255 0
47 0 255 255
48 255 0 0
49 255 255 0
50 0 255 0
51 0 0 255
52 0 0 255
53 0 0 255
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210518/b1931fcb/attachment.html>