Just 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-user > > > _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
