FME与遥感影像处理：想把一整批 GeoTIFF 转成 COG 传到 S3，COG Writer 的压缩方法 JPEG/DEFLATE/LZW/ZSTD 在遥感反射率产品上到底怎么选，金字塔重采样用 nearest 还是 average 对后续分析影响有多大？

一、问题的提出：为什么压缩与重采样不是"随便选"

遥感反射率产品（Surface Reflectance, SR）通常以 16 位整型存储，并附带缩放因子与偏移量（scale/offset），把 DN 值映射回 0–1 或 0–10000 的物理量。这类数据有两个鲜明特征：其一，动态范围被有效量化位深压缩，直方图集中在较窄区间；其二，空间上存在强自相关，相邻像元高度相似。这两个特征共同决定了压缩算法的收益空间，也决定了有损压缩的风险位置。

与此同时，COG 的读取模式与传统"下载整幅影像"截然不同。客户端通过 HTTP Range 请求只取需要的块（tile）与概览层级（overview），因此压缩率、块大小、概览质量三者共同决定了云上读取的延迟与流量。如果压缩方法选错，可能出现"文件变小了，但读取变慢了"的反直觉结果；如果重采样选错，则可能出现"缩略图看着没问题，但统计量系统性偏移"的隐蔽错误。

本文的分析主线：数据语义（连续型物理量 vs 离散型类别）决定压缩与重采样的合法性边界，工程约束（解码速度、生态支持、成本）决定其最优解。任何脱离数据语义谈"最佳压缩"或"最佳重采样"的结论都不可靠。

笔者认为，很多团队在这两个参数上踩坑，根源在于把 COG 当成"另一种 GeoTIFF 格式"而非"一种面向随机读取的服务化数据结构"。前者只关心文件能否打开，后者关心的是在并发、按需、分层读取场景下的综合表现。这个认知差异，直接导致了参数选择的随意性。

二、COG 的底层机制：块、概览与 HTTP Range

2.1 什么是 COG

Cloud Optimized GeoTIFF 是一种遵循特定内部布局约束的 GeoTIFF：影像数据按内部瓦片（internal tile）组织，金字塔概览（overview）与主影像一同存放，且文件头（IFD）位于文件前部。其规范由 OGC 在 2023 年发布的 OGC Cloud Optimized GeoTIFF Standard 1.0 正式标准化（OGC 21-026）。规范的核心诉求是：客户端无需读取整个文件，仅凭少量 Range 请求即可获取任意区域、任意分辨率的子集。

这里需要区分两个常被混淆的概念：tiled GeoTIFF 不等于 COG。一个内部瓦片化的 GeoTIFF 如果概览缺失、或 IFD 分散在文件尾部，仍然不满足 COG 的随机读取要求。GDAL 提供了 gdalinfo -checksum 与 COG 校验工具来验证合规性。

2.2 块大小与读取放大

COG 的读取效率与块大小强相关。块太小，元数据与索引开销上升，Range 请求次数增多；块太大，单次请求传输的数据量超出实际需要，形成"读取放大"。业界常见取值是 256×256 或 512×512。对于 16 位多波段反射率产品，512×512 的单块未压缩体积约为 512×512×2×波段数 字节，若为 6 波段则约 3 MB，压缩后通常落在数百 KB 量级，适合单次 Range 请求。

块尺寸	单块像元数	16bit 单波段未压缩	适用场景
128×128	16,384	32 KB	小范围高频查询
256×256	65,536	128 KB	通用均衡
512×512	262,144	512 KB	大范围分析、多波段
1024×1024	1,048,576	2 MB	归档为主、读取较少

表 1：块尺寸与未压缩体积对照（按 16 位单波段计算，未计压缩；数据为算术推导，非实测）。

本文评述：块大小的选择本质上是"空间局部性"与"请求开销"的权衡。反射率产品若用于区域尺度的指数计算，512×512 往往更优；若用于点位采样或小窗口裁剪，256×256 更灵活。这个判断需要结合具体查询模式，而非套用固定值。

三、四种压缩方法的编码机制与适用边界

3.1 无损与有损的分水岭

在 COG 语境下，DEFLATE、LZW、ZSTD 属于无损压缩，JPEG 属于有损压缩（严格说 JPEG 支持无损模式，但 GDAL 的 JPEG 压缩默认走有损 DCT 路径）。这个分水岭决定了它们能否用于"需要逐像元保真"的场景。

遥感反射率产品在科学分析中通常要求无损，因为缩放因子意味着一个 DN 的误差会被放大为物理量误差，且指数计算（如 NDVI）会放大波段间的相对误差。但工程上并非绝对：可视化瓦片、快速浏览、机器学习预训练样本等场景，有损压缩的收益可能超过精度损失。

3.2 DEFLATE：兼容性之王

DEFLATE（RFC 1951）结合 LZ77 滑动窗口与 Huffman 编码，是 ZIP、PNG、gzip 的底层算法。在 GDAL 中通过 COMPRESS=DEFLATE 启用，可配合 PREDICTOR=2（水平差分）或 PREDICTOR=3（浮点差分）提升压缩率。

优点：几乎所有 GIS 软件、库、语言绑定都支持，解码无外部依赖，是事实上的"安全默认值"。缺点：压缩率中等，解码速度中等，且 GDAL 的 DEFLATE 实现（基于 zlib）在多线程解码上的并行度有限。

3.3 LZW：历史遗产

LZW（Lempel-Ziv-Welch）是 TIFF 规范原生支持的压缩，通过构建字符串字典实现压缩。它在早期 GIS 数据中极为常见，兼容性同样优秀。但在相同数据上，LZW 的压缩率通常略逊于 DEFLATE，且现代实现中优势不明显。

本文评述：LZW 在今天的 COG 生产中没有明显理由作为首选，除非下游系统存在只认 LZW 的历史约束。把它保留为"兼容性备选"是合理的，把它当作默认值则缺乏依据。

3.4 ZSTD：云原生新势力

Zstandard（ZSTD，RFC 8878）由 Facebook 于 2016 年开源，主打"高压缩率 + 高解码速度"的平衡。GDAL 自 2.3 版本起支持 ZSTD 压缩（需编译时链接 libzstd），在 COG 场景中逐渐流行。其关键优势在于：解码速度显著快于 DEFLATE，压缩率通常也更高，且支持多线程压缩与解压。

但 ZSTD 的生态支持不如 DEFLATE 广泛。部分老版本 GIS 客户端、某些云服务的栅格预览组件可能无法直接解码。因此它更适合"自建服务栈、客户端可控"的场景。

3.5 JPEG：有损的诱惑与陷阱

JPEG 压缩通过 DCT 变换、量化和熵编码实现高压缩比，在 8 位影像上表现优异。但用于 16 位反射率产品时问题突出：GDAL 的 JPEG 压缩对 16 位数据的支持有限，且 DCT 的块效应会在高频区域（如水体边界、城市建筑）引入可见伪影。更关键的是，有损压缩会破坏 DN 值的可逆性，导致同一像元在不同读取路径下得到不同值。

工程红线：任何需要参与定量反演、时序变化检测、指数计算的反射率产品，都不应使用有损压缩。JPEG 的合理位置是可视化产品（8 位 RGB 渲染图）与机器学习样本缩略图，而非科学数据本体。

方法	类型	压缩率	解码速度	生态支持
DEFLATE	无损	中	中	极广
LZW	无损	中偏低	中	广
ZSTD	无损	高	高	较广（需较新 GDAL）
JPEG	有损	很高	高	极广

表 2：四种压缩方法的定性对比（综合 GDAL 文档与公开基准的定性归纳，非单一实测）。

四、反射率产品上的压缩选型：数据实测与推理

4.1 反射率数据的可压缩性来源

反射率产品的可压缩性主要来自三方面：空间自相关（相邻像元相似）、波段间相关（多光谱波段高度相关）、以及有效位深低于存储位深（16 位存储但实际动态范围可能只占 12–14 位）。DEFLATE 的 PREDICTOR=2 通过水平差分把空间自相关转化为大量零值或小值，再由 Huffman 编码压缩，这正是其在栅格上有效的原理。

ZSTD 则通过更大的匹配窗口与更优的熵编码阶段获得更高压缩率，同时其解码器针对现代 CPU 做了优化。公开基准（如 GDAL 社区的讨论与部分云厂商的栅格测试）普遍显示：在同类栅格数据上，ZSTD 的压缩率与解码速度综合表现优于 DEFLATE，但具体倍数高度依赖数据内容，不宜引用固定数字。

4.2 一个可复现的对比实验设计

由于不同传感器、不同地表覆盖的压缩表现差异很大，本文不给出"放之四海皆准"的压缩率数字，而是提供一个可复现的实验设计，读者可在自己的数据上验证：

# 对同一景反射率 GeoTIFF，分别用四种压缩生成 COG，记录体积与解码耗时
for COMP in DEFLATE LZW ZSTD JPEG; do
  gdal_translate input_sr.tif out_${COMP}.tif \
    -of COG \
    -co COMPRESS=${COMP} \
    -co PREDICTOR=2 \
    -co BLOCKSIZE=512 \
    -co OVERVIEWS=IGNORE_EXISTING \
    -co RESAMPLING=AVERAGE
  ls -l out_${COMP}.tif
done

# 解码耗时基准（多次取中位数，排除缓存影响）
for COMP in DEFLATE LZW ZSTD JPEG; do
  /usr/bin/time -f "${COMP} %e s" \
    gdal_translate -q out_${COMP}.tif /dev/null
done

注意：JPEG 分支需要输入为 8 位或经适当缩放，16 位反射率直接套用 JPEG 会触发 GDAL 的告警或降级行为，这本身就是"JPEG 不适合科学数据"的一个工程信号。

4.3 选型决策树

基于上述机制与工程约束，笔者给出一条决策路径：

• 若下游存在不可控的老客户端、或需要最大兼容性 → DEFLATE + PREDICTOR=2。
• 若服务栈自建、客户端 GDAL 版本可控（≥2.3）、追求读取性能 → ZSTD。
• 若仅用于可视化、样本缩略、非定量用途 → 可考虑 JPEG，但需明确标注为有损产品。
• LZW 仅作为历史兼容备选，不作为新生产默认。

本文评述：这条决策树的核心不是"哪个压缩率最高"，而是"哪个在满足精度要求的前提下，让读取路径最短"。压缩率只是中间变量，端到端的读取体验才是目标函数。

五、金字塔重采样：nearest 与 average 的统计语义

5.1 重采样的本质是"降采样估计"

金字塔概览是把高分辨率影像逐级降采样得到的低分辨率版本。降采样本质上是一个估计问题：用有限的低分辨率像元去代表高分辨率像元集合的某种统计量。nearest 取中心或最近像元的值，average 取窗口内像元的算术平均。两者代表不同的估计目标。

对于连续型物理量（反射率、温度、高程），average 更接近"区域代表性值"，因为它保留了窗口内的能量/信息均值；nearest 则引入了采样偏差，尤其在纹理复杂区域，单个像元无法代表其邻域。对于离散型类别（土地覆盖分类、掩膜），average 会产生无意义的中间值（如类别 3 和 5 平均成 4），此时必须用 nearest 或众数（mode）。

5.2 对派生指数的影响

这是最容易被忽视的环节。NDVI 等归一化指数是波段间的非线性组合：NDVI = (NIR − R) / (NIR + R)。如果先对 NIR 和 R 分别做 average 再计算 NDVI，与先计算像元级 NDVI 再 average，结果并不相等——这是非线性函数的 Jensen 不等式效应。

关键结论：用 average 生成的金字塔 NDVI 概览，与在全分辨率上计算 NDVI 后再降采样的结果存在系统性偏差。偏差幅度取决于窗口内 NIR 与 R 的变异程度，在混合像元、云边缘、水体边界处最显著。这意味着：基于概览层做的快速统计，不能直接等同于全分辨率统计。

笔者建议的工程做法是：反射率波段的金字塔用 average，分类/掩膜用 nearest，而指数产品应作为独立派生图层单独计算并单独建金字塔，而不是依赖反射率概览的即时组合。这样虽然增加了存储，但保证了各层级统计语义的一致性。

5.3 重采样与压缩的耦合

一个常被忽略的耦合点：概览层的重采样方式会影响概览层的可压缩性。average 产生的概览层更平滑，空间自相关更强，压缩率通常更高；nearest 产生的概览层保留了原始像元的离散性，压缩率略低。这意味着"重采样选择"不仅影响精度，也间接影响存储成本。这个耦合关系在容量规划时应纳入考虑。

数据类型	推荐重采样	理由
反射率波段	average	连续量，均值具区域代表性
分类/掩膜	nearest / mode	离散类别，均值无意义
NDVI 等指数	单独计算后 average	避免非线性组合偏差
QA 位掩膜	nearest（按位处理）	位标志不可插值

表 3：不同数据类型的重采样推荐（基于统计语义的推理，非实测数据）。

六、FME 工作流落地：从 GeoTIFF 到 S3 的完整路径

6.1 为什么用 FME

FME（Feature Manipulation Engine）在批量栅格处理上的优势在于：可视化工作流编排、内置 COG Writer、与云存储（S3、Azure Blob）的原生连接、以及失败重试与日志能力。对于"成百上千景 GeoTIFF 批量转 COG 并上传"这类重复性任务，FME 能把参数固化到工作流中，降低人为误配风险。

需要说明的是，FME 的 COG Writer 底层调用 GDAL，因此本文讨论的压缩与重采样参数在 FME 中同样适用，只是通过 Writer 参数或 RasterBandInterpretation、Compression 等属性暴露。

6.2 工作流骨架

一个稳健的批量转换工作流通常包含以下节点：

1. Reader：读取输入目录或清单文件（CSV/JSON），支持通配符过滤。
2. RasterBandInterpretation / AttributeManager：统一波段解释、设置缩放因子元数据。
3. RasterResampler（可选）：如需统一分辨率或重投影，在此处理。
4. COG Writer：设置 COMPRESS、PREDICTOR、BLOCKSIZE、OVERVIEWS、RESAMPLING。
5. S3 Uploader / HTTP Uploader：上传到目标桶，设置 Content-Type 与元数据。
6. Logger / Terminator：记录成功与失败，失败项进入重试队列。

6.3 关键参数配置

在 FME 的 COG Writer 中，核心参数与 GDAL 的 -co 选项一一对应。以下给出一个面向反射率产品的推荐配置（以 ZSTD 为例）：

COMPRESS=ZSTD
PREDICTOR=2
BLOCKSIZE=512
OVERVIEWS=IGNORE_EXISTING
RESAMPLING=AVERAGE
OVERVIEW_COUNT=6
BIGTIFF=IF_SAFER
NUM_THREADS=ALL_CPUS

若下游兼容性不确定，把 COMPRESS=ZSTD 换成 COMPRESS=DEFLATE 即可，其余参数不变。这种"参数模板化"是 FME 工作流的最大价值之一。

6.4 S3 上传的注意事项

上传到 S3 时，几个细节直接影响 COG 的可用性：

• Content-Type 应设为 image/tiff; application=geotiff，否则浏览器与部分客户端无法正确识别。
• 分块上传：大文件应启用 multipart upload，避免单次请求超时。
• Range 请求支持：S3 原生支持 Range，但需确保未启用会破坏 Range 的中间层（如某些 CDN 配置）。
• 元数据：可把传感器、成像时间、缩放因子等写入对象元数据，便于检索。

拓展阅读：GDAL 官方 COG 驱动文档（gdal.org/drivers/raster/cog.html）、OGC COG 标准（docs.ogc.org/is/21-026）、FME 社区 COG 相关教程（community.safe.com）。

七、验证与对比：如何证明你的选择是对的

7.1 无损性验证

对无损压缩，验证方法是逐像元比对原始与转换后的全分辨率数据。GDAL 提供 gdalcompare.py 工具，可输出差异统计：

python gdalcompare.py -skip_binary original.tif converted.tif

对无损压缩，差异应为 0（元数据差异除外）。若有非零差异，说明压缩链路中混入了有损环节或数据类型转换。

7.2 概览层偏差验证

验证 average 概览的统计偏差，可对比两条路径：

• 路径 A：全分辨率计算 NDVI → 降采样到概览分辨率 → 统计均值。
• 路径 B：反射率概览层（average）→ 计算 NDVI → 统计均值。

两条路径的均值差异即为非线性偏差的量化指标。在均质地表（如大片农田）上差异可能很小，在异质地表（城市、水体边缘）上差异会放大。这个验证应作为数据产品发布前的标准步骤。

7.3 读取性能验证

在 S3 上验证 COG 读取性能，可用 /vsicurl/ 虚拟文件系统模拟真实读取：

# 读取一个 512x512 窗口，观察请求次数与耗时
gdal_translate -srcwin 10000 10000 512 512 \
  /vsicurl/https://bucket.s3.region.amazonaws.com/out_ZSTD.tif \
  window.tif

# 开启 CPL_CURL_VERBOSE 观察 Range 请求
CPL_CURL_VERBOSE=YES gdalinfo /vsicurl/https://.../out_ZSTD.tif

通过对比不同压缩方法的请求次数、传输字节数与耗时，可以得出针对自身网络环境的结论。注意排除 CDN 缓存与本地缓存的影响，多次测量取中位数。

八、局限、风险与前沿预判

8.1 本文分析的局限

首先，压缩率与解码速度高度依赖数据内容与硬件环境，本文刻意避免给出固定倍数，读者应以自身数据实测为准。其次，FME 的 COG Writer 行为可能随版本变化，参数名称与默认值需以所用版本文档为准。第三，重采样偏差的量化需要具体数据支撑，本文给出的是方法论而非普适数值。

8.2 ZSTD 的前景与风险

笔者认为，ZSTD 在云原生栅格中的采用率会持续上升，原因是它与"按需读取、快速解码"的服务化趋势高度契合。但风险在于生态碎片化：如果下游客户端 GDAL 版本参差，ZSTD 文件可能无法打开，反而增加支持成本。因此，在对外开放的数据服务中，DEFLATE 仍是更稳妥的默认；在内部服务栈中，ZSTD 的收益更值得争取。

8.3 重采样的前沿方向

传统的 nearest/average 之外，学界与工业界在探索更保真的降采样方法，如基于面积加权的 conservative resampling、基于频域的抗混叠滤波等。这些方法在保持统计一致性与抑制混叠方面有优势，但计算成本更高，且在 COG 概览这种"多级、批量"场景中的落地仍需权衡。本文评述：短期内 average 仍是连续型反射率概览的合理默认，长期看，能同时保证统计一致性与视觉质量的方案会逐步进入主流工具链。

九、结论与操作清单

回到最初的问题：JPEG/DEFLATE/LZW/ZSTD 怎么选，nearest 还是 average？答案取决于数据语义与工程约束，而非单一指标。以下是可直接执行的操作清单：

这条清单背后的统一逻辑是：让数据语义决定精度边界，让工程约束决定实现路径。压缩与重采样不是孤立的格式参数，而是数据产品契约的一部分。把它们写进工作流模板、写进数据规范，比每次临时决策更可靠。

十、参考文献与拓展资源

10.1 主要参考文献（8–9 篇）

1. OGC. OGC Cloud Optimized GeoTIFF Standard 1.0. OGC 21-026, 2023. 链接
2. GDAL Development Team. GDAL COG Driver Documentation. 2024. 链接
3. Deutsch P. DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF, 1996.
4. Collet Y. Zstandard Compression and the application/zstd Media Type. RFC 8878, IETF, 2021.
5. Welch T A. A Technique for High-Performance Data Compression. Computer, 1984, 17(6): 8–19.
6. GDAL/OGR Contributors. gdal_translate — Raster Format Conversion. 2024. 链接
7. Safe Software. FME Raster and COG Writer Documentation. 2024. 链接
8. NASA LP DAAC. Surface Reflectance Product User Guide. 2023. 链接
9. Rouse J W, Haas R H, Schell J A, et al. Monitoring Vegetation Systems in the Great Plains with ERTS. NASA Special Publication, 1974, 351: 309–317.

10.2 数据集与预处理说明

本文讨论的反射率产品特征参考了公开的 Landsat 与 Sentinel-2 表面反射率产品文档。这类产品通常经过大气校正、地形校正，以 16 位整型存储，附带 scale/offset 元数据。若读者使用自有数据复现本文实验，建议先确认：波段解释（RasterBandInterpretation）是否正确、缩放因子是否保留、NoData 值是否一致。这三项若处理不当，会污染压缩率与重采样偏差的对比结果。

10.3 拓展资源

• GDAL 官方教程与 COG 最佳实践：gdal.org
• OGC COG 标准全文：docs.ogc.org
• FME 社区与知识库：community.safe.com
• Zstandard 官方仓库与基准：github.com/facebook/zstd
• AWS 开放数据栅格访问示例：registry.opendata.aws