GDAL 2.4读取TIFF文件不符合预期的技术咨询

你遇到的这个情况，核心原因是GDAL 2.3版本开始对TIFF格式的解析逻辑做了大幅兼容性优化，尤其是针对那些格式有瑕疵但实际像素数据完整的文件。下面具体拆解你忽略的几个关键点：

1. image_broken的本质：格式有瑕疵但数据完整 #

你的image_broken并不是真的“数据损坏”，而是在生成时存在TIFF格式规范上的小问题，比如：

• 条带/块的偏移量记录有误，但实际数据块的物理位置是正确的
• 元数据字段（比如StripByteCounts）和实际数据大小有轻微不匹配
• 旧版本GDAL或其他工具写入时的遗留bug导致格式不严格符合TIFF标准

这种文件在严格遵循TIFF规范的软件（GDAL 2.2及更早、其他第三方TIFF读取工具）眼里就是“损坏”的，但GDAL 2.3+的读取逻辑新增了自动修复这类瑕疵的能力，所以能正确提取出像素数据。

2. GDAL 2.3的TIFF驱动更新是关键 #

GDAL 2.3版本的GTiff驱动做了不少针对性的兼容性改进：

• 增强了对损坏TIFF的自动修复（比如修复条带计数错误、偏移量错误）
• 优化了对非标准TIFF布局的解析逻辑
• 处理了之前会导致读取失败的元数据异常

这就是为什么从GDAL 2.3开始，两个文件的读取结果一致——新版本能“宽容”地读取那个格式有瑕疵的文件，而旧版本不行。

3. 你忽略了：像素数据一致≠文件格式一致 #

你的测试代码只对比了两个文件的像素数组，而GDAL在读取image_broken时，已经自动修复了格式问题，返回的是正确的像素数据，所以np.array_equal会返回True。但两个文件的底层格式结构是有差异的，要检测这种差异，你需要：

• 用gdalinfo命令行工具查看两个文件的详细结构：

  gdalinfo ./MOD10A1.A2019001.006.snow_multi.tif
  gdalinfo MOD10A1.A2019001.006.snow_multi_bd.tif
  

• 对比输出中的Strip offsets、Strip byte counts、元数据字段等，就能找到格式上的具体差异。

4. 验证方法 #

• 用GDAL 2.2的gdalinfo读取image_broken，大概率会抛出格式错误；用GDAL 2.4的gdalinfo则能正常输出所有信息。
• 用LibTIFF的tiffinfo命令查看两个文件，image_broken应该会显示格式异常的提示。

总结 #

你预期GDAL 2.4能识别出文件差异，是混淆了“像素数据”和“文件格式结构”的区别；而GDAL 2.2和2.4的读取行为不一致，是因为新版本对TIFF格式的兼容性和容错能力做了提升，能自动修复部分格式瑕疵。

内容的提问来源于stack exchange，提问作者gdal_not_working