I noticed this behavior as well and I think it's a bug. I think it would
make more sense to keep the last "-nb" pixels that are not nearblack
instead of dropping them. The effect is especially annoying when you
have image tiles and you end up with a 1-2 pixels gap between them.
I didn't test what happens if we change the behavior. So maybe there is
a reason why it was implemented this way?
Daniel
On 2019-02-19 6:13 p.m., Christopher Mitchell wrote:
I've encountered an error in an image processing pipeline I've built
where nearblack is removing pixels at the border of images, even if
they don't fit the is-"black" criterion. Specifically, I'm using
nearblack to remove nearly-black areas touching the edges of lossy
image tiles that should be fully black. Those images are later
combined into VRT files and warped; where we have multiple tiles
overlapping an area, some of which are missing data, we therefore can
get complete coverage.
Unfortunately, for tiles that have no black areas, nearblack is still
eating the -nb argument's number of pixels at the edges, turning them
into black (0, 0, 0, 0, where we're using 4-channel images), even if
those pixels are nowhere near the color criterion to be recognized as
black. My understanding was that nearblack should only be proceeding
into the interior of the non-black area and then setting pixels to
black if those pixels are /actually/ nearly black.
Am I encountering a bug with nearblack? Do I misunderstand how the -nb
argument works? Happy to provide a MWE if any of the above is unclear,
and thanks in advance.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
