Bug report #8961
Georeferencer creates distorted image
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | C++ plugins/Georeferencer | ||
| Affected QGIS version: | 2.0.1 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | no timely feedback |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 17625 |
Description
I'm finding wrong, distorted results with qgis 2.0 georeferencer. We've tried with the same set of gcp's in envi and the same polynomial (deg 2) and there the results are correct, but with qgis the result is very distorted. Actually, the errors represented by the red segments in the georeferencer do not correspond with the actual gcps displayed on the reference image in Qgis main display.
See an snapshot here: https://dl.dropboxusercontent.com/u/3180464/georef_error.jpeg (404)
It looks like if the polynomial were not correctly fit?
I copy here the gdal command generated by georeferencer and attach the points files (qgis and envi)
Note that as envi has the 1,1 pixel in the upper-left corner, the points file for envi was modified (just deleting the "-" sign):
gdal_translate -of GTiff -gcp 1207.39 115.763 578783 4.72226e+06 -gcp 958.417 92.3122 578740 4.72227e+06 -gcp 89.8603 736.036 578599 4.72216e+06 -gcp 1212.84 708.826 578775 4.72216e+06 -gcp 193.311 13.3885 578610 4.72228e+06 -gcp 555.87 54.7944 578671 4.72227e+06 -gcp 29.2706 962.713 578591 4.72212e+06 -gcp 29.4565 1011.52 578592 4.72212e+06 -gcp 644.944 81.9622 578686 4.72227e+06 -gcp 820.848 215.92 578715 4.72224e+06 -gcp 1166.79 906.536 578765 4.72213e+06 -gcp 139.84 843.825 578607 4.72214e+06 -gcp 121.654 983.156 578605 4.72212e+06 -gcp 179.944 916.777 578613 4.72213e+06 -gcp 215.924 1000.27 578618 4.72212e+06 -gcp 280.845 870.688 578627 4.72214e+06 -gcp 347.305 973.238 578637 4.72212e+06 -gcp 391.396 1008.22 578644 4.72212e+06 -gcp 411.919 808.655 578647 4.72215e+06 -gcp 518.739 983.856 578662 4.72212e+06 -gcp 1085.84 1020.48 578749 4.72211e+06 -gcp 1039.96 959.663 578742 4.72212e+06 -gcp 991.99 979.425 578735 4.72212e+06 -gcp 949.751 986.845 578728 4.72212e+06 -gcp 901.452 952.171 578720 4.72212e+06 -gcp 865.86 986.17 578715 4.72212e+06 -gcp 856.298 936.775 578713 4.72212e+06 -gcp 820.18 982.175 578708 4.72212e+06 -gcp 807.646 919.4 578706 4.72213e+06 -gcp 773.744 967.165 578701 4.72212e+06 -gcp 730.238 914.636 578694 4.72213e+06 -gcp 722.161 1004.16 578693 4.72212e+06 -gcp 708.705 955.883 578691 4.72212e+06 -gcp 674.699 992.498 578686 4.72212e+06 -gcp 684.486 895.594 578687 4.72213e+06 -gcp 633.367 959.056 578679 4.72212e+06 -gcp 623.475 898.529 578678 4.72213e+06 -gcp 583.28 993.685 578672 4.72212e+06 -gcp 588.359 913.902 578673 4.72213e+06 "/media/Iomega_HDD/VINEDO2/20110920output6b_vClara/TTC0856opt1.tif" "/tmp/TTC0856opt1.tif" gdalwarp -r near -order 2 -co COMPRESS=NONE -dstalpha "/tmp/TTC0856opt1.tif" "/media/Iomega_HDD/QGISTESTS/georef/TTC0856opt1_pol2qgis.tif"
History
#1
Updated by Giovanni Manghi about 11 years ago
- Target version changed from Version 2.0.0 to Future Release - High Priority
#2
Updated by Jukka Rahkonen about 11 years ago
You are about ready to send a question to gdal-dev mailing list. It would be excellent if you could include a link to an original image and to the one which is georeferenced with ENVI. Define also what you mean be "wrong" and "distorted". Georeferencing and warping is pure mathematics and if GDAL and ENVI produce a different result they must be using different formulas. For sure both programs are doing their best for minimizing the errors. So basically your question to the gdal-dev list will be that you suspect that GDAL is using a wrong formula for calculating the second order polynomical transformation.
If your aim is a perfect fit in GCP positions between your reference image and the one you are warping, perhaps -tps option would suit your better than polynomical one which tends to shoot out if some GPCs are not accurate.
#3
Updated by alobo - about 11 years ago
Input: https://dl.dropboxusercontent.com/u/3180464/TTC0856opt1.tif (404)
Envi result (once converted to tif using gdal_translate): https://dl.dropboxusercontent.com/u/3180464/TTC0856opt1CG.tif (404)
Qgis result: https://dl.dropboxusercontent.com/u/3180464/TTC0856opt1_pol2qgis.tif (404)
This is not a minor difference. Also note the jpeg I posted.
#4
Updated by alobo - about 11 years ago
A video showing the difference: https://dl.dropboxusercontent.com/u/3180464/qgisgeoref.ogv (404)
#5
Updated by Jukka Rahkonen about 11 years ago
Hi,
One question for QGIS developers: In the GCP file the points have been given with quite a many decimals
mapX,mapY,pixelX,pixelY,enable
578783.34099900000728667,4722262.63798699993640184,1207.38819100000000617,-115.76277799999999729,1
In the gdalwarp command the accuracy seems to be reduced to one metre for x and to full ten meters for y-gcp 1207.39 115.763 578783 4.72226e+06
Are these values really used for running gdalwarp? If they are that could explain a lot. Alobo can also make a test by running gdalwarp manually by using a few more meaning numbers in the -gcp parameters. Full centimeters are for sure enough.
By the way, it is slow and unnecessary to create a temporaty tiff file. Far better to use -of VRT and write a virtual raster as a temporary output, it serves the same purpose but takes close to zero time and disk space.
#6
Updated by Jürgen Fischer over 10 years ago
- Category changed from C++ Plugins to C++ plugins/Georeferencer
#7
Updated by Giovanni Manghi almost 8 years ago
- Priority changed from High to Normal
- Target version deleted (
Future Release - High Priority)
#8
Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#9
Updated by Giovanni Manghi almost 7 years ago
- Status changed from Open to Feedback
Please test with a recent QGIS release (2.18 or 3), if the issue/request is still valid change the affected version accordingly, if is fixed/implemented then close the ticket. Thanks!
#10
Updated by Jürgen Fischer almost 6 years ago
- Resolution set to no timely feedback
- Status changed from Feedback to Closed
Bulk closing 82 tickets in feedback state for more than 90 days affecting an old version. Feel free to reopen if it still applies to a current version and you have more information that clarify the issue.