RGB宏#define _RGB16BIT565(r，g，b) ((b&31)+(g&63)<<5)+((r&31)<<11))为何要先

襄阳城

<p>RGB宏#define _RGB16BIT565(r，g，b) ((b&31)+(g&63)<<5)+((r&31)<<11))为何要先按位与？</p>
<p><img src="http://img.baidu.com/img/iknow/icn_point.gif"> 悬赏分：10 -</p>
<p>解决时间：2010-6-1 11:15</p>
<p>如题~今天和朋友讨论时得出的结论~请问为何要先按为与再移位？难道是怕填入负数的缘故？可是RGB值不是在0-255之间么？</p>
<p>提问者： 追忆的罪咏 - 四级</p>
<p>最佳答案</p>
<p>你说的RGB值在0-255之间变化的编码方案是32位真彩色的编码方案，真彩色位每个</p>
<p>RGB分量分8位，一共24位，每位从0-255；剩下的高八位是alpha位，表示透明，正好</p>
<p>32位。</p>
<p>至于RGB565，R占5位，由0到31，G占6位，由0到63，B占5位，由0到31.将所有位</p>
<p>上的值加起来是从0-65535；</p>
<p>计算机支持颜色运算都是无符号颜色运算，颜色没有负数，即使你以为你输入了</p>
<p>一个负数，但是计算机总是会把它认定成正数。这么说可能有些难懂；打个比方，你</p>
<p>用%d形式输入一个负数，但是输出是用%u形式，怎么也不可能得到负数的；计算机就</p>
<p>好比使用%u形式来读取、输出和使用颜色。</p>
<p>至于你说的为什么先按位与再移位，纯粹是为了方便计算才这么弄得，先移位再</p>
<p>取与得步骤就要比这个要麻烦的多了。你要取与的数值就不是31，63和31这么简单明</p>
<p>了的数值了。而是63488(1111100000000000），2016（0000011111100000）和31，这</p>
<p>样你的计算公式就变成了这样：</p>
<p>#define _RGB16BIT565(r，g，b) ((b&31)+((g<<5)&2016)+((r<<11)&63488))，相比之下是不是比原先的要麻烦呢？？</p>
<p>希望对你有帮助 呵呵</p>
<p>0</p>
<p>回答者：</p>
<p>sniper82556455 - 三级   2010-5-19 16:23</p>
<p>我来评论>></p>
<p>提问者对于答案的评价：</p>
<p>哦哦~原来如此，看来是我考虑不周啊</p>