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