[Qgis-user] Slow rendering of vrt

[Etienne Tourigny]

On Thu, Aug 23, 2012 at 3:31 PM, Giuseppe Sucameli <sucameli at faunalia.it> 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.

I'll try to update that soon.

>
> 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.

sorry I meant the post author (Micha)

>
> Micha, could you try with QGis master and report here,
> please?
>
> 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
>
>
>
> --
> Giuseppe Sucameli - Faunalia