[gdal-dev] Nodata and compression artifacts

Simon Shak skunkmyrddyn at gmail.com
Fri Dec 6 08:39:37 PST 2013 

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.
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.

The VRT file I've created is as follows:

<VRTDataset rasterXSize="65457" rasterYSize="56333">
  <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>
  <GeoTransform> 4.2990600000000000e+005, 1.0000000000000000e+000,
0.0000000000000000e+000, 4.9556800000000000e+006,
0.0000000000000000e+000,-1.0000000000000000e+000</GeoTransform>
  <VRTRasterBand dataType="Byte" band="1">
    <ColorInterp>Red</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="65457" RasterYSize="56333"
DataType="Byte" BlockXSize="1024" BlockYSize="128" />
      <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
      <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
    </SimpleSource>
  </VRTRasterBand>
  <VRTRasterBand dataType="Byte" band="2">
    <ColorInterp>Green</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename>
      <SourceBand>2</SourceBand>
      <SourceProperties RasterXSize="65457" RasterYSize="56333"
DataType="Byte" BlockXSize="1024" BlockYSize="128" />
      <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
      <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
    </SimpleSource>
  </VRTRasterBand>
  <VRTRasterBand dataType="Byte" band="3">
    <ColorInterp>Blue</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">RGBFile.sid</SourceFilename>
      <SourceBand>3</SourceBand>
      <SourceProperties RasterXSize="65457" RasterYSize="56333"
DataType="Byte" BlockXSize="1024" BlockYSize="128" />
      <SrcRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
      <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
    </SimpleSource>
  </VRTRasterBand>
  <VRTRasterBand dataType="Byte" band="4">
    <ColorInterp>Alpha</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">mask.tif</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="6545" RasterYSize="5633"
DataType="Byte"/>
      <SrcRect xOff="0" yOff="0" xSize="6545" ySize="5633" />
      <DstRect xOff="0" yOff="0" xSize="65457" ySize="56333" />
    </SimpleSource>
  </VRTRasterBand>
</VRTDataset>


On Mon, Nov 25, 2013 at 3:48 PM, Simon Shak <skunkmyrddyn at gmail.com> wrote:

> 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" <even.rouault at mines-paris.org>
> 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" <even.rouault at mines-paris.org>
>> >
>> > 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131206/0655eed3/attachment.html>

More information about the gdal-dev mailing list