[gdal-dev] Nearblack Eating Image Border

[Daniel Morissette]

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