<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Even,</p>
<p>Thank you for your detailed reply.</p>
<p>I should have added that my concern is mainly about random access to parts of the images - for QGIS server and QGIS Desktop.</p>
<p>I have internal pyramids. I am not so sure if it is tiled or not. Does gdalinfo reveal whether the TIFF was created with "TILED=YES"?</p>
<p>So from your analysis it looks like lzma is the slowest, but overall, the differences aren't that huge. I don't know how random access to parts of the image changes the game a bit, compared to your analysis where you examine the decompression of the whole image - right?</p>
<p>Thanks,</p>
<p>Andreas</p>
<p>On 2016-10-14 12:09, Even Rouault wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Le vendredi 14 octobre 2016 09:45:38, Neumann, Andreas a écrit :
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Hi,<br /><br /> I have a question on TIFF compression alternatives.<br /><br /> My data of concern is 8bit gray value. Lots of white pixel (>95%), the<br /> rest is black pixels (content) and some gray pixels because of<br /> antialiasing.<br /><br /> I would like to compress to save some storage, but I need a good<br /> performance. What is the recommended compression that is fast on<br /> decompression?<br /><br /> I tried DEFLATE, but it is rather slow to decompress. Would LZW or<br /> PACKBITS be preferred in this situation? How about LZMA? I would like to<br /> avoid non-compressed data, because I use SSD storage for performance<br /> reasons.</blockquote>
<br /> My findings on a 37614 x 18816 8 bit image (a scan of a text page) that should <br /> be similar to what you describe.<br /><br /> Decompression time is the result of the second run of "time gdalinfo -<br /> checksum" (so you can consider that I/O is cached by the OS and you measure <br /> essentially CPU time. storage is spinning disk)<br /><br /> No tiling:<br /><br /> Size Compression Decompression time<br /> 707895750 out_nocompression.tif 9.3 s<br /><br /> 11239972 out_deflate.tif 10.8 s<br /> 17749306 out_lzw.tif 10.5 s<br /> 12337710 out_lzma.tif 12.6 s<br /> 36201320 out_packbits.tif 9.9 s<br /><br /> Tiling:<br /><br /> Size Compression Decompression time<br /> 8813833 out_deflate_tiled.tif 11.1 s<br /> 14614121 out_lzw_tiled.tif 11.0 s<br /> 8479238 out_lzma_tiled.tif 13.0 s<br /> 37018470 out_packbits_tiled.tif 10.2 s<br /><br /> Note: in the tiling case, the gdalinfo -checksum benchmark might not be ideal <br /> as it proceeds line by line (and not block by block), thus there's a lot of <br /> copying between cached blocks and output buffer that is done.<br /><br /> So I've done time gdal_translate XXX.tif /vsimem/out.tif -q :<br /><br /> deflate tiled: 2.5 s<br /> lzw tiled: 2.3 s<br /> packbits tiled: 1.5 s<br /> lzma tiled: 4.5 s<br /><br /> Times for non tiled files are essentially the same.<br /><br /><br /> Note: if you use tiling and you have whole tiles that are at white value, if <br /> you use GDAL trunk, set the SPARSE_OK=YES creation option and set the nodata <br /> value to 255, then those tiles will be entirely omitted from the compressed <br /> file. This might save a few extra bytes, and also some decompression time.<br /><br /> gdal_translate out_nocompression.tif out_packbits_tiled.tif -co tiled=yes -co <br /> compress=packbits<br /> gdal_translate out_nocompression.tif out_packbits_tiled_sparse.tif -co <br /> tiled=yes -a_nodata 255 -co compress=packbits -co sparse_ok=yes<br /><br /> 37018470 out_packbits_tiled.tif<br /> 30409074 out_packbits_tiled_sparse.tif<br /><br /> time gdal_translate out_packbits_tiled_sparse.tif /vsimem/out.tif -q: 1.3 s<br /><br /> Even</div>
</blockquote>
<p> </p>
<div> </div>
</body></html>