Re: [問題] 關於RGB轉灰階的程式碼問題

看板C_and_CPP作者 (鬼翼&娃娃魚)時間16年前 (2009/04/08 15:19), 編輯推噓6(6023)
留言29則, 4人參與, 最新討論串2/5 (看更多)
※ 引述《devilrucifer (devilrucifer)》之銘言: : 各位板大好: : 小弟因為最近剛開始學影像處理,所以有很多東西不懂, : 在此想請教一下各位先進關於灰階轉換的問題,常見的兩種的算式 : Gray=(B*28+G*151+R*77)/256 : OR : gray=R*0.299+G*0.587+B*0.114 理論上, 後面這個比較精確, 常見的做法還會加一個四捨五入的0.5 但是, 在CPU上, 甚至一些embbed system, 前者會算的比較快.... 有一個折衷的方案是: gray = (R*299 + G*587 + B*114 + 500) / 1000; : 請問要用哪一種會比較精準,還是是沒差的呢? : 還有想請教為什麼RGB要乘於那些係數呢? : 最後除以256是為什麼呢?灰階不是只有0-255? 習慣上我們表示一個channle的color都是0.0~1.0.... 代表這個pixel的各個channel輸出的強度要是無~最強.... 但是display device只有固定level, RGB888來說就是8bits一個channel 所以才會有fixed 0-255, 這是用0.0~1.0的range scale到0-255的結果.... 但是前面那個公式小弟比較沒見過, 只是28+151+77 = 256 所以它只是用另一個比例去混出gray level的值.... 這兩個運算結果看起來不太一樣, 除了G的強度看起來差不多.... : 還有小弟有看過這種程式碼 : : //--------------------------------------------------------------------------- : void __fastcall TForm1::Button3Click(TObject *Sender) : { : int x,y,graylevel; : for(y=1;y<=Image1->Height;y++) : { : for(x=1;x<=Image1->Picture->Width;x++) : { : TCColor c=Image1->Canvas->Pixels[x][y]; : graylevel=((int)c.Red+(int)c.Green+(int)c.Blue)/3; : Image1->Canvas->Pixels[x][y]=TCColor(graylevel,graylevel,graylevel).Color; : } : } : } : //--------------------------------------------------------------------------- : : 請問為什麼程式碼可以這樣寫,他的意思是什麼?RGB加起來除以3也是灰階嗎? : 煩請有空的版友撥空回覆一下小弟,小弟感激不盡。 另一種更懶的算法, 就是(R+G+B)/3, 這也是一種算法.... Color -> Gray, 有時候你會在別種不同的Color Space裡.... 看到Intensity, Brightness, Luminence, Y, L等等的用詞.... 大部份都是指, 利用R/G/B三個channel的強度用一個比例.... 來算出一個(中文簡單的說是)亮度值, 不同Color Space有不同算法.... 印象中, 第二個算法是YCbCr的, 第三個是HSI好像會用到.... 詳細的作法請參考不同的Color Space (transform)的計算公式(plz google them) 簡單的說, Color->Gray Level 是 彩色->灰階, 怎麼轉就有很多公式可以用.... 以上, 是小弟以前稍微摸一下Color Image Processing的記憶:) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.174.98

04/08 23:22, , 1F
包~~我注意到了, 第一個公式的是BGR的順序, 那其實跟第
04/08 23:22, 1F

04/08 23:23, , 2F
二個是一樣的, 暈...@_@" 印象中是還有其他相似的算法:)
04/08 23:23, 2F
※ 編輯: VictorTom 來自: 220.132.174.98 (04/08 23:28)

04/08 23:28, , 3F
修一個錯字, 包的地方懶得修, 反正要解釋/256....Orz
04/08 23:28, 3F

04/08 23:34, , 4F
第一式猜測是基於整數的分配原則,畢竟灰階亦沒有小數點
04/08 23:34, 4F

04/08 23:38, , 5F
其實第一式很單純啦, 原本RGB各別的小數乘256再四捨五入
04/08 23:38, 5F

04/08 23:38, , 6F
只是它是BGR的順序, po文時眼花沒注意到, 它和我的折衷
04/08 23:38, 6F

04/08 23:39, , 7F
式是差不多的意思, 只是某種程度上我的式子稍微精確點:)
04/08 23:39, 7F

04/08 23:43, , 8F
不是喔他是直接去分配灰階的256個點,小算盤按起來會不同
04/08 23:43, 8F

04/08 23:45, , 9F
你要這麼解釋也無所謂, 但是這只是文字描述的觀點不同.
04/08 23:45, 9F

04/08 23:46, , 10F
實際上就是RGB以一個比例混合成gray, scale到gray level
04/08 23:46, 10F

04/08 23:47, , 11F
算出來不同, 單純只是兩者精確度不同, 一個計算只要四捨
04/08 23:47, 11F

04/08 23:48, , 12F
五入一次, 跟四捨五入三次, 有誤差本來就再所難免:)
04/08 23:48, 12F

04/08 23:57, , 13F
感謝大大認真回文 專業 謝謝您
04/08 23:57, 13F

04/08 23:57, , 14F
所以RGB係數隨便給都可以嗎? 這部分還是不太懂
04/08 23:57, 14F

04/08 23:59, , 15F
是去查 Color Space 的不同算法嗎?
04/08 23:59, 15F

04/09 00:00, , 16F
當然不是隨便給, 亮度值的轉換有幾種常見的計算方式....
04/09 00:00, 16F

04/09 00:01, , 17F
像#1#2, 印象中是用了人眼感知上, 不同channel的強度對
04/09 00:01, 17F

04/09 00:01, , 18F
亮度造成的感受訂出來的, 舉例, 我們看純Green就會覺得
04/09 00:01, 18F

04/09 00:02, , 19F
比純Red或純Blue亮; 其他需要亮度(Y/I/L等)的Color
04/09 00:02, 19F

04/09 00:02, , 20F
Space也會有自己的理由決定, 您可以依您的需求選擇:)
04/09 00:02, 20F

04/09 00:04, , 21F
恩恩 有點瞭解了 小弟會再去查書看看的
04/09 00:04, 21F

04/09 00:04, , 22F
真的很感謝大大您
04/09 00:04, 22F

04/09 00:05, , 23F
如果沒有特別需要, 只是單純Color->Gray, #2#3頗常見:)
04/09 00:05, 23F

04/09 00:09, , 24F
小弟會再多看資料的 有問題再跟您請教 感謝您^^
04/09 00:09, 24F

04/09 00:10, , 25F
www.couleur.org/index.php?page=transformations
04/09 00:10, 25F

04/09 00:10, , 26F
有許多Color Space的資料, 還3D展示給你看:)
04/09 00:10, 26F

04/09 00:11, , 27F
Well~~通常轉Gray是Spatial Domain處理的第一步....
04/09 00:11, 27F

04/09 00:11, , 28F
小弟只是看到Color Space有點high, 您還是忙您的吧^^
04/09 00:11, 28F

04/09 00:45, , 29F
0.299*r+0.587*g+0.114*b,RGB->YUV的Y,黑白電視亮度採Y值
04/09 00:45, 29F
文章代碼(AID): #19tC25FA (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #19tC25FA (C_and_CPP)