#6986 closed defect (invalid)
gdalwarp with jpeg compression doesnt respect -cutline
Reported by: | landry | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.2.2 |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
Using 2.0.0 (also 2.2.1) i'm trying to use -cutline to remove borders of an orthoimagery and properly set nodata, but using -dstnodata 255 -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=90 -co TILED=YES -cutline /path/to/geojson i get 'almost nodata' (ie 254 254 254 for example) pixels *outside* of the cutline polygon.
Attachments (1)
Change History (5)
by , 7 years ago
Attachment: | border.png added |
---|
comment:1 by , 7 years ago
This seems specific to jpeg-in-tiff compression, as using COMPRESS=DEFLATE doesnt show the same issue. Using gdaladdo on the same file also generates overviews with 'almost nodata' pixels outside the cutline, and using nearblack -white doesnt fix them.
comment:2 by , 7 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
This is completely expected and is indeed linked to JPEG compression that operates on 8x8 blocks (or 16x16 when using YCBCR).
You could for example gdalwarp to a non-compressed (or losslessly compressed) RGBA file and then create a JPEG compressed RGB file with a DEFLATE compressed mask with:
gdal_translate rgba.tif rgbmask.tif -b 1 -b 2 -b 3 -mask 4 -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=90 -co TILED=YES --config GDAL_TIFF_INTERNAL_MASK YES
comment:3 by , 7 years ago
Hm, i will try this, but i found no 'full' example of this pipeline in the various tutorials.
Right now i'm doing first: gdalbuildvrt foo.vrt *.tif
- resampling to 24m:
gdal_translate -tr 24 24 -r lanczos foo.vrt 24m.tif
- Then clipping to remove 'empty' white zones (5 tiles have some)
gdalwarp -cutline /tmp/emprise_2016_fix.geojson -dstnodata 255 -r lanczos -co COMPRESS=DEFLATE -co PREDICTOR=2 -co TILED=YES 24m.tif cut.tif
So i'm not sure at which point in the pipeline i have an RGBA file - nor if -crop_to_cutline has to be used - but i'll make sure to test more options.
Will using gdaladdo (with/without -ro) on the 'rgbmask.tif' file keep the mask/band/avoid the artefacts ? gdaladdo manpage doesnt mention masks...
I tried doing the resampling via -tr directly in gdalwarp but it was taking maaany hours, while doing it with gdal_translate only took 45mn.
comment:4 by , 7 years ago
For the record (and if it can be useful to the next who looks at doing the same), here's a recipe that worked for me:
gdalbuildvrt -addalpha 2016.vrt dalles/*.tif gdal_translate -tr 24 24 -r lanczos 2016.vrt ${dest}_reech.tif gdalwarp -cutline /tmp/emprise_2016_fix.geojson -dstnodata 255 -r lanczos \ --config GDAL_CACHEMAX 500 -wm 500 -wo OPTIMIZE_SIZE=YES ${dest}_reech.tif ${dest}_cut.tif gdal_translate ${dest}_cut.tif ${dest}.tif -b 1 -b 2 -b 3 -mask 4 \ -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=90 -co TILED=YES --config GDAL_TIFF_INTERNAL_MASK YES gdaladdo -ro -r lanczos --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL ${dest}.tif 2 4 8 16
I tried doing the 'simpler' variant with cutting to a vrt and then resampling and compressingat the same time:
gdalbuildvrt -addalpha 2016.vrt dalles/*.tif gdalwarp -of VRT -cutline /tmp/emprise_2016_fix.geojson -r lanczos --config GDAL_CACHEMAX 500 -wm 500 -wo OPTIMIZE_SIZE=YES 2016.vrt 2016_cut.vrt gdal_translate 2016_cut.vrt ${dest}.tif -tr 24 24 -r lanczos -b 1 -b 2 -b 3 -mask 4 \ -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=90 -co TILED=YES --config GDAL_TIFF_INTERNAL_MASK YES
but that was *ways* slower.
white are the 'almost nodata' pixels, green line is the cutline, and red is the qgis background