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