[Qgis-user] Slow rendering of vrt

Fri Aug 24 12:12:55 PDT 2012

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 <micha at arava.co.il> wrote:
> On 23/08/2012 21:31, Giuseppe Sucameli wrote:
>
> Hi Etienne,
>
> On Aug 23, 2012, at 5:57 PM, Etienne Tourigny <etourigny.dev at gmail.com>
> 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
> <etourigny.dev at gmail.com> 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 <radim.blazek at gmail.com>
> wrote:
>
> On Thu, Aug 23, 2012 at 5:57 PM, Etienne Tourigny
> <etourigny.dev at gmail.com> wrote:
>
> On Thu, Aug 23, 2012 at 11:00 AM, Even Rouault
> <even.rouault at mines-paris.org> 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 <micha at arava.co.il> 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
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
> This mail was received via Mail-SeCure System.
>
>
>
> --
> Micha Silver
> 052-3665918
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>