[Qgis-developer] Raster resampling

[Marco Hugentobler]

Hi Radim

Ok, after some tests, I see that resampling and reprojection together do 
not perform too well. Also (comparing with UMN), there is a quality 
difference if doing the resampling after the otf-reprojection (without 
otf-reprojection, quality and performance are similar).

Fortunately, QgsRasterProjector is quite generic. So maybe it is 
possible to to use it directly in the raster renderer classes and do the 
resampling in source SRS.

Regards,
Marco

On 20.01.2012 15:26, Marco Hugentobler wrote:
> Hi Radim
>
>> It seems that sometimes it is slower reprojection and sometimes
>> resampling, depending on which resampling algorithm is used,
>> complexity of projection and if approx repro is used. We need some
>> benchmarks on this. Would it be possible to have an optional order of
>> projection and resampling and choose the faster one on runtime?
>
> Not sure I understand exactly what you mean.
>
> Is it to have resampling on layer (and color) level and additionaly 
> resampling on provider (and raster band) level in the method 
> QgsRasterDataProvider::readBlock? Then if otf-reprojection is on and 
> raster type is not paletted, use the one inside the provider level, 
> else the one on layer level?
> This sounds like a good solution to me.
>
> Regards,
> Marco
>
>
>
>
> On 19.01.2012 18:07, Radim Blazek wrote:
>> On Tue, Jan 17, 2012 at 1:32 PM, Marco Hugentobler
>>> The problem here is that resampling sometimes can only be done once 
>>> you know
>>> the pixel color. E.g. in case of paletted raster, two adjacent pixel 
>>> values
>>> can have totally different color (therefore resampling needs to be 
>>> done on
>>> color components, not on raster value).
>> OK.
>>
>>> How is it with GRASS? it probably has the resampling on a lower level?
>> GRASS supports  only nearest neighbour.
>>
>>>> I am especially concerned about reprojection, because reprojection of
>>>> images oversampling^2 times bigger may be significantly slower.
>>>   True, I need to do some more tests here. At the moment, the 
>>> oversampling
>>> rate is kept at a maximum of 4 (that should probably be a user option
>>> later). Ok, maximum 16 times more data to reproject (hopefully no 
>>> problem
>>> with your approximative reprojection :-) ).
>> It seems that sometimes it is slower reprojection and sometimes
>> resampling, depending on which resampling algorithm is used,
>> complexity of projection and if approx repro is used. We need some
>> benchmarks on this. Would it be possible to have an optional order of
>> projection and resampling and choose the faster one on runtime?
>>
>> Radim
>
>


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux&  Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee