> I wouldn't expect that effect to be as strong as you observed, but indeed > there are technical > grounds for your findings. When a tile is partial, ie for the right most or > bottom most tiles > when tile size is not a multiple of the tile dimension, the TIFF format still > impose that the > invisible parts of the tile must be encoded. So we have to fill them with > some value. > Currently, for JPEG compression, we fill the invisible portions of the tile > by replicating the > values of the last column (or line). Perhaps with your data, given the JPEG > compression > characteristics, this causes artifacts. Wondering if mirroring (at least to > fill a full MCU) > wouldn't produce better results. > If you feel like experimenting hacking this, the play ground is at > https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/gtiff/geotiff.cpp#L8175
Thanks for the insights Even. I'll take a stab at hacking on it and post a ticket if I get anything worth sharing. The aerial imagery I'm working with covers a lot of farms with a large amount of light-brown field areas, where a long, grey line shows up more than it might inside a darker urban or forested area. > I would also have a try by making first a virtual mosaic with gdalbuildvrt > and then running gdal_translate instead of using gdal_merge.py. > > -Jukka Rahkonen- Thanks for the idea, I hadn't thought of that. I tried both this and gdalwarp too while I was at it but they seem to give the exact same output as the gdal_merge method. Based on these results and the code Even linked to, it looks like this is caused by the geotiff driver itself, not the method used to mosaic the files together. I think my best bet moving forward is to just modify the extent to be multiples of the tile size until I can play around with the code. Jake Adams _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
