[gdal-dev] Warping MrSid Images

[Frank Warmerdam]

Dan Greve wrote:
> Greetings,
> 
> I'm having an issue with a MrSid dataset.  Performance seems to be 
> dreadfully slow reprojecting data from this 14336 pix by 14336 pix 8bit, 
> 3 band RGB, UTM rotated image with 8 overviews. Whether I warp the image 
> into a  512 pix x 428 pix geotiff or a 15620 pix x 13102 pix geotiff, 
> (EPSG:4326) both warp operations take over 5 minutes. (5:30 for the 
> small image, 7:15 for the large which required 600 megabyte of disk 
> output).
>
> Might there be a better way of creating a VRT, grabbing one of the 
> overview bands, and using this virtual "overview" dataset in the warp 
> operation.  Strangely enough, if I translate the source into a GeoTiff, 
> and create 8 explicit overviews, the 512 pix x 428 pix warp operation 
> takes about 30 seconds.

Dan,

Whew, a bad mix.  Warped VRT and MrSID.

Generally speaking "random access" to MrSID tends to be slow.  And the
Warped VRT mechanism tends to result in quite a bit of random access
though I haven't analysed it carefully.

The other thing to keep in mind is that the Warp API always reads the
source data required for a particular output rectangle at full resolution.
This ensures that it can do the resampling kernels and such precisely.
But if you are downsampling greatly this is serious overkill.  It would
in fact be nice, and even reasonable, for the warp api to take advantage
of overviews if they are at least of the required resolution.  But it is
hard for the warp API to really know the resolution required in many cases
since it is at least potentially possible for a reprojection or other
warp to be highly irregular in resolution across an area and thus "highest
resolution" can't be determined without alot of internal scanning.

If you want dramatically lower resolution warps from a source image, you are
actually best off building a separate overview file and warping from that.

BTW, MapServer does not have this problem because it assumes that accuracy
of reprojection is not all that important.  So the warper just reads the
source data at something like 2x the expected resolution of the output and
it doesn't really worry about bad edge cases.  This makes MapServer fast,
but somewhat sloppy.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org