[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