I'm reading a fairly large (at least to me) geotif (about 2GB) a line at a time. I noticed that memory usage increases as I read the image. It appears that what's going on is that the driver hangs onto these lines of the image, even though I'm providing the same buffer for it to read into each time. At this point I noticed the FlushCache method. Calling this after each reading each scan line solves the problem of the growing memory usage.

I assume this behavior of caching whatever is read is deliberate. I think it would be useful in the API examples to make this behavior clear and perhaps show the use of the FlushCache method.
For example, the API Tutorial page shows this for how to read a line into a buffer:
Reading Raster Data
There are a few ways to read raster data, but the most common is via the GDALRasterBand::RasterIO() method. This method will automatically take care of data type conversion, up/down sampling and windowing. The following code will read the first scanline of data into a similarly sized buffer, converting it to floating point as part of the operation.

In C++:

        float *pafScanline;
        int   nXSize = poBand->GetXSize();

        pafScanline = (float *) CPLMalloc(sizeof(float)*nXSize);
        poBand->RasterIO( GF_Read, 0, 0, nXSize, 1,
                          pafScanline, nXSize, 1, GDT_Float32,
                          0, 0 );

The pafScanline buffer should be freed with CPLFree() when it is no longer used.
I think it would be useful to point out, in addition to the need to CPLFree the buffer that if you are using this example in a loop to read the image a line at a time, you should FlushCache every line (or periodically) to keep from accumulating the entire image in the cache (which is invisible to the user). It seems (to me) that it would be better to put this in the API Tutorial rather than as a code snippet in the Wiki, since the tutorial is where most people would look when starting out.




_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to