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

[Jan Hartmann]

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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130424/15a23db7/attachment-0001.html>