[gdal-dev] GDAL performance compared with libtiff

[Immanuel Weber]

Hi all,

I'm working on an application where lots of images have to be written. Until now I'm using libtiff for that task. But as I want to add georeferencing and the like I'm having a look at GDAL right now. I did a quick evaluation of its performance related to libtiff and unfortunately it has quite a lot of overhead.
I first tested GDAL 1.10 and it was a factor of 6-7 slower than the direct write with libtiff. With GDAL 2.0 it got a little better with a factor of 4. (I took a 1,5 MP image and wrote for a few hundred times to the disk and libtiff takes about 3 ms for that, where as GDAL around 12 ms). I read about a performance issue with GDALDataSet::RasterIO vs GDALRasterBand::ReadBlock and tried to implement the storage using GDALRasterBand::WriteBlock* but that almost took more time than the GDALDataSet::RasterIO version.

Is there any other way to write tiffs quickly with GDAL, or is that kind of overhead expected for the added functionality?

Thanks and best regards,
Immanuel

*I wasn't really successful in doing that, because I didn't find a way to write pixel interleaved images with that (but the amount of data written was the same as with RasterIO. Is there a way to write images like these correctly with WriteBlock? My code for that looks like this (image is an opencv cv::Mat)
auto type = (image.elemSize1() == 2)? GDT_UInt16 : GDT_Byte;
auto dataset = driver->Create(filename.data(), image.cols, image.rows, image.channels(), type, nullptr);
auto band = dataset->GetRasterBand(1);
auto xBlockSize = 0;
auto yBlockSize = 0;
band->GetBlockSize(&xBlockSize, &yBlockSize);
auto xNumBlocks = (band->GetXSize() + xBlockSize - 1) / xBlockSize;
auto yNumBlocks = (band->GetYSize() + yBlockSize - 1) / yBlockSize;
for (auto bI = 1; bI <= dataset->GetRasterCount(); ++bI) {
auto band = dataset->GetRasterBand(bI);
for (auto yI = 0; yI < yNumBlocks; ++yI) {
for (auto xI = 0; xI < xNumBlocks; ++xI) {
band->WriteBlock(xI, yI, image.data);
}
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150806/f72d5c47/attachment.html>