[gdal-dev] Compression Artifacts After Merging Imagery

Even Rouault even.rouault at spatialys.com
Mon Sep 25 16:01:30 PDT 2017


On lundi 25 septembre 2017 16:16:26 CEST Jacob Adams wrote:
> Oh ye great minds of the GDAL world, I've run into a problem that I've not
> been able to solve.
> 
> I have aerial imagery comprised of about 1500 jpegs that I am trying to
> merge together into three large (~18gb) jpeg-compressed geotiffs to be
> served by Geoserver. The images are tiled such that they shift down about
> 100 pixels (out of ~7000) every so often. With a pure gdal_merge or
> gdalwarp mosaic, this leaves compression artifacts in the nodata spaces
> along the borders. The cause of these artifacts seems to be explained in
> Evan's comments on this ticket: https://trac.osgeo.org/gdal/ticket/5102).
> 
> I tried pre-processing a handful of the tilesinto geotiffs with the
> following three commands based on a similar discussion in February
> (http://lists.osgeo.org/pipermail/gdal-dev/2017-February/046027.html):

> nearblack -co TILED=YES -of Gtiff -nb 0 -near 0 -setmask -o temp1.tif  Tile1.jpeg

I think one issue is in the above nearblack invocation. Did you check temp1.tif is "clean" by 
displaying it ?
Basically by setting -near 0, you say that nearblack should expect a very clean frontier 
between nodata areas and valid areas. Whereas JPEG decompression artifacts in such a 
situation will result in intermediate values in a few pixels beyond the border.
I'd suggest trying with the default of nearblack, -near 15 and -nb 2, and tune them if needed.


>     gdal_translate -co TILED=YES -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -b 1 -b 2 -b 
3 -mask 4 --config GDAL_TIFF_INTERNAL_MASK YES temp2.tif Tile1_out.tif 

You shouldn't JPEG compress intermediate products. This will decrease image quality. Only 
apply it to the final stage of your workflow.


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170926/964a6c66/attachment.html>


More information about the gdal-dev mailing list