yuv和yCbCr的差异

一、和rgb之间换算公式的差异

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<-->rgb

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)

Note: 上面各个符号都带了一撇，表示该符号在原值基础上进行了gamma correction

 

二、来源上的差异

yuv色彩模型来源于rgb模型，

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

应用：basic color model used in analogue color TV broadcasting.

 

YCbCr模型来源于yuv模型。YCbCr is a scaled and offset version of the YUV color space.

应用：数字视频，ITU-R BT.601 recommendation

 

ps:

通过上面的比较可以确定，我们在h.264,mpeg等编码标准中用的yuv其实是YcbCr，大家不要被名称搞混淆了。

---

网易邮箱，没有垃圾邮件的邮箱。

转：刷坏BIOS不要急，盲刷方法实测有效（T400，X200）但是有局限性

因为工作之便，最近在3台机器上尝试了 BIOS盲刷拯救法，
其中2台成功，1台失败
因为只有3台，所以总结的经验不一定对
个人总结出的 盲刷成功率 的局限性：
开机几个灯闪一下就没反应的，可能无效
开机一长两短报警的，比较有戏

但是个人感觉死马当活马医，这个方法是值得尝试的。

详细说下这3台机器，2台成功的一台是X200一台T400，都是开机一长两短报警，失败的一台X200是开机几个灯一闪就没反应的。这3台机器其中2台是客户刷新bios后，机器重启过程中强制关机的，其中一台是windows下刷新bios程序假死客户直接关电的。

T61等老机器我没测试过。T410等新机器也没测试过。

具体盲刷方法如下：
1，下载一个叫做 wincris 的工具，并解压缩到比如 D:wincris 目录下，这是 Phoenix 公司提供的应急启动盘工具，Google一下就有
2，找到你机器对应的BIOS的ROM文件，改名为 BIOS.WPH文件备用， 个人建议准备2-3个版本备用，一个不成功可以换另一个：
a，一个是你刷错之前的版本，这个可以把硬盘拆下来，找到c:driversflashxxxx 下面有个bios.bak的文件（这是你之前windows 下刷新时，刷新软件自动备份的文件）改名为 BIOS.WPH 文件备用
b，一个是你刷的新版本的，如果你刷的本来就是.rom的文件（破解版啊加白名单版啊，无所谓），直接把它改名 BIOS.WPH 文件备用
c，如果你本来是刷官方bios挂掉的，官方bios内不会有新版rom文件，所以你就去bios之家找你对应机型的下一个吧。把rom文件改名为 BIOS.WPH 文件备用
注意！这个WPH文件格外重要，千万不要搞错型号
另注意正常T400的这个文件都是8M，X200 BIOS ID 6D开头的是8M，7X开始的是4M的版本，注意不要搞错
3，找一台XP的机器（Vista或Win7都不行）
4，找一个2G以内的U盘，我是用1G的成功的。（最好有读写指示灯）（大于2G不能格为Fat）
5，运行 wincris，选择U盘盘符，点start
6，弹出对话框问你盘会格式化掉是否继续，选是。
7，若干秒后，弹出对话框说做好了，是否需要再做一个，选否。
8，打开U盘，发现里面有 minidos.sys 和 PHLASH16.exe 2个文件
9，将前面准备的 BIOS.WPH 文件拷贝到U盘，先用老版本的好了。
10，记得弹出优盘再拔出，避免文件没写入完成。


应急BIOS恢复U盘准备好了，我们就开始盲刷。

1，取下笔记本电池，拔掉电源
2，插上优盘，按住Fn+Esc 按住不放
3，另一只手插上电源，按开关键，Fn+Esc 始终按住不放
4，如果一切正常，会发现 U盘狂闪，机器发出短促的 beep声（持续）
5，30秒后，一声清脆长 beep 声 后U盘停止闪动，这表示bios文件已经全部读到内存，开始刷新。这时候Fn+Esc 可以松了，但是不要千万不要关机，让他继续
6，大概再过30秒，机器会自动关机。
7，拔掉U盘，开机，如果一切正常，你会看到久违的 ThinkPad开机logo，然后就进bios恢复默认设置什么就好。
8，如果需要，还可以去刷回正常你需要的BIOS版本（前面用的WPH文件如果不是你所需版本的话）

容易出错和不成功的部分
1，优盘，我换了3个才成功，首先大于2G肯定不行，太老的可能不行，如果盲刷过程第4步发现U盘压根就不读取，先重做优盘。
2，WPH文件，一个不行，换一个试试。

转自网络

---

网易邮箱，没有垃圾邮件的邮箱。

快来测测你的电脑是男的还是女的?

你的电脑是男的还是女的?

让电脑替你说I IOVE YOU(原来电脑是有性别的...)：
①新建一个记事本文件
②在里面输入 CreateObject("SAPI.SpVoice").Speak "I love YOU"
③保存扩展名为 .VBS 文件 如：我爱你.vbs
④带上耳机，双击运行，电脑就会说 i love you 了。你听到的是男声还是女生呢？当然你也可以换其他英文。 还可以写中文，就是把I LOVE YOU 换成别的汉字也可以.
看看你的电脑是男的还是女的?

---

您想拥有和网易免费邮箱一样强大的软件吗？

JPEG 解码过程简述

解码过程简述
-------------
8. 一个数据单元 Y 的解码 (其余类同)
--------------------------------
在整个图片解码的开始, 你需要先初始化 DC 值为 0.
1) 先解码 DC:
         a) 取得一个 Huffman 码 (使用 Huffman DC 表)
         b) Huffman解码, 看看后面的数据位数 N
         c) 取得 N 位, 计算 Diff 值
         d) DC + = Diff
         e) 写入 DC 值:      " vector[0]=DC "
2) 解码 63 个 AC:
------- 循环处理每个 AC 直到 EOB 或者处理到 64 个 AC
       a) 取得一个 Huffman 码 (使用 Huffman AC 表)
       b) Huffman 解码, 得到 (前面 0 数量, 组号)
[记住: 如果是(0,0) 就是 EOB 了]
       c) 取得 N 位(组号) 计算 AC
       d) 写入相应数量的 0
       e) 接下来写入 AC
-----------------
下一步的解码
------------
上一步我们得到了 64 个矢量. 下面我们还需要做一些解码工作:
1) 反量化 64 个矢量 : "for (i=0;i<=63;i++) vector*=quant" (注意防止溢出)
2) 重排列 64 个矢量到 8x8 的块中
3) 对 8x8 的块作 IDCT
对 8x8 块的 (Y,Cb,Cr) 重复上面的操作 [Huffman 解码, 步骤 1), 2), 3)]
4) 将所有的 8bit 数加上 128
5) 转换 YCbCr 到 RGB
9. JPG 文件(Byte 级)里怎样组织图片信息
-----------------------------------
注意 JPEG/JFIF 文件格式使用 Motorola 格式, 而不是 Intel 格式, 就是说, 如果
是一个字的话, 高字节在前, 低字节在后.
JPG 文件是由一个个段 (segments) 构成的. 每个段长度 <=65535. 每个段从一个标
记字开始. 标记字都是 0xff 打头的, 以非 0 字节和 0xFF 结束. 例如 'FFDA' ,
'FFC4', 'FFC0'. 每个标记有它特定意义, 这是由第2字节指明的. 例如, SOS (Start
Of Scan = 'FFDA') 指明了你应该开始解码. 另一个标记 DQT (Define Quantization
Table = 0xFFDB) 就是说它后面有 64 字节的 quantization 表
在处理 JPG 文件时, 如果你碰到一个 0xFF, 而它后面的字节不是 0, 并且这个字节
没有意义. 那么你遇到的 0xFF 字节必须被忽略. (一些 JPG 里, 常用用 0xFF 做某
些填充用途) 如果你在做 huffman 编码时碰巧产生了一个 0xFF, 那么就用 0xFF
0x00 代替. 就是说在 jpeg 图形解码时碰到 FF00 就把它当作 FF 处理.
另外在 huffman 编码区域结束时, 碰到几个 bit 没有用的时候, 应该用 1 去填充.
然后后面跟 FF.
下面是几个重要的标记
--------------------
SOI = Start Of Image = 'FFD8'
这个标记只在文件开始出现一次
EOI = End Of Image = 'FFD9'
JPG 文件都以 FFD9 结束
RSTi = FFDi ( i =  0..7)  [ RST0 = FFD0, RST7=FFD7]
     = 复位标记
通常穿插在数据流里, 我想是担心 JPG 解码出问题吧(应该配合 DRI 使用). RST 将
Huffman 的解码数据流复位. DC 也重新从 0 开始计
(SOS --- RST0 --- RST1 -- RST2 --...
...-- RST6 --- RST7 -- RST0 --...)
-------
10. 标记
-------
下面是必须处理的标记
SOF0 = Start Of Frame 0 = FFC0
SOS  = Start Of Scan    = FFDA
APP0 = it's the marker used to identify a JPG file which uses the JFIF
    specification       = FFE0
COM  = Comment          = FFFE
DNL  = Define Number of Lines    = FFDC
DRI  = Define Restart Interval   = FFDD
DQT  = Define Quantization Table = FFDB
DHT  = Define Huffman Table      = FFC4
11. JPG 文件中 Haffman 表的储存
-----------------------------
JPEG 里定义了一张表来描述 Haffman 树. 定义在 DHT 标记后面. 注意: Haffman
代码的长度限制在 16bit 内.
一般一个 JPG 文件里会有 2 类 Haffman 表: 一个用于 DC 一个用于 AC (实际有 4
个表, 亮度的 DC,AC 两个, 色度的 DC,AC 两个)
这张表是这样保存的:
1) 16 字节:
第 i 字节表示了 i 位长的 Huffman 代码的个数 (i= 1 到 16)
                                        
2) 这表的长度 (字节数) = 这 16 个数字之和
现在你可以想象这张表怎么存放的吧? 对应字节就是对应 Haffman 代码等价数字. 我
不多解释, 这需要你先了解 Canonical Huffman Code. 这里只举一个例子:
Haffman 表的表头是 0,2,3,1,1,1,0,1,0,0,0,0,0,0,0,0
就是说长度为 1 的代码没有
长度为 2 的代码为 00
                 01
长度为 3 的代码是 100
                 101
                 110
长度为 4 的代码是 1110
长度为 5 的代码是 11110
长度为 6 的代码是 111110
长度为 7 的代码没有 (如果有一个的话应该是 1111110)
长度为 8 的代码是 11111100
         .....
后面都没有了.
如果表下面的数据是
    45 57 29 17 23 25 34 28
就是说
    45 = 00
    57 = 01
    29 = 100
    17 = 101
    23 = 110
等等...
使用 Canonical Huffman Code 的好处在于可以很简洁的重建对应关系表.
12. 采样系数
-----------
下面讲解的都是真彩 JPG 的解码, 灰度 JPG 的解码很简单, 因为图形中只有亮度信
息. 而彩色图形由 (Y, Cr, Cb) 构成, 前面提到过, Y 通常是每点采样一次, 而 Cr,
Cb 一般是 2x2 点采样一次, 当然也有的 JPG 是逐点采样, 或者每两点采样 (横向
两点, 纵向一点) 采样系数均被定义成对比最高采样系数的相对值.
一般情况 (即: Y 逐点采样, Cr Cb 每 2x2 点一次) 下: Y 有最高的采样率, 横向采
样系数HY=2 纵向采样系数 VY=2; Cb 的横向采样系数 HCb=1, 纵向采样系数 VCb=1;
同样 HCr=1, VCr=1
在 Jpeg 里, 8x8 个原始数据, 经过 RLE, Huffman 编码后的一串数据流称为一个
Data Unit (DU) JPG 里按 DU 为单位的编码次序如下:
     1)      for  (counter_y=1;counter_y<=VY;counter_y++)
                  for (counter_x=1;counter_x<=HY;counter_x++)
                     {  对 Y 的 Data Unit 编码 }
     2)      for  (counter_y=1;counter_y<=VCb ;counter_y++)
                  for (counter_x=1;counter_x<=HCb;counter_x++)
                     {  对 Cb 的 Data Unit 编码 }
     3)      for  (counter_y=1;counter_y<=VCr;counter_y++)
                  for (counter_x=1;counter_x<=HCr;counter_x++)
                     {  对 Cr 的 Data Unit 编码 }
按我上面的例子: (HY=2, VY=2 ; HCb=VCb =1, HCr,VCr=1) 就是这样一个次序
    YDU,YDU,YDU,YDU,CbDU,CrDU
这些就描述了一块 16x16 的图形. 16x16 = (Hmax*8 x Vmax*8) 这里 Hmax=HY=2
Vmax=VY=2
一个 (Hmax*8,Vmax*8) 的块被称作 MCU (Minimun Coded Unix) 前面例子中一个
MCU = YDU,YDU,YDU,YDU,CbDU,CrDU
如果  HY =1, VY=1
      HCb=1, VCb=1
      HCr=1, VCr=1
这样 (Hmax=1,Vmax=1), MCU 只有 8x8 大, MCU = YDU,CbDU,CrDU
对于灰度 JPG, MCU 只有一个 DU (MCU = YDU)
JPG 文件里, 图象的每个组成部分的采样系数定义在 SOF0 (FFC0) 标记后
13. 简单说一下 JPG 文件的解码
-------------------------
解码程序先从 JPG 文件中读出采样系数, 这样就知道了 MCU 的大小, 算出整个图象
有几个 MCU. 解码程序再循环逐个对 MCU 解码, 一直到检查到 EOI 标记. 对于每个
MCU, 按正规的次序解出每个 DU, 然后组合, 转换成 (R,G,B) 就 OK 了
附:JPEG 文件格式
~~~~~~~~~~~~~~~~
  - 文件头 (2 bytes):  $ff, $d8 (SOI) (JPEG 文件标识)
  - 任意数量的段 , 见后面
  - 文件结束 (2 bytes): $ff, $d9 (EOI)
段的格式:
~~~~~~~~~
  - header (4 bytes):
       $ff     段标识
        n      段的类型 (1 byte)
       sh, sl  该段长度, 包括这两个字节, 但是不包括前面的 $ff 和 n.
               注意: 长度不是 intel 次序, 而是 Motorola 的, 高字节在前,
        低字节在后!
  - 该段的内容, 最多 65533 字节
注意:
  - 有一些无参数的段 (下面那些前面注明星号的)
    这些段没有长度描述 (而且没有内容), 只有 $ff 和类型字节.
  - 段之间无论有多少 $ff 都是合法的, 必须被忽略掉.
段的类型:
~~~~~~~~~
   *TEM   = $01   可以忽略掉
    SOF0  = $c0   帧开始 (baseline JPEG), 细节附后
    SOF1  = $c1   dito
    SOF2  = $c2   通常不支持
    SOF3  = $c3   通常不支持
    SOF5  = $c5   通常不支持
    SOF6  = $c6   通常不支持
    SOF7  = $c7   通常不支持
    SOF9  = $c9   arithmetic 编码(Huffman 的一种扩展算法), 通常不支持
    SOF10 = $ca   通常不支持
    SOF11 = $cb   通常不支持
    SOF13 = $cd   通常不支持
    SOF14 = $ce   通常不支持
    SOF14 = $ce   通常不支持
    SOF15 = $cf   通常不支持
    DHT   = $c4   定义 Huffman Table,  细节附后
    JPG   = $c8   未定义/保留 (引起解码错误)
    DAC   = $cc   定义 Arithmetic Table, 通常不支持
   *RST0  = $d0   RSTn 用于 resync, 通常被忽略
   *RST1  = $d1
   *RST2  = $d2
   *RST3  = $d3
   *RST4  = $d4
   *RST5  = $d5
   *RST6  = $d6
   *RST7  = $d7
    SOI   = $d8   图片开始
    EOI   = $d9   图片结束
    SOS   = $da   扫描行开始, 细节附后
    DQT   = $db   定义 Quantization Table, 细节附后
    DNL   = $dc   通常不支持, 忽略
    DRI   = $dd   定义重新开始间隔, 细节附后
    DHP   = $de   忽略 (跳过)
    EXP   = $df   忽略 (跳过)
    APP0  = $e0   JFIF APP0 segment marker (细节略)
    APP15 = $ef   忽略
    JPG0  = $f0   忽略 (跳过)
    JPG13 = $fd   忽略 (跳过)
    COM   = $fe   注释, 细节附后
其它的段类型都保留必须跳过
SOF0: Start Of Frame 0:
~~~~~~~~~~~~~~~~~~~~~~~
  - $ff, $c0 (SOF0)
  - 长度 (高字节, 低字节), 8+components*3
  - 数据精度 (1 byte) 每个样本位数, 通常是 8 (大多数软件不支持 12 和 16)
  - 图片高度 (高字节, 低字节), 如果不支持 DNL 就必须 >0
  - 图片宽度 (高字节, 低字节), 如果不支持 DNL 就必须 >0
  - components 数量(1 byte), 灰度图是 1, YCbCr/YIQ 彩色图是 3, CMYK 彩色图
    是 4
  - 每个 component: 3 bytes
     - component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q)
     - 采样系数 (bit 0-3 vert., 4-7 hor.)
     - quantization table 号
DRI: Define Restart Interval:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  - $ff, $dd (DRI)
  - 长度 (高字节, 低字节), 必须是 4
  - MCU 块的单元中的重新开始间隔 (高字节, 低字节),
    意思是说, 每 n 个 MCU 块就有一个 RSTn 标记.
    第一个标记是 RST0, 然后是 RST1 等, RST7 后再从 RST0 重复
DQT: Define Quantization Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  - $ff, $db (DQT)
  - 长度 (高字节, 低字节)
  - QT 信息 (1 byte):
     bit 0..3: QT 号(0..3, 否则错误)
     bit 4..7: QT 精度, 0 = 8 bit, 否则 16 bit
  - n 字节的 QT, n = 64*(精度+1)
备注:
  - 一个单独的 DQT 段可以包含多个 QT, 每个都有自己的信息字节
  - 当精度=1 (16 bit), 每个字都是高位在前低位在后
DAC: Define Arithmetic Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
法律原因, 现在的软件不支持 arithmetic 编码.
不能生产使用 arithmetic 编码的 JPEG 文件
DHT: Define Huffman Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~
  - $ff, $c4 (DHT)
  - 长度 (高字节, 低字节)
  - HT 信息 (1 byte):
     bit 0..3: HT 号 (0..3, 否则错误)
     bit 4   : HT 类型, 0 = DC table, 1 = AC table
     bit 5..7: 必须是 0
  - 16 bytes: 长度是 1..16 代码的符号数. 这 16 个数的和应该 <=256
  - n bytes: 一个包含了按递增次序代码长度排列的符号表
    (n = 代码总数)
备注:
  - 一个单独的 DHT 段可以包含多个 HT, 每个都有自己的信息字节
COM: 注释:
~~~~~~~~~~
  - $ff, $fe (COM)
  - 注释长度 (高字节, 低字节) = L+2
  - 注释为长度为 L 的字符流
SOS: Start Of Scan:
~~~~~~~~~~~~~~~~~~~
  - $ff, $da (SOS)
  - 长度 (高字节, 低字节), 必须是 6+2*(扫描行内组件的数量)
  - 扫描行内组件的数量 (1 byte), 必须 >= 1 , <=4 (否则是错的) 通常是 3
  - 每个组件: 2 bytes
     - component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q), 见 SOF0
     - 使用的 Huffman 表:
- bit 0..3: AC table (0..3)
- bit 4..7: DC table (0..3)
  - 忽略 3 bytes (???)
备注:
  - 图片数据 (一个个扫描行) 紧接着 SOS 段.

jpeg解码的部分说明（baseline模式)

看了一整天的资料，终于理清一些头绪，并且发现网上流传的一个关于JPEG编码中例子的错误，（只是查表的一个小错误，原理还是正确的）

先将所有用到的表格列出

 

DC差分系数size编码表

Size     Amplitude

0         0

1        -1,1

2        -3,-2,2,3

3       -7~-4，4~7

4       -15~-8，8~15

5       -31~-16，16~31

6       -63~-32，32~63

7       -127~-64，64~127

8       -255~-128，128~255

9       -511~-256，256~511

10      -1023~512，512~1023

11      -2047~-1024，1024~2047

 

AC系数size编码表

Size        Amplitude

1            -1,1

2           -3,-2,2,3

3           -7~-4，4~7

4          -15~-8，8~15

5          -31~-16，16~31

6          -63~-32，32~63

7          -127~-64，64~127

8          -255~-128，128~255

9          -511~-256，256~511

10        -1023~512，512~1023

 

亮度量化表
  16     11     10     16     24     40     51     61
  12     12     14     19     26     58     60     55    
  14     13     16     24     40     57     69     56    
  14     17     22     29     51     87     80     62    
  18     22     37     56     68     109    103    77    
  24     35     55     64     81     104    113    92    
  49     64     78     87     103    121    120    101    
  72     92     95     98     112    100    103    99    

色度量化表
  17     18     24     47     99     99     99     99      
  18     21     26     66     99     99     99     99    
  24     26     56     99     99     99     99     99    
  47     66     99     99     99     99     99     99    
  99     99     99     99     99     99     99     99    
  99     99     99     99     99     99     99     99    
  99     99     99     99     99     99     99     99    
  99     99     99     99     99     99     99     99

 

光亮度DC系数差huffman表

类别	代码长度	代码字
0	2	00
1	3	010
2	3	011
3	3	100
4	3	101
5	3	110
6	4	1110
7	5	11110
8	6	111110
9	7	1111110
10	8	11111110
11	9	111111110

 

色度DC系数差的huffman表

类别	代码长度	代码字
0	2	00
1	2	01
2	2	10
3	3	110
4	4	1110
5	5	11110
6	6	111110
7	7	1111110
8	8	11111110
9	9	111111110
10	10	1111111110
11	11	11111111110

 

亮度和色度的AC系数的huffman表过于庞大，请参阅其他资料，如需帮助，E2me:zww219@163.com

例如，一个8*8的模块的熵编码的中间格式为：

(DC)(2)(3), (AC) (1,2)(-2), (0,1)(-1), (0,1)(-1), (0,1),(-1) (2,1),(-1).(EOB)(0,0)

被编码为01111（此处很多文章写成11011,是不对的，查表错误），1101101，000，000，000，111000，1010时，先读到011，

每 读取一个bit进行一次huffman码表的扫描，第一个肯定是DC的编码，，，，便可根据  DC亮度Huffman 表，查到size为2，在根据这个size2读取后2位，11，进过VLI反编码，得到幅度为3，这样，就解码出(DC)(2)(3),然后，相继解码出 63个AC系数，这样，组成了一个8*8的模块后，进行逆量化后进行IDCT变换，最后得到第一个元素（Y）的8*8幅值表

以下是引用Ham的空间中的解码过程：http://user.qzone.qq.com/591170887/blog/1197016242

下 面讲解的都是真彩 JPG 的解码, 灰度 JPG 的解码很简单, 因为图形中只有亮度信息. 而彩色图形由 (Y, Cr, Cb) 构成, 前面提到过, Y 通常是每点采样一次, 而 Cr,Cb 一般是 2x2 点采样一次, 当然也有的 JPG 是逐点采样, 或者每两点采样 (横向两点, 纵向一点) 采样系数均被定义成对比最高采样系数的相对值. 一般情况 (即: Y 逐点采样, Cr Cb 每 2x2 点一次) 下: Y 有最高的采样率, 横向采样系数HY=2 纵向采样系数 VY=2; Cb 的横向采样系数 HCb=1, 纵向采样系数 VCb=1;同样 HCr=1, VCr=1
在 Jpeg 里, 8x8 个原始数据, 经过 RLE, Huffman 编码后的一串数据流称为一个
Data Unit (DU) JPG 里按 DU 为单位的编码次序如下:
     1)      for  (counter_y=1;counter_y<=VY;counter_y++)
                  for (counter_x=1;counter_x<=HY;counter_x++)
                     {  对 Y 的 Data Unit 编码 }
     2)      for  (counter_y=1;counter_y<=VCb ;counter_y++)
                  for (counter_x=1;counter_x<=HCb;counter_x++)
                     {  对 Cb 的 Data Unit 编码 }
     3)      for  (counter_y=1;counter_y<=VCr;counter_y++)
                  for (counter_x=1;counter_x<=HCr;counter_x++)
                     {  对 Cr 的 Data Unit 编码 }
按我上面的例子: (HY=2, VY=2 ; HCb=VCb =1, HCr,VCr=1) 就是这样一个次序
    YDU,YDU,YDU,YDU,CbDU,CrDU
这些就描述了一块 16x16 的图形. 16x16 = (Hmax*8 x Vmax*8) 这里 Hmax=HY=2
Vmax=VY=2
一个 (Hmax*8,Vmax*8) 的块被称作 MCU (Minimun Coded Unix) 前面例子中一个
MCU = YDU,YDU,YDU,YDU,CbDU,CrDU
如果  HY =1, VY=1
      HCb=1, VCb=1
      HCr=1, VCr=1
这样 (Hmax=1,Vmax=1), MCU 只有 8x8 大, MCU = YDU,CbDU,CrDU
对于灰度 JPG, MCU 只有一个 DU (MCU = YDU)
JPG 文件里, 图象的每个组成部分的采样系数定义在 SOF0 (FFC0) 标记后

简单说一下 JPG 文件的解码
-------------------------
解码程序先从 JPG 文件中读出采样系数, 这样就知道了 MCU 的大小, 算出整个图象
有几个 MCU. 解码程序再循环逐个对 MCU 解码, 一直到检查到 EOI 标记. 对于每个
MCU, 按正规的次序解出每个 DU, 然后组合, 转换成 (R,G,B) 就 OK 了

两分钟给你讲清楚哥本哈根大会是咋回事

如果一百多人在漏水的船上讨价还价谁该往外多舀水，那是明摆着的蠢，事实上没人会这么干，连船上那最自私最无耻的人，也会拿出最大公无私的精神拼命舀水的。

但是事情如果再复杂一点，就会有新鲜的现象了。如果船上的人算计一下，在这条船沉没前，他们有足够的时间安全抵达港口，危险属于下一船乘客时，有很多人就会停下来安静地欣赏海景了。

哪怕这条船在抵达港口前的确会沉没一部分，比如灌满一个叫"马尔代夫"的船舱，其他舱室的人，基本上都会无动于衷。

更复杂的是，如果这艘船超重，需要乘客们把身上的金银细软抛下船的话，扯蛋就来了。穷人们说，富人钱多经得起糟蹋你先扔，至少得再扔40%；富人则说穷鬼你那堆破烂儿又沉又不值钱你先扔；穷人说我扔也可以但你富人得拿出年收入的0.5%-1%，即3000块补偿给我，还得教会我发财致富的秘诀，富人说你丫做白日梦吧老子已经一年白给你100块了，多了别想，你救的不是我是你自己。

穷人说老子才刚坐这船没两天，你狗日富人坐好几年了，生生把新船坐成了破船，现在多出点血是天经地义的；富人说以前天杀的知道这船是会坐破的，再说如果不是我们富人天天捣鼓这船，你这帮农民今天还在刨地球，能懂航海术、看西洋景？今天这船要沉了也是我们发现的，要不你们这帮?人淹死了都不知道咋回事。

蛋还没扯完，眼见船越来越漏的厉害。于是船客们聚到"日本房间"，穷人们靠着人多强行通过了一份《京都协议书》，要求富人赶紧扔东西，穷人却可以不扔。最富的富人米利坚说，这是明显的仇富嘛，天下哪有这道理，俺不玩了。穷人说你B一家最重，负担就占了全船的近1/5，你不扔谁扔？米利坚说我的东西是最重，但也最值钱。俺以全船1/4的值钱物件才占了1/5的重量，凭啥我扔？你们看看那叫拆哪的穷鬼，以不到3%的价值也占了近1/5的负担，为啥不让他多扔？

黑眼睛黑头发黄皮肤的拆哪一听急了：穷兄弟们别听他的，俺们可都是穷苦人家出身，你们要是把我推出来，以后你们中有人小偷小摸耍流氓谁罩着啊？好歹这船是大家的，你米利坚就是东西最多最重，这船也属你坐的时间最长次数最多，看我干啥？凭啥？你凭啥？这最怕船沉的不是咱穷棒子是富人，他们经不起大规模人员伤亡。

为了尽快把蛋扯完，船客们最近又在一间叫"丹麦"的房间开了一个会。据最新消息，把蛋扯完的机会已经很渺茫。最重大的成果将是形成一份《哥本哈根共识》，这份有所有船客签名的共识说："我们都发现并且承认，这船在漏水，而且是会沉的。"

这份共识发表后，船客们纷纷接到恭喜电话，表扬他们表现出了高超的政治智慧，并且坚定地捍卫了国家利益。

中国：没有名牌的茶叶大国

作为全球最受欢迎饮品——茶叶的故乡，中国完全有理由感到自豪。在世界最大产茶国及消费国的头衔旁落100年后，中国最近从印度手中夺回了这一历史地位。但中国未能打造出一个全球知名的茶叶品牌，是本土茶叶的支持者们感到沮丧的原因之一。

无论是在国内还是在国外，中国的茶叶品牌都难以与国外竞争者相抗衡。在中国，联合利华(Unilever)的立顿(Lipton)品牌占有的市场份额，是仅次于它的本土竞争对手的三倍。

“中国7万家茶场为啥抵不上一个‘立顿'茶？”

北京的一家报纸最近在一篇文章中遗憾地表示。中国茶叶行业面临着与中国其它许多行业相同的挑战：产品质量问题；国内市场过度竞争；海外售价太低、利润微薄；品牌塑造水平不高。

这些缺点的根源很简单：市场过度分散。
 
这个问题从茶园就开始了。在中国中部、南部和西部的产茶区，约有800万农民在茶园内劳作，其中大多是面积很小的自留地。将土地合并为面积更大的种植园受到中国土地法的限制——根据中国的土地法，土地所有权不归农民所有，因此他们也不能出售土地。结果，中国茶叶行业的工业化程度远低于肯尼亚和印度等经济发达程度较低的国家。浙江省是中国的产茶大省和最富裕的省份之一，那里有100多万家小茶园，平均面积不足0.2公顷。监控数百万家星罗棋布的茶园的质量，无疑是痴人说梦，而且中国的茶叶出口商一向难以达到国外的安全标准。在国际市场上，中国茶叶的平均售价仅为每千克2美元，低于印度茶叶的2.7美元，以及备受赞誉的斯里兰卡茶叶的3.4美元。除非质量控制得到全面改善，否则中国的出口商就无法让自己的茶叶在国际市场上持续卖出好价钱。而要想有所改善，首先就要对茶园和茶叶加工厂进行大力整合。

在中国本土，数千家生产商和品牌之间的激烈竞争，导致各自只能获得极小的市场份额和微薄的利润。中国茶叶一般按照品种和产地出售，而非品牌，而各个地区都有自己最喜爱的本地品牌。另一方面，立顿等领先品牌明白，创造集合价值有赖于全国性的市场营销以及高效的一体化分销网络。立顿从独立茶商手中收购廉价茶叶，装进茶包，再以高得离谱的价格，出售其再普通不过的“黄牌精选红茶”它的茶并不出色，但运作却相当出色。

在中国高度分散的零售市场，还没有哪个本土品牌能取代立顿的地位。相反，出售有机茶的高端生产商正试图在国内外开拓利润丰厚的利基市场。以湖南省茶业有限公司在该省白云山种植的茶叶为例。白云山气候温暖潮湿，有深厚的红棕色土壤，是种植高品质茶叶的理想之地。在一片墨绿色的针叶林背后，一排排整齐的茶树丛闪闪发亮，沐浴在夏日的阳光下，蜜蜂嗡嗡作响，懒洋洋地在枝头盘绕。一块板子上写着一系列规定，要求采茶者不得蓄长指甲，不得在脸上搽粉；严禁吸烟。这里不使用杀虫剂，而是电子灭虫器来保护茶树免受叶蝉及其它嗜茶叶害虫的侵害。这些新茶在来年春天被摘下来后，有一批会运往日本，贴上海东兄弟(Kaito Brothers)的标签，作为高级有机茶出售；另一批将包装成获奖的“冠云”品牌，在国内市场销售，两小袋10克装茶叶就能卖出100美元的高价。

富有的日本和中国饮茶者很乐意掏数百美元购买春天采摘的顶级茶叶，就像西方的爱酒人士会一掷千金购买一瓶上等红酒一样。但特制茶不会给中国带来它所渴望的国际品牌认知度。要想获得国际认知，中国必须进行广泛的行业整合和更加老练的市场营销。

尽管拥有世界上最古老的茶业生产商，但中国的现代茶业才刚刚起步。本土茶叶公司要实现规模经济、获得挖掘出产品全部价值所必需的品牌塑造技能，还有很长一段路要走。在此之前，大块收入还会被主打便利和生活时尚牌的有实力的外国品牌抢走。有人要来一杯立顿红茶吗？