图像处理之基础---yuv420及其rgb,bayer, yuv, RGB的相互转换详解

YUV格式解析1(播放器——project2)

根据板卡api设计实现yuv420格式的视频播放器

打开*.mp4;*.264类型的文件,实现其播放。

使用的视频格式是YUV420格式

YUV格式通常有两大类:打包(packed)格式和平面(planar)格式。前者将YUV分量存放在同一个数组中,通常是几个相邻的像素组 成一个宏像素(macro-pixel);而后者使用三个数组分开存放YUV三个分量,就像是一个三维平面一样。表2.3中的YUY2到Y211都是打包 格式,而IF09到YVU9都是平面格式。(注意:在介绍各种具体格式时,YUV各分量都会带有下标,如Y0、U0、V0表示第一个像素的YUV分 量,Y1、U1、V1表示第二个像素的YUV分量,以此类推。)

MEDIASUBTYPE_YUY2 YUY2格式,以4:2:2方式打包

MEDIASUBTYPE_YUYV YUYV格式(实际格式与YUY2相同)

MEDIASUBTYPE_YVYU YVYU格式,以4:2:2方式打包

MEDIASUBTYPE_UYVY UYVY格式,以4:2:2方式打包

MEDIASUBTYPE_AYUV 带Alpha通道的4:4:4 YUV格式

MEDIASUBTYPE_Y41P Y41P格式,以4:1:1方式打包

MEDIASUBTYPE_Y411 Y411格式(实际格式与Y41P相同)

MEDIASUBTYPE_Y211 Y211格式

MEDIASUBTYPE_IF09 IF09格式

MEDIASUBTYPE_IYUV IYUV格式

MEDIASUBTYPE_YV12 YV12格式

MEDIASUBTYPE_YVU9 YVU9格式

表2.3

YUV 采样

YUV 的优点之一是,色度频道的采样率可比 Y 频道低,同时不会明显降低视觉质量。有一种表示法可用来描述 U 和 V 与 Y 的采样频率比例,这个表示法称为 A:B:C 表示法:


4:4:4 表示色度频道没有下采样。


4:2:2 表示 2:1 的水平下采样,没有垂直下采样。对于每两个 U 样例或 V 样例,每个扫描行都包含四个 Y 样例。


4:2:0 表示 2:1 的水平下采样,2:1 的垂直下采样。


4:1:1 表示 4:1 的水平下采样,没有垂直下采样。对于每个 U 样例或 V 样例,每个扫描行都包含四个 Y 样例。与其他格式相比,4:1:1 采样不太常用,本文不对其进行详细讨论。

图 1 显示了 4:4:4 图片中使用的采样网格。灯光样例用叉来表示,色度样例则用圈表示。

图 1. YUV 4:4:4 样例位置

4:2:2 采样的这种主要形式在 ITU-R Recommendation BT.601 中进行了定义。图 2 显示了此标准定义的采样网格。

图 2. YUV 4:2:2 样例位置

4:2:0 采样有两种常见的变化形式。其中一种形式用于 MPEG-2 视频,另一种形式用于 MPEG-1 以及 ITU-T recommendations H.261 和 H.263。图 3 显示了 MPEG-1 方案中使用的采样网格,图 4 显示了 MPEG-2 方案中使用的采样网格。

图 3. YUV 4:2:0 样例位置(MPEG-1 方案)

图 4. YUV 4:2:0 样例位置(MPEG-2 方案)

与 MPEG-1 方案相比,在 MPEG-2 方案与为 4:2:2 和 4:4:4 格式定义的采样网格之间进行转换更简单一些。因此,在 Windows 中首选 MPEG-2 方案,应该考虑将其作为 4:2:0 格式的默认转换方案。

表面定义

本节讲述推荐用于视频呈现的 8 位 YUV 格式。这些格式可以分为几个类别:


4:4:4 格式,每像素 32 位


4:2:2 格式,每像素 16 位


4:2:0 格式,每像素 16 位


4:2:0 格式,每像素 12 位

首先,您应该理解下列概念,这样才能理解接下来的内容:


表面原点。对于本文讲述的 YUV 格式,原点 (0,0) 总是位于表面的左上角。


跨距。表面的跨距,有时也称为间距,指的是表面的宽度,以字节数表示。对于一个表面原点位于左上角的表面来说,跨距总是正数。


对齐。表面的对齐是根据图形显示驱动程序的不同而定的。表面始终应该 DWORD 对齐,就是说,表面中的各个行肯定都是从 32 位 (DWORD) 边界开始的。对齐可以大于 32 位,但具体取决于硬件的需求。


打包格式与平面格式。YUV 格式可以分为打包 格式和平面 格式。在打包格式中,Y、U 和 V 组件存储在一个数组中。像素被组织到了一些巨像素组中,巨像素组的布局取决于格式。在平面格式中,Y、U 和 V 组件作为三个单独的平面进行存储。

4:4:4 格式,每像素 32 位

推荐一个 4:4:4 格式,FOURCC 码为 AYUV。这是一个打包格式,其中每个像素都被编码为四个连续字节,其组织顺序如下所示。

图 5. AYUV 内存布局

标记了 A 的字节包含 alpha 的值。

4:2:2 格式,每像素 16 位

支持两个 4:2:2 格式,FOURCC 码如下:


YUY2


UYVY

两个都是打包格式,其中每个巨像素都是编码为四个连续字节的两个像素。这样会使得色度水平下采样乘以系数 2。

YUY2

在 YUY2 格式中,数据可被视为一个不带正负号的 char 值组成的数组,其中第一个字节包含第一个 Y 样例,第二个字节包含第一个 U (Cb) 样例,第三个字节包含第二个 Y 样例,第四个字节包含第一个 V (Cr) 样例,如图 6 所示。

图 6. YUY2 内存布局

如果该图像被看作由两个 little-endian WORD 值组成的数组,则第一个 WORD 在最低有效位 (LSB) 中包含 Y0,在最高有效位 (MSB) 中包含 U。第二个 WORD 在 LSB 中包含 Y1,在 MSB 中包含 V。

YUY2 是用于 Microsoft DirectX® Video Acceleration (DirectX VA) 的首选 4:2:2 像素格式。预期它会成为支持 4:2:2 视频的 DirectX VA 加速器的中期要求。

UYVY

此格式与 YUY2 相同,只是字节顺序是与之相反的 — 就是说,色度字节和灯光字节是翻转的(图 7)。如果该图像被看作由两个 little-endian WORD 值组成的数组,则第一个 WORD 在 LSB 中包含 U,在 MSB 中包含 Y0,第二个 WORD 在 LSB 中包含 V,在 MSB 中包含 Y1。

图 7. UYVY 内存布局

4:2:0 格式,每像素 16 位

推荐两个 4:2:0 每像素 16 位格式,FOURCC 码如下:


IMC1


IMC3

两个 FOURCC 码都是平面格式。色度频道在水平方向和垂直方向上都要以系数 2 来进行再次采样。

IMC1

所有 Y 样例都会作为不带正负号的 char 值组成的数组首先显示在内存中。后面跟着所有 V (Cr) 样例,然后是所有 U (Cb) 样例。V 和 U 平面与 Y 平面具有相同的跨距,从而生成如图 8 所示的内存的未使用区域。

图 8. IMC1 内存布局

IMC3

此格式与 IMC1 相同,只是 U 和 V 平面进行了交换:

图 9. IMC3 内存布局

4:2:0 格式,每像素 12 位

推荐四个 4:2:0 每像素 12 位格式,FOURCC 码如下:


IMC2


IMC4


YV12


NV12

在所有这些格式中,色度频道在水平方向和垂直方向上都要以系数 2 来进行再次采样。

IMC2

此格式与 IMC1 相同,只是 V (Cr) 和 U (Cb) 行在半跨距边界处进行了交错。换句话说,就是色度区域中的每个完整跨距行都以一行 V 样例开始,然后是一行在下一个半跨距边界处开始的 U 样例(图 10)。此布局与 IMC1 相比,能够更加高效地利用地址空间。它的色度地址空间缩小了一半,因此整体地址空间缩小了 25%。在各个 4:2:0 格式中,IMC2 是第二首选格式,排在 NV12 之后。

图 10. IMC2 内存布局

IMC4

此格式与 IMC2 相同,只是 U (Cb) 和 V (Cr) 行进行了交换:

图 11. IMC4 内存布局

YV12

所有 Y 样例都会作为不带正负号的 char 值组成的数组首先显示在内存中。此数组后面紧接着所有 V (Cr) 样例。V 平面的跨距为 Y 平面跨距的一半,V 平面包含的行为 Y 平面包含行的一半。V 平面后面紧接着所有 U (Cb) 样例,它的跨距和行数与 V 平面相同(图 12)。

图 12. YV12 内存布局

NV12

所有 Y 样例都会作为由不带正负号的 char 值组成的数组首先显示在内存中,并且行数为偶数。Y 平面后面紧接着一个由不带正负号的 char 值组成的数组,其中包含了打包的 U (Cb) 和 V (Cr) 样例,如图 13 所示。当组合的 U-V 数组被视为一个由 little-endian WORD 值组成的数组时,LSB 包含 U 值,MSB 包含 V 值。NV12 是用于 DirectX VA 的首选 4:2:0 像素格式。预期它会成为支持 4:2:0 视频的 DirectX VA 加速器的中期要求。

YUV格式解析2

又确认了一下H264的视频格式——

H264支持4:2:0的连续或隔行视频的编码和解码

YUV(亦称YCrCb)是被欧洲电视系统所采用的一种颜色编码方法(属于PAL)。YUV主要用于优化彩色视频信号的传输,使其向后兼容老式 黑白电视。与RGB视频信号传输相比,它最大的优点在于只需占用极少的带宽(RGB要求三个独立的视频信号同时传输)。其中“Y”表示明亮度 (Luminance或Luma),也就是灰阶值;而“U”和“V”表示的则是色度(Chrominance或Chroma),作用是描述影像色彩及饱和 度,用于指定像素的颜色。“亮度”是通过RGB输入信号来创建的,方法是将RGB信号的特定部分叠加到一起。“色度”则定义了颜色的两个方面—色调与饱和 度,分别用Cr和CB来表示。其中,Cr反映了GB输入信号红色部分与RGB信号亮度值之间的差异。而CB反映的是RGB输入信号蓝色部分与RGB信号亮 度值之同的差异。

补充一下场的概念——

场的概念不是从DV才开始有的,电视系统已经有了(当然,DV和电视的关系大家都知道)归根结底还是扫描的问题,具体到PAL制式是:
每秒25帧,每帧两场,扫描线(包括电视机的电子束)自上而下先扫描一场,然后再自上而下扫描第二场
之所以引入场的概念,我的理解是主要为了在有限的带宽和成本内使画面运动更加平滑和消除闪烁感。
这两个场的扫描线是一条一条互相间隔开的,比如说对于一个帧来讲,最上面一条线编号为0,紧挨着的是1,再下来是2,3,4,5,6。。。。那么第一场也许是0,2,4,6;也许是1,3,5,7——这就是隔行扫描
在逐行扫描模式下,就是扫描线按照0,1,2,3,4,5的顺序依次扫描,很明显,这时候就不存在场的概念了。

下面区分一下YUV和YCbCr

YUV色彩模型来源于RGB模型,

该模型的特点是将亮度和色度分离开,从而适合于图像处理领域。

应用:模拟领域

Y‘= 0.299*R‘ + 0.587*G‘ + 0.114*B‘

U‘= -0.147*R‘ - 0.289*G‘ + 0.436*B‘ = 0.492*(B‘- Y‘)

V‘= 0.615*R‘ - 0.515*G‘ - 0.100*B‘ = 0.877*(R‘- Y‘)

R‘ = Y‘ + 1.140*V‘

G‘ = Y‘ - 0.394*U‘ - 0.581*V‘

B‘ = Y‘ + 2.032*U‘

YCbCr模型来源于YUV模型。YCbCr是 YUV 颜色空间的偏移版本.

应用:数字视频,ITU-R BT.601建议

Y’ = 0.257*R‘ + 0.504*G‘ + 0.098*B‘ + 16

Cb‘ = -0.148*R‘ - 0.291*G‘ + 0.439*B‘ + 128

Cr‘ = 0.439*R‘ - 0.368*G‘ - 0.071*B‘ + 128

R‘ = 1.164*(Y’-16) + 1.596*(Cr‘-128)

G‘ = 1.164*(Y’-16) - 0.813*(Cr‘-128) - 0.392*(Cb‘-128)

B‘ = 1.164*(Y’-16) + 2.017*(Cb‘-128)

PS: 上面各个符号都带了一撇,表示该符号在原值基础上进行了伽马校正,伽马校正有助于弥补在抗锯齿的过程中,线性分配伽马值所带来的细节损失,使图像细节更加 丰富。在没有采用伽马校正的情况下,暗部细节不容易显现出来,而采用了这一图像增强技术以后,图像的层次更加明晰了。

所以说H264里面的YUV应属于YCbCr.

下面再仔细谈谈YUV格式, YUV格式通常有两大类:打包(packed)格式和平面(planar)格式。前者将YUV分量存放在同一个数组中,通常是几个相邻的像素组成一个宏像 素(macro-pixel);而后者使用三个数组分开存放YUV三个分量,就像是一个三维平面一样。

我们常说得YUV420属于planar格式的YUV, 颜色比例如下:

Y0U0V0             Y1                 Y2U2V2                      Y3

Y4                 Y5                 Y6                          Y7

Y8U8V8             Y9                 Y10U10V10                   Y11

Y12                Y13                Y14                         Y15

其他格式YUV可以点这里查看详细 内容, 而在YUV文件中YUV420又是怎么存储的呢? 在常见H264测试的YUV序列中,例如CIF图像大小的YUV序列(352*288),在文件开始并没有文件头,直接就是YUV数据,先存第一帧的Y信 息,长度为352*288个byte, 然后是第一帧U信息长度是352*288/4个byte, 最后是第一帧的V信息,长度是352*288/4个byte, 因此可以算出第一帧数据总长度是352*288*1.5,即152064个byte, 如果这个序列是300帧的话, 那么序列总长度即为152064*300=44550KB,这也就是为什么常见的300帧CIF序列总是44M的原因.

4:4:4采样就是说三种元素Y,Cb,Cr有同样的分辨率,这样的话,在每一个像素点上都对这三种元素进行采样.数字4是指在水平方向上对于各种 元素的采样率,比如说,每四个亮度采样点就有四个Cb的Cr采样值.4:4:4采样完整地保留了所有的信息值.4:2:2采样中(有时记为YUY2),色 度元素在纵向与亮度值有同样的分辨率,而在横向则是亮度分辨率的一半(4:2:2表示每四个亮度值就有两个Cb和Cr采样.)4:2:2视频用来构造高品 质的视频彩色信号.

在流行的4:2:0采样格式中(常记为YV12)Cb 和Cr在水平和垂直方向上有Y分辨率的一半.4:2:0有些不同,因为它并不是指在实际采样中使用4:2:0,而是在编码史中定义这种编码方法是用来区别 于4:4:4和4:2:2方法的).4:2:0采样被广泛地应用于消费应用中,比如视频会议,数字电视和DVD存储中。因为每个颜色差别元素中包含了四分 之一的Y采样元素量,那么4:2:0YCbCr视频需要刚好4: 4:4或RGB视频中采样量的一半。

4:2:0采样有时被描述是一个"每像素12位"的方法。这么说的原因可以从对四个像素的采样中看出. 使用4:4:4采样,一共要进行12次采样,对每一个Y,Cb和Cr,就需要12*8=96位,平均下来要96/4=24位。使用4:2:0就需要6*8 =48位,平均每个像素48/4=12位。

在一个4:2:0隔行扫描的视频序列中,对应于一个完整的视频帧的Y,Cb,Cr采样分配到两个场中。可以得到,隔行扫描的总采样数跟渐进式扫描中使用的采样数目是相同的。

对比一下:

Y41P(和Y411) (packed格式)格式为每个像素保留Y分量,而UV分量在水平方向上每4个像素采样一次。一个宏像素为12个字节,实际表示8个像素。图像数据中 YUV分量排列顺序如下: U0 Y0 V0 Y1 U4 Y2 V4 Y3 Y4 Y5 Y6 Y8 …

IYUV格式(planar)为每个像素都提取Y分量,而在UV分量的提取时,首先将图像分成若干个2 x 2的宏块,然后每个宏块提取一个U分量和一个V分量。YV12格式与IYUV类似,但仍然是平面模式。

YUV411、YUV420格式多 见于DV数据中,前者用于NTSC制,后者用于PAL制。YUV411为每个像素都提取Y分量,而UV分量在水平方向上每4个像素采样一次。YUV420 并非V分量采样为0,而是跟YUV411相比,在水平方向上提高一倍色差采样频率,在垂直方向上以U/V间隔的方式减小一半色差采样,如下图所示。

(好像显示不出来突下图像)

各种格式的具体使用位数的需求(使用4:2:0采样,对于每个元素用8个位大小表示):

格式: Sub-QCIF 亮度分辨率: 128*96  每帧使用的位: 147456
格式: QCIF  亮度分辨率: 176*144  每帧使用的位: 304128
格式: CIF  亮度分辨率: 352*288  每帧使用的位: 1216512
格式:  4CIF  亮度分辨率: 704*576  每帧使用的位: 4866048

http://www.infineon-ecosystem.org/focusnie/blog/13-07/295634_5bc12.html

//平面YUV422转平面RGB24
static void YUV422p_to_RGB24(unsigned char *yuv422[3], unsigned char *rgb24, int width, int height)
{
 int R,G,B,Y,U,V;
 int x,y;
 int nWidth = width>>1; //色度信号宽度
 for (y=0;y<height;y++)
 {
  for (x=0;x<width;x++)
  {
   Y = *(yuv422[0] + y*width + x);
   U = *(yuv422[1] + y*nWidth + (x>>1));
   V = *(yuv422[2] + y*nWidth + (x>>1));
   R = Y + 1.402*(V-128);
   G = Y - 0.34414*(U-128) - 0.71414*(V-128);
   B = Y + 1.772*(U-128);
   
   //防止越界
   if (R>255)R=255;
   if (R<0)R=0;
   if (G>255)G=255;
   if (G<0)G=0;
   if (B>255)B=255;
   if (B<0)B=0;
   
   *(rgb24 + ((height-y-1)*width + x)*3) = B;
   *(rgb24 + ((height-y-1)*width + x)*3 + 1) = G;
   *(rgb24 + ((height-y-1)*width + x)*3 + 2) = R;  
  }
 }
}

//平面YUV420转平面YUV422
static void YUV420p_to_YUV422p(unsigned char *yuv420[3], unsigned char *yuv422, int width, int height) 
{
 int x, y;
 //亮度信号Y复制
 int Ylen = width*height;
 memcpy(yuv422, yuv420[0], Ylen);
 //色度信号U复制
 unsigned char *pU422 = yuv422 + Ylen; //指向U的位置
 int Uwidth = width>>1; //422色度信号U宽度
 int Uheight = height>>1; //422色度信号U高度 
 for (y = 0; y < Uheight; y++)
 {        
  memcpy(pU422 + y*width,          yuv420[1] + y*Uwidth, Uwidth);
  memcpy(pU422 + y*width + Uwidth, yuv420[1] + y*Uwidth, Uwidth);
 }
 //色度信号V复制
 unsigned char *pV422 = yuv422 + Ylen + (Ylen>>1); //指向V的位置
 int Vwidth = Uwidth; //422色度信号V宽度
 int Vheight = Uheight; //422色度信号U宽度
 for (y = 0; y < Vheight; y++)
 { 
  memcpy(pV422 + y*width,          yuv420[2] + y*Vwidth, Vwidth);
  memcpy(pV422 + y*width + Vwidth, yuv420[2] + y*Vwidth, Vwidth);
 }
}

//平面YUV420转RGB24
static void YUV420p_to_RGB24(unsigned char *yuv420[3], unsigned char *rgb24, int width, int height)
{
//  int begin = GetTickCount();
 int R,G,B,Y,U,V;
 int x,y;
 int nWidth = width>>1; //色度信号宽度
 for (y=0;y<height;y++)
 {
  for (x=0;x<width;x++)
  {
   Y = *(yuv420[0] + y*width + x);
   U = *(yuv420[1] + ((y>>1)*nWidth) + (x>>1));
   V = *(yuv420[2] + ((y>>1)*nWidth) + (x>>1));
   R = Y + 1.402*(V-128);
   G = Y - 0.34414*(U-128) - 0.71414*(V-128);
   B = Y + 1.772*(U-128);

//防止越界
   if (R>255)R=255;
   if (R<0)R=0;
   if (G>255)G=255;
   if (G<0)G=0;
   if (B>255)B=255;
   if (B<0)B=0;
   
   *(rgb24 + ((height-y-1)*width + x)*3) = B;
   *(rgb24 + ((height-y-1)*width + x)*3 + 1) = G;
   *(rgb24 + ((height-y-1)*width + x)*3 + 2) = R;
//    *(rgb24 + (y*width + x)*3) = B;
//    *(rgb24 + (y*width + x)*3 + 1) = G;
//    *(rgb24 + (y*width + x)*3 + 2) = R;   
  }
 }
}

http://www.360doc.com/content/11/0723/12/4238731_135363852.shtml 项目测试中一用到

http://www.360doc.com/content/12/0210/21/3705128_185646693.shtml  bayer, yuv, RGB转换方法

http://read.pudn.com/downloads198/sourcecode/windows/bitmap/932122/YUV_gray(王兵写的图像处理界面)/RGB2YUVView.cpp__.htm

时间: 2024-09-30 20:55:50

图像处理之基础---yuv420及其rgb,bayer, yuv, RGB的相互转换详解的相关文章

Android基础入门教程——8.3.16 Canvas API详解(Part 1)

Android基础入门教程--8.3.16 Canvas API详解(Part 1) 标签(空格分隔): Android基础入门教程 本节引言: 前面我们花了13小节详细地讲解了Android中Paint类大部分常用的API,本节开始我们来讲解 Canvas(画板)的一些常用API,我们在Android基础入门教程--8.3.1 三个绘图工具类详解 中已经列出了我们可供调用的一些方法,我们分下类: drawXxx方法族:以一定的坐标值在当前画图区域画图,另外图层会叠加, 即后面绘画的图层会覆盖前

Android基础入门教程——2.5.3 AlertDialog(对话框)详解

Android基础入门教程--2.5.3 AlertDialog(对话框)详解 标签(空格分隔): Android基础入门教程 本节引言: 本节继续给大家带来是显示提示信息的第三个控件AlertDialog(对话框),同时它也是其他 Dialog的的父类!比如ProgressDialog,TimePickerDialog等,而AlertDialog的父类是:Dialog! 另外,不像前面学习的Toast和Notification,AlertDialog并不能直接new出来,如果你打开 Alert

Android 基础总结:( 十四)Handler详解(上)

Handler的定义: 主要接受子线程发送的数据, 并用此数据配合主线程更新UI. 解释: 当应用程序启动时,Android首先会开启一个主线程 (也就是UI线程) , 主线程为管理界面中的UI控件,进行事件分发,比如说,你要是点击一个 Button ,Android会分发事件到Button上,来响应你的操作. 如果此时需要一个耗时的操作,例如:联网读取数据,或者读取本地较大的一个文件的时候,你不能把这些操作放在主线程中,如果你放在主线程中的话,界面会出现假死现象,如果5秒钟还没有完成的话,会收

Android基础入门教程——8.3.18 Canvas API详解(Part 3)Matrix和drawBitmapMash

Android基础入门教程--8.3.18 Canvas API详解(Part 3)Matrix和drawBitmapMash 标签(空格分隔): Android基础入门教程 本节引言: 在Canvas的API文档中,我们看到这样一个方法:drawBitmap(Bitmap bitmap, Matrix matrix, Paint paint) 这个Matrix可是有大文章的,前面我们在学Paint的API中的ColorFilter中曾讲过ColorMatrix 颜色矩阵,一个4 * 5 的矩阵

Android基础入门教程——2.3.2 EditText(输入框)详解

Android基础入门教程--2.3.2 EditText(输入框)详解 标签(空格分隔): Android基础入门教程 本节引言: 上一节中我们学习了第一个 UI控件TextView(文本框),文中给出了很多实际开发中可能遇到的一些需求 的解决方法,应该会为你的开发带来便利,在本节中,我们来学习第二个很常用的控件EditText(输入框): 和TextView非常类似,最大的区别是:EditText可以接受用户输入!和前面一样,我们不一个个讲属性, 只讲实际应用,要扣属性可以自己查看API文档

搜索引擎-倒排索引基础知识(摘自《这就是搜索引擎:核心技术详解》)

1.单词--文档矩阵 单词-文档矩阵是表达两者之间所具有的一种包含关系的概念模型,图3-1展示了其含义.图3-1的每列代表一个文档,每行代表一个单词,打对勾的位置代表包含关系. 图3-1 单词-文档矩阵 从纵向即文档这个维度来看,每列代表文档包含了哪些单词,比如文档1包含了词汇1和词汇4,而不包含其它单词.从横向即单词这个维度来看,每行代表了哪些文档包含了某个单词.比如对于词汇1来说,文档1和文档4中出现过单词1,而其它文档不包含词汇1.矩阵中其它的行列也可作此种解读. 搜索引擎的索引其实就是实

Android 基础总结:( 十五)Handler详解(下)

Android GWES之Android消息系统 Looper,Handler,View 我们要理解Android的消息系统,Looper,Handle,View等概念还是需要从消息系统的基本原理及其构造这个源头开始.从这个源头,我们才能很清楚的看到Android设计者设计消息系统之意图及其设计的技术路线. 1.消息系统的基本原理 从一般的系统设计来讲,一个消息循环系统的建立需要有以下几个要素: 消息队列 发送消息 消息读取 消息分发 消息循环线程 首先来研究一下消息驱动的基本模型,我使用如下的

图像处理之基础---用Shader实现的YUV到RGB转换:使用3重纹理实现 .

上一篇中,我是用一个RGB格式的纹理来存储每一帧的画面,其中纹理为m_FrameWidth * m_FrameHeight大小,这样,在内存中,就必须要先对YUV的数据进行排序,然后才能当做RGB的数据格式传给纹理内存.我们发现对一个很大帧的图片进行数据重新排序会花费很多时间,为了减少这个时间,当然可以用汇编语言来进行这个排序的操作.然而,有一种更好的方法. 我们发现在上一次所用到的YUV420数据格式是一种平面格式,他的数据排列十分有规律,这里,考虑用3重纹理来实现他的转换. 先定义3个纹理,

基础之——原码、反码、补码 详解

本篇文章讲解了计算机的原码, 反码和补码. 并且进行了深入探求了为何要使用反码和补码, 以及更进一步的论证了为何可以用反码, 补码的加法计算原码的减法. 论证部分如有不对的地方请各位牛人帮忙指正! 希望本文对大家学习计算机基础有所帮助! 一. 机器数和真值 在学习原码, 反码和补码之前, 需要先了解机器数和真值的概念. 1.机器数 一个数在计算机中的二进制表示形式,  叫做这个数的机器数.机器数是带符号的,在计算机用一个数的最高位存放符号, 正数为0, 负数为1. 比如,十进制中的数 +3 ,计