[gdal-dev] Re: GDAL custom build (ECW required)

[Gilles Bassière]

Gilles Bassière wrote:
> Hi (again),
> 
> I'm facing problems with GeoTiff compression on a custom build of GDAL.
> 
> My source dataset is a virtual raster composed of ECW tiles built with:
>  gdalbuildvrt ortho-dept04-2004-la2e.vrt ortho-dept04-2004-la2e/*.ecw
> 
> The error comes when I try to extract and reproject some portions of
> this virtual raster with gdalwarp. With no compression, everything runs
> fine but I get huge GeoTiffs. Problems arise with compression:
> 
> with COMPRESS=JPEG:
> 
>  Creating output file that is 10000P x 10000L.
>  Processing input file ortho-dept04-2004-la2e.vrt.
>  0...10...20...30..gdalwarp: tif_jpeg.c:691: JPEGPreDecode: Assertion
> `sp->cinfo.comm.is_decompressor' failed.
>  Aborted
> 
> with COMPRESS=DEFLATE:
> 
>  Creating output file that is 10000P x 10000L.
>  Processing input file ortho-dept04-2004-la2e.vrt.
>  0...10...20...30...40...50...60...70...80...90ERROR 1:
> ZIPDecode:ortho-dept04-2004-lam93-tif/04-2004-0895-6290-lam93.tif:
> Decoding error at scanline 0, incorrect header check
>  ERROR 1: TIFFReadEncodedTile() failed.
>  ...100 - done.
> 
> with COMPRESS=LZW:
> 
>  Creating output file that is 10000P x 10000L.
>  Processing input file ortho-dept04-2004-la2e.vrt.
>  0...10...20...30...40...50...60...70...80...90Segmentation fault
> 
> In the case of JPEG, the error appears randomly (most files are created
> with no error) but in the cases of LZW and DEFLATE, it happens every
> time and always after the 90% mark.
> 
> The command used was:
>  gdalwarp -s_srs "+init=epsg:27572" -t_srs "+init=epsg:2154" \
>     -te $e -ts 10000 10000 -co COMPRESS=LZW -co TILED=YES \
>     -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 ortho-dept04-2004-la2e.vrt \
>     ortho-dept04-2004-lam93-tif/04-2004-$x-$y-lam93.tif
> 
> My system is Ubuntu Jaunty (9.04) and all dependencies where installed
> with the package manager (including -dev packages). I've built libecw
> and gdal from source with the following commands:
> 
> # Build libecw
> DEST=`pwd`
> cd ../src/libecwj2-3.3/
> ./configure --prefix=$DEST
> make -j2
> mkdir $DEST/include
> make install
> 
> # Build GDAL
> cd ../gdal-1.7.1/
> ./configure --prefix=$DEST --with-ecw=$DEST --with-python
> make -j2
> source ../../env/gdal/bin/activate # virtualenv for Python bindings
> make install
> deactivate
> 
> # Register libs in $DEST/lib
> sudo ldconfig
> 
> Because of ticket #3139 [1], I suspect something wrong with my build but
> I don't know what. Any help would be much appreciated.
> 
> Thanks in advance
> 
> [1] https://trac.osgeo.org/gdal/ticket/3139
> 


Below is another example of the strange behaviour of my GDAL build.

I've produced two GeoTiff extracts of my virtual raster with these commands:

$ gdalwarp -s_srs "+init=epsg:27572" -t_srs "+init=epsg:2154" \
    -te 910000 6316500 910500 6319000 -ts 1000 5000 -co COMPRESS=JPEG \
    -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 \
    ortho-dept04-2004-la2e.vrt test1000x5000.tif
 Creating output file that is 1000P x 5000L.
 Processing input file ortho-dept04-2004-la2e.vrt.
 0...10...20...30...40...50...60...70...80...90...100 - done.

$ gdalwarp -s_srs "+init=epsg:27572" -t_srs "+init=epsg:2154" \
    -te 910000 6315000 915000 6320000 -ts 10000 10000 -co COMPRESS=JPEG \
    -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 \
    ortho-dept04-2004-la2e.vrt test10000x10000.tif
 Creating output file that is 10000P x 10000L.
 Processing input file ortho-dept04-2004-la2e.vrt.
 0...10...20...30...40...50...60...70...80...90...100 - done.

The output files can be viewed from
http://depot.makina-corpus.org/public/gdal/

The largest image has a black gap in the middle instead of the actual
data. The smaller image doesn't show this gap and prove that there is
actually data in the input dataset.

Could this be due to wrong values read in the ECW input files?

-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/