Frank, Yes I have written my own program using the tools created by others. I went with NITRO NITF to write the data because it had all the necessary header routines (File Header, Security, Image Header, PIAPRD TRE and XML DE Segment and CSSHPA Segment) at my disposal. I am not one to reinvent the wheel. When I have been testing I unfortunately was testing with 8bit data. So when I tested on 32bit data it did not work. I was using libgeotiff/libtiff libraries. So a week ago I started my search on other libraries that could possibly handle what I am doing. That is when I came across GDAL. I downloaded a dem geotiff (32bit) today to further my testing. Then I noticed the byte swapping. Thanks for explaining to me the difference. The original file is little endian.
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: [email protected] [mailto:[email protected]] On Behalf Of Frank Warmerdam Sent: Thursday, June 14, 2012 3:42 PM To: Trist, Brenda R. Cc: [email protected] Subject: Re: [gdal-dev] GDAL Byte Swapping? On Thu, Jun 14, 2012 at 12:26 PM, Trist, Brenda R. <[email protected]> wrote: > 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. Brenda, I'm guessing you have written your own program that uses GDAL to read the GeoTIFF and Nitro to write the NITF but not using the GDAL NITF driver. Is that right? Assuming the answer is yes, then the only question is what does GDAL do when reading from a GeoTIFF into a memory buffer for non-8bit data. The answer is that the GeoTIFF driver analyses the byte ordering of the GeoTIFF which will start with II if it is little endian (Intel order) or MM if it is big endian (ie. motorola order). The GeoTIFF driver will then byte swap the image data if needed to bring it into the native byte order of the machine on which the program is run. This is well established machinery so I have no reason to believe it would be broken. You might want to check if NITRO expects it's image pixel input in machine local order or some other order. Peeking into the GDAL NITF driver it appears that 16bit data in NITF is normally in big endian format. So if NITRO expects you to pass in the image buffer in big endian order and you are running on Intel you may need to byte swap things in your program. Best regards, -- ---------------------------------------+-------------------------------- ---------------------------------------+------ I set the clouds in motion - turn up | Frank Warmerdam, [email protected] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Software Developer _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
