Opened 7 years ago
Closed 5 years ago
#7020 closed defect (wontfix)
Pixel offsets when using overviews
Reported by: | mojodna | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | GDAL_Raster | Version: | 2.2.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
Image output varies according to whether the source image includes overviews or not. Differences appear to be on internal tile boundaries.
Without overviews:
With overviews:
Animated ("compressed inward" == with overviews):
Original image: https://www.dropbox.com/s/ztp7xbpexx8zl6p/Loshitsa-Bridge-noskew-3_transparent_mosaic_group1.tif?dl=0
Processed image (with overviews): http://oin-hotosm.s3.amazonaws.com/598c1938a260c700113db249/0/03610f03-adb4-4fa7-bd21-bf68f46694f7.tif
The image was processed using gdal_translate
with these options:
-co COMPRESS=JPEG -co PHOTOMETRIC=YCbCr -co TILED=yes -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co NUM_THREADS=ALL_CPUS
Overviews were added using gdaladdo
with these options:
-r lanczos --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCbCr --config GDAL_TIFF_OVR_BLOCKSIZE 512 --config TILED_OVERVIEW yes --config BLOCKXSIZE_OVERVIEW 512 --config BLOCKYSIZE_OVERVIEW 512 --config NUM_THREADS_OVERVIEW ALL_CPUS
The source image is in EPSG:32635; the target image is EPSG:3857.
Change History (3)
comment:2 by , 7 years ago
@nvkelso - that's a red herring--that handling only occurs in the GeoTIFF output. Overview generation occurs at transcoding time, so we won't have touched AREA_OR_POINT
: https://github.com/mojodna/marblecutter-tools/blob/master/bin/transcode.sh#L134-L146
comment:3 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
I suspect this is because in MarbleTiler Seth is setting
dataset.update_tags(AREA_OR_POINT="Point")
Before he writes out the data in:
https://github.com/mojodna/marblecutter/blob/master/marblecutter/formats/geotiff.py#L57
And then the overview creation in gdaladdo assumes AREA instead (and doesn't look like it takes an option.
That seems consistent with the 1/2 pixel offset that is exaggerated larger in each overview.