Opened 7 years ago

Closed 7 years ago

#5497 closed defect (invalid)

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

Reported by: YellowBeard Owned by: warmerdam
Priority: normal Milestone:
Component: Algorithms Version: 1.11.0
Severity: major Keywords: color-relief, gdaldem, DEM
Cc:

Description (last modified by 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

Attachments (2)

colourTextFile.txt (63.4 KB) - added by YellowBeard 7 years ago.
Color mapping file
gdaldemPngOutputExample.png (58.7 KB) - added by YellowBeard 7 years ago.
Circled examples of incorrect png colours

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by YellowBeard

Attachment: colourTextFile.txt added

Color mapping file

Changed 7 years ago by YellowBeard

Attachment: gdaldemPngOutputExample.png added

Circled examples of incorrect png colours

comment:1 Changed 7 years ago by YellowBeard

Description: modified (diff)

comment:2 Changed 7 years ago by Even Rouault

The source AIG file would be needed to investigate

comment:3 in reply to:  2 Changed 7 years ago by 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?

comment:4 Changed 7 years ago by 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.

comment:5 in reply to:  4 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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

comment:7 in reply to:  6 Changed 7 years ago by 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?

comment:8 Changed 7 years ago by Even Rouault

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.