|
On 24/08/2012 22:12, Etienne Tourigny
wrote:
Several secs, but much less that loading the vrt w/o statisticsJust curious - how much time did the 'gdalinfo -approx_stats file.vrt' command take? This is something that could be done inside QGIS rather easily I think - and persist across sessions.Etienne On Fri, Aug 24, 2012 at 4:10 PM, Micha Silver <[email protected]> wrote:On 23/08/2012 21:31, Giuseppe Sucameli wrote: Hi Etienne, On Aug 23, 2012, at 5:57 PM, Etienne Tourigny <[email protected]> wrote: On the other hand, wouldn't a simple "gdalinfo -stats file.vrt" achieve the same as the linked python script, but easier to run? the python script calculates approximated stats, so it works like gdalinfo -approx_stats file.vrt The problem was the -approx_stats option is not present in the documentation (either help online or using --help), then I wrote that few-lines script to achieve the task. Only now I'm looking at the gdalinfo.c code on the repo I know it's there since Jan 2007 (r10658)... BTW a ticket is needed to update the doc. On Thu, Aug 23, 2012 at 7:39 PM, Etienne Tourigny <[email protected]> wrote: it would be nice if someone (ideally the author) could test the same with nightly master (1.9). +1, but I hope you're talking about the wiki page author :) I cannot do any test because I have no VRT files so big. Micha, could you try with QGis master and report here, please? Thanks for all the advice. I did another quick test with both 1.8 and latest 1.9 (OSGeo4W installer on WinXP) on a somewhat slow laptop: I made a new vrt from 13 tiles of ecw aerial photos. Loading the individual rasters on both 1.8 and 1.9 was almost instantaneous. Loading the vrt (same tiles) took > 30 secs in 1.8, and about 15 secs using version 1.9. Next I ran gdalinfo -approx_stats on that vrt. After that in both 1.8 and 1.9 loading the vrt was almost instantaneous. So there is some improvement in 1.9 even without the statistics. But creating approx statistics shows dramatic improvement in load times in both the current version and master. Regards, Micha Regards. Etienne On Thu, Aug 23, 2012 at 2:27 PM, Radim Blazek <[email protected]> wrote: On Thu, Aug 23, 2012 at 5:57 PM, Etienne Tourigny <[email protected]> wrote: On Thu, Aug 23, 2012 at 11:00 AM, Even Rouault <[email protected]> wrote: It would be nice to have this bultin to gdalbuildvrt (as an optin of course) - could the authors make a patch? For a *byte* data type, which must be the common case, why wouldn't QGIS just use min=0 and max=255 when statistics are not computed ? good question. Unless I am mistaken, min/max are set to 0/255 by default, unless QgsRasterDataProvider::bandStatistics() or QgsRasterLayer::bandStatistics() is called - which is probably what happens. Default contrast enhancement in current master (may be changed in Options > Rendering > Rasters): Single band gray: Stretch to min / max Multiband color (byte/band): No stretch Multiband color (>byte/band): Stretch to min / max Limits (min/max): Cumulative count cut. The min/max are calculated using 250000 pixels sample, which should be fast. It would be useful to test the VRT without stats collected with current master. It would be possible to add another default contrast enhancement for Single band gray byte, but I believe that if the whole raster can be rendered in reasonable time, the min/max calculation must be also fast and contrast enhancement may be important even with byte data. Radim I don't understand what is the problem, does the VRT load slowly initially, or is getting statistics rather slow? On the other hand, wouldn't a simple "gdalinfo -stats file.vrt" achieve the same as the linked python script, but easier to run? Etienne Regards, Etienne On Thu, Aug 23, 2012 at 7:34 AM, Micha Silver <[email protected]> wrote: On 23/08/2012 11:33, Giovanni Manghi wrote: http://trac.osgeo.org/gdal/wiki/CatalogueForQIS Magic! Many thanks, and also to Andrea Peri for posting the python code. In windows I had to run it as: " python computestats.py -approx <filename.vrt> " it would be very nice to have this added as tool directly in QGIS... cheers -- Giovanni -- On Thu, 2012-08-23 at 11:27 +0300, Micha Silver wrote: Hello all: I have a batch of over 100 raster tiles in ecw format. Each is 50 - 100 MB in size. When I choose 20 or so files to load they appear (render) very quickly - in a matter of a few seconds or less. If I create a vrt of that same batch of tiles, it takes a long time to first render - upwards of 15 - 30 seconds. Once the vrt is loaded response is excellent (zooming, etc). But that initial delay is a bit annoying. Anything I can do to improve it? (QGIS 1.8, Win 7 64 bit) Many thanks, Micha -- Micha Silver 052-3665918 _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user This mail was received via Mail-SeCure System. -- Micha Silver 052-3665918 _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-userThis mail was received via Mail-SeCure System. |
_______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
