I'm using gdaldem color-relief to read a Uint32 raster and write an RGB tif. The input color_text_file has one line:

102216130 23:105:102

My input file is a single (large) pixel of value 102216130, matching the one line in the color text file.

If I run gdaldem with the -exact_color_entry flag, the output is a pixel with RGB 0 0 0. If I run it without the flag, the output is correct, a pixel with 23 105 102.

Why is this? It certainly doesn't matter for this raster (-exact_color_entry appears to be unnecessary), but for rasters with more lookup values in the color text file (700, in one case), the general case (i.e. not using -exact_color_entry) is important, as output colors do not exactly match my input.

The help page for gdaldem states that -exact_color_entry:

use strict matching when searching in the color configuration file. If none matching color entry is found, the "0,0,0,0" RGBA quadruplet will be used

Can I edit this color configuration file? The colors that are being approximated seem normal (R 21, G 191, B 217 for example) but the exact values are not being written to tiff.

Alternatively, is there a better tool than gdaldem for essentially reclassifying one raster to three bands?

  • It feels like value 102216130 is changing a bit for some reason in the process. I can't imagine why and how but perhaps gdaldem is not heavily tested with single pixel images. – user30184 Jun 9 '16 at 5:06
  • Yeah, I'm not sure what the deal is either. The strange thing is that this happens for large pixel images as well. Setting -exact_color_entry leads to an all black output image when the input is a 500 px by 500 px raster. – Charlie Hofmann Jun 9 '16 at 12:02
  • I suggest to write to gdal-dev mailing list and attach 1x1 or 500x500 image as an attachment. – user30184 Jun 9 '16 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.