[gdal-dev] Nearblack Eating Image Border

[Travis Kirstine]

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 <dmorissette at mapgears.com>
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
> > <dmorissette at mapgears.com <mailto:dmorissette at mapgears.com>> 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
> >      > gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> >      > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >      >
> >
> >
> >     --
> >     Daniel Morissette
> >     Mapgears Inc
> >     T: +1 418-696-5056 #201
> >     _______________________________________________
> >     gdal-dev mailing list
> >     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> >     https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> > --
> > Darafei Praliaskouski
> > Support me: http://patreon.com/komzpa
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
>
>
> --
> Daniel Morissette
> Mapgears Inc
> T: +1 418-696-5056 #201
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190220/51901edf/attachment.html>