[gdal-dev] gdalbuildvrt -init 255
Even Rouault
even.rouault at mines-paris.org
Mon Jan 4 18:10:10 EST 2010
Even Rouault a écrit :
Well, actually, I can propose a 3rd solution that should work with any
recent GDAL version to produce a white & small raster.
1) Copy your source.vrt as white.vrt
2) Add a <NoDataValue>255</NoDataValue> line after each <VrtRasterBand>
3) Remove all existing <SimpleSource> content
So basically you get something as simple as that :
<VRTDataset rasterXSize="20" rasterYSize="20">
<SRS>PROJCS["NAD27 / UTM zone
11N",GEOGCS["NAD27",DATUM[&q
uot;North_American_Datum_1927",SPHEROID["Clarke
1866",6378206.4,2
94.9786982138982,AUTHORITY["EPSG","7008"]],AUTHORITY["E
PSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree&q
uot;,0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTIO
N["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],P
ARAMETER["central_meridian",-117],PARAMETER["scale_factor",0
.9996],PARAMETER["false_easting",500000],PARAMETER["false_northin
g",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]
],AUTHORITY["EPSG","26711"]]</SRS>
<GeoTransform> 4.4072000000000000e+005, 6.0000000000000000e+001,
0.00000000000
00000e+000, 3.7513200000000000e+006,
0.0000000000000000e+000,-6.0000000000000000
e+001</GeoTransform>
<VRTRasterBand dataType="Byte" band="1">
<NoDataValue>255</NoDataValue>
</VRTRasterBand>
<VRTRasterBand dataType="Byte" band="2">
<NoDataValue>255</NoDataValue>
</VRTRasterBand>
<VRTRasterBand dataType="Byte" band="3">
<NoDataValue>255</NoDataValue>
</VRTRasterBand>
</VRTDataset>
Then recreate your main VRT by adding white.vrt as the first dataset
(with GDAL 1.7.0 gdalbuildvrt, you would need to specify -srcnodata None
so that the nodatavalue of white.vrt is just considered as white and not
processed as a nodata value by the rendering layer of the main VRT... of
course !)
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
More information about the gdal-dev
mailing list