<div dir="ltr">Hi Even,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your input </div><div><br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 3:34 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le mardi 09 avril 2013 19:06:28, Etienne Tourigny a écrit :<br>

<div>> I have committed new warping methods average and mode to trunk, this will<br>
> be part of gdal-1.10<br>
<br>
</div>Hi Etienne,<br>
<br>
It would be good if you could extend the autotest suite to add tests for those<br>
new warping methods. For that, you can likely take inspiration from the first<br>
tests of autotest/warp/warp.py. "Reference" images based on utmsmall.tif<br>
reference image is a bit big, but you can likely start from a smaller source<br>
image like byte.tif instead that will produce reference images of reasonable<br>
size to be put in svn.<br></blockquote><div><br></div><div>I will do that, thanks</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<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 large<br>
image whose floating point values are rarely identical. So I think that<br>
VSIRealloc shoud be used instead with a test on the result to fail properly.<br>
I'm also a bit doubtfull about the practical usefulness of this case on real<br>
data. There might also be a performance issue due to the loop "//Check array<br>
for existing entry" that is at the most inner level of the algorithm. Unless<br>
you have a practical use case, my personnal opinion would be to refuse to run<br>
mode resampling on floating point data, or implement it with a tolerance<br>
parameter to avoid strict floating point comparison (if that makes sense), but<br>
even that wouldn't guarantee reasonable performance and memory consumption.<br></blockquote><div><br></div><div>The logic was copied from existing code for overviews...</div><div>It is rather inefficient when dealing with floating-point or even integer (16/32 bits).</div>
<div><br></div><div>You are right that it is not really practical, but I decided to go ahead and implement it anyway. </div><div style>Mostly I implemented it to deal with 16 and 32 bit integers, and was lazy to implement an integer-only solution.</div>
<div style><br></div><div style>So here is my suggestion : modify this to use 32-bit integers instead, and refuse to run with floating-point data.</div><div style>The same could be done to overviews, although that *might* cause some regressions (although as you point out, mode resampling doesn't make sense for floating-point data).</div>
<div style>Or another solution is to implement a new integer algorithm, and leave the floating-point one around but print a warning.</div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
As far as mode resampling is concerned, it would likely run correctly for<br>
images with color tables, so I believe that the warning in gdalwarp.cpp at<br>
line 1048 could be shut down in that case too (in addition to nearest<br>
resampling)<br></blockquote><div><br></div><div>I have tested with a color table, and mode resampling does work. I forgot to update gdalwarp for this case, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
<br>
Best regards,<br>
<br>
Even<br></blockquote><div><br></div><div><br></div></div></div></div>