[gdal-dev] Warping MrSid Images

[Dan Greve]

Frank,
 
Thanks for the tips.  Until I understand the warp operation better I'll stay away from the VRTWarped dataset, and instead create a "MEM" In Memory raster using the overview that is just larger than the required resolution.  It sounds though like the MapServer "simple decimation" algorithm might be more appropriate for datasets without overviews, followed by the necessary reprojection operation. In my application responsiveness of the UI is currently more important than accuracy. 
 
By the way, get those 2008 Rush Tour tickets before they sell out!
 
-- dan



> 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> 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080121/ba1c50b3/attachment-0001.html