[gdal-dev] gdal2tiles for 16bit data

[David Strip]

On 9/22/2014 2:18 PM, Jan Tosovsky wrote:
> On 2014-09-21 David Strip wrote:
>> Looking back at the code, the actual output file is created with 
>> this line:
>> self.out_drv.CreateCopy(tilefilename, dstile, strict=0)
> Hmm, I have no idea how to pass this info into CreateCopy:
> http://www.gdal.org/classGDALDriver.html

This was bad advice. CreateCopy uses the same datatype as the raster
it's copying, so it couldn't be the source of your problem (and there's
no way to specify a datatype, since it's just copied).
>
>> If this still doesn't fix it, the first thing to do is run gdalinfo
>> against one of the tiles and let us know the result.
> Thanks for the hint. I've checked the tiling source (correct file):
>
> ...
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> ...
> Band 1 Block=256x256 Type=Int16, ColorInterp=Gray
>   NoData Value=0
>
>
> While my tile is:
> ...
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> ...
> Band 1 Block=256x8 Type=UInt16, ColorInterp=Gray
> Band 2 Block=256x8 Type=UInt16, ColorInterp=Undefined
>
> I've changed UInt16 to Int16, but in this case there are 'ERROR 1: Buffer
> too small' errors when tiles are produced (but they are somehow generated
> anyway). It fixes the type to Int16, but there are still some differences.
I have no idea what this is about. It does appear to be some sort of
numpy error msg from within the routine, but why it occurs and you can
still get output is a mystery to me.
>
> What exactly is 'Block=256x256' and is 'Block=256x8' in the second case
> correct?
The block  describes how the pixels are laid out in the file. The fact
that the input and output block sizes are different is not an error.
Likewise, interleave = band vs. pixel is a matter of internal
organization and shouldn't matter.

> Are other differences cosmetic or fatal ones?
gdal2tiles automatically creates a mask band (band2) for the tile, so
the addition of the second band is not surprising or incorrect. This
also accounts for the removal of the NoData Value
>
> Thanks, Jan
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>