<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Pasted into <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/issues/5016">https://github.com/OSGeo/gdal/issues/5016</a><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="mimeAttachmentHeader"></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>