The black image shows the result of the gdalbuildvrt. Please note the large black areas near the western edge of the canvas, which are created as a result of the gdalbuildvrt, and not being able to specify -init 255 for a white canvas. The white image shows how it would look if I could pass -init 255 for a white canvas to gdalbuildvrt, as I do to gdal_merge.py. Greg
gdalbuildvrt black image http://homepage.mac.com/gregcoats/jp2/images/gdalbuildvrt_black.png gdalbuildvrtwhite image (simulated) http://homepage.mac.com/gregcoats/jp2/images/gdalbuildvrt_white.png On Jan 4, 2010, at 5:59 PM, Even Rouault wrote: > I was a bit confused by what your 2 screenshots showed. I know suppose that > they show 2 VRTs layers. On Jan 4, 2010, at 5:59 PM, Even Rouault wrote: > 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
