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