どうすべきか。
8-bit RGB だと精度が足りんと思う。16-bit にするならするでパイプライン丸ごと 16-bit にしたほうがいい気がする。今のパイプラインは基本 8-bit RGB なはず。
ただ，16-bit LUT はそれなりのデータ量 (16 / 2) bytes × 2^(16) 通り = 131,072 bytes = 128 KB になる。sRGB, P3, BT.601, BT.709, BT.2020 の LUT をデフォルトでオンメモリーにした場合，1280 KB，つまり 1.25 MB。でかい。
さあ，どうしようか。LUT 使えば計算量はそれなりに抑えられるので，高速。核となる色変換部分も HLSL/GLSL で GPU 上で実行。
んー，一番いいのはディスプレイは sRGB か Adobe RGB，Display P3 のどれかであること。ICC プロファイルのデコードは Little CMS に任せるとして，それgaどの色空間を持つのかをちゃんと識別して，独自色空間なら LUT 計算して，みたいな賢い処理しないとダメな気がする。
一番いいのはモニターの固有 ID 的なのを取ってそれの LUT をローカルに保存し保持する，ってのだろうけど，プロファイルが変わったかどうか識別もだるい。でも LUT 作るコストは 16-bit の場合それなりにある…
うーん，どうしようかなぁ…
動画向けの LUT は少なくとも用意するけど，“ディスプレイに出す” LUT はどうしようかマジで悩む。特にマルチプラットフォームなのでカラマネ周りの情報めっちゃ送り付けてもらえるとありがたい。
追記
BT.601, BT.709, BT.2020 に対しての LUT は基本同一 (12-bit color に対してのみ計算式が変わる) だし，LUT は精度高め (16-bit でも耐えられるレベル) で作って，2 種類を使いまわせばいいのではないか？ ディスプレイ LUT は遅延（必要になったら初期化）して起動するでもいいかも。
問題はモニターに対する LUT をどう扱うか，な気がしてきた。NTSC, PAL, BT 系を持ってもそれほどコストではないし
