Sorry my phone botched the reply. Meant to say having something like having 9 input files into gdalwarp and needing a cutline for each input to mask their individual Nodata. On Nov 25, 2013 3:44 PM, "Even Rouault" <[email protected]> wrote:
> > > I often have multiple input files and didn't > > see a way to use the cutline option with multiple input cutline. > > You can try merging them into a single OGR layer (with ogr2ogr for example) > > > On Nov 25, 2013 3:33 PM, "Even Rouault" <[email protected]> > > > > wrote: > > > Le lundi 25 novembre 2013 22:29:00, Simon Shak a écrit : > > > > 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. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > 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. > > > > > > You can use the -cutline option of gdalwarp if you have the mask as a > > > shapefile > > > or another OGR datasource. > > > You could also use a VRT file to combine the MrSID imagery and add > > > another band > > > from TIF for example as the alpha/mask band. > > > > > > > > > -- > > > Geospatial professional services > > > http://even.rouault.free.fr/services.html > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
