[gdal-dev] gdal_merge nodata evaluation

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

Thanks Even.  It also looks like gdal_merge always uses nearest neighbor
interpolation, which is another reason we’ll have to use gdalwarp instead.

Matt
.................................................................
Matthew Cechini
Contractor, Science Systems and Applications, Inc.
NASA GIBS Systems/Software Engineer
410.205.6272




On 10/20/16, 4:56 PM, "Even Rouault" <even.rouault at spatialys.com> wrote:

>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