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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
