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

[Chaitanya kumar CH]

Derek,

Sorry I missed your mail.

You can very well use RasterIO to get a downsampled image. But the disk I/O
is still going to be the same. That is the main bottleneck. Also, you are
stuck with the nearest neighbor method, which can become very choppy at
higher levels.

On Wed, Jun 15, 2011 at 11:50 PM, Cole, Derek <dcole at integrity-apps.com>wrote:

>  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>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
>> 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/20110626/725de241/attachment.html