Georeferencer does not allow to ignore whatever positional info in the input and does havoc due to that

[mmokrejs]

What is the bug or the crash?

I spent several months in overall, time to time trying to georeference several aerial images. Most of them were roughly georeferenced already from the Cadastral institute and that was the culprit.

It worked for some and seemed NOT to work for other files (Georeferencer did not complain and finished cleanly, the calculated GCP points seemed fine) but the resulting layer/image loaded in QGIS in a completely wrong area. No matter if loaded directly after georeferencing or later from the resulting raster file. I use EPSG:5514 which also has negative both X and Y coordinates in Czechia but it also breaks if I use WGS84 to derive the GCP points.

Workaround:
Zap the eventually added roughly georeferenced positions from the input image. Neither QGIS Georeferencer nor Freehand raster georeferencer v. 0.8.3 are able to ignore the input georeferencing values (in my case they were quite inexact). QGIS does havoc and on a side note, Freehand raster georeferencer refuses to operate on the input. Both should just give me warning and ask to proceed with the input while IGNORING the original values. At least the image rotation should be preserved from the rough georeferencing info. And the georef info could be respected by the main QGIS GUI, I do not mind that Georeferencer uses pixel in its own window. But the main QGIS GUI would navigate me into the area where the image was taken.

To get around try on Linux:

# get rid of S-JTSK negative coords
convert inputfile.tif -format bmp - > outputfile.without_coords.bmp

# maybe the following would be just enough?
exiftran -f -o outputfile.flipped.tif inputfile.tif

Fix:
>QGIS-3.28.2-Firenze should ignore the original, unwanted georef values in the input image but preserve rotation, incl. flip&flop info and main QGIS GUI could navigate me into the area.

Steps to reproduce the issue

See above.

Versions

3.28.2-Firenze

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[agiudiceandrea]

@mmokrejs could you please specify if and how this issue is different from #51367 or #51699, #51299, #51197, #44994?
A bunch of Georeferencer issues have been recently fixed. The fixes are currently available in QGIS 3.29.0-Master nightly build and they will be available in QGIS 3.28.4.

[mmokrejs]

I had a look to some even before posting. The bug #51367 is different one.

The issue #51699 could be same but in my case the offset was huge, somewhere totally elsewhere on Earth, if at all. I had to use convert -flip -flop to make it easier to Georeferencer to do its job and discard the georef data which were huge values -X -Y probably related to the huge offset. I cannot express myself probably correctly but "normaly" Georeferencer uses the positive X and Y values in the window (local, virtual coordinates, seems you speak of pixels) but in my case it picked those huge negative values. That possibly caused the huge offset because the local/virtual/pixel coords are in range of millions but the EPSG values were a few magnitute orders more negative. But somebody needs to confirm the idea.

The issue #51299 could be same case I faced, it just depend how latge are the values in you originally georeferenced image (which nobody warned you about).

The issue #51197 is exactly what I found as well. But I think I had even had at that time an older version of QGIS. Like mentioned in #51197 (comment) I also have the impression that also the broken GCP points were fetched during my repeated experiments. One should drop the *.points *.aux.xml *.tfw files from the source directory to ensure they are not picked up. QGIS could show along the way which sources of information were picked. Especially in the map and report files.

Again, issue #44994 is yet another instance of what I hit as well. Regarding #44994 (comment) , there should be a warning message raised tot he user of QGIS and second, an automated way to discard the offending georef values directly inside the Georeferencer GUI. The fix #51705 is only partion IMO. At least commit description does not say it does automagically discard the offending georef data.

[agiudiceandrea]

If you want you can test if the issue does occur using the latest QGIS 3.29.0-Master nightly build or provide a sample raster layer and exact step and GCP points in order replicate the issue.

[mmokrejs]

No, with master I still get an offsetted georef result. The input was a TIF file with .tfw left on the disk. Probably it is the source of the georef information. Here are its contents:

.107911
.000891
.001012
-.107982
-563436.98

The error after georeferencing is still about 20-30 m, depending on the number of points used (20 to 40). Even wirh 56 GCPs I get an error of 20 m.

QGIS version
3.29.0-Master
QGIS code revision
48a42c7fae
Qt version
5.15.8
Python version
3.9.16
GDAL/OGR version
3.6.2
PROJ version
9.1.1
EPSG Registry database version
v10.076 (2022-08-31)
GEOS version
3.11.1-CAPI-1.17.1
SQLite version
3.40.1
PDAL version
2.5.0
PostgreSQL client version
unknown
SpatiaLite version
5.0.1
QWT version
6.1.5
QScintilla2 version
2.13.3
OS version
Gentoo Linux

Note the input and out coords are both in EPSG:5514 where the source should be in pixels, right?

At least if the debug messages were more descriptive:

src/core/qgsmessagelog.cpp:29 : (logMessage) [2078445ms] 2023-02-13T12:51:21 Messages[3] Georeference Successful : Raster was successfully georeferenced.

What image file was used as the input, its pixel x pixel size, aimed target projection, in which projection were the reference positions collected from main GUI, etc.

[mmokrejs]

Yeah, see the input coords were treated as the pixels after rounding according to report.pdf?

I do not understand the loong red lines (Residuals) in the schema close to the beginning of the report.pdf. Some are way long and have opposite=conflicting orientation. Are those shifts detected in the image to be made? Is the resiaduals schema oriented as is teh image thumbnail above it? I doubt.

report.pdf

I can provide the map.pdf in a personal email which shows that quite clearly.