[gdal-dev] gdalbuildvrt -init 255

Greg Coats gregcoats at mac.com
Mon Jan 4 17:24:58 EST 2010


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

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


More information about the gdal-dev mailing list