[gdal-dev] downsampling geotiff with a low-pass filter

[Kay F. Jahnke]

On 15.11.18 12:59, Marco wrote:

> Upsample to 1m, then downsample to 5?

That helps with the 'five does not divide by two' aspect and would be an 
improvement on averaging over all contributing points. But it still uses 
a box filter on the interpolated signal, which does not have what you'd 
want in a low-pass filter, namely a short transition band and good 
stop-band attenuation.

Another problem with your proposal is that it initially requires to 
produce an intermediate data set which is four times (2*2) as large as 
the original one, which makes the process long and memory-hungry.

It's better to use a sensible smoothing method in the first place. I 
suppose noone has given this over much thought as in the past you were 
ever so happy about every bit of resolution you could get. But in a time 
where we get very high resolution LIDAR data, the need to downsample 
properly is arising. Look at the interpolation methods: gdalwarp lists 
twelve different ones. The first few are for upsampling, and the 
remainder mostly for dealing with noisy data. Upsampling is well 
covered: cubicspline and lanczos are reasonably sophisticated upsampling 
filters, but there is no good downsampling filter. I think this is an 
omission, hence my post. The problem is real; downsampling with 
'average' produces artifacts, even from previously upsampled data.

Kay

> On 15-11-18 12:06, Kay F. Jahnke wrote:
>>
>> I have a very detailed GeoTIFF DEM of part of my target area (2m 
>> resolution). The remainder of the area is covered in 5m. So I'd like 
>> to downsample the moore detailed data to have everything in 5m for 
>> further processing. The nearest thing to what I have in mind is using 
>> -r average, but from signal processing theory I know that using a 
>> simple average over a block of data is not a good approximation for a 
>> low-pass filter. Also, since some of the source pixels are fully 
>> inside the target pixels and some are only partly (5 doesn't divide by 
>> 2), An average over all participating source pixels seems wrong. What 
>> would you advise?
>>
>> With regards
>> Kay
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev