[gdal-dev] Nodata and compression artifacts

Simon Shak skunkmyrddyn at gmail.com
Mon Nov 25 13:48:14 PST 2013


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/20131125/3d9daeae/attachment.html>


More information about the gdal-dev mailing list