1.2 GB。我注意到，如果将内容包装到tarball中，它将粉碎到大约82 MB。我想将其检入修订控制系统，以便其他人可以使用它，并且似乎可以挤出一些空间。GDAL GeoTIFF驱动程序页面列出了很多可用于创建压缩的GeoTIFF文件的选项。还有很多选项会影响每种算法的工作方式。
帮助页面在描述选项方面做得很好，但是没有详细说明如何选择算法或相关的取舍方法随着压缩水平的变化。这会导致以下问题：
使用压缩的优点是可以节省大量空间。缺点是什么？压缩图像时信息会丢失吗？
如何选择一种算法和压缩级别。某些类型的图像是否适合某种算法？
#1 楼
要选择压缩方法，您需要使用以下命令：gdal_translate -co "COMPRESS=method" src_dataset dst_dataset
使用压缩时，最大的折衷是解压缩图像所需的额外处理时间，并且解压缩后的图像仍然会消耗相同的内存量。关于信息丢失，压缩有两种基本类型：
无损-保留原始数据值
有损-降低数据质量以节省更多空间
当必须保留原始数据值（例如DEM或栅格要素）时，您将采用无损算法。像PACKBITS，DEFLATE和LZW这样的算法是无损的，可以根据压缩率进行排序：
LZW-最高压缩率，最高处理能力
DEFLATE
压缩率仍取决于数据，如果数据具有很多相似的值，PACKBITS将产生良好的结果。
与无损相反，您将使用JPEG之类的有损算法可压缩不必返回精确值的栅格。例如，可以使用有损算法来压缩正射照片或卫星图像。
#2 楼
在使用lzw和deflate进行压缩时，使用-co predictor=2进行压缩可以帮助平滑变化的图像，因为它可以压缩像素之间的差异而不是绝对值，并且这些差异会变小并且具有更多的图案（参考）。 Predictor仅在lzw和deflate压缩时有用，该选项对其他方法无效。 gdal_translate -co compress=lzw -co predictor=2 ...
预测变量的节省可能是巨大的。我只是将使用默认LZW设置的高达17GB的16位geotiff高程模型的目录重新压缩为只有预报器= 2的5GB。
关于预报器2和3之间的区别以及何时使用的信息存在冲突每种方法都最好使用（ref1，ref2）。也许为另一个问题助燃。
另一个易于省钱的选择是
-co tiled=yes。有一些软件无法读取平铺图像，但是这些软件变得越来越稀少，并且大多在GIS之外（我不知道现在没有读取它们的主流GIS软件）。以@alfonx使用压缩概览的答案为基础：这样可以无损地存储基本图像，以确保数据完整性，金字塔可以有损，以节省速度并节省空间。这几乎是两全其美。对于在RGB图像上具有
gdaladdo的可能的最小概览，请使用jpeg压缩，平均或高斯重采样，而不要使用默认的最近邻（使概览更平滑）和YCBCR光度概览。有关这些选项的更多信息，请参阅gdaladdo参考页（尽管并没有太多说明光度学的全部内容）。这是Windows批处理文件的一部分，我使用它来应用外部jpeg概述到目录中的所有tiff：
set _opts= -r gauss --config PHOTOMETRIC_OVERVIEW YCBCR ^
--config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 85
for %%a in (*.tif) do gdaladdo -ro %_opts% %%a 2 4 8 16 32 64
注释
GDAL 1.6.0引入了
gauss重采样，在锐利边缘具有高对比度或噪点的情况下，可以产生更好的结果。应该使用2的幂（2 4 8 ...），以便选择3x3重采样的高斯核。average-如果未指定，则使用默认值75％，这会产生较小的文件，但我发现85％的尺寸和质量之间的折衷更好。更新，2015年：GDAL 1.8和2.0引入了许多新的选项，这里没有介绍，而我还没有消化的时间。阅读官方的gtiff格式页面，我确定还有详细的有用设置。
#3 楼
对于大型栅格，GeoTiff提供了将缩小的总览作为多余的图像存储到GeoTiff文件中的可能性。可以使用gdaladdo（= GDAL ADD概述）来完成。创建这些概述时，您也可以手动告诉gdal对其进行压缩：gdaladdo --config COMPRESS_OVERVIEW JPEG
加快查看数据的速度，而无需增加太多大小。
注意：Geotools Geoserver，uDig，AtlasStyler，Geopublisher等应用程序都可以使用此功能并从概述中受益。
#4 楼
要启用部分图像解压缩，只需使用TILED = YES即可。Peter
#5 楼
最终，您可能需要尝试不同的选项，然后看看能满足您的需求。我一直在基于小波的格式上更多地使用JPEG压缩的GeoTIFF。我的成绩很好。使用GDAL可以实现与基于小波格式相当的压缩率，而不会造成太多数据丢失。减压带来的性能下降是可以接受的。
我最喜欢这种方法的地方是GeoTIFF支持几乎是通用的，而对基于小波格式的支持却并非总是可以保证的，有时会遇到棘手的许可问题。
#6 楼
@dodobas和@ matt-wilkie的答案涵盖了与使用GDAL压缩和模糊以减小图像大小的行为有关的所有内容。我想补充两点：
GDAL的文件格式文档：http://www.gdal.org/frmt_gtiff.html;
请参阅创建选项（
-co），具体是： COMPRESS NUM_THREADS PREDICTOR ZLEVEL 必须验证将使用GeoTIFF的软件：
支持所需的压缩方法；
建议使用压缩。
例如，GeoServer不建议压缩GeoTIFF：
最后，Geotiff支持各种压缩，但我们建议
不使用它。虽然允许较小的文件，但
解压缩过程非常昂贵，并且将在每次数据访问时执行，这大大降低了渲染速度。根据我们的经验，解压时间要比纯磁盘数据读取时间长。
如果已经使用了概述，切片和高性能存储介质（企业），则尤其如此。级别的磁盘或SSD）。
评论
我还需要压缩jpeg图像，因为我无法使用gdalin Python将栅格转换为数组。它显示内存错误，有时还显示内存不足。任何人都无法知道如何在python中实现这一行（gdal_translate -co“ COMPRESS = method” src_dataset dst_dataset）。我是使用gdal的新手。因此，有时我很难理解其结构。
– Shiuli Pervin
16-09-22在7:39
@ShiuliPervin，首先，JPEG已经是压缩（有损）格式。其次，听起来您遇到的是块问题，而不是压缩问题。读取文件时，应以块，带或块的形式读取文件，而不要一次读取所有文件。即使文件已压缩，使用时也必须解压缩（例如：如果4GB文件在压缩时在磁盘上使用2GB，则在全部加载以进行处理时仍会占用4GB RAM。节省空间的替代方法，您可能需要研究GeoTIFF的稀疏格式。
–凯文
16 Sep 25 '15：53
@ShiuliPervin，不过，我可能会误解你的问题。压缩本身通常会占用大量内存，但是除非库中存在错误或为您提供了无效的参数，否则压缩不会导致系统溢出。如果您在将JPEG作为GeoTIFF的压缩类型方面遇到问题，请尝试使用LZMA或DEFLATE。
–凯文
16-09-25在15:59
#7 楼
我将GeoTIFF与Earth Resource Mapping的ECW（增强压缩小波）压缩进行比较的经验是，压缩高分辨率的航空照片时，ECW的性能要好几个数量级。基于小波的压缩的另一个重要优势是，与GeoTIFF，JPEG（而非JPEG 2000）等旧格式不同，仅图像的一部分可以被解压缩。 1]。不能低估这一优势的重要性，尤其是在使用“大于大约一半的计算机内存大小”的情况下。-我从来没有机会进行过测试-MrSID，另一个专有的基于小波的文件格式也比“较旧的”格式和选择性解压缩具有更高的压缩率。
ref 1：http：//www.ifp.uni-stuttgart.de/publications/phowo01/Ueffing.pdf
评论
dariapra，请记住，GeoTIFF-Packbits或GeoTIFF-LZW是无损压缩，而ECW和JPEG有损。必须根据将来的数据使用情况仔细选择无损或有损压缩。
– markusN
2010年11月16日在7:10
我并不是说松散的压缩格式始终是有效的存储格式。我的意思是说，使用ECW之类的格式适合某些生产环境。例如，如果我们有一个MapServer实例通过WMS提供正照片层，则ECW比GeoTIFF更合适。没有什么禁止您也使用无损压缩来存储原图的。
– dariapra
2010年11月16日在12:04
#8 楼
对于使用较新GDAL版本的用户，还有无损ZStandard（ZSTD）压缩（GDAL> = 2.3）和有损有限错误光栅压缩（LERC）压缩（GDAL> = 2.4）可供选择。通常尽管说起来，
ZSTD在压缩率相似的情况下提供的数据读取速度要比LZW和DEFLATE快，但写入文件时速度可能会稍慢（取决于您使用的设置）。不必对数据精度大惊小怪（例如，仅进行可视化而不是分析），那么
LERC可能是一个不错的选择。有一个MAX_Z_ERROR设置，可让您调整您愿意牺牲的精度。例如。一个MAX_Z_ERROR=0.001或1mm可以在一个基准测试中节省50％的空间（请参阅参考资料）。最好的部分是您还可以使用
LERC将ZSTD与COMPRESS=LERC_ZSTD结合使用！或者，如果您更喜欢使用DEFLATE，则可以执行COMPRESS=LERC_DEFLATE。另请参阅GDAL GeoTIFF官方文档的组合/设置的完整列表https://gdal.org/drivers/raster/gtiff.html#creation-options 可找到更多详细信息和完整的基准比较在此宝贵的参考资料中：
@kokoalberti的“使用GDAL进行GeoTIFF压缩和优化的指南”
评论
+1是个不错的答案。 PACKBITS是一种游程长度编码（en.wikipedia.org/wiki/Run-length_encoding）的形式，它对于具有很多相邻相同值的数据（例如，如果您有很多NULL或分类栅格）非常适用。 LZW是一种更健壮的算法，可对多种数据有效。如上所述，一般的权衡是在空间和速度之间，因此适当的选择取决于您的使用和数据。另外，某些软件不支持某些类型的GeoTiff压缩。
– scw
10年8月12日在19:04
这是一篇不错的相关文章linfiniti.com/2011/05/…
–oeon
2011年6月1日下午5:01
好的答案，它很好地总结了您的选择。还要记住，每种压缩方法都有您可以设置的参数，这将大大影响结果。 @ j03lar50n，很高兴您发现我的博客文章有用...
–R Thiede
2011年9月1日20:34
漂亮的答案！如此简单而正确。
– sys49152
18年1月31日在13:41
@scw您能详细说明哪些软件不支持某些类型的压缩-具体来说，是否有不支持lzw或packbits的软件？还是您主要指的是不太常见的算法？
– David LeBauer
19年1月31日在21:27