<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>All,</div>
<div> We’ve recently begun usage of the gdal_merge utility in our processing workflow and have hit a snag. I’m not sure if the snag is by design or is user error. Here’s the scenario:</div>
<div><br>
</div>
<div> We have two 24_bit PNG images, and existing image (E) and a new image (N) we are merging into E. They are the same size/projection/etc, so that’s ignored here. Some pixels within N are transparent with non-zero RGB band values. The behavior we want
is for gdal_merge to ignore these transparent pixels during the merge. Unfortunately, it appears that the <i>-n nodata_value</i> argument is evaluated band-by-band. So, the following merged pixel (M) occurs for a merge of E and N:</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>E: 100, 100, 100, 255</div>
<div> N: 0, 0, 3, 0</div>
<div> M: 100, 100, 3, 255</div>
<div><br>
</div>
<div> To work around this, we figured out a gdal_calc command that will set RGB bands to 0 (nodata) in N if the pixel is transparent. So that gives us this:</div>
<div><br>
</div>
<div>
<div><span class="Apple-tab-span" style="white-space: pre;"></span>E: 100, 100, 100, 255</div>
<div> N': 0, 0, 0, 0</div>
<div> M: 100, 100, 100, 255</div>
</div>
<div><br>
</div>
<div> That’s fine, however, we still have the problem of opaque pixels in N merging incorrectly:</div>
<div><br>
</div>
<div>
<div><span class="Apple-tab-span" style="white-space: pre;"></span>E: 100, 100, 100, 255</div>
<div> N: 0, 0, 3, 255</div>
<div> M: 100, 100, 3, 255</div>
</div>
<div><br>
</div>
<div> In this case, we either have to come up with a gnarly gdal_calc command… or accept the infrequent merge issues.</div>
<div><br>
</div>
<div> The exploratory question is “why does gdal_merge evaluate the nodata value band-by-band?” This is also a limitation with gdal_translate, whereas gdalwarp allows for multiple band nodata values. Answers to that will be interesting, but not necessarily
fix our immediate issue, so how do we resolve this situation using existing gdal capabilities?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Matt</div>
<div>
<div>.................................................................</div>
<div><span class="Apple-style-span" style="font-family: 'Lucida Grande';"><span style="font-size: 11pt;">Matthew Cechini</span></span></div>
<div><span style="font-size: 13px; font-family: 'Lucida Grande';">Contractor, Science Systems and Applications, Inc.</span></div>
<div><span style="font-size: 10pt; font-family: 'Lucida Grande';">NASA GIBS Systems/Software Engineer</span></div>
<div><span class="Apple-style-span" style="font-family: 'Lucida Grande';"><font size="2"><span style="font-size: 10pt;">410.205.6272</span></font></span></div>
</div>
</body>
</html>