Off topic but I've found that gdal_rasterize.py the best method for dealing with this type of issue.
On Wed, 20 Feb 2019 at 10:22, Daniel Morissette <[email protected]> wrote: > That's a great point. So it's not a bug, it is a feature in some cases. :) > > Maybe what we need is an option to switch between the two behaviors then. > > > > On 2019-02-20 8:23 a.m., Darafei "Komяpa" Praliaskouski wrote: > > 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] <mailto:[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] <mailto:[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] <mailto:[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 > > > > > -- > Daniel Morissette > Mapgears Inc > T: +1 418-696-5056 #201 > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
