3

I am trying to create a geotiff from a jpeg by inputting gcps with gdal_translate:

gdal_translate -of GTiff -a_srs EPSG:4326 -gcp [1616.0 0 -121.459869532 38.5822533549] -gcp [0 0 -121.460081357 38.5831052365] -gcp [0 1080.0 -121.460807872 38.5829948432] -gcp [1616.0 1080.0 -121.460596039 38.582142963] pict20140910_131103_0.JPG tmp.tif

followed by gdalwarp to set the geotiff projection:

gdalwarp -s_srs EPSG:4326 -t_srs EPSG:4326 tmp.tif geo_pict20140910_131103_0.tif

however the gdalwarp process fails with:

ERROR 1: Failed to compute GCP transform: Transform is not solvable.

The gcp coordinates are the image footprint vertices and were calculated using the image location, altitude, orientation and camera attributes. The gcps are in lat/lon (wgs84 epsg:4326), and the image size is 1616x1080.

Here is the gdalinfo for the file after gcps have been added, but before gdalwarp:

Driver: GTiff/GeoTIFF
Files: tmp.tif
Size is 1616, 1080
Coordinate System is `'
GCP Projection = 
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
GCP[  0]: Id=1, Info=
          (0,0) -> (-121.459869532,38.5822533549,0)
GCP[  1]: Id=2, Info=
          (0,0) -> (-121.460081357,38.5831052365,0)
GCP[  2]: Id=3, Info=
          (0,1079) -> (-121.460807872,38.5829948432,0)
GCP[  3]: Id=4, Info=
          (0,1079) -> (-121.460596039,38.582142963,0)
Metadata:
  AREA_OR_POINT=Area
  EXIF_BrightnessValue=(4.275)
  EXIF_ColorSpace=1
  EXIF_ComponentsConfiguration=0x1 0x2 0x3 00
  EXIF_CompressedBitsPerPixel=(3)
  EXIF_Contrast=0
  EXIF_CustomRendered=0
  EXIF_DateTime=2014:09:10 13:11:02
  EXIF_DateTimeDigitized=2014:09:10 13:11:02
  EXIF_DateTimeOriginal=2014:09:10 13:11:02
  EXIF_DigitalZoomRatio=(1)
  EXIF_ExifVersion=0230
  EXIF_ExposureBiasValue=(0)
  EXIF_ExposureMode=0
  EXIF_ExposureProgram=4
  EXIF_ExposureTime=(0.001)
  EXIF_FileSource=0x3
  EXIF_Flash=16
  EXIF_FlashpixVersion=0100
  EXIF_FNumber=(4)
  EXIF_FocalLength=(16)
  EXIF_FocalLengthIn35mmFilm=24
  EXIF_GPSAltitude=(66)
  EXIF_GPSAltitudeRef=00
  EXIF_GPSImgDirection=(79)
  EXIF_GPSImgDirectionRef=T
  EXIF_GPSLatitude=(38) (34) (57.45)
  EXIF_GPSLatitudeRef=N
  EXIF_GPSLongitude=(121) (27) (37.22)
  EXIF_GPSLongitudeRef=W
  EXIF_GPSVersionID=0x2 0x3 00 00
  EXIF_Interoperability_Index=R98
  EXIF_Interoperability_Version=0x30 0x31 0x30 0x30
  EXIF_ISOSpeedRatings=2000
  EXIF_LightSource=0
  EXIF_Make=SONY
  EXIF_MaxApertureValue=(2.96875)
  EXIF_MeteringMode=5
  EXIF_Model=NEX-5T
  EXIF_Orientation=1
  EXIF_PixelXDimension=1616
  EXIF_PixelYDimension=1080
  EXIF_ResolutionUnit=2
  EXIF_Saturation=0
  EXIF_SceneCaptureType=0
  EXIF_SceneType=0x1
  EXIF_Sharpness=0
  EXIF_Software=NEX-5T v1.01
  EXIF_WhiteBalance=0
  EXIF_XResolution=(350)
  EXIF_YCbCrPositioning=2
  EXIF_YResolution=(350)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0, 1080.0)
Upper Right ( 1616.0,    0.0)
Lower Right ( 1616.0, 1080.0)
Center      (  808.0,  540.0)
Band 1 Block=1616x1 Type=Byte, ColorInterp=Red
Band 2 Block=1616x1 Type=Byte, ColorInterp=Green
Band 3 Block=1616x1 Type=Byte, ColorInterp=Blue
  • that image has two 0,0's and both the others are lower right, that's not what was in the gdal_translate.. what's up with that? Perhaps do the 0,0 first then follow with UL, UR and finally LR. – Michael Stimson Apr 16 '15 at 1:59
  • yup, well spotted - seems like the gcp pixel x-dimension (1616) is not coming through properly (the same happens when I just add one gcp in at a time) - any idea whatI'm doing wrong? – jeremyeastwood Apr 16 '15 at 2:37
  • I don't know why it's not keeping the values you set. Perhaps it expects them in a particular order, I'd have to go to the source code to see if there's something there. – Michael Stimson Apr 16 '15 at 3:59
  • 2
    Order of ground control points does not matter but perhaps the brackets [ ] make it to fail. I tried with gdal_translate -of GTiff -a_srs EPSG:4326 -gcp 1616.0 0 -121.459869532 38.5822533549 -gcp 0 0 -121.460081357 38.5831052365 -gcp 0 1080.0 -121.460807872 38.5829948432 -gcp 1616.0 1080.0 -121.460596039 38.582142963 pict20140910_131103_0.JPG tmp2.tifand gdalwarp for tmp2 was a success. – user30184 Apr 16 '15 at 8:18
  • @user30184 that's sage advice, can you make that into an answer. – Michael Stimson Apr 16 '15 at 22:14
5

The gdal_translate document page http://www.gdal.org/gdal_translate.html may indeed give an impression that the values for Ground Control Points should be closed between brackets

[-gcp pixel line easting northing [elevation]]*

However, that is not the case as close reading reveals and correct syntax for your case is

gdal_translate -of GTiff -a_srs EPSG:4326 -gcp 1616.0 0 -121.459869532 38.5822533549 -gcp 0 0 -121.460081357 38.5831052365 -gcp 0 1080.0 -121.460807872 38.5829948432 -gcp 1616.0 1080.0 -121.460596039 38.582142963 pict20140910_131103_0.JPG tmp.tif

That gdal_translate accepts the input with brackets without sending an error message and makes on invalid output as a result may be considered as a bug. Write a mail to gdal-dev mailing list and ask an opinion.

A hint for the future: The best format to use for the interim result is GDAL Virtual raster .VRT http://www.gdal.org/gdal_vrttut.html. It is a small text file that has only a reference to the physical image file. Because image data is not copied you will get the result faster and save disk space. In the next step you just warp the VRT file.

gdalwarp -s_srs EPSG:4326 -t_srs EPSG:4326 tmp.vrt geo_pict20140910_131103_0.tif

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.