<div dir="ltr">I'm trying to get the VRT file to work. I used gdalbuildvrt to create the information from both files, and then by hand performed a merge of the extra band into the original, but when I try to use gdal_translate or gdalwarp to test if the files are reading appropriately, I'm getting an "empty" file with enough filesize to have all the pixels. Viewing it shows nothing even if I remap the bands.<div>
My process is I take the .sid, use gdal_translate to scale it down into an uncompressed GTiff so I can create a mask efficiently (I know it won't be a 100% match, but this should work for my purposes). I use imagemagick to create the alpha channel and save it to the mask.tif and then another gdal_translate to rebind the geotag into the tif.</div>
<div><br></div><div>The VRT file I've created is as follows:</div><div><br></div><div><div><VRTDataset rasterXSize="65457" rasterYSize="56333"></div><div> <SRS>PROJCS["NAD83 / UTM zone 10N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.2572221010002,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-123],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26910"]]</SRS></div>
<div> <GeoTransform> 4.2990600000000000e+005, 1.0000000000000000e+000, 0.0000000000000000e+000, 4.9556800000000000e+006, 0.0000000000000000e+000,-1.0000000000000000e+000</GeoTransform></div><div> <VRTRasterBand dataType="Byte" band="1"></div>
<div> <ColorInterp>Red</ColorInterp></div><div> <SimpleSource></div><div> <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename></div><div> <SourceBand>1</SourceBand></div>
<div> <SourceProperties RasterXSize="65457" RasterYSize="56333" DataType="Byte" BlockXSize="1024" BlockYSize="128" /></div><div> <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div>
<div> <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div><div> </SimpleSource></div><div> </VRTRasterBand></div><div> <VRTRasterBand dataType="Byte" band="2"></div>
<div> <ColorInterp>Green</ColorInterp></div><div> <SimpleSource></div><div> <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename></div><div> <SourceBand>2</SourceBand></div>
<div> <SourceProperties RasterXSize="65457" RasterYSize="56333" DataType="Byte" BlockXSize="1024" BlockYSize="128" /></div><div> <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div>
<div> <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div><div> </SimpleSource></div><div> </VRTRasterBand></div><div> <VRTRasterBand dataType="Byte" band="3"></div>
<div> <ColorInterp>Blue</ColorInterp></div><div> <SimpleSource></div><div> <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename></div><div> <SourceBand>3</SourceBand></div>
<div> <SourceProperties RasterXSize="65457" RasterYSize="56333" DataType="Byte" BlockXSize="1024" BlockYSize="128" /></div><div> <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div>
<div> <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div><div> </SimpleSource></div><div> </VRTRasterBand></div><div> <VRTRasterBand dataType="Byte" band="4"></div>
<div> <ColorInterp>Alpha</ColorInterp></div><div> <SimpleSource></div><div> <SourceFilename relativeToVRT="1">mask.tif</SourceFilename></div><div> <SourceBand>1</SourceBand></div>
<div> <SourceProperties RasterXSize="6545" RasterYSize="5633" DataType="Byte"/></div><div> <SrcRect xOff="0" yOff="0" xSize="6545" ySize="5633" /></div>
<div> <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" /></div><div> </SimpleSource></div><div> </VRTRasterBand></div><div></VRTDataset></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 25, 2013 at 3:48 PM, Simon Shak <span dir="ltr"><<a href="mailto:skunkmyrddyn@gmail.com" target="_blank">skunkmyrddyn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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. </p>
<div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Nov 25, 2013 3:44 PM, "Even Rouault" <<a href="mailto:even.rouault@mines-paris.org" target="_blank">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">
<br>
> I often have multiple input files and didn't<br>
> see a way to use the cutline option with multiple input cutline.<br>
<br>
You can try merging them into a single OGR layer (with ogr2ogr for example)<br>
<br>
> On Nov 25, 2013 3:33 PM, "Even Rouault" <<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>><br>
><br>
> wrote:<br>
> > 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.<br>
> ><br>
> > The<br>
> ><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<br>
> > > of the imagery overlooked it, or if the format doesn’t support a mask.<br>
> ><br>
> > Either<br>
> ><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<br>
> > > the images are non 100% black pixels, that though I’m sending<br>
> > > –srcnodata 0<br>
> ><br>
> > into<br>
> ><br>
> > > gdalwarp, they get read as pixels and progress through. I’ve looked<br>
> > > into using the nearblack command on the files first, but the<br>
> > > compression ratio of the .SID files makes it such that the files don’t<br>
> > > easily fit into my hard drive array for pre-nearblacking them before<br>
> > > processing, plus the physical size of some of these files are large<br>
> > > enough that the nearblack takes a long time to run. Without the<br>
> > > nearblack step, my multithreaded control script can process one chunk<br>
> > > in a day, but adding the nearblack, and it increases to a week at<br>
> > > least.<br>
> > ><br>
> > ><br>
> > ><br>
> > > I’m looking for a solution that would not require making a large<br>
> > > interim uncompressed version and would hopefully not incur a lengthy<br>
> > > additional 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<br>
> > > ignored,<br>
> ><br>
> > or<br>
> ><br>
> > > a way to include an ancillary file that could contain a mask. Either<br>
> ><br>
> > would<br>
> ><br>
> > > work for me, I have potential ways to quickly generate a mask for the<br>
> ><br>
> > input<br>
> ><br>
> > > files. I’d think the mask could work much like .TIF can have a .TFW,<br>
> ><br>
> > that<br>
> ><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<br>
> > shapefile<br>
> > or another OGR datasource.<br>
> > You could also use a VRT file to combine the MrSID imagery and add<br>
> > 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>
<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>
</div></div></blockquote></div><br></div>