Bug report #1540

"Save as Image" georeference is off up to 1 cell

Added by Maciej Sieczka - over 11 years ago. Updated almost 11 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:Rasters
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

Description

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.

patch_for_1540.txt Magnifier - patch QgsMapCanvas::saveAsImage (1.91 KB) Steven Mizuno, 2009-04-08 08:03 PM

Associated revisions

Revision f14d7582
Added by Marco Hugentobler over 11 years ago

Backport of smizunos patch that fixes #1540

git-svn-id: http://svn.osgeo.org/qgis/branches/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Steven Mizuno over 11 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 over 11 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?

Regards,
Marco

#3 Updated by Steven Mizuno over 11 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.

Cell size:
iface.mapCanvas().mapUnitsPerPixel()

Coordinates of center of Upper Left cell:
iface.mapCanvas().extent().xMinimum()+(iface.mapCanvas().mapUnitsPerPixel()/2),iface.mapCanvas().extent().yMaximum()-(iface.mapCanvas().mapUnitsPerPixel()/2)

I am interested in any further information as I do want to get this correct.

Regards, Steve

#4 Updated by Marco Hugentobler over 11 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 ().

#5 Updated by Anonymous almost 11 years ago

Milestone Version 1.0.2 deleted

Also available in: Atom PDF