[gdal-dev] gdalbuildvrt -init 255

[Greg Coats]

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