[Gdal-dev] issues merging 7 bands of Landsat scene into 1 image

[Maciej Sieczka]

Andrey,

Thanks for your reply. Please read below. CCing Mateusz who offered his
help on this issue off-list.

Andrey Kiselev wrote:

> On Tue, Mar 13, 2007 at 10:37:17PM +0100, Maciej Sieczka wrote:
>> So I tried GeoTIFF:
>>
>> $ gdal_merge.py -of GTIFF -separate -o merge.tif nn*.tif
>>
>> which went ok, BUT colortables of bands 2-6 are "Undefined" instead of
>> "Gray":
>>
>> $ gdalinfo merge.tif | grep ColorInterp
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 2 Block=254x32 Type=Byte, ColorInterp=Undefined
>> Band 3 Block=254x32 Type=Byte, ColorInterp=Undefined
>> Band 4 Block=254x32 Type=Byte, ColorInterp=Undefined
>> Band 5 Block=254x32 Type=Byte, ColorInterp=Undefined
>> Band 6 Block=254x32 Type=Byte, ColorInterp=Undefined
>> Band 7 Block=254x32 Type=Byte, ColorInterp=Undefined
>>
>> while the for each input image the ColorInterp is "Gray":
>>
>> $ for i in `ls | grep nn.\.tif`; do gdalinfo $i | grep ColorInterp; done
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
>> Band 1 Block=254x32 Type=Byte, ColorInterp=Gray
> 
> And that is no problem. GDAL marks extra bands as being alpha-channels,

So does the ColorInterp=Undefined mean the same as ColorInterp=Alpha?

> they will be read back well by the GDAL and other RS software.

Can I somehow set arbitrary names for bands? Eg. call band 1 "Landsat
blue", band 2 "Landsat green" etc.? If so, could that brake anything?

>> In that case I tried the -pct switch, but it makes gdal_merge.py crash:
>>
>> $ gdal_merge.py -pct -of GTIFF -separate -o merge_pct.tif nn*.tif
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gdal_merge.py", line 479, in ?
>>     t_fh.GetRasterBand(1).SetRasterColorTable(file_infos[0].ct)
>>   File "/usr/lib/python2.4/site-packages/gdal.py", line 892, in
>> SetRasterColorTable
>>     return _gdal.GDALSetRasterColorTable( self._o, ct._o )
>> AttributeError: 'NoneType' object has no attribute '_o
> 
> That should be related to old style Python bindings your GDAL built
> with. Try to rebuild with options '--without-python --with-ngpython'.

I have problems :(.

I fetched the stable 1.4.0 trunk (thanks for the hint in your other
email, Andrey).

GDAL --without-python --with-ngpython (full config syntax and other
details below) configures and builds without errors, but after the make
install, no python scripts get installed, including gdal_merge.py. How
do I build GDAL --with-ngpython and install it properly?

I have python2.4-numeric 24.2 and python2.4-numarray 1.5.1 installed
into /usr. site-packages dir is /usr/lib/python2.4/site-packages/

Note: there is a warning in config.log: "checking for NumPy include
files... missing"; does that matter?



DETAILS:

Fetched GDAL like this:
$ svn checkout https://svn.osgeo.org/gdal/branches/1.4/gdal gdal140_svn

Build steps:
$ export CPPFLAGS="-I/usr/include/python2.4/Numeric
-I/usr/include/python2.4/numarray"

$ ./configure --with-hdf4=/usr/local/lib --with-libz=internal
--with-png=internal --with-libtiff=internal --with-geotiff=internal
--with-jpeg=internal --with-gif=internal --with-geos=yes
--with-pg=/usr/bin/pg_config --with-sqlite=/usr/lib --with-xerces=yes
--without-python --with-ngpython

$ make

$ sudo make install

Logs for configure, make and make install are attached.

Maciek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tar.bz2
Type: application/x-bzip
Size: 25380 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20070318/6b4e53cc/logs.tar.bin