Bug report #1540
"Save as Image" georeference is off up to 1 cell
|Affected QGIS version:||Regression?:||No|
|Operating System:||Debian||Easy fix?:||No|
|Pull Request or Patch supplied:||Resolution:||fixed|
|Crashes QGIS or corrupts data:||Copied to github as #:||11600|
Compared to an original raster on QGIS map canvas, the raster map (png+pngw) that "Save as Image" creates is off up to one cell vertically and/or horizontally.
1. Load a raster map.
2. Zoom in until you see raster map cells.
3. "Save as Image".
4. Load the saved raster map and compare.
Backport of smizunos patch that fixes #1540
git-svn-id: http://svn.osgeo.org/qgis/branches/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c
#1 Updated by Steven Mizuno almost 14 years ago
The offset is caused in part by two things:
1. the world file may lack sufficient precision for the origin and possibly the cell dimensions
2. the origin written to the world file is the corner of the top left cell, where it should be the center of the top left cell
I have also found additional problems
1. on Windows the line terminations of the world file have 2 carriage returns and a line feed which causes gdal to not use the file, therefore not positioning the image in the expected place.
2. dotted file names are possible for the image, but the world file would just get the base name without the additional parts up to the extension.
I provide a patch to QgsMapCanvas::saveAsImage() which fixes these problems:
1. the numbers (except the hard-coded rotations) are written to the world file with up to 17 digits precision using the "g", 17 formatting options.
2. the center of the top left cell is written for the origin.
3. Text mode is not used in the file open call, allowing the explicit "\
" without any translation. The carriage return really isn't necessary, but helps when viewing the file on Windows.
4. use completeBaseName function to obtain the base file name for the world file.
#2 Updated by Marco Hugentobler almost 14 years ago
I tried the patch but I still have an offset. What I did was the following (with applied patch):
1. load a raster map
2. zoom to best resolution
3. save as image
4. load image as additional raster layer
5. toggle new image layer on and off
I still have small shifts in the image. Do you also have this effects or is it only on my system?
#3 Updated by Steven Mizuno almost 14 years ago
Replying to [comment:2 mhugent]:
I don't notice any offsets when I use the procedure you list. This is exactly what I was doing to determine the problem and test my changes. I have also tried at different scales - no difference between map and image.
As long as the extent isn't changed the image saved exactly overlays the original map.
I am using rasters in UTM zone 15, NAD83.
I have considered what would happen with other CRS and believe that there shouldn't be any problem. I did test with a raster in a local county coordinate system in the same general area and found that the saved image exactly overlays the map as expected.
Here are some Python statements I used to get the values for the world file, which I modified by hand at first. These were just executed in the Python console.
The results should be the same as written to the world file for the saved image.
Coordinates of center of Upper Left cell:
I am interested in any further information as I do want to get this correct.
#4 Updated by Marco Hugentobler almost 14 years ago
- Resolution set to fixed
- Status changed from Open to Closed
After looking at it again I think that you are right. The small image differences that I noticed are probably due to image compression and not because of image position. The patch is applied to trunk now ().