試した環境

Unity 2019.3.3
Universal RP 7.2.1
Post Processing 2.3.0

はじめに

Universal RP において、Post Processing V2 は互換性のために使えるようになっていて、2020.1でサポート外になるようです。Universal RP で Post Processing V2 を使う方法などは、過去の記事に書きました。
手探りで試していたので、この構成で試してしまいました。
本記事では、Auto Exposure の挙動を確認するために　Debug 表示ができる Post Processing V2 を使っています。HDRPのAuto Exposureは、一部、機能が異なりますが、考え方を理解すれば、応用できると思っています。
本記事で述べている内容は、個人的に動作確認して得た見解なので、誤っている可能性があります。特にデバッグ表示機能に関しては、全く資料をみつけられなかったので、勘になります。現状、ソースコードを読めていなく、今後、読もうと思っています。

準備

Post Processing の基本的な設定方法、操作方法は、ここでは省略させていただきます。
Post Processing の Auto Exposureを設定しています。
Post-proces Debug コンポーネントを追加しています。
以下にスクリーンショットを載せています。

ヒストグラムの表示

以下のスクリーンショットの解説です。
Post-process Debug - Monitors - Light Meter にチェックをつけると左上にグラフが表示されます。
ビューポートのピクセルの輝度の分布情報を示すグラフだと思われます。
左が暗い、右が明るい、だと思います。画像編集ソフトと一緒です。
Histogram にチェックをつけると自動露出を行った後の輝度の分布情報が見ることができると思われます。同時に2個並べられます（めちゃくちゃ高機能！）。

Auto Exposure をON

以下のスクリーンショットの解説です。
グラフがシアンで塗られる点については、後に述べます。
Auto Exposure をONにすると、平均輝度を計算後、ビューポート全体が暗い（平均輝度が暗い、輝度の低いピクセルが多い）と判断して、自動露出補正が適用されて、明るくなると思われます。
グラフのマジェンタの線が、平均輝度だと思われます。
グラフのマジェンタの線が、中央よりも左なので、暗いと判断していると思われます。
極端な事例にしたため、自動露出補正の結果、明るくなりすぎています。

Fitering による平均輝度の計算対象の指定

Fitering を用いることで、極端に明るい、極端に暗いピクセルを平均輝度の計算の対象外にできるようです。
以下に試したGIFアニメーションを載せました。GIFアニメーション内に説明を書いてみました。無限ループなので、どこが開始がわからないです。大失敗です。「極端に明るいピクセルがある」が開始になります。そして、GIFアニメはポーズできないので見づらいですね。
補足を書きます。
平均輝度を求めるときに、明るいピクセルを計算の対象外にしたので、結果として平均輝度が下がり、マジェンタの線が左に移動したと思われます。
平均輝度が下がったので、自動露出の結果、全体が明るくなったと思われます。
UnityのEditor内の説明にパーセント指定とあります。ビューポート内の最大輝度と最低輝度の範囲内で、パーセントを指定して、フィルタリングできると思われます。シーンによって、最大輝度、最低輝度が異なるので、その方が都合が良さそうです（シーンごとに設定を変えるのは、辛すぎるので）。
最初、飛び抜けた点を無視するために、輝度の分布状況にたいして、パーセント指定して、フィルタリングするのかと思いましたが、試した限りでは、そうではなさそうです。それだと、とある1点が光っているという演出ができなくなってしまい使い物にならないので、私の考えが愚かだと気づきました。

Minimun(EV) と Maximun(EV) の設定

自動露出に使用する平均輝度を計算した結果の最大値と最小値を調整できると思われます。
MinimunとMaximunの範囲が半透明のシアンで塗られと思われます。
MinimumとMaximumを動かすと、求めた平均輝度の値が範囲が制限され、マジェンタの線が動きます。
この時、マジェンタの線は、平均輝度を計算後に、最小値と最大値処理が適応された結果の値になっていると思います。
以下のGIFアニメーションを載せました。私は、このアニメーションが意味することを理解するのに、かなり時間がかかりました。

以上で、調査結果の報告は終了になります。
デバッグモニターが超絶高機能で、ソースコードを読まなくても、Auto Exposureの動作をおそらく理解することができました。絵を作るときも、便利に使えそうです。

動機（より光を感じる演出を求めて）

動機を冒頭に書こうと思いましたが、Too Longにもほどがあるという状態になってしまったので、下部に持ってきました。ここから先は、語りたいだけで、得られる情報はないのでご注意ください。

光を感じる絵作りをするためにはどうすればいいか

私の感覚では、BloomとAuto Exposure の演出を加えると、光を感じ、神秘的な気持ちになります。モニタの設定で輝度を最大値して、モニタ全体が真っ白な画面を見るのとは異なる感覚のような気がします。あまりにも輝度が高いと不快になります。
AEの演出において、急に画面を暗くして、一部のみを明るい領域にすると、虹彩が適応が間に合わず、明るい領域をより明るく感じるのかもしれません。もしそうならば、リアルな感覚です。または、カメラが身近に存在する現在において、「強い逆光などで、人をなどを撮ろうとすると、人が暗くなる」という感覚は、なんとなく学習している気がします。目が光の量を調整する感覚も経験していると思います。そのような経験から、光を感じるのかもしれません。
Bloomの演出においては、光があふれている情景を経験的に知っているので、光を感じるのかもしれません。
科学的な根拠が全くない、個人的な見解です。このあたり、人間の感覚の面白さを感じ、絵画やCGで、より光を感じさせるには、どうしたらいかを追求したくなります。

光を感じさせる演出について考えて、最近作った事例の紹介

太陽の位置確認(日時計)モバイルアプリ

以下のGIFアニメーションは、画面に占める太陽の大きさをもとに、他のオブジェクトの輝度を調整するように独自にシェーダープログラミングしたものです。
平均輝度は計算していません。Post Processingもしていません。
物理法則は完全に無視で、感覚だけで輝度を調整しています。本シーン限定で、汎用性がなく、すぐに破綻します。作っているときに、何度も整合性が取れなくなり泣きそうになりました。「空に対して、地面が明るすぎない？」など。
太陽の光の放射の演出は、Fragment Shaderで描いたものです。Bloomがないのであまり光を感じません。
AE演出の遅延を試してみましたが、しない方がマシという品質になってしまったので、最終的に取り除きました。

2D画像を使った光を表現する映像作品

以下のGIFアニメーションは、リアルタイムではなく、動画に書き出すことを前提に作った作品です。
HDRPの Bloom + Auto Exposure機能で2Dの画像を演出しています。
背後の光によって、キャラクターが暗くなって見えなくなる、リムライトが現れる、という演出をやってみたく試してみました。
Visual Effect Graphで作ったParticleで、Line形状のライトではありません。
法線ありの2D画像のではなく、背後から光があたったときに光りそうな箇所を感覚で絵を描いて、Emittional Mapに設定しています。
つまり、物理法則を完全に無視した演出です。すぐに破綻します。つまり、調整に苦労するという地獄がまっています。
少しですが、光を感じる演出が作れたと思っています。

動機のまとめ

Post Processing を使うと光の表現がしやすく積極的に導入したいと考えるようになりました。
今まで、Auto Exposure のパラメーターを適当に値をいじって、いい感じになる値をみつけてきたが、ちゃんと理解したいと思いました。
本来はこの後、本題に入る。

全体のまとめ

Auto Exposure は、光を感じられますが、目に負担がかかりそう、見づらくもなるときがありそうなので、慎重に採用する必要があると感じました。
インタラクティブなコンテンツの場合、あらゆるシーンを事前に確認できるわけではないので、Auto Exposureが適用された結果の絵を把握しづらく、しっかりと設計しないと、シーンによって、暗すぎ、明るすぎなどになってしまうことがあると感じました。Auto Exposureというより、HDRレンダリングに言える話なのかもしれません。
一方で、シーン固定の動画などを作るときは、Auto Exposure の演出を気楽に使えると思いました。

参考資料

Unity Technologies Post processing V2 github