Bug report #523
|Affected QGIS version:||Regression?:||No|
|Operating System:||Windows||Easy fix?:||No|
|Pull Request or Patch supplied:||Resolution:||fixed|
|Crashes QGIS or corrupts data:||Copied to github as #:||10582|
Tried to georeference a jpeg image to EPSG 32119 projection. The output jgw file looked like this:
The qgis - generated points file :
mapX mapY pixelX pixelY
551629.000000 119426.000000 1042.95 -1942.69
558297.000000 128803.000000 1320.27 -1560.28
561736.000000 142243.000000 1460.38 -1023.16
554963.000000 154641.000000 1185.99 -519.606
532042.000000 159226.000000 234.348 -329.862
539335.000000 147557.000000 536.478 -807.141
529333.000000 124635.000000 132.178 -1723.75
I converted the above y pixel coordinates from negative to positive and used the altered coordinates as gcp points in gdalwarp and got the following correct world file:
My simplistic assumption is that the qgis georeferencer is passing negative y coordinates for a jpeg file when they should be positive instead.
#3 Updated by Magnus Homann almost 14 years ago
We had some issues where if proejction was turned on when you entered georeference tools, it wouldn't work. have you tried turning off projection?
Also, if you have the possibility try downloading the latest from SVN and try it there. I have done some work with it.
If this does/does not work, let me know. There is nothnig bad with negative coordinates as I see it (0,0) is upper left pixel according to world file specification. What happens if you use gdalwarp with the negative coordinates?
#4 Updated by doug_newcomb-fws-gov - almost 14 years ago
I can go back and check, but I as I recall using negative line numbers with GCPs caused the image to flip upside down. ( I had tried it with a tiff version of the file as well)
the world file associated had the following contents:
With a negative y pixel size
I thought image specs in general had the 0,0 in the upper left hand corner and positive x going right and positive y going down?