# GDAL_TRANSLATE Assumes Picture is Orientated North?

I used gdal_translate to change a jpeg to a geotiff. Attempting to use gdalwarp to create a mosaic I found the images skewed and this lead me to the observation in the title of the question. Below I've posted the line I used to translate and gdalinfo on the new image. Notice that the upper left and lower left longitudes are the same (-76.4303686) and the upper right and upper left latitudes are the same (38.1480727). Is this a flaw/bug or am I doing something wrong?

C:\Users\path\to'Desktop>gdal_translate -a_ullr -76.43036800559511 38.14807271147
146 -76.43183999600483 38.148231283935985 IMG028.jpg img28.tif
Input file size is 400, 267
0...10...20...30...40...50...60...70...80...90...100 - done.

C:\Users\path\to\Desktop>gdalinfo img28.tif
Driver: GTiff/GeoTIFF
Files: img28.tif
Size is 400, 267
Coordinate System is '
Origin = (-76.430368005595113,38.148072711471457)
Pixel Size = (-0.000003679976024,0.000000593904362)
Metadata:
EXIF_BitsPerSample=8 8 8
EXIF_ColorSpace=65535
EXIF_DateTime=2013:11:02 15:13:42
EXIF_ExifVersion=0221
EXIF_Orientation=1
EXIF_PhotometricInterpretation=2
EXIF_PixelXDimension=400
EXIF_PixelYDimension=267
EXIF_ResolutionUnit=2
EXIF_SamplesPerPixel=3
EXIF_Software=Adobe Photoshop CC (Windows)
EXIF_XResolution=(72)
EXIF_YResolution=(72)
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( -76.4303680,  38.1480727)
Lower Left  ( -76.4303680,  38.1482313)
Upper Right ( -76.4318400,  38.1480727)
Lower Right ( -76.4318400,  38.1482313)
Center      ( -76.4311040,  38.1481520)
Band 1 Block=400x6 Type=Byte, ColorInterp=Red
Band 2 Block=400x6 Type=Byte, ColorInterp=Green
Band 3 Block=400x6 Type=Byte, ColorInterp=Blue


I appreciate help. I'm new to GIS and really programming in general. Simple explanations would be helpful and links to where I could have found the solution myself

[EDIT] Thank you for the responses. The pictures were taken from a high altitude and the camera was pointed directly below. The picture is effectively a rectangle. I do not have 'world files.' That being said, I do have information that was read from a GPS unit. The information is: latitude, longitude, altitude, heading (degrees clockwise from North). These co-ordinates are assumed to be at the exact center of the picture. The hard-coded ulx uly, lrx, lry values are a result of trigonometry. They were intended to represent the latitude and longitude of the upper-left and lower-right corners of the picture (which is what I understood GDAL wanted). Thus it might totally be possible that the upper-left corner of the picture is actually more southward than the lower right (i.e. the picture is upside down). I thought GDAL automatically reads the size of the image and assigns proper bounds for the upper right and lower left corners.

I read over the translate docs again and there seem to be no parameters with which I can tell GDAL to read data about orientation using a 'world file.' What methods are available to factor in the rotation of the image? Rather: can someone provide easy-to-read links on how to use gdal_translate properly? Ones that are made for newbies. In particular, multiple methods of factoring in image rotation would be preferred. I do not want to create world files. It would be good if I could somehow factor in rotation using command line flags or something. Additionally, I'm unclear about what a projection is. I know 'projection' is like assigning parameters for what a pixel means in meters and what latitude and longitude means. But something like this is not helpful:

-a_srs srs_def:
Override the projection for the output file. The srs_def may be any of the usual GDAL/OGR forms, complete WKT, PROJ.4, EPSG:n or a file containing the WKT.


Thank you a lot! I will continue to work on projection because I have a few leads but this 'world file' business and image rotation I do not even know where to start. I appreciate it a lot!

• What exactly are you trying to do here? The -a_ullr sets xmin, ymax, xmax, ymin. Everything is as it should be. It appears you may have 'stretched' your image. Were the pixels in the original square? – user10353 Dec 16 '13 at 19:48
• Is your source file mirrored or rotated from North upside? – AndreJ Dec 17 '13 at 12:04

## 2 Answers

GDAL uses a combination of the image projection and any extra parameters such as skew/rotation to determine how an image should be oriented. Those extra parameters can be embedded in the file if the format supports it (like GeoTIFF) or in a separate world file if it not.

The skew or rotation could be coming from information stored in world files along with your jpeg images (usually .wld or .jpgw). Or, you could be missing those files (the images should be rotated but they aren't).

It would also be helpful to assign the proper projection. It may not be what is causing the distortion, but it would be something to rule out.

edit

You may be able to create the world files but you will need to know the pixel resolution and calculate the skew. Your world file should be named exactly the same as the image, but with a different exstention (.wld or .jpgw) and have the following lines:

1. pixel resolution * cos(rotation angle)
2. -pixel resolution * sin(rotation angle)
3. -pixel resolution * sin(rotation angle)
4. -pixel resolution * cos(rotation angle)
5. upper left x
6. upper left y

That may be too difficult given your images and available data. Another approach would be to supply ground control points, with the -gcp option, for each corner of the image and then use gdalwarp to apply them. Essentially, you could georectify your images instead.

• Thank you for the reply. I've made an edit. Your 'world file' theory is probably correct if that is what GDAL uses because I do not even have 'world files!' As I wrote, I thought GDAL automatically does it given the width and length of the image. So how does this work? After I create the 'world' file does GDAL use it automatically? What must it be named? I want to translate the image to reflect the accurate co-ordinates of the upper left, lower left, upper right, lower right corners. If possible I don't want to use world files. – user2316667 Dec 19 '13 at 4:20
• @user2316667 GDAL will automatically use the world files if present. You could create them, but it may be easier to supply ground control points at the corners of your image and use gdalwarp instead. I've edited my answer with more detail. – Evil Genius Dec 19 '13 at 12:27
• Thanks alot! I will accept your answer. One thing though if you get to see this (and sorry for perhaps wasting your time). Setting gcps gives a pixel a lat and long in some specified co-ordinate system. The purpose of a gcp is to transform a dataset from one co-ordinate system to another. But then gdal_warp has to be applied. Why? What does gdal_warp do? In this link below we translate to a geotiff using a co-ordinate system but then apply gdal_warp with the same system. Why? stackoverflow.com/questions/10956818/… – user2316667 Dec 19 '13 at 23:09
• @user2316667 You're very welcome. You are correct, although in your case you are probably using WGS84 for your coordinate system (Lat/Lon). Just assigning the GCPs doesn't actually perform a transformation, it just embeds those coordinates into the image metadata. gdalwarp then uses those GCPs to do the actual transformation (georectifying). If you specify a different coordinate system, then gdalwarp would also reproject it. – Evil Genius Dec 20 '13 at 12:19

The right order of coordinates to assign to the input image is: ulx uly lrx lry, i.e. upper-left x and y, lower-right x and y, as reported in gdal_translate documentation:

-a_ullr ulx uly lrx lry:
Assign/override the georeferenced bounds of the output file. This assigns georeferenced bounds to the output file, ignoring what would have been derived from the source file.

so, considering signs and absolute values of your coordinates, I think that you need simply to switch the two pairs of coordinates after the -a_ullr option:

gdal_translate -a_ullr -76.43183999600483 38.148231283935985 -76.43036800559511 38.14807271147146 IMG028.jpg img28.tif
`