[gdal-dev] gdalbuildvrt -init 255

[Even Rouault]

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