本ページにはアフィリエイト広告（プロモーション）が含まれる場合があります。

彩度と自然な彩度（バイブランス）

色の基礎
Saturation and Vibrance
別名: バイブランス
別名: 自然な彩度
別名: Vibrance
別名: Saturation

「彩度」という語には少なくとも3つの別々の意味がある。CIE が定義する知覚属性としての saturation、HSL/HSV の S、そして現像ソフトのスライダーである。「自然な彩度（バイブランス）」に至っては統一された定義がなく、同じ darktable の中でさえ、名前が同じで逆方向に働くモジュールが並存していた。Adobe が「低彩度の色を主に上げ、肌色の過飽和を防ぐ」と説明しているのは事実だが、そのアルゴリズムは公開されていない。一方オープンソースの実装はソースコードを読めば何をしているかが行単位で確定する。このページでいちばん確かなのは「実装ごとに動作が違う」という事実のほうで、「自然な彩度とは何か」という定義そのものには、参照できる共通の原典が存在しない。

図で見る

「自然な彩度」の効き方は実装によって逆を向く実線は darktable 旧 vibrance モジュールのソースコードから導いた形で、効きの重みが元のクロマに正比例することは式（重み = √(a²+b²)/256、彩度倍率 = 1 + amount×重み）から確定している。もう一方は「彩度の低い色を優先する」という一般的な説明を向きだけ図にした模式図であり、具体的な式が公開されていないものを含むため実測値でも実装の再現でもない。縦軸の絶対量には意味がなく、読み取れるのは傾きの向きが逆だということだけ。

この操作が画像に何をするか

彩度スライダーは、色の「色みの強さ」を一律に増減する。自然な彩度（バイブランス）は、それを一律ではなく元の彩度に応じて加減すると説明されることが多いが、その加減の仕方には統一された定義がない。darktable の旧 vibrance モジュールは、Lab の a・b からクロマの重みを求め、a・b に (1 + amount×重み) を、明度 L に (1 − 0.25×amount×重み) を掛けるだけの実装で、重みが元のクロマに比例するため彩度の高い画素ほど強くかかる。一方、同じ darktable の現行モジュール color balance rgb の global vibrance は「クロマの低い色を優先し、すでに色鮮やかな画素を誇張しない」と説明されている。RawTherapee の「肌色を保護」はチェックボックスで、既定はオフである。Adobe は効果を説明しているが式は公開していない。つまり「自然な彩度」はアルゴリズムの名前ではなく、各ソフトが独自に定義した機能名である。したがって「自然な彩度を使えば肌が守られる」といった説明は、どのソフトのどの世代の実装を指しているかを言わなければ検証できない。

効く場面

全体の色みは残したまま、くすんだ部分だけを持ち上げたいとき（使うソフトがそう実装している場合）
空や緑が飽和しやすい風景で、上げすぎの判定を自分で持ちたいとき
人物が入る画面で、彩度を上げたいが肌の色は動かしたくないとき（保護機能を明示的に有効にする）
フィルム調の仕上げで、色相ごとの強さを揃えず意図的に偏らせたいとき

つまずきやすい点

「自然な彩度なら肌は守られる」と思い込む（少なくとも RawTherapee では既定でオフのオプション）
使っているソフトの vibrance が低彩度優先か高彩度優先かを確かめずに強く掛ける
彩度を上げた結果 sRGB の色域を外れ、書き出しで階調が潰れてから気づく
コントラストを上げたことで見かけの彩度も上がっているのに、さらに彩度を足す

どこまで裏が取れているか

この項目についてよく言われることを、出典に当たって確かめた結果です。出典が見つからなかったものは、見つからなかったと書いています。

原典で確認できる「彩度」には互いに別の定義が並存している。CIE の saturation は「明るさに比して判断された colourfulness」という知覚属性だが、HSL の S は sRGB のガンマ符号化値の最大・最小から計算される幾何量であり、W3C 自身がその明度 L について「色相をまたいだ知覚的明度には対応しない」と明記している。 CIE 側は e-ILV（CIE が無料公開している国際照明用語集。内容は CIE S 017:2020 の定義そのもので、規格本体は有償のため定義文のみ確認）の colourfulness (17-22-072) / saturation (17-22-073) / chroma (17-22-074) で、いずれも「visual perception の属性」「judged（判断される）」という語で書かれた知覚量である。HSL 側は W3C の参照実装で、S = (max − L) / min(L, 1 − L)、L = (min + max)/2 という純粋に幾何的な式であり、入力はガンマ符号化された sRGB 値。W3C 自身が「青も黄色も HSL 明度は 50% だが、黄色のほうがはるかに明るく見える」と例示している。Photoshop など個々のアプリの「HSL」が同じ式を使っているかは確認していない。また HSV（HSB）は CSS 仕様が定義していないため、「HSL の S と HSV の S で同じ色の値が違う」ことは本調査では一次資料で確認できていない。出典: W3C CSS Color Module Level 4 §7「HSL Colors」／§7.2 参照実装（および CIE e-ILV 17-22-072〜074）
原典で確認できる darktable の（旧）vibrance モジュールは、Lab のクロマが高い画素ほど強く彩度を上げる実装になっており、肌色を保護する処理は含まれていない。「バイブランスは彩度の低い色を上げる」という一般的な説明とは逆向きである。 process() の中で重み sw = √(a²+b²)/256 を求め、a・b には ss = 1 + amount×sw を、明度 L には ls = 1 − 0.25×amount×sw を掛けている。sw は元のクロマに比例するので、彩度の高い画素ほど強くかかる。ファイル全体に肌色（色相範囲）の判定は存在しない。公式マニュアルの説明文「最も彩度の高い画素の彩度を上げて明度を下げる」もこれと一致する。ただしこのモジュールは darktable 3.6 以降 deprecated で、マニュアルにも「新規の編集には使うべきでない」と書かれている。したがって「現行の darktable の vibrance がこう動く」という主張には使えず、「vibrance という名前の実装のひとつはこう動いていた」という事実である。GPL で公開されたソースコード。出典: darktable ソースコード src/iop/vibrance.c（release-3.4.0）
出典によって食い違う「自然な彩度（vibrance）」に統一された定義はない。同じ darktable の中に、彩度の高い画素を優先する実装と、低クロマの色を優先する実装が並存していた。現行モジュールのマニュアルは global vibrance を「画像全体の色のクロマ次元に作用し、クロマの低い色を優先する。これによりすでに色鮮やかな画素を誇張することなくニュートラルな色のクロマを上げられる」と説明しており、旧 vibrance モジュールのコード（彩度の高い画素ほど強くかかる）とちょうど逆である。対比対象は https://raw.githubusercontent.com/darktable-org/darktable/release-3.4.0/src/iop/vibrance.c 。どちらかが誤りだと主張しているのではなく（旧モジュールは deprecated、新モジュールが現行）、同じ名前の機能に共通の定義が無いことの証拠として並べている。他ソフト（Adobe / Capture One 等）の vibrance が両者のどちらに近いかは、アルゴリズムが公開されていないため確認できていない。なお color balance rgb は「このモジュールは CIE の chroma と saturation の定義に従う」とも述べている。出典: darktable 4.6 ユーザーマニュアル「color balance rgb」（global vibrance の節）
原典で確認できる RawTherapee の「肌色を保護（Protect Skin Tones）」は自動的に働く処理ではなく、既定でオフの明示的なオプションである。コンストラクタの初期値が protectskins(false) であり、この機能の既定値がオフであることを直接示している。公式ドキュメント（https://rawpedia.rawtherapee.com/Vibrance ）も「有効にすると、自然な肌の色に近い色はバイブランス調整の影響を受けなくなる」と条件付きで説明しており、常時働く処理でないことと整合する。実装本体（rtengine/ipvibrance.cc）では if (protectskins) の内側で肌色判定関数が呼ばれ、判定は Lab の明度・色相・クロマを引数に取るが、具体的な閾値までは本調査では追跡していない。なお同じコンストラクタで avoidcolorshift（色相ずれ回避）は既定でオンになっている。GPL で公開されたソースコード。出典: RawTherapee ソースコード rtengine/procparams.cc（dev ブランチ、VibranceParams のコンストラクタ）
二次資料でしか確認できていない Adobe は Vibrance を「彩度の低い色を主に変え、肌色の過飽和を防ぐ」と説明しているが、そのアルゴリズムは公開されていない。オープンソースの同種機能ならソースコードで確定できる内容が、Adobe では「そう説明されている」以上には確認できない。この引用が裏づけるのは「Adobe がそう説明している」ことだけで、実際に何が計算されているか（どの色空間で、どの量を、どういう関数で変え、肌色をどう判定しているか）は述べられていない。この記述からアルゴリズムを再現することはできないため、公式ヘルプという権威はあっても格付けは secondary_only にとどまる。Adobe の Vibrance / Clarity / Texture 等のアルゴリズムを記述した公開文書は本調査では発見できず、DNG 仕様書 1.6.0.0 の全文にも Vibrance の記述は無かった。／ヘルプページは Adobe の公式サイトから直接取得し、引用した3文がいずれも本文中に存在することを機械照合で確認した。出典: Adobe Camera Raw ヘルプ「Make color and tonal adjustments in Camera Raw」

他の項目の主張とあわせて確かめたい場合は根拠の強さで見るもご覧ください。