神马文学网图像抖动算法理解收集
来源：百度文库 编辑：神马文学网 时间：2024/04/28 09:45:37
1.关于屏幕的一点麻烦事
现在又有一个新的趋势出现，那就是普适计算，很多设备都将拥有屏幕，而内容将被分发到各种类型的终端上。你不可能要求那些终端都是顶级显示屏，它们的分辨率、颜色数、对比度……可以说会是千差万别，开发工具做好相应的准备了吗？ 2.windows mobile下的位图
在WM（Windows Mobile）下的位图有一定的特殊性，可操作API也不多，所以这里重点讲解一下WM的位图知识，但不对位图文件的格式做重点介绍。才疏学浅，特别欢迎高人指正。如果你要看懂这篇文章，需要有一定的基础，并对位图有实际操作经历，因为我不会详述基础知识。众说周知，程序中Windows标准的图像处理使用的都是BMP格式。在WM下也不例外，所有被存储的图形都是BMP，并且所有windows mobile系列的手机只支持65536色，这就是意味着，手机上显示的图像都是16位的，那么在实际的程序中，创建一个DIB时，用16位位图是比较现实的，图像文件也建议都改成16位的格式。16位的位图在显示上特别是在出现大区域，高相位的惭变操作时，会出现色差，造成惭变不连续的问题。通过抖动算法会处理掉色差，但会降低原32位色的纯度。这就是65536色的问题
因此，在做WM界面设计时，尽量不要使用大区域，高相位的惭变设计。WM中的位图分为DDB和DIB。DDB叫做设备相关位图，一般用来做WM软件界面的交换和提取。并对图片执行一些简单的操作，比如截屏，缩放，显示。使用bitblt或strechblt这些函数捣腾的位图，很多是设备相关位图，一般此类位图都与HDC相关。并且只能在内存中，不能以文件的形式存出来。在WM下，无法直接取到DDB位图的像素的RGB阵列DIB叫做设备无关位图，一般界面上很少用到，但在做一些较复杂的界面特效时会用到DIB位图，它的最大的特点就是能够取到像素的RGB阵列，从而通过对这个阵列的操作，改变图形显示的效果。并且能够存为.BMP文件。所有.BMP格式的文件都是DIB位图，在WM的内存中只能通过CreateDIBSection来创建有DIB特点的位图。网上有很多对这个Section的解释，说是DDB和DIB的混合体。不懂，我就把它当DIB位图来看了。创建这个位图有很多参数。我拣紧要的说一下：先看代码：//建立这个位图的内存空间,并初始化结构，这个指针是要做CreateDIBSection参数的int iSize = sizeof(BITMAPINFO)BITMAPINFO* pBMI = (BITMAPINFO*) malloc(iSize);memset(pBMI, 0, iSize); // 填充结构数据，BITMAPINFO结构里面带一个BITMAPINFOHEADER结构，和一个调色板或掩码pBMI->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);pBMI->bmiHeader.biWidth = 2048;//位图宽，单位是像素pBMI->bmiHeader.biHeight = 512;//位图高，单位是像素pBMI->bmiHeader.biPlanes = 1; //不懂，只能设1pBMI->bmiHeader.biBitCount = 16; // 位深，就是一个像素用几个位来表示，这是16位,2的16次方就是65536,所以说16位只能表示65536种色彩//pBMI->bmiColors;//对这个参数我很无语。用不来，我的理解：这个参数在16位以下，不包括16位的数据格式用的是调色板，就是一个表，存上了图像中所有要用的像素RGB值。在16位以上，包括16位的数据格式就是每个像素的掩码值,每个像素的RGB值会与这个掩码做与运算一次。因为16位以上的数据就没有调色板了。所以这里的数据只记录RGB三色的掩码，但是没有格式的说明。//pBMI->bmiHeader.biCompression = BI_BITFIELDS; //压缩属性pBMI->bmiHeader.biCompression = BI_RGB; // 压缩属性 BYTE* pBits ;HBITMAP hbitmapTexture = CreateDIBSection( hdc, pBMI, DIB_RGB_COLORS, //DIB_PAL_COLORS,//只能在8位色深上可用，使用系统DC的调色板 (VOID **) &pBits, NULL, 0);代码中BITMAPINFOHEADER结构中还有一些数据没有填，直接默认为初始值，具体的查阅一下MSDN。在对biCompression格式设定要注意：当biCompression设为BI_RGB时，我这个DIB位图的像素RGB阵列就只能是555格式,后面pBMI->bmiColors这个参数就可以直接默认初始值了，当设为BI_BITFIELDS,可能是555,也可能是565,事实上我认为createdibsection创建成的DIB位图就是RGB555的格式，没有565。待解！这样一个没有数据的DIB的hbitmap就创建出来了，当你bitblt一个选内这个DIB位图的内存DC时，pBits的数据就被填充了，就能够得到像素RGB阵列了，这个方法也可以转换一个DDB成为DIB。特别指明的是在使用SHLoadImageFile函数加载图像数据时，无论你使用是什么位深，都会转换为16位，并且能获得的bitmap格式中的pBits像素数据(DDB位图中pBits数据是空的)。采用RGB565格式正序排列的，在photoshop中，存出的位图默认是以倒行序排列的，当在存储时有一个翻转行序选项时，选上后存储才是正行序排列像素数据。当在使用CreatDIBSection函数创建设备无关位图数据时，也是倒行序。 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/kekobobo/archive/2009/10/28/4740360.aspx
遇到一个问题：我们开发的嵌入式设备的屏幕是16位色的，这在通常情况下问题不大，但显示颜色丰富的图形时，可能就非常糟糕。
更加糟糕的是，用photoshop转换32位色的图像为16色，它的算法竟然只是简单地取临近安全色，这样得到的图像，和直接用16位屏幕显示32位图像得到的效果是一样的，当离格当。
后来百了一度，得知acdsee有更好的算法，它加入了抖动的处理（用几个像素点的色彩去逼近初始色彩）……果然，效果不错。
我的Director按照这个思路，先在photoshop里面给图像添加噪声，然后再让ps转换为16位色，也不失为一种可行的方法。而且在add noise时有很多参数可选。
下面的图中，左边是放大5倍后查看的效果，右边是100%显示。 
- 原始的32位图像，过渡均匀。
- photoshop转换的16位图像，色彩出现明显的带状。
- acdsee转换的16位图像。
- 在photoshop中添加噪声，然后转换为16位色，没有细致调节噪声的参量，效果应该还可以更好点。
如果你的显示器看不出这几张图之间的差异，呵呵，我向你表示深切的同情和问候。
adobe对新媒体的反映总是相当的迟钝。web兴起的时候，它没有抓住机遇，最后自己也承认是凭借设计师对photoshop的喜爱和习惯，才侥幸没被淘汰。现在又有一个新的趋势出现，那就是普适计算，很多设备都将拥有屏幕，而内容将被分发到各种类型的终端上。你不可能要求那些终端都是顶级显示屏，它们的分辨率、颜色数、对比度……可以说会是千差万别，开发工具做好相应的准备了吗？ 2.windows mobile下的位图
在WM（Windows Mobile）下的位图有一定的特殊性，可操作API也不多，所以这里重点讲解一下WM的位图知识，但不对位图文件的格式做重点介绍。才疏学浅，特别欢迎高人指正。如果你要看懂这篇文章，需要有一定的基础，并对位图有实际操作经历，因为我不会详述基础知识。众说周知，程序中Windows标准的图像处理使用的都是BMP格式。在WM下也不例外，所有被存储的图形都是BMP，并且所有windows mobile系列的手机只支持65536色，这就是意味着，手机上显示的图像都是16位的，那么在实际的程序中，创建一个DIB时，用16位位图是比较现实的，图像文件也建议都改成16位的格式。16位的位图在显示上特别是在出现大区域，高相位的惭变操作时，会出现色差，造成惭变不连续的问题。通过抖动算法会处理掉色差，但会降低原32位色的纯度。这就是65536色的问题
因此，在做WM界面设计时，尽量不要使用大区域，高相位的惭变设计。WM中的位图分为DDB和DIB。DDB叫做设备相关位图，一般用来做WM软件界面的交换和提取。并对图片执行一些简单的操作，比如截屏，缩放，显示。使用bitblt或strechblt这些函数捣腾的位图，很多是设备相关位图，一般此类位图都与HDC相关。并且只能在内存中，不能以文件的形式存出来。在WM下，无法直接取到DDB位图的像素的RGB阵列DIB叫做设备无关位图，一般界面上很少用到，但在做一些较复杂的界面特效时会用到DIB位图，它的最大的特点就是能够取到像素的RGB阵列，从而通过对这个阵列的操作，改变图形显示的效果。并且能够存为.BMP文件。所有.BMP格式的文件都是DIB位图，在WM的内存中只能通过CreateDIBSection来创建有DIB特点的位图。网上有很多对这个Section的解释，说是DDB和DIB的混合体。不懂，我就把它当DIB位图来看了。创建这个位图有很多参数。我拣紧要的说一下：先看代码：//建立这个位图的内存空间,并初始化结构，这个指针是要做CreateDIBSection参数的int iSize = sizeof(BITMAPINFO)BITMAPINFO* pBMI = (BITMAPINFO*) malloc(iSize);memset(pBMI, 0, iSize); // 填充结构数据，BITMAPINFO结构里面带一个BITMAPINFOHEADER结构，和一个调色板或掩码pBMI->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);pBMI->bmiHeader.biWidth = 2048;//位图宽，单位是像素pBMI->bmiHeader.biHeight = 512;//位图高，单位是像素pBMI->bmiHeader.biPlanes = 1; //不懂，只能设1pBMI->bmiHeader.biBitCount = 16; // 位深，就是一个像素用几个位来表示，这是16位,2的16次方就是65536,所以说16位只能表示65536种色彩//pBMI->bmiColors;//对这个参数我很无语。用不来，我的理解：这个参数在16位以下，不包括16位的数据格式用的是调色板，就是一个表，存上了图像中所有要用的像素RGB值。在16位以上，包括16位的数据格式就是每个像素的掩码值,每个像素的RGB值会与这个掩码做与运算一次。因为16位以上的数据就没有调色板了。所以这里的数据只记录RGB三色的掩码，但是没有格式的说明。//pBMI->bmiHeader.biCompression = BI_BITFIELDS; //压缩属性pBMI->bmiHeader.biCompression = BI_RGB; // 压缩属性 BYTE* pBits ;HBITMAP hbitmapTexture = CreateDIBSection( hdc, pBMI, DIB_RGB_COLORS, //DIB_PAL_COLORS,//只能在8位色深上可用，使用系统DC的调色板 (VOID **) &pBits, NULL, 0);代码中BITMAPINFOHEADER结构中还有一些数据没有填，直接默认为初始值，具体的查阅一下MSDN。在对biCompression格式设定要注意：当biCompression设为BI_RGB时，我这个DIB位图的像素RGB阵列就只能是555格式,后面pBMI->bmiColors这个参数就可以直接默认初始值了，当设为BI_BITFIELDS,可能是555,也可能是565,事实上我认为createdibsection创建成的DIB位图就是RGB555的格式，没有565。待解！这样一个没有数据的DIB的hbitmap就创建出来了，当你bitblt一个选内这个DIB位图的内存DC时，pBits的数据就被填充了，就能够得到像素RGB阵列了，这个方法也可以转换一个DDB成为DIB。特别指明的是在使用SHLoadImageFile函数加载图像数据时，无论你使用是什么位深，都会转换为16位，并且能获得的bitmap格式中的pBits像素数据(DDB位图中pBits数据是空的)。采用RGB565格式正序排列的，在photoshop中，存出的位图默认是以倒行序排列的，当在存储时有一个翻转行序选项时，选上后存储才是正行序排列像素数据。当在使用CreatDIBSection函数创建设备无关位图数据时，也是倒行序。 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/kekobobo/archive/2009/10/28/4740360.aspx
图像抖动算法理解收集
*神了，显示屏图像抖动，我不花一分钱修好啦
EMA与MA－理解公式算法
理解不同类型的时钟抖动-放大/调整/转换-电子工程专辑
CSDN技术中心 加密解密、信息摘要算法收集
基于最大熵与小波变换的图像边缘检测算法
根据特征点及梯度进行改进的矩不变阈值分割图像算法
数学形态学的基本算法及在图像预处理中应用
图像处理 - 应用通道系列——《计算法 选择效果最好的通道》
基于ICA的混合图像盲分离算法 - 新闻资讯中心 - 星星电子网
基于ICA的混合图像盲分离算法 - 21IC中国电子网
基于ICA的混合图像盲分离算法 - 21IC中国电子网
显示器抖动的原因
显示器屏幕为什么抖动
握拳抖动 强肾法
深入java虚拟机第9章, 垃圾收集（3）火车算法
雨刮抖动暂时解决
智能语义聚合框架：像人类一样收集和理解知识
上汽PASSAT怠速抖动故障维修
时钟的抖动测量与分析
显示器抖动的原因及解决方法
冷启动或者空档候车时抖动
贝叶斯算法
经典算法