<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 4:16 PM Daniel Morissette <<a href="mailto:dmorissette@mapgears.com">dmorissette@mapgears.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I noticed this behavior as well and I think it's a bug. I think it would <br>
make more sense to keep the last "-nb" pixels that are not nearblack <br>
instead of dropping them.  The effect is especially annoying when you <br>
have image tiles and you end up with a 1-2 pixels gap between them.<br>
<br>
I didn't test what happens if we change the behavior. So maybe there is <br>
a reason why it was implemented this way?<br>
<br>
Daniel<br>
<br>
On 2019-02-19 6:13 p.m., Christopher Mitchell wrote:<br>
> I've encountered an error in an image processing pipeline I've built<br>
> where nearblack is removing pixels at the border of images, even if<br>
> they don't fit the is-"black" criterion. Specifically, I'm using<br>
> nearblack to remove nearly-black areas touching the edges of lossy<br>
> image tiles that should be fully black. Those images are later<br>
> combined into VRT files and warped; where we have multiple tiles<br>
> overlapping an area, some of which are missing data, we therefore can<br>
> get complete coverage.<br>
> <br>
> Unfortunately, for tiles that have no black areas, nearblack is still<br>
> eating the -nb argument's number of pixels at the edges, turning them<br>
> into black (0, 0, 0, 0, where we're using 4-channel images), even if<br>
> those pixels are nowhere near the color criterion to be recognized as<br>
> black. My understanding was that nearblack should only be proceeding<br>
> into the interior of the non-black area and then setting pixels to<br>
> black if those pixels are /actually/ nearly black.<br>
> <br>
> Am I encountering a bug with nearblack? Do I misunderstand how the -nb<br>
> argument works? Happy to provide a MWE if any of the above is unclear,<br>
> and thanks in advance.<br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> <br>
<br>
<br>
-- <br>
Daniel Morissette<br>
Mapgears Inc<br>
T: +1 418-696-5056 #201<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div>Darafei Praliaskouski</div><div>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></div></div></div></div>