transparency of 0 value do not apply to GDAL virtual rasters (vrt)

[pcav]

If I load a virtual raster (BW, TIFF) and I apply full transparency to value 0 (to remove collars), the areas=0 remain white. If I do the same to individual TIFFs, the correctly become transparent: a bug, or a limitation of the VRT format?

[ersts]

Paolo,

I just fired up your vrt dataset on a linux box (Ubuntu 9.04 - stock GDAL) running QGIS trunk r11665.

In the color table, 0 = white (255,255,255) and 1 = black(0,0,0). When I added [0, 100%] to the transparency table all of the white was removed. As I only had your virtual raster loaded I had to change the background of the map canvas to another color, but the transparency seem to work as expected.

Are you running on windows or linux? version 1.3.0?

[pcav]

white collars and transparency settings shown

[pcav]

See the attached image: I set up 100% transparency on 0 value, but the white collars are still shown. Debian, QGIS compiled yesterday from trunk. Thanks.

[lutra]

Hi,

I tested also a different tiff/vrt on ubuntu 9.04 with qgis 1.3 installed from the ubuntugis repositories. Transparency works for any chosen colour on both formats.

[ersts]

Replying to pcav:

See the attached image: I set up 100% transparency on 0 value, but the white collars are still shown.

This is not a transparency issue, it seems to be a registration problem. I turned my map canvas green so I can tell if the transparency is working - making white in the virtual raster 100% transparent - which ends up giving me black on green. See the attached screen grab.

[pcav]

An interesting note from Giovanni Pasini:

With a single band raster map (eg. topographical black/white map) if there is a collar (eg. white border) around the raster, using gdalbuilvrt (and BuildVRT plugin) the result is a vrt file where the map have white strips in overlap area [1]. In this case making little modification in the vrt text file you can obtain a nice result [2]. What is important is to set the NODATA value in vrt for each raster and replace SimpleSource with ComplexSource. I don't remember where I find this trick (mailing list?) and I'm not a gdal guru (vrt specification in gdal web site [3]).

When created the vrt file (via command-line or the very useful new plugin) I run: sed -e 's/<SimpleSource>/<ComplexSource>/g' -e 's/<\/SimpleSource>/ <NODATA>0<\/NODATA>\n <\/ComplexSource>/g' file_created.vrt

and now all is ok. Note that the trasparency of the final map must be set in qgis in the usual manner.

[brushtyler]

This could be a buildvrt bug... I've opened a ticket on GDAL ​ticket. They can add a new param to set which color is blanc (e.g. -nodata 0) or resolve this bug in another way.

[brushtyler]

Replying to brushtyler:

This could be a buildvrt bug... I've opened a ticket on GDAL ​ticket. They can add a new param to set which color is blanc (e.g. -nodata 0) or resolve this bug in another way.

Hi all,
the GDAL bug was closed as fixed in gdal 1.7.0 (the dev version actually in trunk)

Below the ticket closing comment:

---

Enhancement implemented in :

r18146 /trunk/gdal/apps/ (gdal_utilities.dox gdalbuildvrt.cpp): gdalbuildvrt: add -srcnodata and -vrtnodata options, similar to the ones of gdalwarp, to set/override/unset the nodata settings at the source level and the VRTRasterBand level (#3254)

r18147 /trunk/autotest/utilities/test_gdalbuildvrt.py: Add test for -srcnodata option of gdalbuildvrt (#3254)

--> For your use case, 'gdalbuildvrt -srcnodata 0 out.vrt 250010.tif 250020.tif' should do.

---

I think that now, if there isn't other related problems, this ticket should be closed.

[brushtyler]

This is not a QGis bug, but a GDAL enhancement (implemented in gdal 1.7.0.)