Hi, Yes for performance you must adapt your reading pattern to the underlying structure of the data. You could still have performant RasterIO() if you define GDAL_CACHEMAX to at least (raster_width * block_height * 4), so that when you read a scanline there will be enough memory in the block cache to keep all the blocks that have been read for that scanline. Instead of using GDALReadBlock(), you could also use GDALRasterIO() but on a window that is aligned to tile boundaries and dimensions. The reason for which gdal_translate was more performant than your code is that it does exactly that : work on block/tile dimensions.
Even > Hi, > > Just to follow up, once I got GDAL built with OpenJPEG support on Windows I > found the performance was terrible there as well. So I tried reading in > blocks and that was obviously the way to do it. The way I was doing it was to > read a scanline from each rasterband, perhaps 4 different bands for an RGBA > image, and process all the pixels for a scanline at once. Now I read blocks > from each rasterband in turn. It completes in a minute or so instead of > taking 10 minutes without completing one scanline! > > It's interesting because it kind of makes having a codepath based on > GDALRasterBand::RasterIO() redundant, for my purposes anyway. Originally I > thought I would have two codepaths based on reading scanlines (especially > considering I'd written it all before trying JPEG 2000!) and reading blocks > which were switched between depending on block size. That ends up being a > chunk of code though, and with the risk of major performance issues it seems > better just to go with reading blocks. All RasterIO() seems to get you, on > the surface at least, is the data type conversion. However I found > GDALCopyWords() which seems to handle that. > > Thanks to whoever wrote the sample code in the ReadBlock() docs, very helpful > as a start :-). > > Regards, > > Jo Meder > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
