[gdal-dev] gdal_merge nodata evaluation

[Even Rouault]

On Thursday 20 October 2016 20:27:14 Cechini, GSFC-423.0, Inc.] wrote:
> 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?

gdalwarp can generally be used as a replacement for gdal_merge. I'd try it :

gdalwarp new.tif existing.tif

Possibly with: -srcnodata "X Y Z" -wo UNIFIED_SRC_NODATA=YES

But this may not be necessary if your source is PNG as the NODATA_VALUES="X Y 
Z" metadata is probably already defined.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com