Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#1540 closed bug (fixed)

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

Reported by: msieczka Owned by: nobody
Priority: critical: causes crash or data corruption Milestone:
Component: Rasters Version: Trunk
Keywords: Cc:
Must Fix for Release: Yes Platform: Debian
Platform Version: Awaiting user input: no

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.
  1. Zoom in until you see raster map cells.
  1. "Save as Image".
  1. Load the saved raster map and compare.

Attachments (1)

patch_for_1540.txt (1.9 KB ) - added by smizuno 15 years ago.
patch QgsMapCanvas::saveAsImage

Download all attachments as: .zip

Change History (6)

comment:1 by smizuno, 15 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 "\r\n" 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.

by smizuno, 15 years ago

Attachment: patch_for_1540.txt added

patch QgsMapCanvas::saveAsImage

comment:2 by mhugent, 15 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

in reply to:  2 comment:3 by smizuno, 15 years ago

Replying to 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

comment:4 by mhugent, 15 years ago

Resolution: fixed
Status: newclosed

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 (r10592).

comment:5 by (none), 15 years ago

Milestone: Version 1.0.2

Milestone Version 1.0.2 deleted

Note: See TracTickets for help on using tickets.