Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3459 closed defect (fixed)

Bad output buffer sizing while warping

Reported by: warmerdam Owned by: Even Rouault
Priority: normal Milestone: 1.7.2
Component: Algorithms Version: 1.7.0
Severity: normal Keywords: warper
Cc:

Description

I am seeing very slow gdalwarp in some cases apparently due to poor selection of the output buffer size. I suspect the problem relates to r18035 and it does not occur in 1.6, though it does happen in 1.7 and trunk. The command is:

gdalwarp -rn -te -4000000 -3000000 0 3000000 -t_srs '+proj=gnom  +lon_0=-90.0 +lat_0=58 +a=5500000 +b=5500000' -tr 2000 2000 bug3458.tif out.tif -co TILED=NO

the input is:

Driver: GTiff/GeoTIFF
Files: bug3458.tif
Size is 21600, 21600
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,90.000000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-180.0000000,  90.0000000) (180d 0'0.00"W, 90d 0'0.00"N)
Lower Left  (-180.0000000, -90.0000000) (180d 0'0.00"W, 90d 0'0.00"S)
Upper Right (   0.0000000,  90.0000000) (  0d 0'0.01"E, 90d 0'0.00"N)
Lower Right (   0.0000000, -90.0000000) (  0d 0'0.01"E, 90d 0'0.00"S)
Center      ( -90.0000000,   0.0000000) ( 90d 0'0.00"W,  0d 0'0.01"N)
Band 1 Block=21600x1 Type=Byte, ColorInterp=Red
Band 2 Block=21600x1 Type=Byte, ColorInterp=Green
Band 3 Block=21600x1 Type=Byte, ColorInterp=Blue

The output includes many tiny output buffer regions like:

GDAL: GDALWarpKernel()::GWKNearestNoMasksByte()
Src=634,2161,631x1766 Dst=0,0,1000x1
0GDAL: GDALWarpKernel()::GWKNearestNoMasksByte()
Src=1259,406,9542x1757 Dst=1000,0,1000x1
GDAL: GDALWarpKernel()::GWKNearestNoMasksByte()
Src=637,2162,634x1765 Dst=0,1,1000x1

I would note the behavior is very different with TILED=YES in the creation switches.

Change History (3)

comment:1 Changed 11 years ago by Even Rouault

Status: newassigned

comment:2 Changed 11 years ago by Even Rouault

Milestone: 1.7.2
Resolution: fixed
Status: assignedclosed
Version: unspecified1.7.0

In fact, it's unrelated to the CHECK_WITH_INVERT_PROJ stuff, but comes from r18277 that was an attempt to align chunk dimension to block size of target dataset to reduce the size in the case of a compressed target dataset. However, your use case shows that it causes some major slowdowns for some reprojections where the distorsion between source and target is very important and thus the 'shapes' of source and target zones are not similar at all. Hum, this is a bit difficult to explain with words...

r19013 /trunk/gdal/alg/ (gdalwarper.cpp gdalwarpoperation.cpp): warp algorithm: back out alignment by default to block boundaries of target dataset that may cause poor performancesin some reprojection cases to revert to pre 1.7 behaviour; introduce instead a new warping option OPTIMIZE_SIZE that must be explicetly set by the user (#3459)

Backported in branches/1.7 in r19014.

I imagine that some heuristics could be found to select automatically the OPTIMIZE_SIZE=TRUE case in the case of compressed dataset when it won't hurt performance but this is not the kind of thing to try in the middle of packing lugage ;-)

comment:3 Changed 11 years ago by Even Rouault

Test added in r19017

Note: See TracTickets for help on using tickets.