<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Craig,</p>
    <p>fix queued in <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/5313">https://github.com/OSGeo/gdal/pull/5313</a></p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 17/12/2021 à 23:25, Craig Bruce a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:a7442ef1-1f1b-6905-2c71-5e7fec1b4ca2@cubewerx.com"> I
      tried to submit this issue on GitHub, but it wouldn't let me press
      the Submit button and wouldn't tell me why not.<br>
      <br>
      ## Expected behavior and actual behavior.<br>
      <br>
      The generation of Cloud-Optimized GeoTIFF images sometimes
      includes an fringe of random colors around the edge of opaque and
      transparent pixels of the coarser zoom levels.<br>
      <br>
      The edge of a COG level with an alpha channel should be a smooth
      tapering of translucent pixels with the proper colors from the
      source image.<br>
      <br>
      ## Steps to reproduce the problem.<br>
      <br>
      Using GDAL-3.3.1, take an image [like this, naip_denull.tif](<a
        class="moz-txt-link-freetext"
href="https://drive.google.com/file/d/1KIJ-8E3nxxaVCdQ1uaKE4rcZtCtlqT0x/view?usp=sharing"
        moz-do-not-send="true">https://drive.google.com/file/d/1KIJ-8E3nxxaVCdQ1uaKE4rcZtCtlqT0x/view?usp=sharing</a>)
      (188 MB) and run:<br>
      <br>
      $ gdal_translate naip_denull.tif cog.tif -of COG -co COMPRESS=LZW<br>
      <br>
      Then open the COG in an application like GIMP that lets you select
      which zoom-level to view.  Choose the coarsest level and view —
      random fringe!<br>
      <br>
      Screenshot: ![naip_fringe_screen](<a class="moz-txt-link-freetext"
href="https://user-images.githubusercontent.com/18429680/146596047-1081f20b-e6cb-4670-82f4-099ea8525032.png"
        moz-do-not-send="true">https://user-images.githubusercontent.com/18429680/146596047-1081f20b-e6cb-4670-82f4-099ea8525032.png</a>)<br>
      <br>
      All of the reduced-resolution levels have this problem to a
      degree, though the more zoomed-out ones have it worse.  Using
      these levels to produce a map makes it look bad.<br>
      <br>
      The problem seems to be exacerbated by the source image having
      pixels that are either fully opaque or fully transparent and by
      the image content having complicated patterns, such as streets.<br>
      <br>
      My guess is that the resampling method when generating a
      zoomed-out pixel is indiscriminately including source-pixel values
      that are fully transparent and shouldn't be included.  The
      randomness of the fringe suggests that the sample values for
      transparent pixels remain uninitialized as some kind of
      optimization.<br>
      <br>
      I've seen this problem before on other systems with a dark fringe
      from erroneously including transparent pixels that have sample
      values of 0.<br>
      <br>
      ## Operating system<br>
      <br>
      Fedora 33 Linux, x64.<br>
      <br>
      ## GDAL version and provenance<br>
      <br>
      GDAL-3.3.1.<br>
      <br>
      <div class="moz-signature">-- <br>
        Dr. Craig S. Bruce <br>
        Senior Software Developer <br>
        CubeWerx<i> </i>Inc. <br>
        <a href="http://www.cubewerx.com/" moz-do-not-send="true">https://www.cubewerx.com</a></div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-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="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>