ENVI：FLAASH 定标的三个前置规矩：输出 BIL 格式、Float 类型、Scale Factor 0.1

一、问题的提出：为什么这三个选项值得单独讨论

在遥感影像预处理的标准流程中，辐射定标（Radiometric Calibration）与大气校正（Atmospheric Correction）是两个紧邻但性质迥异的环节。前者把 DN 值转换为具有物理量纲的表观辐亮度（Radiance, W·m⁻²·sr⁻¹·μm⁻¹）或表观反射率（TOA Reflectance），后者则进一步剥离大气散射与吸收的贡献，得到地表反射率（Surface Reflectance）。ENVI 的 FLAASH 模块并不直接读取原始 DN，而是要求输入已经过辐射定标的产品，这就产生了一个"接口"问题：定标输出以什么格式、什么数据类型、什么量纲交付给 FLAASH，直接决定了 FLAASH 能否正确解析。

在 ENVI 的 Radiometric Calibration 工具面板中，有三个默认设置长期存在：Output Interleave 默认为 BIL，Output Data Type 默认为 Float，Scale Factor 默认为 0.1。多数教程只告诉读者"保持默认即可"，却很少解释为什么。本文评述：这种"默认即正确"的传播方式，在单一传感器、单一数据源的场景下确实不会出问题，但一旦切换到多传感器协同、批处理流水线或跨平台迁移（如从 ENVI 迁移到 Python 生态），默认值的隐含假设就会失效，而失效的表现往往滞后到大气校正结果出来之后才显现，届时排查成本极高。

笔者认为，把这三个选项称为"前置规矩"而非"参数设置"是更准确的定位。规矩意味着它们是链路闭合的必要条件，而非可调优的选项。本文的分析主线即由此确立：三者共同构成辐射定标向大气校正交付数据的"接口契约"，契约的核心是量纲、内存布局与数值精度的三重一致性。任何一环断裂，链路就无法闭合。

工程现场观察：在某省级自然资源卫星应用中心的批处理流水线中，曾出现同一景 GF-2 影像在单机处理时结果正常、在集群批处理时反射率整体偏低约 10 倍的现象。最终定位为批处理脚本在调用 Radiometric Calibration 时未显式指定 Scale Factor，而不同 ENVI 版本对该参数的默认继承行为不一致。这类问题的根源，正是接口契约未被显式声明。

二、辐射定标与大气校正的接口逻辑

2.1 辐射定标的输出到底是什么

辐射定标的本质是把无量纲的 DN 值，通过传感器定标系数（Gain/Offset，或辐射定标系数表）转换为具有物理意义的辐射量。以 Landsat 8 OLI 为例，USGS 提供的定标系数以元数据形式随影像分发，定标公式为 L_λ = M_L · Q_cal + A_L，其中 M_L 为乘性系数，A_L 为加性系数，Q_cal 为量化后的 DN 值（USGS, 2023）。定标后的辐亮度量级通常在 0–1000 W·m⁻²·sr⁻¹·μm⁻¹ 之间，具体取决于传感器与地物。

问题在于，这个辐亮度值如果以 Float32 存储，单波段单像元占 4 字节；若以 UInt16 存储，则占 2 字节，但 UInt16 的取值范围是 0–65535，无法直接容纳带小数的辐亮度。ENVI 的解决方案是引入 Scale Factor：把浮点辐亮度乘以一个系数后取整存入整型，读取时再除以该系数还原。这就是 Scale Factor 的原始动机——用整型存储换取空间，用量纲系数换取精度。

2.2 FLAASH 对输入的隐含假设

FLAASH 的输入要求在其官方文档中有明确说明：输入影像应为辐射定标后的辐亮度数据，单位 W·m⁻²·sr⁻¹·μm⁻¹，且需提供影像中心经纬度、传感器类型、飞行高度、地面高程、气溶胶模型、水汽反演设置等辅助参数（Exelis VIS, 2015）。但文档中有一处关键细节常被忽略：FLAASH 在读取输入影像时，会依据影像头文件中的 Data Type 与 Scale Factor 字段进行量纲还原，若头文件信息与实际数据不符，还原结果就会错误。

本文评述：FLAASH 的设计哲学是"信任头文件"，它不会去校验数据本身是否真的是辐亮度。这意味着接口契约的履行完全依赖定标环节的自觉。一旦定标输出的头文件标注为 Float 但实际存的是缩放后的整型，或者 Scale Factor 标注为 1 而实际用了 0.1，FLAASH 都会"照单全收"地算出一个错误的地表反射率。这种错误不会报错，只会静默地污染结果。

2.3 接口契约的三要素

综合上述分析，定标向 FLAASH 交付数据时，契约包含三个要素：内存布局（Interleave）、数值精度（Data Type）、量纲系数（Scale Factor）。三者分别对应"怎么读""读成什么""读完怎么还原"三个问题。BIL 解决的是读取效率与波段顺序问题，Float 解决的是精度无损问题，Scale Factor 解决的是量纲还原问题。三者相互独立又彼此耦合，下文逐一拆解。

三、规矩一：输出 BIL 格式——内存访问模式的决定权

3.1 BSQ、BIL、BIP 的本质区别

遥感影像的三种常见存储格式——BSQ（Band Sequential）、BIL（Band Interleaved by Line）、BIP（Band Interleaved by Pixel）——区别在于波段、行、像元三个维度的排列顺序。BSQ 按波段顺序存储，同一波段的数据连续排列；BIL 按行交错，同一行内各波段的数据连续排列；BIP 按像元交错，同一像元各波段的数据连续排列。

从磁盘 I/O 的角度看，BSQ 适合"逐波段处理"的场景，因为读取一个波段时磁头可以连续读取；BIP 适合"逐像元处理"的场景，如光谱匹配、端元提取；BIL 则介于两者之间，是"逐行处理"场景的折中。FLAASH 的内部算法需要逐行读取所有波段进行大气参数计算，因此 BIL 是访问效率最高的格式。ENVI 官方文档明确指出，FLAASH 对 BIL 格式的支持最为成熟（Harris Geospatial, 2022）。

3.2 为什么 FLAASH 偏好 BIL

FLAASH 的核心计算流程包括：逐像元计算大气透过率、逐波段计算气溶胶光学厚度、逐行进行辐射传输方程求解。其中"逐行"是关键——FLAASH 在求解辐射传输方程时，需要同一行内所有波段的数据同时参与计算，因为水汽反演、气溶胶反演都依赖波段间的比值关系（如 0.66 μm 与 2.1 μm 波段的比值用于暗像元法）。BIL 格式恰好把同一行的所有波段数据连续存放，一次磁盘读取即可获得整行数据，缓存命中率最高。

本文评述：BIL 的选择并非 FLAASH 的"偏好"，而是其算法结构的必然要求。如果强行用 BSQ 输入，FLAASH 会在内部先做一次格式转换，这个转换过程会额外占用内存并产生临时文件。对于大幅面高光谱影像（如 GF-5 AHSI 的 330 个波段、幅宽 60 km），这个临时文件可能达到数十 GB，在内存受限的机器上直接导致处理失败。因此，在定标环节就输出 BIL，本质上是把格式转换的成本前置到可控环节，避免在大气校正环节被动触发。

3.3 工程陷阱：格式转换中的波段错位

在 ENVI 中，格式转换通过 Convert Interleave 工具完成。这个工具本身很稳定，但有一个常见陷阱：当输入影像带有坏波段（如 Landsat 8 的 B8 全色波段与多光谱波段分辨率不一致）时，若未先做波段剔除，转换后的 BIL 文件波段顺序可能与头文件描述不符。FLAASH 读取时会按头文件的波段波长信息匹配，一旦错位，水汽反演就会用错波段，导致校正结果出现系统性偏差。

笔者建议的操作路径是：在辐射定标之前，先用 Layer Stacking 工具把需要参与大气校正的波段按波长顺序堆叠，剔除全色波段、卷云波段（如 Landsat 8 的 B9）和 QA 波段，然后再做定标并输出 BIL。这样可以从源头避免波段错位。

四、规矩二：Float 数据类型——量纲传递的保真底线

4.1 整型存储的精度损失有多大

辐射定标后的辐亮度是浮点数，典型量级在 0–1000 之间，小数部分通常有 2–4 位有效数字。如果以 UInt16 存储，必须乘以一个 Scale Factor 后再取整。以 Scale Factor = 0.1 为例，实际存储的是 L/0.1 = L×10，即把辐亮度放大 10 倍后取整。此时 1 个存储单位对应 0.1 W·m⁻²·sr⁻¹·μm⁻¹ 的辐亮度，量化误差最大为 ±0.05。

这个误差在辐亮度层面看似很小，但大气校正是一个"减法+除法"的过程：先减去程辐射（Path Radiance），再除以大气透过率与球面反照率的组合项。程辐射在短波波段可能达到辐亮度的 30%–50%，减法之后剩余的信号被压缩，此时量化误差的相对占比会被放大。本文评述：整型存储的量化误差在大气校正的除法环节会被放大数倍，这是 Float 类型不可替代的根本原因。

4.2 Float32 与 Float64 的取舍

ENVI 的 Radiometric Calibration 默认输出 Float32。Float32 有 24 位有效尾数，约 7 位十进制有效数字，对于辐亮度这种量级的数据完全够用。Float64 虽然精度更高，但存储空间翻倍，且 FLAASH 内部计算本身以 Float32 为主，输入 Float64 会在读取时被降精度，收益有限。

笔者认为，除非做多时相叠加的定量反演（如长时间序列的植被指数趋势分析），否则 Float32 是性价比最优的选择。对于单景大气校正，Float32 与 Float64 的结果差异远小于气溶胶模型选择带来的差异。

4.3 一个容易被忽略的细节：头文件中的 Data Type 字段

ENVI 的影像头文件（.hdr）中有一个 data type 字段，用数字编码表示数据类型：1 = Byte，2 = Int16，3 = Int32，4 = Float32，5 = Float64，12 = UInt16，13 = UInt32 等。这个字段是 FLAASH 读取数据时判断如何解析字节流的唯一依据。如果定标输出时选择了 Float32，但后续用其他工具（如 GDAL）修改了数据而未同步更新头文件，FLAASH 就会按错误的类型解析，结果完全错乱。

本文评述：头文件与数据文件的一致性，是遥感数据工程中最基础也最容易被破坏的约束。在跨平台工作流中（ENVI 定标 → GDAL 裁剪 → ENVI FLAASH），每一次工具切换都可能引入头文件不同步的风险。建议在进入 FLAASH 之前，用 ENVI 的 File > Open 重新加载一次影像，确认头文件信息与实际数据匹配。

五、规矩三：Scale Factor 0.1——被误解最深的量纲还原系数

5.1 Scale Factor 的两种含义

Scale Factor 在 ENVI 中有两种截然不同的用法，这是误解的根源。第一种是"存储缩放"：当输出数据类型为整型时，把浮点值乘以 Scale Factor 后取整存储，读取时除以 Scale Factor 还原。第二种是"量纲转换"：把辐亮度乘以 Scale Factor 转换为其他单位，如把 W·m⁻²·sr⁻¹·μm⁻¹ 转换为 μW·cm⁻²·sr⁻¹·nm⁻¹。

在 Radiometric Calibration 工具中，Scale Factor 的默认值 0.1 属于第一种用法。当输出类型为 Float 时，理论上不需要缩放，Scale Factor 应设为 1。但 ENVI 的默认值仍是 0.1，这就产生了一个矛盾：Float 类型 + Scale Factor 0.1 的组合，意味着输出的数值是真实辐亮度的 0.1 倍，头文件中记录了 scale factor = 0.1，FLAASH 读取时会除以 0.1 还原。

这个机制本身是自洽的，但问题在于：如果用户在定标时把 Scale Factor 改成了 1，而 FLAASH 的输入设置中仍按 0.1 处理（或反之），量纲就会错 10 倍。更隐蔽的是，某些 ENVI 版本在 FLAASH 面板中不显示 Scale Factor 输入框，而是直接读取头文件，此时若头文件被篡改，错误就无从察觉。

5.2 为什么默认是 0.1 而不是 1

这个默认值的历史可以追溯到 ENVI 4.x 时代。当时计算机内存昂贵，Float32 存储被视为"奢侈"，多数用户选择 UInt16 输出以节省空间。UInt16 的最大值是 65535，而典型辐亮度在 0–1000 之间，若 Scale Factor = 1，则 1000 以内的整数部分可以存储，但小数部分全部丢失；若 Scale Factor = 0.1，则 1000 的辐亮度存储为 10000，仍在 UInt16 范围内，且保留了 0.1 的精度。0.1 是在"不溢出"与"保精度"之间的折中。

本文评述：0.1 这个默认值是特定历史条件下的产物，在 Float32 输出已成主流的今天，它的存在更多是一种"历史惯性"。但正因为它是默认值，且 FLAASH 会读取头文件中的 scale factor 字段，所以保持定标与 FLAASH 两端的 Scale Factor 一致，比纠结具体取值更重要。如果定标用 0.1，FLAASH 就必须知道是 0.1；如果定标用 1，FLAASH 就必须知道是 1。

5.3 一个可复现的验证方法

要验证 Scale Factor 是否被正确传递，可以在定标完成后、进入 FLAASH 之前，用 ENVI 的 Statistics 工具查看影像的直方图。如果定标输出的是 Float 且 Scale Factor = 0.1，那么直方图的数值范围应该在 0–100 左右（真实辐亮度的 0.1 倍）；如果范围在 0–1000 左右，说明 Scale Factor 实际为 1。把这个范围与头文件中的 scale factor 字段对照，即可确认一致性。

实操提示：ENVI 的 Edit Header 工具可以直接查看和修改头文件中的 scale factor 字段。在批处理场景下，建议用 IDL 或 ENVI Modeler 显式设置该字段，而不是依赖默认继承。相关官方说明可参考 NV5 Geospatial 的 Radiometric Calibration 文档。

六、三者的耦合关系：一个失配的连锁反应

6.1 耦合矩阵

三个规矩并非孤立，它们的失配会相互放大。下表梳理了常见的失配组合及其后果（模拟数据，基于 ENVI 5.6/6.0 的实测行为归纳）。

6.2 为什么错误总是滞后暴露

这三个规矩的失配之所以难以在定标环节发现，是因为定标工具本身不校验物理合理性。它只负责按公式计算、按设置存储，不判断结果是否在合理范围内。而 FLAASH 又信任头文件，不做二次校验。于是错误被"封装"进数据，直到用户看到地表反射率结果时才发现异常——此时已经过去了整个处理流程。

本文评述：接口契约的验证必须前置到定标完成的那一刻，而不是等到大气校正之后。建议在定标输出后立即做三项检查：直方图范围是否合理、头文件 data type 与 scale factor 是否与设置一致、波段波长信息是否完整。这三项检查耗时不到一分钟，却能避免数小时的返工。

七、完整操作路径：从 L1 到地表反射率

7.1 步骤一：波段筛选与堆叠

打开 ENVI，使用 File > Open 加载 L1 级影像。对于 Landsat 8 OLI，剔除 B8（全色）、B9（卷云）、B1（海岸气溶胶，可选保留）和 QA 波段。使用 Layer Stacking 工具（Toolbox > Raster Management > Layer Stacking）按波长从短到长堆叠。输出格式暂选 BSQ 即可，因为下一步定标会重新指定。

7.2 步骤二：辐射定标

打开 Toolbox > Radiometric Correction > Radiometric Calibration。在面板中依次设置：

• Calibration Type：Radiance（辐亮度），若后续要做 FLAASH，必须选 Radiance 而非 Reflectance；
• Output Interleave：BIL；
• Output Data Type：Float；
• Scale Factor：0.1（保持默认，但需记录该值）；
• Output Filename：建议命名为 *_rad_bil_float.dat，便于追溯。

点击 OK 执行。完成后用 Statistics 查看直方图，确认数值范围在合理区间。

7.3 步骤三：FLAASH 参数设置

打开 Toolbox > Radiometric Correction > Atmospheric Correction Module > FLAASH Atmospheric Correction。关键设置包括：

• Input Radiance Image：选择上一步的 BIL/Float 文件；
• Output Reflectance File：指定输出路径；
• Output Directory for FLAASH Files：指定临时文件目录，建议放在空间充足的磁盘；
• Scene Center Location：从影像头文件自动读取，需核对；
• Sensor Type：选择对应传感器（如 Landsat-8 OLI）；
• Ground Elevation：从 DEM 获取，或使用影像区域平均高程；
• Atmospheric Model：根据纬度和季节选择（如 Mid-Latitude Summer）；
• Aerosol Model：根据区域选择（如 Rural、Urban、Maritime）；
• Water Retrieval：高光谱数据建议开启，多光谱数据视波段配置而定。

在 Advanced Settings 中，确认 Scale Factor 与定标输出一致。若面板中无该选项，则 FLAASH 会读取头文件，需提前用 Edit Header 核对。

7.4 步骤四：结果验证

FLAASH 完成后，用 Spectral Profile 工具对比校正前后的光谱曲线。健康植被在校正后应在 0.55 μm 附近有绿峰、0.68 μm 附近有红谷、0.75 μm 之后有近红外高台。若曲线形态异常（如红谷消失、近红外低于红光），说明校正参数有误。此外，可用已知地物的实测光谱做交叉验证，或与 USGS 的 Landsat 地表反射率产品（LaSRC 算法）对比。

拓展资源：ENVI 官方提供了 FLAASH 的完整教程与示例数据，可参考 NV5 Geospatial FLAASH 文档。此外，USGS 的 Landsat Surface Reflectance 页面 提供了官方地表反射率产品的算法说明，可用于交叉验证。

八、诊断表：常见报错与结果异常的归因

下表汇总了 FLAASH 定标环节相关的常见问题及其归因，供排查时参考（基于 ENVI 5.6/6.0 的用户社区反馈与实测归纳，模拟数据）。

九、前沿预判：ENVI 6.x 与开源替代的接口演进

9.1 ENVI 6.x 的变化

ENVI 6.x 在架构上做了较大调整，底层引入了更现代的栅格数据抽象层。从公开的 Release Notes 看，6.x 对 BIL 的依赖有所弱化，FLAASH 在读取非 BIL 格式时的内部转换效率有所提升（NV5 Geospatial, 2024）。但本文评述：效率提升不等于契约消失，Scale Factor 与 Data Type 的一致性要求依然存在，因为这是数值正确性问题，不是性能问题。

此外，ENVI 6.x 开始支持通过 ENVI Modeler 和 IDL 进行更细粒度的参数控制，这对批处理流水线是利好——可以把三个前置规矩显式写入脚本，而不是依赖 GUI 默认值。

9.2 开源替代方案的接口设计

在开源生态中，大气校正的主流方案包括 6S（Second Simulation of the Satellite Signal in the Solar Spectrum）、Py6S、MODTRAN 以及面向水体的 Acolite。这些工具的接口设计与 ENVI 有本质差异：它们通常不依赖"头文件中的 Scale Factor"，而是要求在调用时显式传入辐亮度数据及其单位。

本文评述：开源方案的做法更符合"显式契约"的工程原则。Py6S 的 API 要求用户明确指定波长、辐亮度、几何条件，不存在隐含的缩放系数。这种设计虽然增加了调用者的负担，但消除了"默认值陷阱"。笔者认为，ENVI 的 GUI 友好性是以隐含契约为代价的，在批处理和跨平台场景下，显式传参的开源方案反而更可靠。

9.3 未来趋势：从"选项"到"元数据"

随着 STAC（SpatioTemporal Asset Catalog）和 COG（Cloud Optimized GeoTIFF）的普及，遥感数据的元数据描述正在标准化。未来，Scale Factor、Data Type、Interleave 这些信息有望以标准字段的形式嵌入元数据，由处理引擎自动解析，而不是依赖用户在 GUI 中手动设置。本文评述：这一趋势会弱化"三个前置规矩"的存在感，但不会消除其背后的物理约束——量纲、精度、内存布局的一致性要求，是辐射传输计算的固有属性，与工具形态无关。

十、结论与工程建议

回到本文的主线：输出 BIL、Float 类型、Scale Factor 0.1 这三个设置，本质上是辐射定标向 FLAASH 交付数据的接口契约。BIL 保证内存访问效率，Float 保证量纲传递精度，Scale Factor 保证数值还原正确。三者共同构成链路闭合的必要条件。

基于全文分析，笔者给出以下工程建议：

1. 显式声明，不依赖默认。在批处理脚本中显式设置三个参数，并在日志中记录实际取值。
2. 定标后立即验证。检查直方图范围、头文件字段、波段波长信息，三项检查耗时不到一分钟。
3. 保持两端一致。定标端的 Scale Factor 与 FLAASH 端读取的值必须一致，建议统一用 0.1 并记录。
4. 跨平台时重建头文件。经过 GDAL 等工具处理后，用 ENVI 重新加载并核对头文件，必要时用 Edit Header 修正。
5. 建立结果验证基线。用已知地物的光谱曲线或官方地表反射率产品做交叉验证，形成可复现的质量控制流程。

这三个前置规矩的价值，不在于它们本身有多复杂，而在于它们提醒我们：遥感数据处理链路的每一个接口，都承载着物理量纲与数值精度的传递责任。把接口当"选项"，错误就会滞后暴露；把接口当"契约"，链路才能稳定闭合。