I believe this behavior is great for over-compressed imagery JPEGs where you have corrupted border of several "black-poisoned" non-black pixels that you'd better remove and take from some other image in the mosaic, since in this scenario you usually have an overlap.
On Wed, Feb 20, 2019 at 4:16 PM Daniel Morissette <[email protected]> wrote: > 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 -- Darafei Praliaskouski Support me: http://patreon.com/komzpa
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
