液晶の「黒」は、なぜ少し灰色なのか — local dimming の効果と副作用を自作シミュレータで描く
- python
- 電子工作
- ディスプレイ
- 画像処理
- led
はじめに
暗い部屋で映画を観ていて、画面の黒い部分が「真っ黒」ではなく、ほんの少し灰色っぽく浮いて見えたことはありませんか。私は何度もあります。表示まわりを触っていると、この「黒が締まらない」感じは、液晶につきまとう古くからの宿題でした。
理由はシンプルで、液晶は自分で光らないからです。有機 EL(OLED)は画素自身が発光するので、黒くしたい画素は消してしまえばよく、暗い部屋ではほとんど黒にできます。一方の液晶は、後ろのバックライトを液晶のシャッターで遮って絵を作ります。シャッターは完全には閉じきれないので、黒のつもりの場所からも光が少し漏れる。これが「黒の浮き」の正体です。
その答えのひとつが local dimming(ローカルディミング) です。バックライトを区画(ゾーン)に分けて、暗いところだけ LED を絞る。黒がぐっと沈み、消費電力も下がる——のですが、ただ良いことばかりではなく、ブルーミング(ハロ) という副作用がついてきます。
この記事は、その効果と副作用を、実機もデータシートも使わずに、自分で書いた小さなシミュレータで全部グラフにして確かめてみた記録です。先日まで書いていた EMI 対策部品の連作と同じ方針で、グラフはすべて教科書的なモデルから自分で描き起こしています。細部の数字は実パネルとは合いませんが、そのぶん種も仕掛けも全部見えます。
表示輝度 = バックライト × 透過率
まず、液晶の見え方は、ざっくりこの 1 行で書けます。
表示輝度 = バックライト輝度 × 液晶の透過率
液晶の透過率は 0〜1 の間で動きますが、0 まで閉じきれません。わずかに漏れる下限があり、これがパネル素のコントラスト比(=一番明るい白 ÷ 一番暗い黒)を決めます。白を 1 に正規化したとき、コントラスト比が仮に 1000:1 なら、黒側=透過率の下限が 1/1000 です。
下の図は、この関係を画面の横方向の断面で見たものです。黒地に明るい物体が 2 つあるシーンを、バックライト全点灯(普通の液晶)と local dimming で比べています。

- 上段: バックライト。普通の液晶はオレンジの点線のように全面を点けっぱなしですが、local dimming(青)は物体のない場所で輝度を落としています。
- 中段: 液晶の透過率。バックライトを落としたぶん、物体のある場所だけ液晶を余計に開けて、目標の明るさを保ちます(画素補正)。
- 下段(対数軸): 実際に見える輝度。普通の液晶(オレンジ)は、黒い場所でも漏れ光の下限から下がれません。local dimming(青)は物体から離れた黒で深く沈みますが、物体のすぐ近くだけ少し持ち上がっています。これがハロです。
落とすのは「バックライト」、開け直すのは「液晶」。この二段構えが local dimming の基本動作で、後で出てくる副作用もだいたいここから説明できます。
バックライトの置き方 — エッジライトと直下型
LED をどこに置くかで、絞れる細かさが変わります。大きく 2 通りあります。
- エッジライト: 画面の縁に LED を並べ、導光板で面に広げる。薄く安く作れますが、光が縁から入る都合で、絞れる細かさが帯状(1 次元的)になりやすいのが弱みです。実機の挙動は導光板の設計しだいで変わりますが、この記事では「縦のストリップだけを制御できる 1 次元モデル」として扱います。
- 直下型(FALD: Full-Array Local Dimming): パネルの背面に LED を格子状に並べる。2 次元のゾーンとして自由に絞れますが、LED の数とそれを駆動する回路が増え、厚く・高くなります。
同じ「ゾーン数」でも、効き方はかなり違います。下は、黒地の白い丸に対して、両者が作るバックライトの形を並べたものです。

エッジライト(中央)は、丸を含む列が上から下まで帯状に光ってしまいます。直下型(右)は、丸のまわりだけを局所的に点けられます。この例だと、黒に漏れる光(leak)は直下型のほうが小さく、消費電力も少なく済んでいます。直下型のほうが性能は良いが、コストは高い——という、よく聞くトレードオフが、そのまま図に出ています。
効果と副作用を、同じ絵で見る
では、普通の液晶と local dimming で、同じ絵がどう変わるのか。黒地に月のような白い丸を置いて、3 枚並べました(漏れ光が目に見えるよう、画像はガンマ補正してあります)。

- 中央(普通の液晶): 黒い背景が、漏れ光のぶんだけ灰色に浮いています。システムのコントラスト比はパネル素のまま、おおよそ 1000:1。
- 右(local dimming): 月から離れた黒がしっかり沈みます。このシミュレータで「月から十分離れた黒の平均」を分母にしてシステムコントラスト比を測ると、2 万:1 近くまで跳ね上がります(あくまでこの合成シーンと定義に対する値で、実機のスペック値ではありません)。ただし、月のまわりをよく見ると、淡い光の輪(ハロ)が残っています。
これがブルーミングです。原因は単純で、バックライトのゾーンが、液晶の画素よりずっと粗いから。小さな白い点ひとつのために、その点を含むゾーンを丸ごと点けるしかなく、点の周囲の「黒くあってほしい画素」にまで光が回ってしまう。液晶側で閉じようとしても、例の漏れ光の下限があるので閉じきれず、薄く光ってしまうわけです。
「ゾーン数」というダイヤル
ハロを抑えるいちばん素直な方法は、ゾーンを細かくすることです。ゾーンが細かいほど、点けっぱなしにする無駄な面積が減り、ハロは小さくなります。下は、ゾーン数を変えながら、省電力・ブルーミング・コントラストの 3 つを追ったものです(位置の偏りをならすため、複数シーンの平均を取っています)。

この単純なモデルと暗背景中心のシーンでは、3 枚とも、ゾーン数を増やすほど良くなっていきます。コントラストは上がり、ブルーミングは減り、バックライトの削減量も伸びる。そして数百ゾーン以上の実用域では、省電力・黒漏れ・コントラストのいずれも、同じゾーン数なら直下型(青)がエッジライト(オレンジ)を上回ります(横方向にしか刻めないエッジライトは、画素列より細かいゾーンを持てないので、ある所で頭打ちになります)。逆にゾーン数がごく少ないうちは、横に細かく刻めるぶんエッジライトが勝つこともあり、実機でも制御アルゴリズムや拡散板、ピーク輝度の制限しだいで、ここまできれいに単調にはならないこともあります。
ただし、ゾーンを増やすことには代償があります。LED の数も、それを駆動するドライバのチャネル数も増える。ここが効果とコストの綱引きになります。mini-LED は、この「ゾーン数」を一気に桁で増やすための技術で、数千〜一万ゾーンといった製品も出てきました。図の右側、ゾーンを増やしたときの伸びを、ハードウェアで取りにいったもの、と見ると分かりやすいと思います。
バックライトの削減量は、絵の中身しだいでもあります。暗いシーンほど消せるゾーンが多く、よく効きます。逆に全面が明るいシーンでは、そもそも消すところがありません。なお、ここでの「削減率」はバックライトの指令値(LED の明るさ)を平均したもので、実際のコンセント電力そのものではありません(後述)。

誰がこれを制御しているのか
ここまでの「ゾーンの明るさをいくつにするか」「液晶側をどれだけ開け直すか」という判断は、フレームごとに実時間でやり続ける必要があります。
テレビやモニタでは、これを製品内部のチップの組み合わせが自動でやってくれます。ここで役割を分けておくと分かりやすくて、映像を解析してゾーンごとの目標や画素補正値を計算するのは映像処理 SoC(映像エンジン)や T-CON(タイミングコントローラ)、その指示を受けて LED に実際の電流・PWM を流すのがLED ドライバ、という分担が一般的です。ひとことで「ドライバ IC が全部やる」わけではなく、重い演算側(SoC / T-CON)と駆動側(LED ドライバ)が連携している、というのが実態に近いです。
一方で、車載のディスプレイのように要求が特殊な分野では、事情が変わってきます。直射日光に負けない高い輝度、広い温度範囲、HDR、そして長期の信頼性。こうした要件に合わせて、アルゴリズムを内蔵した車載向けの local dimming コントローラ IC(スマート T-CON 系)を使う場合もあれば、要件やゾーン配置に合わせて FPGA で独自の制御を組む場合もあります。どちらを選ぶかは、必要なゾーン数や応答、対応すべき入力、量産規模しだい、というのが実情だと思います。
このあたりは公開情報をなぞった一般論にとどめます。大事なのは、「絵を見てバックライトと液晶へ指示を出す箱」が、テレビでは見えないだけで必ずどこかにいる、という点です。今回のシミュレータは、その箱が中でやっていることを、いちばん素朴な形で書き出したもの、とも言えます。
このモデルが省いていること
最後に、正直な注記です。今回のシミュレータは仕組みを見るための最小モデルで、実機を再現するものではありません。とくに次を割り切っています。
- 輝度だけを扱い、色は見ていません(モノクロ相当)。
- バックライトの広がりはガウシアンで近似しています。実際の LED と導光・拡散の光学はもっと複雑です。
- 「削減率」はバックライト指令値(LED の明るさ)の平均から出した量で、実消費電力そのものではありません。LED 効率の非線形、ドライバ自体が食う静的電力、ゾーン数を増やしたぶんの制御・通信のオーバーヘッドは無視しています。なので図の 70〜90% という値は、この暗めの合成シーンに対する上限寄りの数字で、実機の一般的な平均はもっと控えめです。
- 時間方向(応答速度やちらつき)も扱っていません。
それでも、「黒がなぜ浮くのか」「local dimming は何を得て何を払うのか」「エッジと直下で何が違うのか」「ゾーン数を増やすと何が起きるのか」——このあたりの形と読み方は、ちゃんと見えてくると思います。
おわりに
local dimming は、「液晶の黒は漏れる」という弱点に、「ならば後ろの光を切り分けよう」と答える、シンプルで力技な解決策でした。効果(深い黒・省電力)と副作用(ハロ)は、どちらも「バックライトが画素より粗い」という同じ一点から出てきます。そして、その粗さをお金(LED とドライバ)で細かくしていくのが、ゾーン数や mini-LED の話だった、という整理になります。
今回のシミュレータと、この記事の図を生成するスクリプトは、まとめてリポジトリに置いておきます(自分で動かして、ゾーン数や拡散を変えて遊べます)。
- リポジトリ: logicia32/local-dimming-lab(Python だけで動きます)
暗いシーンで黒の浮きが気になったとき、あるいは明るい点のまわりにうっすら輪が見えたとき、画面の後ろで何が起きているのかを思い出すきっかけになれば嬉しいです。
この記事は Zenn に初出したものを加筆・補足したものです ── Zenn の元記事を見る