On Jun 6, 2009, at 1:37 PM, Even Rouault wrote:
William,
you didn't mention how you have generated the VRT. If it's with
gdalbuildvrt,
Yes, gdalbuildvrt.
I've just commited a change in trunk (r17201) that probably solves
your
issue. It appears that when a source has a nodata value, it is not
sufficient
to set it at the VRTRasterBand level. It must also been specified
for each
source by using a ComplexSource instead of a SimpleSource, so that
nodata
pixels from the source are not drawned on the destination buffer.
Will you be backporting this to 1.6 then? Then I can get it into my
GDAL framework binaries for OSX until a future 1.6.2 release.
You can fix your VRT manually by replacing all SimpleSource
references by
ComplexSource and by adding a <NODATA>256</NODATA> inside each
<ComplexSource> element.
This did the trick. thanks.
Note that with qgis from svn trunk, I could manage to make it display
correctly RGB images whose bands are of type UInt16 (it displayed only
black), even when specifying the value range as 0...255 instead of the
default 0...65535. I had to edit manually the VRT so that the
VRTRasterBands
are declared as Byte. This appears to be a qgis issue/feature, as
openev can
display correctly the same VRT.
gdal_translate also had the missing nulls. With the manually fixed
vrt above, gdal_translate and Qgis 1.1 display correctly.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Mon Dieu! but they are all alike. Cheating, murdering, lying,
fighting, and all for things that the beasts of the jungle would not
deign to possess - money to purchase the effeminate pleasures of
weaklings. And yet withal bound down by silly customs that make them
slaves to their unhappy lot while firm in the belief that they be the
lords of creation enjoying the only real pleasures of existence....
- the wisdom of Tarzan
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
