Le vendredi 14 juin 2013 00:26:52, Phil Scadden a écrit :
> >Not sure to completely follow you ...
>
> Okay, what goes on in gdal2tiles.py, is that after creating the base
> tiles, (and in my version, they are quantised) the base tiles are taken
> in groups of 4, read into a new MEM driver raster to make a one tile,
> then resampled down to size of base tile to create an overview. It is
> repeated for each level up the tree. The rescaled output tile from this
> process has lost all the orginal colour - its just variations of red.
> Either in reading them into MEM or in the resampling, I have lost the
> palette info.
I suppose (*) that gdal2tiles isn't ready to deal with paletted datasets. It
must just concatenate the raw values of the 4 source tiles (i.e. index to
palettes), then do the resampling and write to the file. If the 4 tiles don't
share the same palette, this is bound to result in non-sensical data. If they
share the same palette, some code should be added to do somelink like
target_ds.SetColorTable(source_ds.GetColorTable())
(*) confirmed by the test I can see at line 732:
if self.in_ds.GetRasterBand(1).GetRasterColorTable():
# TODO: Process directly paletted dataset by generating VRT in
memory
self.error( "Please convert this file to RGB/RGBA and run
gdal2tiles on the result.",
--
Geospatial professional services
http://even.rouault.free.fr/services.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
