<p dir="ltr">I will look into the vet file. I often have multiple input files and didn't see a way to use the cutline option with multiple input cutline. </p>
<div class="gmail_quote">On Nov 25, 2013 3:33 PM, "Even Rouault" <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le lundi 25 novembre 2013 22:29:00, Simon Shak a écrit :<br>
> I’m working with gdalwarp to reprocess a large amount of imagery to be<br>
> compatible with another program that requires imagery to be in WGS84.  The<br>
> input imagery is compressed in MrSID format and does not include an<br>
> internal mask for nodata.  I don’t know if this is because the creator of<br>
> the imagery overlooked it, or if the format doesn’t support a mask.  Either<br>
> way, when I attempt to merge neighboring sets, I get odd bands of dark<br>
> color.  I’ve looked closely, and it is evident because at the edge of the<br>
> images are non 100% black pixels, that though I’m sending –srcnodata 0 into<br>
> gdalwarp, they get read as pixels and progress through.  I’ve looked into<br>
> using the nearblack command on the files first, but the compression ratio<br>
> of the .SID files makes it such that the files don’t easily fit into my<br>
> hard drive array for pre-nearblacking them before processing, plus the<br>
> physical size of some of these files are large enough that the nearblack<br>
> takes a long time to run.  Without the nearblack step, my multithreaded<br>
> control script can process one chunk in a day, but adding the nearblack,<br>
> and it increases to a week at least.<br>
><br>
><br>
><br>
> I’m looking for a solution that would not require making a large interim<br>
> uncompressed version and would hopefully not incur a lengthy additional<br>
> process.<br>
><br>
><br>
><br>
> The simpler thoughts I have would be to adjust gdalwarp’s –srcnodata to<br>
> take a range option, much like nearblack, so that if it detects a pixel<br>
> (even in the middle) that is with the range specified would get ignored, or<br>
> a way to include an ancillary file that could contain a mask.  Either would<br>
> work for me, I have potential ways to quickly generate a mask for the input<br>
> files.  I’d think the mask could work much like .TIF can have a .TFW, that<br>
> a .MSK could be detected as well.<br>
<br>
You can use the -cutline option of gdalwarp if you have the mask as a shapefile<br>
or another OGR datasource.<br>
You could also use a VRT file to combine the MrSID imagery and add another band<br>
from TIF for example as the alpha/mask band.<br>
<br>
<br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</blockquote></div>