そして、グラフィックスと密接に協力した人は、これらの数字を文字通り心から知っています-昔、enikeyshchikiはWindowsのシリアル番号を覚えていました。 係数は2番目の符号に丸められることもあれば、4番目に調整されることもありますが、正準形はそれだけです。
相対的な色の明るさを計算します（相対的な輝度またはいくつかの輝度コンテキストで、明るさと明るさと混同しないでください）。RGBカラー画像をグレースケールおよび関連タスクに変換するために広く使用されます。
この式は、StackOverflowの何千もの記事、フォーラムの議論、および回答で複製され引用されています...しかし、事実は、唯一の正しい場所は歴史のゴミ箱にあるということです。 使用できません。 しかし、彼らはそれを使用します。
しかし、なぜですか？ そして、これらの係数はどこから来たのですか？
歴史への小さな余談
テレビおよびラジオ通信の分野（ ITU ）の推奨事項（事実上の標準）を開発している国際機関があります。
1982年に採用されたITU-R BT.601の推奨事項（参照により更新された版）で、私たちにとって関心のあるパラメーターが詳しく説明されています。 すでにこの時点で、少し驚かれるかもしれません-私たちはどこにいて、82年目はどこですか？ しかし、これはほんの始まりに過ぎません。
1970年からのITU-R BT.470勧告から移行された数値（更新されたバージョンはここでも入手可能です）。
そして、それらは、1953年にNTSC北米放送システム用に開発されたYIQカラーモデルの遺産です！ 現在のコンピューターやガジェットと関係があるのは、何もないことよりも少し多くあります。
宇宙船と古代ローマの馬のお尻の幅との関係についての物語を誰かに思い出させませんか？
1970年にPAL / SECAMシステムの近代化に伴い、最新の比色パラメーターが結晶化し始めました。 ほぼ同時期に、アメリカ人は同様の蛍光体のSMPTE-C仕様を思いつきましたが、NTSCは1987年にのみそれらに切り替えました。 確かなことはわかりませんが、悪名高いRec.601の誕生の事実を説明しているのは、この遅れであると思われます。結局のところ、彼らは登場時までに道徳的に時代遅れです。
その後、1990年にITU-R BT.709の新しい推奨事項があり、1996年にsRGB標準が考案されました。これは、今日まで世界と（消費者部門で）統治されています。 それに代わるものがありますが、それらはすべて非常に特定の分野で需要があります。 そして、それはもう20年も経ちました-アタビズムを完全に取り除く時間ではないでしょうか？
それでは、正確に何が問題なのでしょうか？
これらの係数は人間の視覚のいくつかの基本的な特性を反映しているため、制限の規定がないと考える人がいるかもしれません。 これは完全に真実ではありません-特に、係数は色再現技術に関係しています。
RGB空間（およびYIQはRGBモデルの変換）は、3つの基本的なパラメーターによって決定されます。
1. 3つの原色の色座標（原色と呼ばれます）;
2.白色点の色座標（白色点または基準白色）;
3.ガンマ補正。
通常、色座標はCIE xyYシステムで設定されます。 この場合の文字の大文字小文字は重要です：小文字のxyは色彩図（よく知られている「馬蹄形」）の座標に対応し、大文字のYはCIE XYZベクトルからの輝度です。
次に、すべてのNTSC原色のYコンポーネントを見てください（私はそれらをピンクにマークしました）。
* Bruce LindblumのWebサイトにある他の多くのスペースを含む元のテーブル。
おなじみのデジタルですよね？ 「どこから来たの？」という質問に対する答えです。
問題は、現在使用されているsRGBスペースが60年前のシステムとは大きく異なることです。 そして、それは良くも悪くもありません- それらは単に異なっています：
三角形は幅が広く、横にずれています。 別の白い点。 ちなみに、port窓Cは、一般にDシリーズのport窓、特に最も人気のあるD65のfavor窓を支持して廃止されたと認識されてきました。 色域のボディは異なります-したがって、輝度計算の結果は現実には不十分です。
あなたは尋ねるかもしれません：なぜ古代のNTSCカバレッジは（Adobe RGB 1998のカバレッジとほぼ同じです！）現代のsRGBよりもはるかに多いのですか？ 知りません 当時の絵の管ではカバーできなかったことは明らかです。 おそらく彼らは未来の基盤を作りたいと思っていたのでしょうか？
どうですか？
sRGB空間の原色の相対的な明るさは上の表に示されています（緑色でマークされています）-それらは使用されるべきです。 実際には、通常4文字に切り上げられます。
注意深い読者は、Rの係数がルールによって丸められる（下向き）ことに気付くでしょうが、これはエラーではありません。 実際、3つの数値すべての合計は1に等しくなければならず、「正しい」丸めはエラーを引き起こします。 ペダルは小数点以下6桁すべてを使用でき、心配する必要はありません。
この式は、典型的なケースの99％に十分です。 すべての仕様でW3Cを使用します（たとえば、 SVGのマトリックスフィルター ）。
より正確にする必要がある場合は、 L *を計算する必要がありますが、これは別の大きなトピックです。 さらに読むための出発点を提供するStackOverflowへの良い回答 。
異なる色空間（Adobe RGB、ProPhoto RGBなど）に画像がある場合-係数は異なります。 それらは前述のブルース・リンドブルムの表にあります。
なぜ私を悩ますのですか？
前述のように、長年にわたって式は無数のサイトで複製されており、すべての検索エンジンのトップに位置しています（ たとえば ）。 より深刻な情報源は両方の式を引用することが多いが、それらを適切に区別せず、同等の代替として提示している。 スタックオーバーフローの典型的な例： RGBカラーの明るさを決定する公式 -答えは非常に詳細ですが、被験者にいない人が情報に基づいた選択をすることは困難です。
公平に言えば、深刻なプロジェクトはそのようなエラーにほとんど苦しむことはありません-著者は基準をチェックすることを軽disせず、聴衆のフィードバックは機能しています（例外はありませんが）。 しかし、問題をすばやく解決する必要がある普通のプログラマーは、「rgb to grayscale」のようなものを検索エンジンに送り込み、彼はあなたが何を知っているのかを手放します。 数式は引き続き検出され、コピーと貼り付けが行われます！ 驚異的なサバイバビリティ。
これらの例を検索するのに約20分かかりました。
- Microsoftのドキュメント
- Matlabドキュメント
- Go標準ライブラリ
- Reactのトレンディなカラーピッカー （> 2kスター）
- Chart.js （> 23kスター！）
- 画像処理用のCImgライブラリ
- OpenCVのいくつかの モジュール （それらは二次的であるようです）
- WebGLのデモ集
- gimp 内の 何かとInkscapeのユーティリティ
- Swift 、 Go 、 Three.js 、 JSの誰かの小さなプロジェクト
古いプロジェクトと一緒に、リストには最新で最新の技術への多くの参照が含まれていることに注意してください。つまり、コードは最近作成/コピーされました。
そして、このメモを書いた理由は、HolyJS-2016のVasilika Klimovaのレポートからのスライドで、同じ先史時代の公式を使用しています。 数式がスピーチの主な意味に影響を与えなかったことは明らかですが、2016年にうっかりグーグルをする可能性を明確に示しました。
要約すると、誰かの現在のコードにシーケンス299/587/114が表示されている場合、このメモへのリンクを作成者に投げてください。
アップデート1
コメントは例を促します。 しかし、見た目ほど簡単ではありません。
任意の写真を撮って2つの方法でb / wに変換すると、何も表示されません。 写真は少し異なります。 視聴者が評価できるのは、どのオプションが彼にとって主観的にきれいかです。 しかし、それはポイントではありません！ 事実は、どちらのオプションがより正確で、より正確であるかです。
少し考えて、この種のことをスケッチしました： codepen.io/dom1n1k/pen/LZWjbj
このスクリプトは、100個のランダムカラーの2倍を生成し、すべてのキューブの輝度が理論的に同じになるようにコンポーネントを選択します（Y = 0.5）。 つまり、フィールド全体を主観的にできるだけ均一に知覚する必要があります（異なるトーンを考慮せず、明るさの点で正確に均質です）。
左側には古い「間違った」式があり、右側には新しい「正しい」式があります。 右側では、均一性が実際に著しく高くなっています。 もちろん理想的ではありませんが、精度を高めるには、知覚明度L *を計算する必要があります。
更新2.1
ガンマについて別の質問がありました。 彼はすでに少なくとも3人の人々によって育てられていたので、私も更新します。 質問は実際には単純ではなく、一部は哲学的です（完全に別の記事を参照します）。
厳密に言えば、はい、ガンマをデコードして画像をb / wに変換する必要があります。 しかし、実際には（正確な測色に関係しないタスクで）このステップは、単純さとパフォーマンスのために省略されることがよくあります。 たとえば、Photoshopはグレースケールに変換するときにガンマを考慮しますが、同じ名前（ MDN ）のCSSフィルターは考慮しません。
結果の正確さの観点から、重みの選択とガンマの再計算は補完的なものです。 両方に影響します。 唯一の違いは、ガンマには追加の計算が必要ですが、正しい係数は無料です。
ガンマを考慮したデモの2番目のバージョン（最初のバージョンはどこにも行っていません）： codepen.io/dom1n1k/pen/PzpEQX
もちろん、より正確に判明しました。