From: Alex Highviz
Sent: 22 June 2018 18:27:14
To: even.roua...@spatialys.com
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster algebra
benchmark
On 14/06/2018 21:22, Even Rouault wrote:
>
> [ ]
> - 1000x1000 is somewhat small
> I ended up with the following timings:
>
> GDAL-Only using ReadBlock(...) : 7.7 seconds
> GDAL-Only using RasterIO(...): 30.1 seconds
> GDAL-Only using GetLockedBlockRef(...) : 8.9 seconds
> Pronto Raster using GetLockedBlockRef(...
On 19/06/2018 18:41, Mateusz Loskot wrote:
> On 19 June 2018 at 11:50, Alex HighViz wrote:
>> On 19/06/2018 10:28, Mateusz Loskot wrote:
>>> On 19 June 2018 at 11:22, Alex HighViz wrote:
Regrettably I overstated the performance in my previous post, due to a bug
that is now solved. With
On 19 June 2018 at 11:50, Alex HighViz wrote:
> On 19/06/2018 10:28, Mateusz Loskot wrote:
>> On 19 June 2018 at 11:22, Alex HighViz wrote:
>>> Regrettably I overstated the performance in my previous post, due to a bug
>>> that is now solved. With the solved bug, Pronto is about 50% slower than
On 19/06/2018 10:28, Mateusz Loskot wrote:
> On 19 June 2018 at 11:22, Alex HighViz wrote:
>> Regrettably I overstated the performance in my previous post, due to a bug
>> that is now solved. With the solved bug, Pronto is about 50% slower than
>> GDAL directly. I believe this is still good co
On 19 June 2018 at 11:22, Alex HighViz wrote:
>
> Regrettably I overstated the performance in my previous post, due to a bug
> that is now solved. With the solved bug, Pronto is about 50% slower than GDAL
> directly. I believe this is still good considering the benefits, but not as
> glamorous
> Even Rouault wrote
> A few thoughts:
[ ]
> 1000x1000 is somewhat small. Perhaps benchmark on larger rasters
I am still working on your other suggestions, but thought it would be fair to
report on my progress.
Regrettably I overstated the performance in my previous post, due to a bug that
is
Great, will try and let you know.
From: Mateusz Loskot
Sent: 15 June 2018 00:27:34
To: Alex HighViz
Cc: Even Rouault; gdal-dev@lists.osgeo.org; Hagen-Zanker AH Dr (Civil & Env.
Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster alg
On 15 June 2018 at 01:22, Alex HighViz wrote:
> I need to look into sse2/ave2. My feeling is that will be easier
> and more effective for the reference case than for Pronto, because pronto is
> geared to express all operations at the pixel level.
You may try with auto vectorization first (could b
pronto is geared
to express all operations at the pixel level.
From: Even Rouault
Sent: 14 June 2018 21:22:36
To: gdal-dev@lists.osgeo.org
Cc: Alex HighViz; Hagen-Zanker AH Dr (Civil & Env. Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for ra
On 14 June 2018 at 18:47, Alex HighViz wrote:
> Would you by any chance be able (and willing) to conjure up a simple example
> of "OUT = 3 * A + B * C" using Boost.GIL?
Quick update: out of the box, GIL provides related algorithm that
accepts one or two sources: transform_pixels
Here is example
On 14 June 2018 at 18:47, Alex HighViz wrote:
> I remember when looking at it at the time that I felt that using Boost.GIL
> would give me more difficulty than reward.
It is not easy indeed. Things had not been improved for long time,
esp. documenation. It's changing and improving though.
> I w
Hi,
Interesting work.
A few thoughts:
- the benchmark_3_rasters_reference() could receive a few comments for non-
advanced users to mention that it is correct only if all the rasters use Byte
datatype, and all have the same block size.
- It would be interesting to see a variant of this referen
6:34
To: Alex HighViz
Cc: gdal-dev@lists.osgeo.org; Hagen-Zanker AH Dr (Civil & Env. Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster algebra
benchmark
On 14 June 2018 at 14:17, Alex HighViz wrote:
>
> I few times I have posted to the list trying to promote the idea of
On 14 June 2018 at 14:17, Alex HighViz wrote:
>
> I few times I have posted to the list trying to promote the idea of
> providing iterators over pixels in a raster band , and more generally to
> make raster data accessible using (future) standard conforming ranges.
In case you are not aware, Boos
Dear all,
I few times I have posted to the list trying to promote the idea of providing
iterators over pixels in a raster band , and more generally to make raster data
accessible using (future) standard conforming ranges. It would make
implementing algorithms on raster data a lot more intuitive
16 matches
Mail list logo
