[gdal-dev] Re: GDAL_retile slowdown at next level

[acangi]

I moved my level 1 tiles to a machine with big hard disk, many processors and
a lot of memory.
Then I restarted the process taking the level 1 tiles as source : 

gdal_retile.py -targetDir subpyramid/ -levels 11 -pyramidOnly -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r bilinear -co
"COMPRESS=JPEG" -co "INTERLEAVE=PIXEL" -tileIndex orthocol -tileIndexField
location --optfile ls.txt &>subpyramid/out.txt &

Differences with previous commands :
 -targetDir subpyramid/ : I'm writing to another folder, planning to merge
both pyramids later
 -levels 11 instead of 12
 --optfile ls.txt : too many files for bash (the source files of the
previous commands were 4000x4000 geotiffs)
 &>subpyramid/out.txt : to keep track of the output

In /usr/local/bin/gdal_retile.py, I set the self.cacheSize=1465 (my longest
row is around 458 tiles + security)

It takes a few hours before the first tile is written, gdal_retile prints a
whole bunch of :
ERROR 1: JPEGSetupEncode:RowsPerStrip must be multiple of 8 for JPEG
ERROR 1: TIFFWriteEncodedStrip() failed.

, outputs 297 black tiles then crashes with 

Error openenig:<type 'exceptions.NameError'>

I'm not sure if this problem is related with the self.cacheSize change or
with the JPEGSetupEncode error. 

Also, I'm not sure whether I had those JPEGSetupEncode errors when creating
the two first levels, as I didn't save the output of the process.

As I think my global problems with pyramid creation are related to the small
tiles, I'll try to produce a pyramid with bigger tiles (4096x4096, inner
tiled). Maybe I should also add -co BLOCKYSIZE=8 ? 

I'm sorry I can't provide more feedback on the change of self.cacheSize...
-- 
View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-retile-slowdown-at-next-level-tp5034870p5069771.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.