<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Etienne and Jan,</div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><div>-David</div></div><div><br></div><div><div>On Apr 24, 2013, at 12:51 AM, Jan Hartmann <<a href="mailto:j.l.h.hartmann@uva.nl">j.l.h.hartmann@uva.nl</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<font face="Times New Roman, Times, serif">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?<br>
<br>
Jan<br>
<br>
</font>
<div class="moz-cite-prefix">On 04/09/2013 11:57 PM, Etienne
Tourigny wrote:<br>
</div>
<blockquote cite="mid:CA+TxYvPJZdgi9GEx6-G=EdTHwU-P8vYb2S2A9jCmP5de_HG8aA@mail.gmail.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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 moz-do-not-send="true" 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>gdal-dev mailing list<br><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>http://lists.osgeo.org/mailman/listinfo/gdal-dev</blockquote></div><br></body></html>