Greg Coats a écrit :
I do not think I want the black, opaque areas that gdalbuildvrt is making up
for areas where there is no imagery to become transparent and remain black, I
want them to be white and opaque. Surely, there are many places in the RGB
images where one or more bands is already set to the value 255, and I do not
want to change any legit 255 R, G, B values in the imagery. I do not want to
convert the 1699 RGB images to RGBA. Essentially, I want for gdalbuildvrt what
-init 255 does for gdal_merge.py. But, for now there does not seem to be a way
to do that? Greg
No, basically there's no support in the VRT driver for initializing the
buffer to a non-zero value except if you set a nodata value. I don't see
a theoretical difficulty in extenting but that woud require an addition
to the XML VRT syntax.
I was a bit confused by what your 2 screenshots showed. I know suppose
that they show 2 VRTs layers. So, if I were you, I'd begin by setting
the vrtnodata to 255 and see if the result match your expectations. You
can already do that by manually editing the VRT and adding a
<NoDataValue>255</NoDataValue> just after each <VrtRasterBand> element.
If you blend the result onto a white background, I think this should not
alter visually the result.
There's another workaround I'm just thinking about, but it is a bit more
involved and may lower performance when displaying the VRT. You can
create a totally white GeoTIFF that has the extent of the whole VRT, and
add it first in the VRT. Something like this python script :
import gdal
ds = gdal.Open('source.vrt')
wkt = ds.GetProjectionRef()
gt = ds.GetGeoTransform()
xsize = ds.RasterXSize
ysize = ds.RasterYSize
ds_white = gdal.GetDriverByName('GTiff').Create('white.tif', xsize,
ysize, 3, options = ['TILED=YES', 'COMPRESS=LZW'])
ds_white.SetGeoTransform(gt)
ds_white.SetProjection(wkt)
ds_white.GetRasterBand(1).Fill(255)
ds_white.GetRasterBand(2).Fill(255)
ds_white.GetRasterBand(3).Fill(255)
ds_white = None
If you use a QGIS version that relies on GDAL 1.7.0, you can replace the
creation of the white dataset by :
ds_white = gdal.GetDriverByName('GTiff').Create('white.tif', xsize,
ysize, 3, options = ['TILED=YES', 'SPARSE_OK=YES'])
ds_white.SetGeoTransform(gt)
ds_white.SetProjection(wkt)
ds_white.GetRasterBand(1).SetNoDataValue(255)
ds_white = None
This will create a sparse GeoTIFF that should be very small and when
reading it, GDAL 1.7.0 will initialize the empty blocks with the nodata
value (previous GDAL version would initialize with 0). The rendering of
a VRT referencing that file should be much faster than with the white
geotiff produced by the first solution.
On Jan 4, 2010, at 4:08 PM, Even Rouault wrote:
Greg,
I don't think the issue is really about black or white, but more about setting
nodata appropriately. Basically, if I've well understood your needs, you want
to make some black padding in images transparent. Assuming that your imagery is
RGB, you could try adding -srcnodata 0 to the gdalbuildvrt command line, so
that pixels with value 0 in source imaginery are not drawn in the VRT buffer.
You will also need to specify a -vrtnodata XXX (which is about like -init XXX
of gdal_merge.py, but does more than -init as it sets that value as nodata),
where XXX can be 255 if you want it to be nodata white, but 0 should also do,
but the value should not matter much to QGIS : it should just ignore the pixels
matching the nodata value whichever it is.
You must be aware of the limitation of the nodata concept when working with RGB
imagery however. Nodata is considered band per band, and not as a triplet. I
mean if you have a blue pixel (0,0,255), and you set a nodata value of 255 for
each of the 3 bands, the blue component of (0,0,255) being 255, it will be
considered as nodata for that component... The only proper way to deal with
that is to work with RGBA imagery.
Best regards,
Even
By default, gdal_merge.py starts by creating an output image with all black
pixels, and then replaces these black pixels with pixels from the images being
read in. Passing to gdal_merge.py -init 255 pre-initializes the output image to
all white, instead of all black, pixels.
Similar to gdal_merge.py, gdalbuildvrt fills with black pixels. I am seeking
for gdalbuildvrt, the -init 255 option that gdal_merge.py supports, but do not
see -init 255 as a supported option on the gdalbuildvrt man page. In GDAL
1.7.0, will gdalbuildvrt support -init 255? If not, then in GAL 1.7.0 can the
option -vrtnodata be used in a way similar to how gdal_merge.py supports -init
255? I need areas where there is no image to be white, rather than the black
that gdalbuildvrt is by default setting them to be.
Greg
gdal_merge.py man page
http://www.gdal.org/gdal_merge.html
gdalbuildvrt man page
http://www.gdal.org/gdalbuildvrt.html
gdalbuild_black image
http://homepage.mac.com/gregcoats/jp2/images/gdalbuildvrt_black.png
gdalbuildvrt_white image (simulated)
http://homepage.mac.com/gregcoats/jp2/images/gdalbuildvrt_white.png
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
