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 <[email protected]> On Behalf Of [email protected]
Sent: May 17, 2021 12:24 AM
To: [email protected]
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
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to