[gdal-dev] Warping MrSid Images

[Dan Greve]

Frank, Just thought I'd let you know how well a VRTDataset wrapped around MrSid overviews went.  I was able (naturally) to reduce the time to create a 512 x 428 using a raw MrSid to MEM warp operation from 5 minutes to 5 seconds.  Overall using the VRT wrapped MrSid overviews takes 20 minutes on my crappy PC to generate an image quadtree of a 20 megabyte MrSid to 800 Megabyte uncompressed DDS tiles. Naturally, images without overviews don't benefit from this approach, but even building overviews on images that support them should still cut down overall processing time. Thanks again! -- Dan Greve-- Northrop Grumman Integrated Systems

> Date: Mon, 21 Jan 2008 21:07:32 -0500> From: warmerdam at pobox.com> To: grevedan at hotmail.com> CC: gdal-dev at lists.osgeo.org> Subject: Re: [gdal-dev] Warping MrSid Images> > 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> 
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080122/63cf79c1/attachment-0001.html