[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