Delphi图像处理 图像高斯模糊处理（改进版）
我在文章《Delphi图像处理 -- 图像卷积及高斯模糊》中，介绍了利用通用的图像卷积过程对图像进行高斯模糊处理，其处理效果还不错，处理小型图像时感觉也还行，但是处理较大图像时的速度还是嫌慢，在我的P4 2.8G、1G内存的机器上对千万像素图像进行Q=3，R=5的高斯模糊处理，不包括图像装载和前期数据转换，耗时达8600ms以上，虽经几次修改，其处理速度始终得不到明显提高，主要原因还是采用通用卷积过程处理的问题：用R=5得到的卷积模板为11*11像素，一个像素有4个分量（32位ARGB），对每个象素必须作11*11*4=484个乘法、484个加法及4个除法，最后还得作4个分量是否超界的判断处理，想不慢都难啦！如果不是采用BASM定点数处理代码，其处理速度更是难以想象。
我在网上多次查找图像高斯模糊的优化算法，不少算法和处理方式，包括代码优化还不如我的那个高斯模糊处理过程，使我很失望。前天查找其它资料时，在国外某个网站上发现介绍图像高斯模糊处理方法时似乎与常规的算法有所不同，但都没有详细的资料（因为不懂外语，很少上国外网站，但看些公式、伪代码还是行的）， 经过反复琢磨，可以将其处理流程归纳如下：
1、用给定的确定Q和长度size，计算一个size+1长的高斯分布权数数据weights：
radius = size / 2
// 计算初始数据
for (i = -radius; i <= radius; i ++)
{
x = i / Q;
weights[i+radius] = exp(-x * x / 2)
}
// 求和
sum = 0
for (i = -radius; i <= radius; i ++)
{
sum += weights[i+radius]
}
// 数据归一，即归一后的数据之和等于1
for (i = -radius; i <= radius; i ++)
{
weights[i+radius] /= sum
}
2、使用weights对原图像作垂直的模糊运算，即以像素(x, y)为中心，对(x, y - radius)和(x, y + radius)的像素点与weights对应的值相乘后求和得到新的像素，并写入到一个临时的图像上相应的点上（因为数据进行了归一处理，乘积和不必再作除法运算）；
3、使用weights对临时图像作水平的模糊运算，即以像素(x, y)为中心，对(x - radius, y)和(x + radius, y)的像素点与weights对应的相乘后求和得到新的像素，并写入到目标图像上相应的点上。
处理过程结束。
由于上面的处理流程只是对图像每个象素作了一个“十&rd
相关文档：
有关开发习惯的一些想法，如鲠在喉，不吐不快。究其发贴动机，当然不排除有骗取参与分的可能，但另一方面，也希望能给同行（念Xing）者提供一些
建议，或者参考(希望不是误人子弟)。同时，也希望各位能够就我的这些陋习，发表一点看法，给出批评和指正的意见。谢谢。
一．建立工程目录
&n ......
在低版本中设定MSCOMM控件，是导入MSCOMM组件，然后就可以看见MSCOMM控件的电话的图标了，但是在DELPHI 2005或以上版本中就必须先把此控件创建到包中（BPL）然后导入BPL，那个电话图标就可以看见在工具条上了。我试了多少回才试出来的。 ......
最近面试了一家企业,下面有一道从来没有想过的问题,当时有思路,不过写不出来.回来后,调试了一下,发现还是有难度的,写上来看大家是否还有更优化的写法,欢迎讨论:
下面实现将字符串"10ad200d3" 中的数字合计,10+200+3=213
var s1:string;
var i:integer;
var n1:integer;
var tem1: string;
var tem2:integer;
......
明天就是五一节了，辛苦了好几个月，借此机会应该尽情放松一番。可是想到Blog好久没有写文章，似乎缺些什么似的。这几个月来在项目中又增长了许多经验，学到许多实际应用的知识。不如把一些比较有用的记录下来，供朋友们参考可好。
我想到Delphi的事件，那可真是个方便的东西，初学者在窗体上拉几个� ......
如今RealPlayer的流式媒体文件以其强大的视频压缩比正逐步悄然兴起。RealPlayer Plus播放器也理所当然地成为大家播放RealPlayer格式文件的首选软件。不过RealPlayer Plus也不是十全十美的，比如启动时间慢，占用空间大，留有历史记录等等。其实我们可以利用Delphi打造一个完全符合自己要求的RealPlayer� ......
