Opened 19 years ago

Last modified 19 years ago

#666 closed defect (fixed)

CreateCopy on South-Up Images

Reported by: jason.hughes@… Owned by: warmerdam
Priority: high Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description

I've experienced this on Sun and Windows. Upon testing with NITF's and 
GeoTiffs that our exactly south-up using the CreateCopy method flips 
Geolocation data, but not image data.

Using the following code:
GDALDatasetH hSrcDS = GDALOpen( inputFile.c_str(), GA_ReadOnly );
	GDALDatasetH hDstDS;

	if( hSrcDS == NULL)
		return NULL;	

	GDALDriverH hDriver = GDALGetDriverByName( "GTiff" );
	
	hDstDS = GDALCreateCopy( hDriver, output.c_str(), hSrcDS, FALSE, 
                             NULL, NULL, NULL );

Change History (2)

comment:1 by warmerdam, 19 years ago

I ran the following program:

#include "gdal.h"

int main()

{
    GDALAllRegister();

    GDALDatasetH hSrcDS, hDstDS;

    hSrcDS = GDALOpen( "Dali_SouthUp.tif", GA_ReadOnly );
    
    GDALDriverH hDriver = GDALGetDriverByName( "GTiff" );

    hDstDS = GDALCreateCopy( hDriver, "out.tif", hSrcDS, FALSE,
                             NULL, NULL, NULL );

    GDALClose( hDstDS );
    GDALClose( hSrcDS );
}

Against Dali_SouthUp.tif which looks like:
Warning 1: Dali_SouthUp.tif:incorrect count for field "GeoDoubleParams" (0,
expecting 1); tag ignored
Driver: GTiff/GeoTIFF
Size is 640, 414
Coordinate System is `'
GCP Projection = GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.2572235629972,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]
GCP[  0]: Id=1, Info=
          (634,408) -> (-90,45,0)
GCP[  1]: Id=2, Info=
          (634,9) -> (-90,44.9,0)
GCP[  2]: Id=3, Info=
          (21,9) -> (-89.9,44.9,0)
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  414.0)
Upper Right (  640.0,    0.0)
Lower Right (  640.0,  414.0)
Center      (  320.0,  207.0)
Band 1 Block=640x8 Type=Byte, ColorInterp=Red
Band 2 Block=640x8 Type=Byte, ColorInterp=Green
Band 3 Block=640x8 Type=Byte, ColorInterp=Blue

and I get out.tif that looks like this:
Driver: GTiff/GeoTIFF
Size is 640, 414
Coordinate System is `'
GCP Projection = GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.2572235629972,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]
GCP[  0]: Id=1, Info=
          (634,408) -> (-90,45,0)
GCP[  1]: Id=2, Info=
          (634,9) -> (-90,44.9,0)
GCP[  2]: Id=3, Info=
          (21,9) -> (-89.9,44.9,0)
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  414.0)
Upper Right (  640.0,    0.0)
Lower Right (  640.0,  414.0)
Center      (  320.0,  207.0)
Band 1 Block=640x12 Type=Byte, ColorInterp=Red
Band 2 Block=640x12 Type=Byte, ColorInterp=Green
Band 3 Block=640x12 Type=Byte, ColorInterp=Blue

From a georeferencing point of view they seem identical.  I also overlayed
the images in OpenEV and they are both south up. 

So far, I don't see the issue.  Could you verify with similar steps or explain
in more detail why you think the georeferencing is getting messed up?

comment:2 by warmerdam, 19 years ago

I have confirmed the problem.  The issue seems to be that the GeoTIFF
driver always makes the "y" scale positive when writing a tiepoint+scale
configuration GeoTIFF file.  This is appropriate since this configuration
would appear to assume north up. 

The fix is to write a geotransmatrix for southup images (the same as we need
to do for rotated or sheared images). 

Fixed in CVS. 

ps. the reason the TIFF file worked was that it used GCP based control info.
Any geotransform based south up file would have produced the same result if
writing to GeoTIFF. 


Note: See TracTickets for help on using tickets.