[gdal-dev] Feature request: gauss and other interpolations in gdalwarp

[David Shean]

Hi Etienne and Jan,
For what it's worth, I would also use a gdalwarp gauss interpolation method.  I've found that the gdaladdo gauss interpolation provides the best anti-aliased downsampling, especially for rasters that contain many small nodata holes surrounded by valid data.  Cubic and lanczos both propagate the nodata holes.

However, in order to obtain optimal results with gdaladdo gauss, I have to iteratively build overviews using the 3x3 gaussian kernel (gdaladdo 2 4 8).  As far as I understand, this is providing gaussian pyramid downsampling with simple edge-inward inpainting of the nodata holes.  A single downsampling step with the larger gaussian kernels (gdaladdo 8) doesn't provide the same output quality.  So I suppose I would be most interested in an implementation of a more generalized iterative gaussian resampling for gdalwarp, allowing for arbitrary output resolution (not limited to integer steps).

I understand that this is likely a special use case, and my BuildOverviews/FillNodata hack for downsampling and filling remaining holes works for now.  Regardless, I appreciate the new interpolation options.  Thanks.
-David

On Apr 24, 2013, at 12:51 AM, Jan Hartmann <j.l.h.hartmann at uva.nl> wrote:

> Hi folks, just a general question: I opened this thread asking to implement a few gdaladdo filters in gdalwarp, and am happy to see that happen now. Would it be possible to add a few new filters to gdalwarp/gdaladdo? I'm thinking about the gauss filter for gdalwarp, and the unsharp mask filter for gdaladdo and gdalwarp. Funding would be no problem, but the question remains: does this make sense to you, and is there someone willing and able to implement it?
> 
> Jan
> 
> On 04/09/2013 11:57 PM, Etienne Tourigny wrote:
>> 
>> 
>> 
>> On Tue, Apr 9, 2013 at 6:50 PM, Even Rouault <even.rouault at mines-paris.org> wrote:
>> Le mardi 09 avril 2013 20:34:40, Even Rouault a écrit :
>> > Le mardi 09 avril 2013 19:06:28, Etienne Tourigny a écrit :
>> > > I have committed new warping methods average and mode to trunk, this will
>> > > be part of gdal-1.10
>> >
>> > Hi Etienne,
>> >
>> > It would be good if you could extend the autotest suite to add tests for
>> > those new warping methods. For that, you can likely take inspiration from
>> > the first tests of autotest/warp/warp.py. "Reference" images based on
>> > utmsmall.tif reference image is a bit big, but you can likely start from a
>> > smaller source image like byte.tif instead that will produce reference
>> > images of reasonable size to be put in svn.
>> >
>> > Regarding nAlgo == 2 (mode with foating point data), the allocations of
>> > pafVals and panSums have the potential to fail if warping is done on a
>> > large image whose floating point values are rarely identical. So I think
>> > that VSIRealloc shoud be used instead with a test on the result to fail
>> > properly. I'm also a bit doubtfull about the practical usefulness of this
>> > case on real data. There might also be a performance issue due to the loop
>> > "//Check array for existing entry" that is at the most inner level of the
>> > algorithm.
>> 
>> I stand corrected on the above comment about big memory consumption. The size
>> of the array is limited to the number of source pixels needed to compute a
>> target pixel, so unless you do extreme subsampling, that should be OK.
>> yes 
>> 
>> I've just noticed however that pafVals and panSums aren't free'd, so there's a
>> memory leak currently. And the CPLRealloc() are a bit weird as currently coded
>> :
>> 
>> 
>>                         int      nMaxNumPx = 0;
>>                         float*   pafVals = NULL;
>>                         int*     panSums = NULL;
>> 
>>                         if (nNumPx > nMaxNumPx)
>>                         {
>>                             pafVals = (float*) CPLRealloc(pafVals, nNumPx *
>> sizeof(float));
>>                             panSums = (int*) CPLRealloc(panSums, nNumPx *
>> sizeof(int));
>>                             nMaxNumPx = nNumPx;
>>                         }
>> 
>> The test is always true, so CPLMalloc() would be clearer. But I think there
>> was a will to move nMaxNumPx, pafVals, panSums before the top loops. So that
>> should likely be done.
>> 
>> I thought it is weird also, but again copied over from overview code. 
>> 
>> I thought about running valgrind, but then forgot. I will take your suggestions into consideration, thanks!
>> 
>> 
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130415/e934dc29/attachment.html>