[Gdal-dev] Creation of geotiff files with gdalwarp that have a
transparent background
Eric Sokolowsky
eric.sokolowsky at gsfc.nasa.gov
Mon Mar 1 18:31:20 EST 2004
On Mon, 1 Mar 2004, Frank Warmerdam wrote:
> Eric Sokolowsky wrote:
> > I have been experimenting with the gdal library, specifically the
> > gdalwarp tool included with the library. It is very useful, and I have
> > been able to transform images to a geographic projection. Is there is a
> > way to specify a default background color? Specifically, I wish to
> > create a geotiff file where the areas not covered by the original source
> > file are transparent. Is this possible, or do I need to start hacking
> > gdal? Would this change be generally useful to others?
> >
>
> Eric,
>
> The default output value of a raster can be set with the INIT_DEST
> warp options.
>
> eg.
>
> gdalwarp in.tif out.tif -t_srs WGS84 -wo INIT_DEST=255
This is a useful option, and I had missed it. Thanks for pointing it
out. But, as you say below, it can't be used to add alpha to an image
that didn't have it before.
> The arguments can be a list of values if you want to apply different
> values to different output bands. The default is to set all output bands
> to zero.
>
> One issue you face is how to make something transparent in
> TIFF format. TIFF supports transparency if you use RGBA format. That
> is four bands with red, green, blue and alpha (transparency). But if
> your inputs is just RGB there is no obvious way to force gdalwarp to
> produce an RGBA output file, and to treat the alpha band as a proper
> transparency overlay.
Yes, I gathered this from the documentation and the source. I was just
wondering if I had missed something.
> The underlying Warp API does contain mechanisms whereby an application
> might be able to maintain an alpha band properly, but the gdalwarp
> program has no mechanism to take advantage of it. Furthermore, this
> hasn't really be used in the warp api so there may be issues I didn't
> anticipate.
>
> Currently, the gdalwarp assumption is that nodata pixel values will be
> used to mark unset areas. So that might involve picking a "background"
> value, like 0, to mark all unset areas. INIT_DEST could be used to
> pre-apply this to the output file if a non-zero value were used. Then
> the warper would replace all pixels for which a value exists. No mechanism
> exists to ensure that the nodata value doesn't existing in the valid image
> data though.
>
> I think it would make sense to modify gdalwarp to explicitly support
> transparency layers. Some common forms I could imagine are:
>
> o An extra output band used to hold transparency. Normally this would
> be assigned 0 to unset pixels and 255 for set pixels.
This limited support would be perfectly adequate for my purposes.
> o A seperate validity file.
This would not be as useful because then I would have to combine it with
my image separately.
> Both mechanisms should also be supported on input, in addition to the
> current -srcnodata switch.
>
> Implementing these capabilities would be a fair amount of work, likely at
> least a day. I don't forsee getting to it in the near future, but if you
> have a pressing need I might be able to do a quick effort sufficient to
> your needs.
Well, I certainly appreciate the support. My need is not extremely pressing
at this time. (This may change after the staff meeting tomorrow.) As I
was looking at the source code for the geotiff format, I saw that there
are only a few places where the number of bands (nBands), so I was going
to try to see if I could add minimal support myself. Since I am only
concerned about geotiff output, I would localize all changes there.
--
____ __ Eric Sokolowsky (GST) NASA Goddard Space Flight Center
/ __/__/_/__ Visualization Programmer Scientific Visualization Studio
/ __/ _/ / _/ 301.286.3751 Mailstop 935.0 Bldg 28 Rm E102
/___/_//_/__/ eric.sokolowsky at gsfc.nasa.gov Greenbelt, MD 20771
More information about the Gdal-dev
mailing list