开帖讨论:泛型图形图像库
我在做一个泛型图形图像库,我把他叫做MTL
先看与一位朋友的对话:这里谈了库的很多信息(略有删改)
(2003-06-21 20:15:28) e侯子.net
我这几天在做MTL库(以前说的那个图像处理库)
这几天又有进展,比较成形了
(2003-06-21 20:19:46) e侯子.net
我想把库做成一个图像处理的标准,像STL之于数据结构和算法一样,STL很难容纳图像的数据结构和算法,而我现在的目标就是做这个工作
(2003-06-21 20:29:40) e侯子.net
现在我觉得他很好用,效率也不错
可以跨操作系统平台和编译器平台(但不能跨语言,必须用C++),而且很容易使用
但现在最大的问题是我还没有找到一种好的方法来表示像素数据本身,很多算法都会对具体的数据产生依赖,我现在的解决办法是:比如所有RGB颜色数据类型都提供一个公共的RGB32bit和RGB浮点转换接口,这样来编写具体的算法,我总觉得这样的解决办法不好
(趁和你聊天来总结自己的一些想法:) )
(2003-06-21 20:39:45) e侯子.net
我今天实现了一个很有趣的功能
库中所有的图像区域都已经抽象出来了,这个抽象体叫做“迭代器”(STL的迭代器行为像指针,MTL库中的迭代器向二维指针),今天完成的是在这个 “迭代器”前加装“镜子”(迭代器配接器),结果形成一个新的“迭代器”,比如实现了放大、旋转等,“镜子”并不改变实际的数据
,只是改变"迭代器"对于算法的外观,而且"镜子"前还可以不断加装"镜子",呵呵,很有趣
(2003-06-21 20:48:47) e侯子.net
这样实现的方法可能获得很高的速度和效率
以前的方法需要真正的改变数据,可能需要几次遍历数据和来回搬搬运数据,而现在你的方法是加装需要的“镜子”,然后一切OK,而且如果编译器优化好的话,效率有可能达到你手工重新为实现该算法编写的代码. (我在VC6下测试,效果好的令人惊讶!)
(2003-06-21 21:03:39) e侯子.net
因为通过镜子去读那个数据时,读写操作会经过几个算法,通过各个镜子的"折射",自动形成了所需要的算法,而且有些算法根本无关紧要,编译器很可能优化掉,如果优化不了,那也至少不会发生有大量数据移动的情况,
而且我还在考虑一些新的镜子,比如带画笔的镜子,所有对“迭代器”的绘制操作都会自动使用该画笔进行,而算法对此一无所知(比如你写的直线算法,现在它自动具有粗细\笔形或反锯齿能力)还可以开发透明度镜子(自动完成图片的合成,而合成方式由镜子决定)、有色镜子(图片染色)\模糊镜子等等 (还有其他很多奇妙的镜子...)
是不是很有趣
(2003-06-21 21:10:31) e侯子.net
现在库的各个部分相互很独立 (很多时候你也可以拿出来独立使用)
他们都可以独自无关的开发,
放在一起时,他们又可以很好的合作
但也存在一个问题是:这些部件要满足的最小公共接口标准很难决定,很难做出取舍
(2003-06-21 21:24:22) e侯子.net
库在使用时可以很容易在“安全”和“速度”或“方便”之间做出选择,比如对于图像区域的访问如果超界,“安全”版将立刻出错退出,“快速版”则根本不管(它这时实际是原始指针操作),“无效版”将忽略超界的操作,甚至还可以使用“调试”版,它会在超界处暂停而进入调试状态等等(还有其他策略)
/////////////////
/////////////////
图形图像算法具有丰富的涵盖范围和多样性
很多以前的库都以(运行期)静态多态(比如虚函数,或函数指针,或提供多个函数或多个参数)来解决这种多样性
MTL库以一个新的思考方式来处理图形图像算法,它以编译期的多态(模板\C++类\内联\泛型\特性手法\完全源码)来应付现实世界的多样性,提供编码期的强大开发能力并提供运行期的最佳效率,最重要的是它使代码复用达到最高