Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback
On 25 November 2014 at 05:34, Even Rouault even.roua...@spatialys.com wrote: Otherwise I have not much to say about this RFC. Blurring has two r's, Fixed Gaussian blur also has another complexity, since it's output dimensions depend on the fftconvolve mode (using scipy.signal docs http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.fftconvolve.html). For example, to blur a DTM and maintain the same output dimensions and geotransform, the mode would need to use a 'valid' convolution with a padded input array. This padded array would also have a mode (similarly from numpy docs http://docs.scipy.org/doc/numpy/reference/generated/numpy.pad.html), such as 'symmetric'. http://gis.stackexchange.com/a/10467/1872 Someone else may want to blur a DTM without using a padded array, and just return a smaller array with modified geotransform. And a different blur would expand the output dimension and modify the geotransform using a 'full' fftconvolve mode, using a 'constant'=0 padded array. An example of this is to blur a polygon that barely extends to the shape's extent, but maintain the blur beyond the initial extent. The constant value would also need to be supplied, as a value of 0 for numpy is default. http://gis.stackexchange.com/a/104338/1872 So in summary, I'm not sure how GDAL could best cover all combinations of padding and convolution modes, except to offer a few prepared use-cases, or somehow provide extra parameters. Or just provide a single use case, similar to Gaussian blur routines in various raster editing software. -Mike ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback
Mike, The gaussian resampling is the one already available for gdaladdo, that was added per http://trac.osgeo.org/gdal/ticket/2137 and http://trac.osgeo.org/gdal/changeset/15323 Basically : - for a downscaling of factor between 1 and 2 (and for upscaling as well), it will use a 3x3 kernel - for a downscaling of factor between 2 and 4, it will use a 5x5 kernel - beyond it will use a 7x7 kernel. I understand that gaussian blur can/could be parametrized in more complex ways. If there are improvements in that area, additional parameters could likely be passed through the GDALRasterIOExtraArg structure. I've also wondered if the resampling algorithm couldn't be specified as a string instead of an enumerated value. In which case you could have had things like gauss_x_y with x and y as parameters. I don't have strong preference for one way or the other one. And both already exist in GDAL : the GDAL warping API uses an enumerated value, the GDAL overview API uses a string... Even On 25 November 2014 at 05:34, Even Rouault even.roua...@spatialys.com wrote: Otherwise I have not much to say about this RFC. Blurring has two r's, Fixed Gaussian blur also has another complexity, since it's output dimensions depend on the fftconvolve mode (using scipy.signal docs http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.fft convolve.html). For example, to blur a DTM and maintain the same output dimensions and geotransform, the mode would need to use a 'valid' convolution with a padded input array. This padded array would also have a mode (similarly from numpy docs http://docs.scipy.org/doc/numpy/reference/generated/numpy.pad.html), such as 'symmetric'. http://gis.stackexchange.com/a/10467/1872 Someone else may want to blur a DTM without using a padded array, and just return a smaller array with modified geotransform. And a different blur would expand the output dimension and modify the geotransform using a 'full' fftconvolve mode, using a 'constant'=0 padded array. An example of this is to blur a polygon that barely extends to the shape's extent, but maintain the blur beyond the initial extent. The constant value would also need to be supplied, as a value of 0 for numpy is default. http://gis.stackexchange.com/a/104338/1872 So in summary, I'm not sure how GDAL could best cover all combinations of padding and convolution modes, except to offer a few prepared use-cases, or somehow provide extra parameters. Or just provide a single use case, similar to Gaussian blur routines in various raster editing software. -Mike -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback
Hi, This is a call for discussion on a new RFC : RFC 51 RasterIO() improvements : resampling and progress callback http://trac.osgeo.org/gdal/wiki/rfc51_rasterio_resampling_progress Below the summary : This RFC aims at extending the RasterIO() API to allow specifying a resampling algorithm when doing requests involving subsampling or oversampling. A progress callback can also be specified to be notified of progression and allow the user to interrupt the operation. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback
Even Rouault even.rouault at spatialys.com writes:
Hi,
This is a call for discussion on a new RFC :
RFC 51 RasterIO() improvements : resampling and progress callback
http://trac.osgeo.org/gdal/wiki/rfc51_rasterio_resampling_progress
Below the summary :
This RFC aims at extending the RasterIO() API to allow specifying a
resampling
algorithm when doing requests involving subsampling or oversampling. A
progress callback can also be specified to be notified of progression and
allow
the user to interrupt the operation.
Hi,
Gdaladdo seems to lose some resampling algorithms. The damage with
average_mp can't be big by reading the comment from the gdaladdo manual page
average_mp is unsuitable for use. Average_magphase averages complex data in
mag/phase space.
Gdaladdo now:
-r {nearest (default),average,gauss,cubic,average_mp,average_magphase,mode}
Gdaladdo once RFC 51 is implemented:
-r parameter now accepts bilinear, cubicspline and lanczos as algorithms.
Otherwise I have not much to say about this RFC. Blurring has two r's, and
I think that it is good that gdal_translate will be able to use different
resampling methods and there will be no need to use gdalwarp if warping is
really not needed.
If you will touch gdal_translate anyway and it will do good job with
resampling I would like to see the same -tr option than in gdalwarp for
setting target resolution simply without a need to play with -outsize plus
-srcwin or -projwin.
-Jukka Rahkonen-
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback
Jukka,
Gdaladdo seems to lose some resampling algorithms.
Ah, the text of the RFC wasn't clear enough. Bilinear, cubicspline and lanczos
are *additional* algorithms to the existing ones.
The damage with
average_mp can't be big by reading the comment from the gdaladdo manual
page average_mp is unsuitable for use. Average_magphase averages complex
data in mag/phase space.
Gdaladdo now:
-r {nearest (default),average,gauss,cubic,average_mp,average_magphase,mode}
Gdaladdo once RFC 51 is implemented:
-r parameter now accepts bilinear, cubicspline and lanczos as algorithms.
Otherwise I have not much to say about this RFC. Blurring has two r's,
Fixed
and I think that it is good that gdal_translate will be able to use
different resampling methods and there will be no need to use gdalwarp if
warping is really not needed.
Yes, this can be significantly faster with gdal_translate -r since the
resampling algorithms of overview computation that are used can use more
optimizations than the general purpose ones of warping.
If you will touch gdal_translate anyway and it will do good job with
resampling I would like to see the same -tr option than in gdalwarp for
setting target resolution simply without a need to play with -outsize plus
-srcwin or -projwin.
That's not technically correlated with the RFC, but I see your point. I'll see
to add this. Note that this will not allow changing alignment of the origin as
you can do with gdalwarp -te/-tap: that would require VRT offsets to be
specified as floating point values.
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
