為什麼這篇灰階計算鄉民發文收入到精華區：因為在灰階計算這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者VictorTom (鬼翼&娃娃魚)看板C_and_CPP標題Re: [問題] 關於RG...
灰階計算 在 Sheng Chen Instagram 的最佳貼文
2021-09-17 18:05:10
［個人進修］退休資產管理 利用休假時間前往台北參加綠角所舉辦的研習課程，幫自己充充電，一天的課程內容實在精彩，下面是一些個人感想。 近年來盛行的F.I.R.E(financial independence retire early)概念讓不少人嚮往，透過一筆足夠支應生活所需的財富，實現早早開除老...
※ 引述《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
→ VictorTom:包~~我注意到了, 第一個公式的是BGR的順序, 那其實跟第 04/08 23:22
→ VictorTom:二個是一樣的, 暈...@_@" 印象中是還有其他相似的算法:) 04/08 23:23
※ 編輯: VictorTom 來自: 220.132.174.98 (04/08 23:28)→ VictorTom:修一個錯字, 包的地方懶得修, 反正要解釋/256....Orz 04/08 23:28
推 snowlike:第一式猜測是基於整數的分配原則，畢竟灰階亦沒有小數點 04/08 23:34
→ VictorTom:其實第一式很單純啦, 原本RGB各別的小數乘256再四捨五入 04/08 23:38
→ VictorTom:只是它是BGR的順序, po文時眼花沒注意到, 它和我的折衷 04/08 23:38
→ VictorTom:式是差不多的意思, 只是某種程度上我的式子稍微精確點:) 04/08 23:39
推 snowlike:不是喔他是直接去分配灰階的256個點，小算盤按起來會不同 04/08 23:43
→ VictorTom:你要這麼解釋也無所謂, 但是這只是文字描述的觀點不同. 04/08 23:45
→ VictorTom:實際上就是RGB以一個比例混合成gray, scale到gray level 04/08 23:46
→ VictorTom:算出來不同, 單純只是兩者精確度不同, 一個計算只要四捨 04/08 23:47
→ VictorTom:五入一次, 跟四捨五入三次, 有誤差本來就再所難免:) 04/08 23:48
推 devilrucifer:感謝大大認真回文 專業 謝謝您 04/08 23:57
→ devilrucifer:所以RGB係數隨便給都可以嗎? 這部分還是不太懂 04/08 23:57
→ devilrucifer:是去查 Color Space 的不同算法嗎? 04/08 23:59
→ VictorTom:當然不是隨便給, 亮度值的轉換有幾種常見的計算方式.... 04/09 00:00
→ VictorTom:像#1#2, 印象中是用了人眼感知上, 不同channel的強度對 04/09 00:01
→ VictorTom:亮度造成的感受訂出來的, 舉例, 我們看純Green就會覺得 04/09 00:01
→ VictorTom:比純Red或純Blue亮; 其他需要亮度(Y/I/L等)的Color 04/09 00:02
→ VictorTom:Space也會有自己的理由決定, 您可以依您的需求選擇:) 04/09 00:02
推 devilrucifer:恩恩 有點瞭解了 小弟會再去查書看看的 04/09 00:04
→ devilrucifer:真的很感謝大大您 04/09 00:04
→ VictorTom:如果沒有特別需要, 只是單純Color->Gray, #2#3頗常見:) 04/09 00:05
推 devilrucifer:小弟會再多看資料的 有問題再跟您請教 感謝您^^ 04/09 00:09
→ VictorTom:www.couleur.org/index.php?page=transformations 04/09 00:10
→ VictorTom:有許多Color Space的資料, 還3D展示給你看:) 04/09 00:10
→ VictorTom:Well~~通常轉Gray是Spatial Domain處理的第一步.... 04/09 00:11
→ VictorTom:小弟只是看到Color Space有點high, 您還是忙您的吧^^ 04/09 00:11
推 sbrhsieh:0.299*r+0.587*g+0.114*b,RGB->YUV的Y,黑白電視亮度採Y值 04/09 00:45