[gdal-dev] Impact of tile size on artifacts in JPEG-compressed Tiffs

[Even Rouault]

On mardi 14 novembre 2017 13:16:40 CET Jacob Adams wrote:
> I'd like to check my understanding of the impact of the tile size on
> JPEG-compressed geotiffs.
> 
> I've been getting dark bands 4 or 5 pixels wide on the bottom and right
> edges of the image when manually creating large image tiles from a
> collection of smaller tiles. I'm using the common aggressive compression
> settings for jpeg with a specified extent (in map units) as follows:
> gdal_merge.py -ps .25 .25 -ul_lr 1528148 3773703 1529109 3772785 -co
> compress=jpeg -co interleave=pixel -co photometric=ycbcr -co tiled=yes -o
> <outfile> <infiles>
> 
> While subtle, they are distracting and are more visible when placed next to
> other imagery or when resampling.
> 
> I've found two ways to get rid of them via trial and error:
> 1) Don't use tiling.
> 2) Make sure your image size (in pixels) is a multiple of your tile size.
> 
> I want to use tiling to speed up access time. If I adjust the extent to make
> the image size a multiple of some of the factors of the tile size, such as
> 128, 16, or 8 (for a default tile size of 256x256) the dark area is still
> there but shrinks to one or two pixels. This tells me it's not related to
> the MCU of the JPEG compression.
> 
> Am I correct in saying that the image size should be a multiple of the tile
> size when using compress=jpeg and tiled=yes to avoid generating these
> darker bands on the bottom and right edges of the images?

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

I would have thought you shouldn't get artifacts if image_size % tile_size is a multiple of the 
MCU (16 in that instance since you use YCbCr), but apparently you still observed artifacts. 
Puzzling.

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/20171115/48e5a49a/attachment.html>