<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
text="#000000">
<div class="moz-cite-prefix">On 24/08/2012 22:12, Etienne Tourigny
wrote:<br>
</div>
<blockquote
cite="mid:CA+TxYvP29Wt9kpVZ86s_F9JxSCJuvLfHzMnvaac92sS1uH0AUg@mail.gmail.com"
type="cite">
<pre wrap="">Just curious - how much time did the 'gdalinfo -approx_stats file.vrt'
command take?
</pre>
</blockquote>
Several secs, but much less that loading the vrt w/o statistics<br>
<br>
<blockquote
cite="mid:CA+TxYvP29Wt9kpVZ86s_F9JxSCJuvLfHzMnvaac92sS1uH0AUg@mail.gmail.com"
type="cite">
<pre wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:micha@arava.co.il"><micha@arava.co.il></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 23/08/2012 21:31, Giuseppe Sucameli wrote:
Hi Etienne,
On Aug 23, 2012, at 5:57 PM, Etienne Tourigny <a class="moz-txt-link-rfc2396E" href="mailto:etourigny.dev@gmail.com"><etourigny.dev@gmail.com></a>
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
<a class="moz-txt-link-rfc2396E" href="mailto:etourigny.dev@gmail.com"><etourigny.dev@gmail.com></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:radim.blazek@gmail.com"><radim.blazek@gmail.com></a>
wrote:
On Thu, Aug 23, 2012 at 5:57 PM, Etienne Tourigny
<a class="moz-txt-link-rfc2396E" href="mailto:etourigny.dev@gmail.com"><etourigny.dev@gmail.com></a> wrote:
On Thu, Aug 23, 2012 at 11:00 AM, Even Rouault
<a class="moz-txt-link-rfc2396E" href="mailto:even.rouault@mines-paris.org"><even.rouault@mines-paris.org></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:micha@arava.co.il"><micha@arava.co.il></a> wrote:
On 23/08/2012 11:33, Giovanni Manghi wrote:
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/wiki/CatalogueForQIS">http://trac.osgeo.org/gdal/wiki/CatalogueForQIS</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
This mail was received via Mail-SeCure System.
--
Micha Silver
052-3665918
_______________________________________________
Qgis-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
_______________________________________________
Qgis-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
_______________________________________________
Qgis-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
_______________________________________________
Qgis-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
</pre>
</blockquote>
<pre wrap="">
This mail was received via Mail-SeCure System.
</pre>
</blockquote>
<br>
</body>
</html>