<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 6:50 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mardi 09 avril 2013 20:34:40, Even Rouault a écrit :<br>
<div class="im">> Le mardi 09 avril 2013 19:06:28, Etienne Tourigny a écrit :<br>
> > I have committed new warping methods average and mode to trunk, this will<br>
> > be part of gdal-1.10<br>
><br>
> Hi Etienne,<br>
><br>
> It would be good if you could extend the autotest suite to add tests for<br>
> those new warping methods. For that, you can likely take inspiration from<br>
> the first tests of autotest/warp/warp.py. "Reference" images based on<br>
> utmsmall.tif reference image is a bit big, but you can likely start from a<br>
> smaller source image like byte.tif instead that will produce reference<br>
> images of reasonable size to be put in svn.<br>
><br>
> Regarding nAlgo == 2 (mode with foating point data), the allocations of<br>
> pafVals and panSums have the potential to fail if warping is done on a<br>
> large image whose floating point values are rarely identical. So I think<br>
> that VSIRealloc shoud be used instead with a test on the result to fail<br>
> properly. I'm also a bit doubtfull about the practical usefulness of this<br>
> case on real data. There might also be a performance issue due to the loop<br>
> "//Check array for existing entry" that is at the most inner level of the<br>
> algorithm.<br>
<br>
</div>I stand corrected on the above comment about big memory consumption. The size<br>
of the array is limited to the number of source pixels needed to compute a<br>
target pixel, so unless you do extreme subsampling, that should be OK.<br></blockquote><div style>yes </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've just noticed however that pafVals and panSums aren't free'd, so there's a<br>
memory leak currently. And the CPLRealloc() are a bit weird as currently coded<br>
:<br>
<br>
<br>
                        int      nMaxNumPx = 0;<br>
                        float*   pafVals = NULL;<br>
                        int*     panSums = NULL;<br>
<br>
                        if (nNumPx > nMaxNumPx)<br>
                        {<br>
                            pafVals = (float*) CPLRealloc(pafVals, nNumPx *<br>
sizeof(float));<br>
                            panSums = (int*) CPLRealloc(panSums, nNumPx *<br>
sizeof(int));<br>
                            nMaxNumPx = nNumPx;<br>
                        }<br>
<br>
The test is always true, so CPLMalloc() would be clearer. But I think there<br>
was a will to move nMaxNumPx, pafVals, panSums before the top loops. So that<br>
should likely be done.<br>
</blockquote></div><br></div><div class="gmail_extra" style>I thought it is weird also, but again copied over from overview code. </div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>I thought about running valgrind, but then forgot. I will take your suggestions into consideration, thanks!</div>
</div>