[gdal-dev] Random questions about GDAL file formats

Frank Warmerdam warmerdam at p...
Mon Feb 26 21:49:23 EST 2001


Simon Perkins wrote:
> 
> Hi,
> 
> (1) For a while I've been looking for a non-proprietary image format
> that supports multi-spectral imagery in a standard way. In theory TIFF
> would seem like a good candidate since it allows the samplesPerPixel tag
> to be set to an aribtrary number. I think GDAL supports this (from
> looking at the source code - haven't tried it yet), but I have yet to
> find any other packages, including GIS / image processing systems that
> recognize this tag. Does anyone know which standard image processing/GIS
> packages support multispectral TIFF? Or is there some other
> non-proprietary multispectral format that is more widely understood?
> Multispectral PNG anyone?

Simon, 

I am reasonably sure that PCI, Erdas and Intergraph all have some degree
of support for SamplerPerPixel other than 1. In part this is driven by
USGS DEMs and Space Imaging data distributed as sixteen bits per pixel. 

I am also pretty sure that PCI, Intergraph and Erdas support an arbitrary
number of bands in TIFF. 

> (2) When using TIFF with GDAL, what compression is used as standard? Is
> there any way of adjusting this?

None compression is standard. The COMPESS=[JPEG,LZW,PACKBITS,DEFLATE,NONE]
option can be used to set the compression. I think I normally build without
LZW support enabled. 

On the gdal_translate command line this would be accomplished with the
-co (create option) commandline switch. 

ie. 
gdal_translate -co "COMPRESS=JPEG" irvine.tif irvine_jpeg.tif

The creation options are all visible on the TIFF help page at:

http://www.remotesensing.org/gdal/frmt_gtiff.html

> (3) I've written a couple of remote-sensing image applications that use
> FITS as a multispectral file format. FITS is really an astronomy format,
> but it's simple, non-proprietary, reasonably easy to find tools for, and
> supports multispectral images as standard. I'd like to start using GDAL
> to support more standard formats, but I'd also like to preserve support
> for FITS for backward compatibility. Would anyone be interested in a
> GDAL driver for FITS based on the standard cfitsio library?

I would be pleased to have FITS support in GDAL, but I see the cfitsio
library is a substantial chunk of code. Would you approach this by
adding something to configure to search for libcfitsio.a, and determine
based on that whether to configure in fits support? 

Would you like some help setting up a code skeleton for fits support
that you could glue the detailed calls into? 

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list