[gdal-dev] Building Overviews for Tiles of Large images

[Cole, Derek]

Bringing this back up, as I am curious. I have started playing around with using RasterIO and providing smaller output buffers for the read-in data, thus making GDAL do the downsampling (which apparently is nearest neighbor type?). Do you think this is faster than creating Overview imagery, which would also have to be read from disk? It seems like with overview imagery, at runtime you might be faster, since it physically reads less data, but you'd have to take a hit somewhere actually creating the overviews, right?

Currently, I am reading in a full-size displayed version of the image, and if a user zooms out, make another read into a fraction of the buffer size to get the downsampled version of the tile.

Thanks

Derek
________________________________
From: Chaitanya kumar CH [chaitanya.ch at gmail.com]
Sent: Saturday, June 11, 2011 8:58 AM
To: Cole, Derek
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Building Overviews for Tiles of Large images

Derek,

Switching to less detailed versions is not as fast as an interactive application would like, especially if you need a good downsampling algorithm. So, adding overviews is more important than creating tiles. Creating tiles is more applicable for web applications where less disk seeking is preferable.

The gdaladdo utility [1] creates and stores the overviews on the disk.

[1]: http://www.gdal.org/gdaladdo.html

On Sat, Jun 11, 2011 at 9:00 AM, Cole, Derek <dcole at integrity-apps.com<mailto:dcole at integrity-apps.com>> wrote:
Hello again,

I am reading over some of the documentation and information I can find on GDAL.

I have some pretty large NITF images that I want to break up for purposes of displaying in a viewer I am developing. My current plan is to tile the images into 1024x1024 blocks. The full images are 32768x32768 pixels

I was hoping that as part of my tiling, I would read in the image blocks and display them as they are on disk, and as a user zoomed out, switch to "Less detailed" versions the further out they go.

I was looking at the gdaladdo sample program. Is this what I want to be looking at to try to replicate this functionality *in memory* for my viewer? Ideally all of the tiles would know what level of zoom they were at, and switch to the appropriate level of detail accordingly.

Does it sound feasible to have my code constantly switching each tile between an overview that is generated on the fly like that, or do people typically write out the lower res imagesonce to file , and re-read that new files?

Thanks for answering!

Derek

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110615/cef91856/attachment.html