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
<[email protected] <mailto:[email protected]>>
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
