原创 新作DELPHI 图片图像处理 PS置换滤镜效果，亮度/对比度，纹理贴图 ,无汇编全部GDI·· 大家鉴定下效果,该怎么处理
原创 新作DELPHI 图片图像处理 PS置换滤镜效果，亮度/对比度，纹理贴图 ,无汇编全部GDI·· 大家鉴定下效果
以前没弄过DELPHI，最近学了1个多星期时间，无聊时候把以前把C#写的部分图像处理代码转换成DELPHI，竟然发现D处理图片的速度比C#快了20倍··················D处理图片0.3s，C#处理同一图片6s多 ，差距真大····················
我写的算法调用GDI+函数，无汇编便于理解，觉的有帮助就顶一个，顶的多就发布下一篇图像处理，转帖的话请写明转帖和原作者： 睿割氏窝老攻 ，QQ 235483710 EMAIL: jennievictor@163.com
代码太多，怕看不清楚，下面是我的BLOG地址 ：
http://blog.****.net/huruihappy/archive/2008/09/06/2892902.aspx
------解决方案--------------------
毫无疑问，直接读到数组快，Bitmap格式不需要做复杂解释，文件头和位图BITMAPFILEHEADER/BITMAPINFOHEADER都是Win SDK直接定义的。对应VCL里的TBitmapFileHeader/TBitmapInfoHeader，根据Header确定后面的调色板和位图数据格式。而TBitmap为了使用GDI直接进行操作，需要创建DIB，作了很多多余操作。可阅读TBitmap.ReadDIB中的代码。要习惯阅读代码，程序上的问题嘛，所有的结论都可以精确得出。根本不需要靠猜测。这是很多Delphi程序员的坏习惯，喜欢靠想象力得出结论。虽然Delphi是个很好的工具，但看看Windows程序设计这类基础书籍还是有必要的，缺乏基础，一样驾驭不了Delphi。
------解决方案--------------------
楼上的看法从理论上非常正确，但实际并不切实可行。
1、“虽然Bitmap格式不需要做复杂解释”，但是各种图片的像素格式是不一样的，对同样的操作，难道每个格式都去写一段代码？不如此，就得自己解析和转换图像格式，自己写的解析、转换代码又比TBitmap效率高多少呢？
2、操作TBitmap的ScanLine的意义还在于，不仅是可以处理Bitmap格式图像，在第三方代码支持下，还可以以同样的代码去处理其它格式的图像，如jpeg、png以及gif等，否则，和上面的结果一样：要么每个格式都去写一段代码，要么自己去解析和转换。
所以，操作TBitmap其实是看中了它的像素格式转换能力。再说了，毕竟基础扎实、语言驾驭能力很强的高手也只是极少数，而往往这类高手的实际运用能力并不是很强，毕竟人的精力是有限的。
------解决方案--------------------
盖个章，这个版好久没有见到这么热烈的讨论了。
------解决方案--------------------
眼看中秋了，说得再热闹，也得准备一下如何过节啊。
有些问题是不容易说清的，其实谈程序的话，从实验角度讲就简单多了，对同样一个材料进行同样处理任务，各自写段实现代码，看结果与效率，就自见分晓。
不过感觉起来，二位主要讨论者的态度略有不同，一个偏向自写代码，一个偏向利用现有技术。相当于一个想做底层，一个想做二次开发那种（利用针对底层功能已有的写得高效的函数）。应该说角度略有不同，也不能完全比较。
实际上，楼主正在做这件事情的研究，那么就正好由楼主来实践这些不同的方法吧。
------解决方案--------------------
ScanLine当然比Pixels好多了~
------解决方案--------------------
如果楼主想深入研究的话我建议你看看opencv
http://www.opencv.org.cn/index.php
------解决方案--------------------
呵呵,GDI+的可不能移植哟,
偶现在的图像库全用自己的函数,
直接用算法实现,既加深了功力,又
保证了库的可移植性.
------解决方案--------------------
------解决方案--------------------
delphi 封装的windows对bmp的处理比较好,c#根本无法比拟,楼主的代码优化后至少可以提升10备.
以前没弄过DELPHI，最近学了1个多星期时间，无聊时候把以前把C#写的部分图像处理代码转换成DELPHI，竟然发现D处理图片的速度比C#快了20倍··················D处理图片0.3s，C#处理同一图片6s多 ，差距真大····················
我写的算法调用GDI+函数，无汇编便于理解，觉的有帮助就顶一个，顶的多就发布下一篇图像处理，转帖的话请写明转帖和原作者： 睿割氏窝老攻 ，QQ 235483710 EMAIL: jennievictor@163.com
代码太多，怕看不清楚，下面是我的BLOG地址 ：
http://blog.****.net/huruihappy/archive/2008/09/06/2892902.aspx
------解决方案--------------------
毫无疑问，直接读到数组快，Bitmap格式不需要做复杂解释，文件头和位图BITMAPFILEHEADER/BITMAPINFOHEADER都是Win SDK直接定义的。对应VCL里的TBitmapFileHeader/TBitmapInfoHeader，根据Header确定后面的调色板和位图数据格式。而TBitmap为了使用GDI直接进行操作，需要创建DIB，作了很多多余操作。可阅读TBitmap.ReadDIB中的代码。要习惯阅读代码，程序上的问题嘛，所有的结论都可以精确得出。根本不需要靠猜测。这是很多Delphi程序员的坏习惯，喜欢靠想象力得出结论。虽然Delphi是个很好的工具，但看看Windows程序设计这类基础书籍还是有必要的，缺乏基础，一样驾驭不了Delphi。
------解决方案--------------------
楼上的看法从理论上非常正确，但实际并不切实可行。
1、“虽然Bitmap格式不需要做复杂解释”，但是各种图片的像素格式是不一样的，对同样的操作，难道每个格式都去写一段代码？不如此，就得自己解析和转换图像格式，自己写的解析、转换代码又比TBitmap效率高多少呢？
2、操作TBitmap的ScanLine的意义还在于，不仅是可以处理Bitmap格式图像，在第三方代码支持下，还可以以同样的代码去处理其它格式的图像，如jpeg、png以及gif等，否则，和上面的结果一样：要么每个格式都去写一段代码，要么自己去解析和转换。
所以，操作TBitmap其实是看中了它的像素格式转换能力。再说了，毕竟基础扎实、语言驾驭能力很强的高手也只是极少数，而往往这类高手的实际运用能力并不是很强，毕竟人的精力是有限的。
------解决方案--------------------
盖个章，这个版好久没有见到这么热烈的讨论了。
------解决方案--------------------
眼看中秋了，说得再热闹，也得准备一下如何过节啊。
有些问题是不容易说清的，其实谈程序的话，从实验角度讲就简单多了，对同样一个材料进行同样处理任务，各自写段实现代码，看结果与效率，就自见分晓。
不过感觉起来，二位主要讨论者的态度略有不同，一个偏向自写代码，一个偏向利用现有技术。相当于一个想做底层，一个想做二次开发那种（利用针对底层功能已有的写得高效的函数）。应该说角度略有不同，也不能完全比较。
实际上，楼主正在做这件事情的研究，那么就正好由楼主来实践这些不同的方法吧。
------解决方案--------------------
ScanLine当然比Pixels好多了~
------解决方案--------------------
如果楼主想深入研究的话我建议你看看opencv
http://www.opencv.org.cn/index.php
------解决方案--------------------
呵呵,GDI+的可不能移植哟,
偶现在的图像库全用自己的函数,
直接用算法实现,既加深了功力,又
保证了库的可移植性.
------解决方案--------------------
------解决方案--------------------
delphi 封装的windows对bmp的处理比较好,c#根本无法比拟,楼主的代码优化后至少可以提升10备.