[Qgis-user] Georeferencer 3.1.9 bug (?) and work-around

[Alister Hood]

Sorry,
My comment was at the bottom... not sure how it got a >  in front of it.


Date: Fri, 10 Jun 2011 12:54:51 +1200
From: "Alister Hood" <alister.hood at synergine.com>
Subject: [Qgis-user] Georeferencer 3.1.9 bug (?) and work-around
To: <qgis-user at lists.osgeo.org>,	<qgis-user at lists.osgeo.org>
Message-ID:
	<AAFD34025E073F47B5F892A97BAFFCAA03E320 at aklserver02.Synergine.local>
Content-Type: text/plain; charset="iso-8859-1"

Hi there,
 
> Date: Wed, 8 Jun 2011 18:04:04 -0400
> From: O <mondifero at gmail.com>
> Subject: [Qgis-user] Georeferencer 3.1.9 bug (?) and work-around
> To: qgis-user <qgis-user at lists.osgeo.org>
> Message-ID: <BANLkTini-WMi3_g=KaxbgOQDX9naqHPUPg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear QGIS users,
> 
> Summary: I'm running the Georeferencer plugin 3.1.9 with QGIS 1.6.0 and it
> doesn't work correctly -- the raster is distorted and plotted in the wrong
> location. However, I found a work-around that fools the plugin into giving
> correct results, and appears to point out a serious bug in the plugin. (Or,
> I'm
> doing something wrong -- please let me know.)
> 
> (And please tell me if I've posted this in the wrong place.)
> 
> Suppose I have an image called "input.tif" that has some geospatial metadata
> with a CRS and image bounds. For the following discussion, here are the
> relevant lines that result from running "gdalinfo input.tif":
> 
> Size is 1101, 1091
> ...
> Upper Left ( 4578.469, -13361.035) ( 5d26'57.36"W, 2d10'18.28"S)
> Lower Left ( 4578.469, -13652.219) ( 5d26'57.36"W, 2d10'35.98"S)
> Upper Right ( 4872.322, -13361.035) ( 5d26'39.49"W, 2d10'18.28"S)
> Lower Right ( 4872.322, -13652.219) ( 5d26'39.49"W, 2d10'35.98"S)
> Center ( 4725.395, -13506.627) ( 5d26'48.43"W, 2d10'27.13"S)
> 
> Now suppose I open the Georeferencer and open this image, and define a
> transformation (say, "polynomial 1") with three ground control points
> (GCPs).
> When I tell it to "start georeferencing" and to load the result into my QGIS
> project, the image is hugely distorted and located in the wrong place. I
> found
> a BIG CLUE about what's happening when I asked it to "generate GDAL script".
> The result was:
> 
> gdal_translate -of GTiff -gcp 4690.78 13510.5 4434.32 -13412.7 \
> -gcp 4721.32 13469.4 4462.09 -13371.6 \
> -gcp 4753.5 13539.4 4497.52 -13458.7 \
> -gcp 4692 13536.2 4430.49 -13445.3 \
> "/path/input.tif" "/tmp/input.tif"
> 
> gdalwarp -r cubic -order 1 -co COMPRESS=NONE "/tmp/input.tif" \
> "/path/output.tif"
> 
> But if we look at the man pages for gdal_translate, the format for input of
> GCPs
> is:
> 
> -gcp pixel line easting northing elevation
> 
> The first argument to "-gcp" should be the x coordinate in *image* space,
> not in
> *coordinate* space. It should be the column number of the pixel in question
> (I
> don't know if it can be a floating point; hopefully it can). The second
> argument to "-gcp" has to be the *row* number of the pixel in the image
> being
> georeferenced. The "easting" and "northing" are indeed the x and y
> coordinates
> in the target coordinate system. But notice that in the gdal_translate
> command
> that the Georeferencer generated, the first two arguments are positions in
> coordinate space, not image space!
> 
> So, here's the work-around. We saw above that the size of the image is 1101
> x
> 1091. All we have to do is change the bounds of the input image so that the
> image's geographic coordinates match the image space coordinates. We can do
> that easily with gdal_translate, being careful to account for QGIS using a
> positive-up y-axis. Here's the command for the current case:
> 
> gdal_translate -of GTiff -a_ullr 0 0 1100 -1090 input.tif input_fixed.tif
> 
> Now, when we open the new input image (input_fixed.tif) into the
> Georeferencer
> and select GCPs, etc, it actually works!
> 
> M

>From my experience I think you're right that there is a "major bug" with the georeferencer.  I too was getting extremely distorted (beyond recognition) output rasters; in my case using a linear transformation.  I thought I only had this problem when using more than two control points - but it's possible I'm remembering that incorrectly, and I actually only got a sensible result by choosing to create world files instead of new rasters.

Alister
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5136 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20110610/5edfd194/attachment.bin>