MS RFC 21:MapServer栅格颜色校正¶
- 日期
2006年10月13日
- 作者
Frank Warmerdam
- 联系方式
Pobox.com上可了解有关Warmerdam的更多信息
- 状态
采用
- 版本
MAPServer 5
概述¶
添加对MapServer的支持，将颜色校正曲线（又称查找表）动态应用于栅格图像。
技术细节¶
将对MapServer的栅格渲染引擎（mapgdaldraw.c）进行扩展，以支持一个处理选项，该选项指示从磁盘读取栅格数据时要即时应用的颜色校正文件。处理选项的形式为：
PROCESSING "LUT=<lut_specification>"
对于同样适用于所有波段的单个LUT，或：
PROCESSING "LUT_<color#>=<lut_specification>"
对于仅适用于一个波段的LUT。<lut_specification>可以是包含lut的文件名，也可以是内联lut定义。内联LUT定义如下所示：
<lut_specification>=<in_value>:<out_value>,<in_value>:<out_value>[,<in_value>:<out_value>]*
文本文件采用相同的格式，除了它可能是多行（行将隐式地用逗号连接）。所以一些常见的形式是：
PROCESSING "LUT=0:0,128:150,255:255"
PROCESSING "LUT_2=green_lut.txt"
请注意，如果提供了相对路径，则将搜索与 Mapfile 相关的LUT规范文件。
在任何缩放到8位后，lut将应用于loadgdalimage（）。因此目前只支持8位（0-255）输入和输出值。或者，我们可以考虑非8bit输入，并允许LUT将缩放应用到8bit，但这在计算效率方面会比较复杂。
256个输入LUT将通过LUT控制点之间的线性插值创建。注意，这与真正的基于“曲线”的方法不同，后者对控制点进行某种形式的曲线拟合。对于大量控制点而言，差异将非常小，但对于只有少数控制点的LUT（即3），差异可能很明显。我们可以选择计算适当的曲线拟合，但这需要额外的研究和开发。
如果输入值0和255没有控制点，则假定为“0:0”和“255:255”的映射。
其他曲线格式¶
GIMP的ASCII曲线格式也将直接得到支持。具体细节有待确定，由于GIMP曲线文件包含多条曲线（针对不同的波段），因此可能需要选择要在处理语句中使用的曲线。可能是这样的：
PROCESSING "LUT_2=GIMP_red:gimp.crv"
Mapfile 含义¶
通过新的处理选项选择所有新选项。 Mapfile 语法没有更改。旧 Mapfile 不应该存在兼容性问题。
MapScript含义¶
没有对mapscript api的添加或更改。新的选项是通过处理层上的信息来控制的，我相信这些层已经可以从mapscript中操作。
文件的含义¶
新的处理选项需要记录在栅格访问howto（可能还有mapfile引用）中。
测试计划¶
每个模式的新测试用例将合并到msautotest/gdal中。
人员配备/时间表¶
新功能将由FrankWarmerdam实现，并在2006年11月30日完成，以包含在MapServer5.0版本中。农业和林业部（芬兰）信息中心提供的资金。