[gdal-dev] GDAL Byte Swapping?

[Trist, Brenda R.]

Even,

I knew of big and little endian but never knew how to tell the difference.  The original geotiff dem is little endian (II).  I have been comparing the two and for the most part the data is there it is just swapped.  The reason I did not use GDAL NITF is because at the time (January) I started writing this software I found NITRO NITF had all the routines necessary to write all the various header formats to a nitf file along with the dem data, PIAPRD TRE, and XML DE Segment.  I just in the past week incorporated GDAL in the mix because the libgeotiff/libtiff library routines could not handle 32bit imagery.  I had been testing with 8bit imagery by mistake and found I needed 32bit.  I just downloaded this 32bit today to further my testing.

Thank you,
Becky Trist

SAIC
100 Rialto Place, Suite 200
Melbourne, FL  32901
321-751-3236

“Sometimes you have to look reality in the eye, and deny it.”   - Garrison Keillor


-----Original Message-----
From: Even Rouault [mailto:even.rouault at mines-paris.org] 
Sent: Thursday, June 14, 2012 3:41 PM
To: gdal-dev at lists.osgeo.org
Cc: Trist, Brenda R.
Subject: Re: [gdal-dev] GDAL Byte Swapping?

Le jeudi 14 juin 2012 21:26:09, Trist, Brenda R. a écrit :
> I am new to GDAL.  I recently downloaded GDAL have successfully built
> 
> and linked to the source.  The program I am writing reads in a
> 
> GeoTiff DEM (32bit format) and writes the dem data portion out to a
> 
> ntif file (using NITRO NITF routines from sourceforge).
> 
> I then ran the command od -c on the tif file I am reading and on the
> 
> ntif I just created to compare the DEM data area.  I noticed that
> 
> while the data is there that the bytes appear to have been swapped.
> 
> I am assuming that I don't want it to do that.  I was wondering if
> 
> anyone has encountered this same thing and if there is something that
> 
> I should be doing differently?  I researched the bug list and all
> 
> mentions of byteswapping pretty much have been closed due to being
> 
> fixed.  So I am assuming that I must be doing something wrong at my end.

On little endian (Intel like) architectures, TIFF files with multi-byte data types are (generally) written in little endian ordering (if the first 2 bytes of the TIFF files are "II", then it's little endian. If it's "MM", then it's big endian). Whereas in NITF, it is always big endian. So what you are seeing is likely expected.

You could compare that the 2 files contain the same data values (taking into account the byte swapping if needed) by checking the checksum value reported "gdalinfo -checksum thefile" 

Any reason not to use the GDAL NITF driver by the way ?