[gdal-dev] gdal_merge nodata evaluation

[Cechini, Matthew F. (GSFC-423.0)[Science Systems & Applications, Inc.]]

All,
   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:

   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 -n nodata_value argument is evaluated band-by-band.  So, the following merged pixel (M) occurs for a merge of E and N:
E: 100, 100, 100, 255
        N: 0, 0, 3, 0
        M: 100, 100, 3, 255

   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:

E: 100, 100, 100, 255
        N': 0, 0, 0, 0
        M: 100, 100, 100, 255

   That’s fine, however, we still have the problem of opaque pixels in N merging incorrectly:

E: 100, 100, 100, 255
        N: 0, 0, 3, 255
        M: 100, 100, 3, 255

   In this case, we either have to come up with a gnarly gdal_calc command… or accept the infrequent merge issues.

   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?

Thanks,
Matt
.................................................................
Matthew Cechini
Contractor, Science Systems and Applications, Inc.
NASA GIBS Systems/Software Engineer
410.205.6272
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161020/871170d2/attachment.html>