ArrayList的效率不比我自己写排序和检索快。
12:51 2007-5-18
昨天调试程序发现一个严重问题：因为原图是24位的，所以Bitmap对象也是24位的，所
以对Bitmap对象的所谓alpha通道做的所有操作都无效。以前之所以没有这个问题是因
为从picBox的的Image属性构建一个新的Bitmap对象的位数是32位的，以前的程序操作
Bitmap对象的时候Bitmap对象是从picBox的Image属性构造的。于是我用Bitmap.Clone
的方法重新构建了一个Bitmap对象，传入参数PixelFormat.Format32bppArgb，从而构
造了一个32位的Bitmap对象。
在修改程序的时候我看到了PixelFormat.Format64bppArgb这个参数！乐得我不行了
都，于是我直接构建64位Bitmap对象，以前那些为了保留精度又兼顾温度范围所做的操
作统统废掉，温度直接可以保存到16位的alpha通道中！我兴冲冲删啊改啊，最后调
试，结果报错，一查，数据溢出，color对象的A属性为byte类型，不能存储超过255的
值。奇怪了，都是64位的图像了，alpha通道怎么还是byte呢？应该是word啊，我MSDN
了一下，结果发现一段备注：
"PixelFormat48bppRGB、PixelFormat64bppARGB 和 PixelFormat64bppPARGB 使用 16
位/颜色分量（通道）的像素格式。GDI+ 1.0 和 1.1 版本都能读取 16 位/通道格式的
图像，但是这种图像需要转换为 8 位/通道格式，以便处理、显示和保存。每个 16 位
颜色通道能够保存一个范围在 0 到 2^13 的值。"
郁闷~！GDI+既然不能处理 16 位/通道格式的图像干嘛允许我构造64位图像啊！！！
怒！
白高兴了，程序也白改了，无奈，只好老老实实将程序改回去……
昨天一个白天就这么折腾掉了。
晚上继续调试程序，结果发现了一个更为严重的问题，以前认识上有个疏漏：我们将温
度值转换之后存入图像每个像素的alpha分量，但是打开一幅存有转换温度值的图像，
程序没办法知道每个转换温度值对应的温度真值是多少，每张图的转换关系都是不一样
的，一张图一个对应表。
这个之前没有考虑到的严重问题让我想了好久。
今天上午问了Dr.Liu之后暂时决定在图像的头的调色板部分存储这样一个表。另外，和
Dr.Liu的讨论的时候我表示了对所做工作的实际意义的担忧，Dr.Liu的观点和我差不多，
也认为意义不是很大，让我问一下Dr.Fu的意思。我去8楼找Dr.Fu，讨论了半天，最后
Dr.Fu拷了一页IR-Fusion技术介绍给我，也许有点用处，不仅可以思考一下它的软件的
融合方式，而且也可以在以后的论文中做对比。
15:09 2007-5-20
___
Sent with SnapperMail on Treo650
No comments:
Post a Comment