<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">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? <br>
<br>
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.
<br>
<br>
Thanks<br>
<br>
Derek<br>
<div style="font-family: Times New Roman; color: rgb(0, 0, 0); font-size: 16px;">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF856646"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Chaitanya kumar CH [chaitanya.ch@gmail.com]<br>
<b>Sent:</b> Saturday, June 11, 2011 8:58 AM<br>
<b>To:</b> Cole, Derek<br>
<b>Cc:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> Re: [gdal-dev] Building Overviews for Tiles of Large images<br>
</font><br>
</div>
<div></div>
<div>Derek,<br>
<br>
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.<br>
<br>
The gdaladdo utility [1] creates and stores the overviews on the disk.<br>
<br>
[1]: <a href="http://www.gdal.org/gdaladdo.html" target="_blank">http://www.gdal.org/gdaladdo.html</a><br>
<br>
<div class="gmail_quote">On Sat, Jun 11, 2011 at 9:00 AM, Cole, Derek <span dir="ltr">
<<a href="mailto:dcole@integrity-apps.com" target="_blank">dcole@integrity-apps.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); font-size: 10pt;">
Hello again,<br>
<br>
I am reading over some of the documentation and information I can find on GDAL. <br>
<br>
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<br>
<br>
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.<br>
<br>
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. <br>
<br>
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?<br>
<br>
Thanks for answering!<br>
<br>
Derek<br>
</div>
</div>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Best regards,<br>
Chaitanya kumar CH.<br>
/tʃaɪθənjə/ /kʊmɑr/ <br>
+91-9494447584<br>
17.2416N 80.1426E<br>
</div>
</div>
</div>
</body>
</html>