<p dir="ltr"><br>
I’m working with gdalwarp to reprocess a large amount of imagery to be compatible with another program that requires imagery to be in WGS84.  The input imagery is compressed in MrSID format and does not include an internal mask for nodata.  I don’t know if this is because the creator of the imagery overlooked it, or if the format doesn’t support a mask.  Either way, when I attempt to merge neighboring sets, I get odd bands of dark color.  I’ve looked closely, and it is evident because at the edge of the images are non 100% black pixels, that though I’m sending –srcnodata 0 into gdalwarp, they get read as pixels and progress through.  I’ve looked into using the nearblack command on the files first, but the compression ratio of the .SID files makes it such that the files don’t easily fit into my hard drive array for pre-nearblacking them before processing, plus the physical size of some of these files are large enough that the nearblack takes a long time to run.  Without the nearblack step, my multithreaded control script can process one chunk in a day, but adding the nearblack, and it increases to a week at least.</p>

<p dir="ltr"> </p>
<p dir="ltr">I’m looking for a solution that would not require making a large interim uncompressed version and would hopefully not incur a lengthy additional process.</p>
<p dir="ltr"> </p>
<p dir="ltr">The simpler thoughts I have would be to adjust gdalwarp’s –srcnodata to take a range option, much like nearblack, so that if it detects a pixel (even in the middle) that is with the range specified would get ignored, or a way to include an ancillary file that could contain a mask.  Either would work for me, I have potential ways to quickly generate a mask for the input files.  I’d think the mask could work much like .TIF can have a .TFW, that a .MSK could be detected as well.</p>