3

I am using ArcSDE as my raster data source with the ultimate goal to tile this dataset: I am running the following gdal_translate command to generate the initial VRT: 

gdal_translate  -projwin 390605 5588320 410128 5568805 -a_srs EPSG:25832 -a_nodata none -of vrt SDE:server,5153,db,user,pw,table,image clippedvrt.vrt

Tiling the resultant VRT produces tiff with weird colors. The colors are either intensified or totally different from the original as you can see from the test results

Here is the result of gdalinfo on the resultant VRT:

Band 1 Block=128x128 Type=Byte, ColorInterp=Palette
Color Table (RGB with 256 entries)
0: -1,-1,-1,255
1: 0,0,-1,255
2: -1,22873,22873,255
3: 26214,13107,0,255
4: -1,22873,22873,255
5: 26214,-17734,-1,255
6: -1,-3342,22873,255
7: 0,-6683,0,255
8: 0,0,0,255
9: -19790,26214,0,255
10: -13108,-1,-13108,255
11: 0,0,0,255
12: -11052,-11052,-11052,255
13: -13108,-1,-1,255
14: -3342,-10538,-21846,255
15: 26214,13107,0,255
16: -19276,-32640,26214,255
17: -1,-1,-1,255
18: -1,-1,-1,255
19: -1,-1,-1,255
20: -1,-1,-1,255
21: -1,-1,-1,255
22: -1,-1,-1,255
23: -1,-1,-1,255
24: -1,-1,-1,255

Could someone shed some light as to what might be happening?

Improve this question

1 Answer 1

Reset to default
3

I ran into the same problem and had to do an extra run with

for %%N in (D:\Karten\gdal\gdal2tiles\NL50\*.tif) DO gdal_translate -of vrt -expand rgba %%N D:\Karten\gdal\gdal2tiles\NL50\%%~nN.vrt

to expand the palettes used in the tifs to RGBA. Every tif has a different palette stored, and that's why stitching them together gives weired colours.

In the next step, I did

gdalbuildvrt -allow_projection_difference index.vrt NL50\*.vrt
Improve this answer
5
  • The input is from an SDE raster dataset, so I would be surprised if the issue was the difference in palettes stored. A preliminary test adding the -expand rgba option to the dataset leads to even weirder colors. BTW, the SDEraster I am using is an 8-bit image
    – algone
    Nov 7, 2013 at 9:22
  • The palette of the vrt generated without the -expand option is: ´Band 1 Block=128x128 Type=Byte, ColorInterp=Palette Color Table (RGB with 256 entries) 0: -1,-1,-1,255 1: 0,0,-1,255 2: -1,22873,22873,255 3: 26214,13107,0,255 4: -1,22873,22873,255 5: 26214,-17734,-1,255 6: -1,-3342,22873,255 7: 0,-6683,0,255 8: 0,0,0,255 9: -19790,26214,0,255 10: -13108,-1,-13108,255 11: 0,0,0,255 12: -11052,-11052,-11052,255 13: -13108,-1,-1,255 14: -3342,-10538,-21846,255 15: 26214,13107,0,255 16: -19276,-32640,26214,255 17: -1,-1,-1,255`
    – algone
    Nov 7, 2013 at 9:32
  • Strange. That Color Palette does not make sense to me. All values should be between 0 and 255. Can you add the color table definition of the .vrt file into your question? You can look into the file with any text editor.
    – AndreJ
    Nov 7, 2013 at 10:31
  • After some further test, I did not go any further. I did a gdalinfo directly on the SDE source and it resulted in that weird palette I already posted. As I said before i tried applying -scale and -expand options but, nothing changed. It seemed to me that the problem was with gdal-translate, so I tried generating the VRT via gdalbuildvrt cmd and alas, same output - vrt with exactly the same palette. Strange thing is, when we create a small tiff out of the raster using ArcGIS we get a correctly paletted tif
    – algone
    Nov 7, 2013 at 13:22
  • You can edit the color palette manually in the vrt file if you have the right values from the small tif. I assume this to be a bug of the driver.
    – AndreJ
    Nov 7, 2013 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.