Incorrect color interpolation in gdaldem (color-relief mode)
|Reported by:||dsogari||Owned by:||warmerdam|
Hello, I have some points to discuss with you about the behaviour of gdaldem in color-relief mode.
Firstly, in apps/gdaldem.cpp:851, inside function GDALColorReliefGetRGBA, there's an algorithm to "Find the index of the first element in the LUT input array that is not smaller than the dfVal value" (quoted from the source file). It uses comparison operator '<', but I believe it should be using '<='. A diff file is attached to show where the comparison operators should be replaced.
Otherwise, it can lead to "holes" in the output raster if the color palette file has repeated entries with the same value and the input raster has pixels that match that value exactly. An example of such raster is attached and the palette file used for testing can be found here: http://soliton.vm.bytemark.co.uk/pub/cpt-city/arendal/temperature.cpt
Secondly, I think you should consider replacing qsort (called in line 1180) by a stable sorting algorithm, or devise a way to handle equivalent color entries. This is because of the nature of qsort, which might reverse the original order of equivalent color entries.
In the case of the aforementioned palette file, the resulting raster can be seen in the attached file named "gdaldem_before.png". Its appearance isn't quite good, as the input pixel values increase monotonically from left to right, while the output colors change back and forth.
In my environment I was able to use the std::stable_sort function provided by <algorithm>. The resulting raster can be seen in the attached file named "gdaldem_after.png", whose appearance is much better.
Lastly, the value of nodata is being used together with the other values during interpolation. For instance, in nearest interpolation if a pixel value lies closest to the nodata value, it will be assigned the same color as nodata pixels. Is this behaviour intended?