<div dir="ltr">Off topic but I've found that gdal_rasterize.py the best method for dealing with this type of issue.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Feb 2019 at 10:22, 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">That's a great point. So it's not a bug, it is a feature in some cases. :)<br>
<br>
Maybe what we need is an option to switch between the two behaviors then.<br>
<br>
<br>
<br>
On 2019-02-20 8:23 a.m., Darafei "Komяpa" Praliaskouski wrote:<br>
> I believe this behavior is great for over-compressed imagery JPEGs where <br>
> you have corrupted border of several "black-poisoned" non-black pixels <br>
> that you'd better remove and take from some other image in the mosaic, <br>
> since in this scenario you usually have an overlap.<br>
> <br>
> On Wed, Feb 20, 2019 at 4:16 PM Daniel Morissette <br>
> <<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a> <mailto:<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a>>> wrote:<br>
> <br>
> I noticed this behavior as well and I think it's a bug. I think it<br>
> 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<br>
> the -nb<br>
> > argument works? Happy to provide a MWE if any of the above is<br>
> 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> <mailto:<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> <mailto:<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>
> Darafei Praliaskouski<br>
> Support me: <a href="http://patreon.com/komzpa" rel="noreferrer" target="_blank">http://patreon.com/komzpa</a><br>
> <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>