Below, is a short c++ program that creates a geotiff file.
You can use the two utilities listgeo and tiffdump to take a look at the
geotiff file it creates -- gtest.tif
The difference from TIF is that you use XTIFFOpen instead of TIFFOpen to
open/create a geotiff file.
Thereafter, you can set a small number of geotiff tags, and a large
number of geotiff keys
(keys are stuffed into a single special geotiff tag, so as not to use up
lots of tag space).
Please let me know if there is anything you would like to understand,
better.
I embedded a couple of relevant urls into the code, below.
Thanks
///////////////////////////////////////////////////////////////////////////////////////////////////////
// Both headers are from the geotiff distribution
// http://trac.osgeo.org/geotiff/
#include "geotiffio.h"
#include "xtiffio.h"
int main( void )
{
const char* fileName = "gtest.tif";
const int numCols = 100;
const int numRows = 80;
const int bitsPerSample = 8;
// Defaults: Single channel, One strip
//---------------------------
// Set up the array of bytes to write into the file.
const int size = numCols * numRows;
unsigned char array[ size ];
for( int ind = 0; ind < size; ++ind )
{
array[ ind ] = (unsigned char) ind;
}
//------------------------
// XTIFFOpen is mostly the same as TIFFOpen, but
// makess some geotif tags available.
// These are defined in xtiffFieldInfo in xtif.c
// http://www.remotesensing.org/geotiff/spec/geotiff2.4.html
TIFF* tifp = XTIFFOpen( fileName, "w" );
TIFFSetField( tifp, TIFFTAG_IMAGEWIDTH, numCols );
TIFFSetField( tifp, TIFFTAG_IMAGELENGTH, numRows );
TIFFSetField( tifp, TIFFTAG_BITSPERSAMPLE, bitsPerSample );
// 0 is imaged as black
TIFFSetField( tifp, TIFFTAG_PHOTOMETRIC, 1 );
TIFFWriteEncodedStrip( tifp, 0, array, size );
//---------------------------
// GeoTiff stuff
GTIF* gtifp = GTIFNew( tifp );
GTIFKeySet( gtifp, GTRasterTypeGeoKey, TYPE_SHORT, 1,
RasterPixelIsPoint );
GTIFKeySet( gtifp, GTCitationGeoKey, TYPE_ASCII, 0, "Just An Example" );
GTIFWriteKeys( gtifp );
if( nullptr != gtifp ) GTIFFree( gtifp );
//------------------------
if( nullptr != tifp ) XTIFFClose( tifp );
}// main
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
On 09/03/2014 12:14 PM, Larry Gritz wrote:
I understand, and it's certainly possible... I guess we could have some kind of query
that would return the underlying "native" data pointer. But that is somewhat
against the OIIO philosophy of trying to hide the implementation details and present a
completely generic API regardless of file format.
The kind of situation I'm worried about is that if we change the underlying
implementation, it would break application code. I doubt we'd ever move away from
libtiff, but for other formats, we may want to change the underlying library -- upgrade
versions of the library that has compatibility break (see, the m_tif is not enough, you
might need to know which version of libtiff you had, and maybe more as well), change from
one library to another, write our own, or replace our poorly written one with a 3rd party
library -- and then app code that assumed a particular underlying implementation would be
confused or broken. Yes, that could be a "caveat emptor" situation, the user
accepts the risk of using this back door, but I think that should be a last resort.
I'd prefer to address your problem more directly, by just supporting geotif.
I'm no expert on it, so maybe you can fill in the details. What additional
functionality do you need to read and write correct geotif files? Is it just a
bunch of additional tags that we need to support? Can it be done by choosing a
convention for metadata names for geotif-specific information, and then just
deal with it inside our TIFF reader/writer? (As we've done already for GPS
information or Exif data.)
To be more concrete, suppose you could get the underlying m_tif. Exactly what
would you do with it? What specific calls would you make to do your geotif
work? Maybe we can think of easy ways to support what you hope to accomplish,
without needing to expose the pointer or require the app to directly interface
with libtiff.
-- lg
On Sep 3, 2014, at 11:29 AM, Norman Goldstein <[email protected]> wrote:
Here is an example of what I mean. Maybe I should have
started off my first email this way ...
Inside the OIIO TIFFInput class, is the data member
private:
TIFF *m_tif; ///< libtiff handle
which is the fundamental libtiff structure for managing a tif file.
A wrapper library, such as OIIO, will expose some of the capabilities
offered by TIFF* and libtiff. By allowing the OIIO user/programmer access to
the TIFF* (in a c++ civilized way), it would allow the best of both worlds:
-- The great uniform functionality of OIIO, and
-- For those willing to take the risk (compatibility with OIIO), further
functionality
available through the TIFF structure.
In my case, I am wanting to do geotif stuff. I suppose I could add a new geotif
file format to OIIO, but it really is just a set of tif tags and the such, so I
think it
makes more sense to enhance the current OIIO TIF format implementation.
I would like to use libgeotif in conjunction with the TIFF* .
I would expect that many other image file formats have similar native structures
that could be used to do stuff that is specific to those formats, so this would
be
a general mechanism to access such functionality.
On 09/02/2014 04:54 PM, Larry Gritz wrote:
I'm not quite sure what you mean by "native format functionality". Exactly what
data are you trying to retrieve?
-- lg
On Sep 2, 2014, at 12:43 PM, Norman Goldstein <[email protected]> wrote:
I have looked through OIIO docs and source code,
looking for access to native format functionality that is not exposed,
or accessible, through OIIO -- for example, access to the TIFF structure
when dealing with tif files.
If such functionality, indeed, is not currently pat of OIIO, I will suggest in
a future email how to do that, and with feedback, would consider putting
in that effort of coding. It is not a lot of work. I think the issue is
whether
this should be considered, philosophically, to become part of OIIO.
Thank you.
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
