gdal raster tile: speed-up generation of (max zoom) tiles in PNG format

[rouault]

By using an optimized code path, one can speed by 36% in some cases tile generation, when using libdeflate. If using zlib only, the gain is more modest, but still there.

e.g using https://nz-imagery.s3-ap-southeast-2.amazonaws.com/otago/otago_2025_0.2m/rgb/2193/CA14_5000_0304.tiff

Before:

$ time GDAL_RASTER_TILE_USE_PNG_OPTIM=NO gdal raster tile CA14_5000_0304.tiff CA14_5000_0304_tiled --progress
0...10...20...30...40...50...60...70...80...90...100 - done in 00:00:12.

real    0m13,234s
user    2m14,696s
sys     0m2,220s

Size of output directory: 373.356 MB

After:

$ time gdal raster tile CA14_5000_0304.tiff CA14_5000_0304_tiled --progress
0...10...20...30...40...50...60...70...80...90...100 - done in 00:00:08.

real    0m8,352s
user    1m26,253s
sys     0m1,929s

Size of output directory: 359.384 MB

[rouault]

FYI @jcphill

[jcphill]

For my generic build (without libdeflate) on I see runtime decrease from 12:55 to 12:00. Adding libdeflate drops it further to 11:42. That's only a 10% drop overall but still an improvement.

Unfortunately, there is something broken in the tile generation as blocks that should be all one color (red in the left half of this example tile) show up as black.

[jcphill]

It looks like if a highest-zoom tile is all one color it is drawn as black, although there are a few other examples where the highest-level tile is black but should be different colors. It is possible that there is one channel that is zero for the entire tile.

[jcphill]

I'm guessing I was seeing the black boxes because the blue channel was zero and it was being read as the alpha channel.

[coveralls]

coverage: 71.091% (-0.003%) from 71.094%
when pulling a99f508 on rouault:gdal_raster_tile_fast_png
into 7b610c0 on OSGeo:master.

[jcphill]

The tile problem is fixed and the runtime is down to 11:10 now, so 17% overall improvement.

[jcphill]

The max zoom tile png files are 5% or so larger, though.