Skip to content

Rasters with GCPs and overviews render incorrectly when zoomed out #65011

Description

@trharris78

What is the bug or the crash?

I noticed this originally with a real GeoTIFF that has 4 corner GCPs, but I was able to reproduce it with a fake one. It seems that when you load one of these files and it has overviews, if you zoom out enough to use the overviews it will incorrectly scale the raster on the canvas.

Here's what the real TIF should look like, stretched between the four corner GCPs which I loaded as a separate GeoJSON with red dots. I obtained this view by gdal_translating away the overviews:
Image

But here's what it actually looks like with overviews (see the tiny raster in the lower-right corner):
Image

Zoomed in one mouse-wheel scroll, it switches to another overview and renders a bit larger:
Image

Steps to reproduce the issue

Rather than transfer a very large raster file, you can reproduce the problem by making one with GDAL:

  1. Create a blank TIF:
gdal_create -of GTiff -outsize 1000 1000 -bands 1 -burn 255 -a_srs EPSG:4326 test.tif
  1. Add GCPs to it with Python:
from osgeo import gdal, osr
srs = osr.SpatialReference()
srs.ImportFromEPSG(4326)
gcp_ul = gdal.GCP(51.3260698902711,35.7494151403027,0.0,-0.5,-0.5)
gcp_ll = gdal.GCP(51.327245751491,35.6906856319661,0.0,-0.5,999.5)
gcp_lr = gdal.GCP(51.3921442028364,35.6822985708757,0.0,999.5,999.5)
gcp_ur = gdal.GCP(51.3905556649637,35.7413035058091,0.0,999.5,-0.5)
ds = gdal.OpenEx("test.tif", gdal.GA_Update)
ds.SetGCPs([gcp_ul, gcp_ll, gcp_lr, gcp_ur], srs)
ds = None

This file on its own renders correctly at all zoom levels:
Image

  1. Add even one overview level though, and it will break if you zoom out enough for it to switch to rendering the overview:
gdaladdo test.tif 2
Image

For visual reference I found it helpful to have the corner points as GeoJSON, here is that file:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          51.3905556649637,
          35.7413035058091
        ]
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          51.3260698902711,
          35.7494151403027
        ]
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          51.327245751491,
          35.6906856319661
        ]
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          51.3921442028364,
          35.6822985708757
        ]
      }
    }
  ]
}

Versions

QGIS version3.44.7-Solothurn
QGIS code revision4edb1325
 
Libraries
Qt version5.15.18
Python version3.12.11
GDAL version3.12.0 — Chicoutimi
PROJ version9.7.0
EPSG Registry database versionv12.022 (2025-08-30)
GEOS version3.14.1-CAPI-1.20.5
SQLite version3.50.4
PDAL version2.9.2
PostgreSQL client version16.9
SpatiaLite version5.1.0
QWT version6.2.1
QScintilla2 version2.13.4
OS versionmacOS 26.3
 
Active Python plugins
QuickOSM1.17.1
profiletool4.1.8
quick_map_services0.19.29
processing2.12.99
grassprovider2.12.99
db_manager0.1.20
MetaSearch0.3.6

Supported QGIS version

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

New profile

Additional context

I did not try to create a new profile because this happened to someone else first, and I tried to help them debug it. So at least two of us using separate profiles on separate laptops have the issue.

Metadata

Metadata

Assignees

Labels

BugEither a bug report, or a bug fix. Let's hope for the latter!UpstreamNeeds changes in an upstream library (like Qt, Proj, GDAL, ...)

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions