Sporadic repeatable errors in png output of gdaldem -color-relief

[YellowBeard]

I have a AIG dataset of Queensland, Australia. In MapWindow, the data looks correct (with the exception of some systematic offset errors near the coast that aren't too serious).

The file is at OneDrive location: ​http://1drv.ms/1rmcjXs

When I run this file through gdaldem -color-relief, the output is almost correct, but with small regions of 'noise' that results in heights of 18,000ft, or -40,000ft, for example.

I am using the gdaldem from ​http://www.gisinternals.com/sdk/PackageList.aspx?file=release-1600-x64-gdal-1-11-mapserver-6-4.zip

my command is: gdaldem.exe color-relief "e153s29dem1_0\w001001.adf" "colourTextFile.txt" "deme153s29.png" -of PNG

[YellowBeard]

Color mapping file

[YellowBeard]

Circled examples of incorrect png colours

[Even Rouault]

The source AIG file would be needed to investigate

[YellowBeard]

Replying to rouault:

The source AIG file would be needed to investigate

It seems unlikely to me that there is some major error in the source - the output errors all seem to suffer the same mathmatical problem. All the output values are something like: 0x5F005454 0x5F007979 0x5EFF2323 0x5EFF0707

(where the last two bytes are always the same). I suspect that sometimes the least significant byte gets copied into the next significant byte accidentally?

[Even Rouault]

I've downloaded the source file and tried the command line, but I don't see anything suspicious in the global output. At which coordinates are the anomalies you have zoomed in ? And what are those hexadecimal values you mention : the output of gdaldem is a RGB image, so I don't manage to make sense of 4 bytes of the hexadecimal sequences you quote.

[YellowBeard]

Replying to rouault:

At which coordinates are the anomalies you have zoomed in ?

There is one at (1516, 469) @ 0x5f4e4e and another neighbour pixel at (1517, 470) @ 0x5f4646

And what are those hexadecimal values you mention : the output of gdaldem is a RGB image, so I don't manage to make sense of 4 bytes of the hexadecimal sequences you quote.

You're right - my mistake. It's outputting a 32bit PNG. I was getting confused with the alpha channel.

[Even Rouault]

The issue might be your color table :

At pixel 1516 469 the value is between 0 and -1

$ gdallocationinfo e153s29dem1_0/prj.adf 1516 469
Report:
  Location: (1516P,469L)
  Band 1:
    Value: -0.307190895080566

The related color palette extract is :

    0  95   0   0
   -1  94 255 255

And the output is logically :

$ gdallocationinfo out.png 1516 469
Report:
  Location: (1516P,469L)
  Band 1:
    Value: 95
  Band 2:
    Value: 78
  Band 3:
    Value: 78

[YellowBeard]

Replying to rouault:

The issue might be your color table :

At pixel 1516 469 the value is between 0 and -1

The related color palette extract is :

    0  95   0   0  
   -1  94 255 255  

And the output is logically :

Location: (1516P,469L) Band 1:

Value: 95

Band 2:

Value: 78

Band 3:

Value: 78

}}}

I don't follow how a value between 0 and -1 outputs a 0x5F4E4E, though. According to the color table, it should be somewhere between 0x5F0000 and 0x5EFFFF, shouldn't it?

[Even Rouault]

No, it's a linear interpolation on each component.

95 * (1 - 0.307) + 94 * 0.307 = 94.693 -> 95
0 * (1 - 0.307) + 255 * 0.307 = 78.285 -> 78

The RGB triplet is not a number. That wouldn't make sense.