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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
