一种简单而快速的灰度图处理法
作者：袖梨
2022-07-02
因自己的程序中需对一个窗体区域频繁进行彩色转灰度处理，为此专门写了个函数。处理对象是一块经常变化的动态区域，且是一系列绘图中的一部分，速度要求较高，算法上力求简单，所以采用以下两步方案：
1、基于DDB来写，虽然转入DIB，可不必面对各种色深，会统一算法，但转换过程会让速度上慢很多，再者这只是针对屏幕位图的函数，并无保存需要。
考虑实际情况，我只写了16、24、32位三种色深下的算法，其实4、8两种位图是最快的了，不管多大的图只需处理16与256次运算，可是现在哪有人的屏幕，还使用这两种显示模式呢？想想就没这个必要了。
相比之下，32位时最快，16位时最慢，心里有点不满意，但好在速度都不慢。差距也不超过50%。
2、灰度算法本来就不复杂，但我还是做了简化，正常处理时一般需对RGB做加权平均，取个值来统一三基色，但这需涉及浮点运算，速度上不去，效果却不见得有多好。
我的方法很简单，就是取三基色之一的值，统一起来，考虑人眼对绿色最敏感，所以算法就成RGB转GGG了。严格的说，这不叫彩转灰，叫绿转灰更合适。RGB的排列G是在中间的，想利用高速Long运算，用B值最快的，但已经够简化了，再简下去，自己都过意不去。（用B值时32位下，速度还可快1/3）
这种算法当然有缺陷，主要是对一些偏色图效果不好，但好在这种情况在色彩丰富的界面中不存在。
C2.4G 256M WinXP SP2下的测试情况
IDE环境下
1024 X 768的位图
32位屏幕 219毫秒
16位屏幕 314毫秒
N代码编译，全部优化打开
1024 X 768的位图
32位屏幕 62毫秒
16位屏幕 75毫秒
注：没有24位环境，所以也就没测了
Option Explicit
Private Type BITMAP
bmType As Long
bmWidth As Long
bmHeight As Long
bmWidthBytes As Long
1、基于DDB来写，虽然转入DIB，可不必面对各种色深，会统一算法，但转换过程会让速度上慢很多，再者这只是针对屏幕位图的函数，并无保存需要。
考虑实际情况，我只写了16、24、32位三种色深下的算法，其实4、8两种位图是最快的了，不管多大的图只需处理16与256次运算，可是现在哪有人的屏幕，还使用这两种显示模式呢？想想就没这个必要了。
相比之下，32位时最快，16位时最慢，心里有点不满意，但好在速度都不慢。差距也不超过50%。
2、灰度算法本来就不复杂，但我还是做了简化，正常处理时一般需对RGB做加权平均，取个值来统一三基色，但这需涉及浮点运算，速度上不去，效果却不见得有多好。
我的方法很简单，就是取三基色之一的值，统一起来，考虑人眼对绿色最敏感，所以算法就成RGB转GGG了。严格的说，这不叫彩转灰，叫绿转灰更合适。RGB的排列G是在中间的，想利用高速Long运算，用B值最快的，但已经够简化了，再简下去，自己都过意不去。（用B值时32位下，速度还可快1/3）
这种算法当然有缺陷，主要是对一些偏色图效果不好，但好在这种情况在色彩丰富的界面中不存在。
C2.4G 256M WinXP SP2下的测试情况
IDE环境下
1024 X 768的位图
32位屏幕 219毫秒
16位屏幕 314毫秒
N代码编译，全部优化打开
1024 X 768的位图
32位屏幕 62毫秒
16位屏幕 75毫秒
注：没有24位环境，所以也就没测了
Option Explicit
Private Type BITMAP
bmType As Long
bmWidth As Long
bmHeight As Long
bmWidthBytes As Long
