- 沒有新回應！
2007-07-12 23:31 將ARGB的數值轉為RGB的碎碎念 (很宅, 正妹勿入)
由於同事用C#將顏色的設定以整數形式寫出檔案
他是用System.Drawing.Color.ToArgb()所寫出來的ARGB格式
該格式共計有4個byte
由左至右分別是ARGB四項值
而我則必須在C裡頭將rgb值取出繪圖
本想說若要取出RGB值
就將該數值與00000000111111111111111111111111做&運算就好
沒想到平常C++用的RGB(255,0,0)這種巨集時
由左而右分別是B->G->R
跟.Net中的ARGB剛好相反
為什麼我知道C裡頭是BGR呢?
只要看了下面這個巨集宣告就會很清楚啦
#define RGB(r, g ,b) ((DWORD) (((BYTE) (R) | ((WORD) (G) << 8)) | (((DWORD) (BYTE) (B)) << 16)))
講到這個就不得不說
以前學位元運算子<<,>>,&,|時都覺得這些東西不知道幹嘛用
但看了上面這個宣告才知道位元運算有時候真的是很讚阿:p
至於實際的轉換程式
我把雛形寫在下面
int CStaticFuntion::ARGB2RGB(int ARGB)
{
const int Mask=(1<<24)-1;
//00000000,11111111,11111111,11111111
ARGB=ARGB & Mask;
byte B=(byte)ARGB;
byte G=(byte)(ARGB>>8);
byte R=(byte)(ARGB>>16);
return ( RGB(R,G,B) );
}
反正就是先弄出224-1來把ARGB中的A都變成0
然後依序取出B,G,R等對應byte的值
照理說數值都應該和255做&運算
但是若故意把R,G,B都宣告成byte
強制轉型時就會有相同的效果
剛好可以省去與255做&運算
也有和同事提到把B,G,R都用整數來宣告
看起來若這樣處理的話就勢必要與255做&運算
否則B和G值一定會大於255
看似好像有問題
但實際上
由於丟到RGB(x,x,x)的巨集時
巨集中也明顯看到把r,g,b都強制轉成BYTE
所以傳回值應該也會是正確的
這篇真的是太宅了
很容易看到睡著的
他是用System.Drawing.Color.ToArgb()所寫出來的ARGB格式
該格式共計有4個byte
由左至右分別是ARGB四項值
而我則必須在C裡頭將rgb值取出繪圖
本想說若要取出RGB值
就將該數值與00000000111111111111111111111111做&運算就好
沒想到平常C++用的RGB(255,0,0)這種巨集時
由左而右分別是B->G->R
跟.Net中的ARGB剛好相反
為什麼我知道C裡頭是BGR呢?
只要看了下面這個巨集宣告就會很清楚啦
#define RGB(r, g ,b) ((DWORD) (((BYTE) (R) | ((WORD) (G) << 8)) | (((DWORD) (BYTE) (B)) << 16)))
講到這個就不得不說
以前學位元運算子<<,>>,&,|時都覺得這些東西不知道幹嘛用
但看了上面這個宣告才知道位元運算有時候真的是很讚阿:p
至於實際的轉換程式
我把雛形寫在下面
int CStaticFuntion::ARGB2RGB(int ARGB)
{
const int Mask=(1<<24)-1;
//00000000,11111111,11111111,11111111
ARGB=ARGB & Mask;
byte B=(byte)ARGB;
byte G=(byte)(ARGB>>8);
byte R=(byte)(ARGB>>16);
return ( RGB(R,G,B) );
}
反正就是先弄出224-1來把ARGB中的A都變成0
然後依序取出B,G,R等對應byte的值
照理說數值都應該和255做&運算
但是若故意把R,G,B都宣告成byte
強制轉型時就會有相同的效果
剛好可以省去與255做&運算
也有和同事提到把B,G,R都用整數來宣告
看起來若這樣處理的話就勢必要與255做&運算
否則B和G值一定會大於255
看似好像有問題
但實際上
由於丟到RGB(x,x,x)的巨集時
巨集中也明顯看到把r,g,b都強制轉成BYTE
所以傳回值應該也會是正確的
這篇真的是太宅了
很容易看到睡著的
回應
