High dynamic range color grading and display in frostbite

slides video

拙訳

フィルムの歴史と用語

film densityによって光に対する応答が異なっていた
フィルムの特性が描くカーブは3つのセクションに分けられる
- 中間部(Mid section): ほぼ線形
- 低輝度部(Toe): 反応がにぶる
- 高輝度部(Shoulder): 反応がにぶる
カーブを非線形にすることで、全体として光の値を広い範囲で捉えることができる
- ToeとShoulderの範囲を縮小する
- 中間部に合わせてシーンを露出する

トーンマッピング

最終的な出力先はディスプレイであるため、そこで表現できる色空間に合わせて値の範囲を縮小しなければならない
トーンマッピングは、大事なディテールを維持しつつ、広いダイナミックレンジを狭いダイナミックレンジに対応させる処理のこと
- FP16をRGB8に変換する
- シーンの注目している地点を、｜中間トーン《mid tones》に合わせて露出する
- フィルムの特性を模倣する

トーンマッパーの例

シンプルなヤツ: 影響の度合いは、最明部が最も大きく、最暗部が最も少ない
- [Reinhard et al. 2002Reinhard, E., Stark, M., Shirley, P. and Ferwerda, J. 2002. Photographic tone reproduction for digital images. ACM Trans. Graph. 21, 3, 267–276. 10.1145/566654.566575. https://www-old.cs.utah.edu/docs/techreports/2002/pdf/UUCS-02-001.pdf.]
- 指数関数
｜フィルム的《filmic》なヤツ: コントラストの変化に応じてToeとShoulderが程よく変化する
- Hejl and Burgess-Dawson
- [Hable 2010Hable, J. 2010. Uncharted 2: HDR Lighting. Game Developers Conference. https://www.gdcvault.com/play/1012459/Uncharted_2__HDR_Lighting.]

カラーグレーディング

カラーグレーディングとは、シーンに特徴的な見た目を適用すること
その始まりは映画産業で、見た目を変えるために使うフィルムを選んだり、現像工程を変化させたりすることを呼んだ
- 例えば、｜銀残し《bleach bypass》など
CGではさらに多くのことができる
- ホワイトバランスや露出の調整
- 色やハイライトの置き換え
- Orange & Teal （肌の補色による色味戦略）
- “Fix it in post” （= 撮影後に行う修正）

昔のテレビと標準規格

昔のテレビやCRTモニタは0.1nitsから100nitsまで
- $[\text{nits}] = [\text{cd}/m^2]$
電気的な入力に対して非線形な応答を持つ
- ｜電気光学伝達関数《Electro Optical Transfer Function》（EOTF）
- いわゆる”ガンマカーブ”
sRGB/BT.1886が標準に導入される
- ディスプレイの｜表示能力《capability》そのまま
- こんにちではよく使われている

今のテレビと標準規格

今のテレビは0.01nitsから300nits超。HDR的なことまでできる
- ハードウェアは標準規格以上の能力がある
- LCDの応答はCRTとは違う
sRGB/709を未だに使っている
- テレビは0.1nitsから100nitsまでの信号を加工してそれっぽく見せている
- キャリブレーション以外では特に制御する術はない
- 最終的にコントラストが強めに出る傾向がある
輝度についても、同じように上限方向に飽和している(例えば、店頭デモモード)

Frostbiteにおける以前のグレーディングパイプライン

ポストプロセス
- ここまでFP16の線形空間
- ブルーム、モーションブラー、Vignette(ビネット効果)、被写界深度、など
トーンマッピング
- ビルトインしたアルゴリズムからアーティストが使うものを選ぶ
- 大抵はフィルム的トーンマップ
- トーンマップはRGB各個に一次元のカーブとして与えられる
sRGBに変換
カラーグレーディング
- オフラインで生成した三次元LUTを使う
  - フォトショップでスクリーンショットを読み込む
  - 32x32x32の独自性を表すカラーキューブレイヤを読み込む
  - 見た目変換を適用する
  - カラーキューブLUTを保存する
UIを描画
ディスプレイに表示

問題

トーンマッピング
- RGB個別の一次元カーブだと色相シフトが起こる
  - 中間部が完全な線形にならない
  - チャネルが切り取られるように、ハイライトがシフトする
- トーンマッピングは”見た目”を適用する
  - “見た目”の選択はグレーディングとは別のワークフローになっている
- 新しいトーンマップを作りづらい
  - トーンマップは選ぶだけでデータ駆動ではない
sRGBとグレーディング
- photoshopは実際にはグレーディングの範疇ではない
- LUTはたいてい8ビット
  - ｜取り返しのつかない《irrecoverable》量子化が行われる
  - マッハバンドや色相シフトが起こる
- sRGB変換が前にあるので、1以上の値を取り扱えない
トーンマッピングからグレーディングまで
- トーンマップ + sRGB = LUT分布関数
  - 分布関数はグレーディングに最適ではない
  - トーンマップに依存して異なる分布が現れる
  - 異なるトーンマップを使っていたら、他のチームとLUTを共有できない
ディスプレイ表示
- SDRにハードコートされている
- より多いビット数の、より大きいダイナミックレンジの、より広い色空間の、HDRディスプレイに対応したい
- クリエイターがこれらすべてを制御できる方法を提供したい
  - テレビの製造業者由来ではなく、クリエイティブな制御ができるように

HDRディスプレイ対応

単純なアプローチ

SDRの最終的な色情報を逆トーンマッピングして、もとのHDRデータを抽出する
- Shoulderをもとに戻すにはどうすれば
制約の数々
- 逆を求めるには、8ビットだと精度が足りない
- トーンマップが複数あれば、その分だけ逆を求める必要がある
- 限定された範囲なら復元できる
- 処理順が正確でない
  - グレーディングとUIがトーンマッピングの後に描かれている
  - 後段で逆トーンマップを求めるとき、これらが不正確に反転されてしまう
さらなる改善案
- トーンマップカーブ(LUT分布関数)を調整する
  - より広い範囲をキャプチャする
  - 解析的な逆マッピングを計算する
- レンダターゲットとグレーディングを10ビットにする
- マイルドな色を使うようチームに頼んでみる
- Shoulderの範囲を使わないようにUIをスケールする

Frostbiteのアプローチ

HDRからLUT空間へ変換する
LUT空間でグレーディングする
UIはオフスクリーン(バッファに直接)描画する
- ｜前乗算アルファ《premultiplied alpha》は必須
HDRにデコード、UIを合成、トーンマッピングして、ディスプレイに合わせてエンコードする
“見た目”のワークフローをすべて一箇所に移動する
グレーディングは出力先を考慮せずにマスター空間で1回のみ行う
UIは見た目が異なるので別に処理する
現在のHDR規格は現行のディスプレイ性能より広い範囲をカバーするので、規格に従えば将来の高性能ディスプレイならよりよく見えるようになるかも

HDRグレーディング

HDRフレンドリーな分布関数を用いる
- 色々(log, S-Log, LogC)試したけど、結局はST.2084かPQ(Perceptual Quantiser)を使うことにした
- PQはLUTが知覚的な空間化がなされるので、うまく制御できる
33x33x33のLUTルックアップを行うランタイムだと10ビットUNORM
- ｜業界標準《industry standard》サイズを使うので、標準のグレーディングツールが使える
単一の分布関数を用いることで、誰でもLUTを作って共有できるので、ライブラリ化できる
業界標準のグレーディングツールであるDaVinci Resolveを使って作る
なぜエンジンには組み込まなかった？
- 車輪の再発明とその後のメンテナンスをしている時間や必要性、要望がなかった
- 熟練のグレーダーとの摩擦を減らしたかった
- Resolveのフリー版でも十分なことができた
“Resolve Live”は多大なワークフロー改善をもたらした
- キャプチャ/モニタカードを買う必要がある

ディスプレイマッピング

ゲームのHDRバージョンをリファレンスとする
トーンマッピングはパイプラインの最後にした
トーンマッピングは接続しているディスプレイに応じて異なる
- SDRでは、アグレッシブなトーンマッピング
- HDRでは、アグレッシブさは抑えめだが、ディスプレイによって変わる
- Dolby Visionでは、トーンマッピングしない
- 個別のケースに合わせて微妙に異なるバージョンのものを使う
- カーブだけでなく、露出にも
ディスプレイマッピングと呼ぶことにした
ディスプレイマッピングの主なチャレンジ
- 広範囲のデバイスに渡ってスケールする
- ディスプレイに関係なく似た見た目を達成する
トーンマッピングはパイプラインの最後にした
トーンマッピングは接続しているディスプレイに応じて異なる
- SDRでは、アグレッシブなトーンマッピング
- HDRでは、アグレッシブさは抑えめだが、ディスプレイによって変わる
- Dolby Visionでは、トーンマッピングしない
- 個別のケースに合わせて微妙に異なるバージョンのものを使う
- カーブだけでなく、露出にも
ディスプレイマッピングと呼ぶことにした
ディスプレイマッピングの主なチャレンジ
- 広範囲のデバイスに渡ってスケールする
- ディスプレイに関係なく似た見た目を達成する
欲しい性質
- Toeなし
- コントラスト変化なし
- 色相シフトなし
- No built in film look
できるだけ中立に作る
どうやって？
- RGBではなく｜輝度《luma》/｜彩度《chroma》でやる
  - Shoulderには輝度のみを適用する
  - Shoulderに依存して彩度を｜漸次的に《progressively》｜脱飽和する《desaturate》
- DolbyがHDR用に開発した、ICtCp空間を使う
  - Chroma follows lines perceptually constant hue
- 画像/ゲームの多くでは目視で調整される
  - ぜんぜんPBRじゃないけど、これは数学ではなくて知覚についてなので

万事OK…じゃない

SDRの性能は0.1-100nitsだが、ディスプレイはその性能に合わせて200から400nitsまで上限を拡大する
HDRは100nitsは100nitsなので、比較すると暗く写ってしまう
HDRをリファレンスとして、SDRの露出を調整した
- SDRディスプレイマッパーは過小露出する

アーティストはSDRのピーク値を設定できる。

ユーザがこの値を調整していることも考えて、デフォルトではSDRディスプレイは200nitsだと仮定する。

既存のアセットで色相シフトを活用したものがあれば直さなければならない

VFXの再制作

炎のエフェクトが変化するのがもっともよくあった｜苦情《complaint》だった
- VFXは前のトーンマッパーで起こるクリッピングによる色相シフトをを使って作られていた
- SDRではよく見えても、HDRになると駄目だった
黒体シミュレーション（温度による色相変化をカラールックアップにする方法）を使う
- エフェクトを温度として作る
- 黒体放射からカラーランプを作る
- 温度でランプを指す
- ちょうどいいようにランプを調整する

こんどこそOK…じゃない

色相を保存したShoulderは常に望まれているわけではない。
- 飽和した非常に明るいビジュアル(エフェクト)を大いに妨げている。
- あるフィルムのルックに合わせることを妨げている。
開発は継続している。
色相シフトの再導入を試している。

色相シフトの再導入

まだ完了していないけど、できてきている。
今年発売するゲームでは違う実装になっているかも。
- 色相を維持するほうが良いものもある。
- 色相をシフトしたほうが良いものもある。
- 色相シフトの具合をコンテンツによって変えられるようにすることになりそう。

ACES

ACES = Academy Color Encoding System
映画のCGI用のカラーマネージメントの標準規格。
処理パイプラインを定義する。
“見た目”とディスプレイマッピングが含まれている。
パイプライン。
- IDT(Input Device Transform)では、入力空間からACESの空間に変換する。
- LMT(Look Modification Transform)では、グレードとルックを適用する。
- RRT(Reference Rendering Transform)は、ようはフィルミックトーンマッピング。
- ODT(Output Device Transform)では、一貫性を保つように各ディスプレイに応じで出力を変換する。
なぜこのまま使わなかったの？
- この仕事を始めた2014年頃は、ACESがまだ動き始めたばかりだった。
- 初期のバージョンではFP16が必要で、いくつかのテクスチャフォーマットに適さなかった。
- フィルミックRRTに納得できなかった。
その原理には賛同していたので、そのコンセプトレベルで用いた。
- 処理順。
- 広いmaster work空間を使う。
- LMT = グレーディング。
- ODT = ディスプレイマッピング。
私は使うべき？
- 絶対にyes。
- ACESccやACEScgも調べておくと良いかも。
Frostbiteでは使うの？
- 将来では、ほぼ確実にyes。
- 調査は継続したい。
- 原理は共有してるし、空間もきちんと定義されているから、移行は容易だろう。
- アセットにACESのカラーマネージメントを採用するのは大いにある話。

LUTの問題

パフォーマンスとクオリティのトレードオフの話。

パフォーマンスを稼ぐため、ディスプレイマッピングをグレーディングと同じLUTに注入したい。

ディスプレイマッピングをグレーディングの最後に組み合わる処理の順序はコンポジションシェーダの初めにやることと同じ。グレードに注入するコストも安いので、実質タダ。

しかし、PQ分布ですら起こった、マッハバンディングとして現れるような、精度の問題がある。

線形フィルタリングは曲線を｜区分《piecewise》線形近似に変換する。

2点のみが寄与するので、一次元では大丈夫に見えるが、LUTはボリューム(三次元)である。

輝度軸(黒から白へのグレースケール)は対角線にあり、テクセルの中間では8近傍が等しく寄与する。

LUTフィルタリング

高階のフィルタ使う、例えば、トライリニアをトライキュービックにすれば、改善することかもしれないが、そのコストは高い。

LUT空間

RGB: やってはいけない。
YCgCo: 一番高速な非相関空間。RGBと比べて大幅な改善が見られる。
YCbCr: YCgCoより良い。
ICtCp: YCbCrと比べて良くない。YCgCoと匹敵する。

我々のディスプレイマッピング空間とそのままマッチするので、ICtCpがベストとなるべきだが、そうではなかった。

この理由は、以下で述べるが、｜色域《color gamut》に由来する。

非相関なものはRGBより輝度で優れている。

線形フィルタリングを使っていても、輝度軸と彩度軸はキューブマップの軸と平行になっている。

輝度のみのランプは一次元であり、関係する近傍は少なくなるため、区分線形近似のアーティファクトは減少する。

カラーグレーディングLUTの正確性

非相関なLUTはディスプレイマッピングの精度問題を改善する。
- 輝度が複数に跨がらずにひとつの軸に整列している。
- 三次元でなく、一次元の｜区分線形近似《piecewise linear approximation》
既存のRGB LUTの上部にディスプレイマッピングを焼きこんでいる。
- 異なる空間が問題を起こすかもしれないことを考えておく。
異なる空間でのLUTのアクセスパターンをプロットしておく。
- 各空間でLUTが触れるパーセンテージを計測する。
- カラーグレーディングの精度に影響があるかどうかを定める。

つまり、非相関であれば、目立ったアーティファクトなしに線形フィルタリングが使える。

基本的には、より多くのテクセルを使えば、グレーディングの精度が上がる。

非相関な空間は根本的に触れるテクセルが少ない。つまり、カラーグレーディングの正確性に影響がある可能性がある。

この点で言えば、ICtCpはYCC系よりも正確だが、RGBよりは正確でない。

(結局の所、ビジュアルのアーティファクトが最小になるので、)RGBでなんとかしていた。だが、将来のために非相関な空間にたいする調査を継続してゆく。

パフォーマンス

パフォーマンスは｜重要《at a premium》
- 60Hzへの注目度の増加。
- 解像度への注目度の増加。
- HDRに気を配るためにビジュアルクオリティを諦めるなんてできない。
新しいパス全体が古いパスを置き換える。
- 古いパスとのパフォーマンス｜等価性《parity》を達成するよう求められた。

パフォーマンス等価性は迅速な｜採用《adoption》を達成する上で必要になる。

昔のフレーム終わりまでのパス:

XBOXにおけるESRAMの一時領域経由でのsRGBレンダターゲットから1080pバックバッファへの分割可能な再サンプリング = 0.43ms

バックバッファの上部へのUI描画 = 任意。典型的には0.2-0.3ms

古いパスのパフォーマンス
- フレームの終わりには、上位の(high order)リサンプルがすでに行われている。
  - デュアルパス(V/H)
  - 中間への縦方向のリサンプル(ESRAM): 0.17ms (720 -> 1080)
  - バックバッファへの横方向のリサンプル(DRAM): 0.26ms (1280 -> 1920)
- トップにUIを描画する。
トータル: 0.43ms + UI
- ただし、UIはDRAMに書き込むため、コストが大きい。
- 注:値はすべてXBox Oneのもの。

バージョン1: ナイーブな実装

バックバッファと同じ解像度のオフスクリーンのRGBA8ターゲットにUIをレンダリングする。
- ターゲットのクリアが必須。
- +0.25ms
デュアルパスリサンプルの第二パスを変更する。
- HDRをリサンプル & PQを線形に変換。
- UIターゲットをロード & sRGBを線形に変換。
- HDRとUIを合成。
- sRGBにエンコード。
- - 0.45ms
トータル: ~1.1ms :(

イテレーション: 解決が容易な問題(Low Hanging Fruit)

シェーダはALUが支配的。
UIレンダターゲットはUNORMにsRGB値を含める。
- 変換なしで読み出せるようにする。
PQを線形に変換するのは高価。
- ALUとテクスチャのトレード & 1D LUTを使う。
Xboxでは帯域制限に引っかかる。
- UIのレンダターゲットをESRAMに置く。
- クリアコストが2等分され、UIレンダリングが2倍早くなる。
トータル: 0.8ms :|

ESRAMは中間バッファとUIの両方で使った。手動ESRAM管理(FrameGraphを参照)ならUIレンダリングがおよそ2倍早くなる。

イテレーション: コンピュートリサンプル

リサンプルにシングルパスのCSを使う。
- 縦方向はgroupsharedへリサンプル結果を渡す。
- 横方向はgroupsharedから結果を受け取る。
最適化(一部はGCN特有)
- 64x1スレッド配置。(線形タイルモードバックバッファ)
- StructuredBuffersに事前計算したカーネルの重みを格納する。
- ロードと縦方向のウェイトの展開にはSMEM/SALU。
トータル: ~0.7ms :|

HDRとはそれほど関係なくできる変更を行った。

パスを1つにすると、仕事量が減り、よりよいスケジューリングを可能にする。

スレッド配置はコンソール向けの最適化として使った。線形タイルモードはスワップチェインやスキャンアウトのターゲットに使う。

1D縦方向スレッド配置は、GCNではタダでフィルタの重みの一部を得るためのスカラパイプラインを使うことができるようになる。

イテレーション: CMASK対応の合成

GCNハードウェアは描かれたピクセルの”CMASK”メタデータを維持する。
4x4のピクセルブロックがレンダリングされたかどうかを保存している。
描かれていないピクセルにクリア色を書き込むため”Fast Clear Eliminate”にて使った。

実際にはGCNはすべてのピクセルを常にクリアしていない。

どのピクセルが描かれたかをメタデータで維持している。

読み戻し前に描かれていないピクセルにだけクリア色を書き戻すため”Fast Clear Eliminate(FCE)“パスが行われる。

このメタデータは読み出すことができる。
- FCEを除去する。
- 合成パスでCMSKを読む。
- UIが描かれていないピクセルでは読み込みと合成をスキップする。
あまり簡単じゃない。
- CMASKタイルはタイル化され、パッキングされている。
- ソフトウェアでタイルを解いて、アンパックしなければならない。
- 安くない。

FCEを使わず、最終のリサンプル/マージ/ディスプレイマップパス上で’タダで’スカラパイプライン経由でロードされるよう設計した、サブタイルから32x1のビットマスクに変換するカスタムCMASKトランスコードをかわりに使う。

合成に優しいフォーマットへ計算するトランスコードCMASK。

- 4x4ピクセルごとに1ビット。

- 128x4ピクセルごとに32ビット。

- 0.02msのコストがかかるが、FCEよりだいぶん安い。

合成パス。
- SMEM経由で32ビットマスクを読み込む。
- 現在のピクセルに対応するビットをアンパックする。
- ビットが0なら、UIロードと合成処理をまるごとスキップする。
トータル: 0.5ms :)

HDR10の追加コスト

追加のALU処理が必要。
- Rotate primaries to 2020
- PQにエンコード。(sRGBエンコードより少し多めのALU)
- トータル: ~0.7ms(0.2ms多い)
Xbox One S(とPS4)のみ動作する。
- XB1SはXB1より~7%速い。(60Hzだと1.1msの猶予がもらえる)
- 0.2msのHDRオーバーヘッドは極小。 XB1Sの性能の大部分はゲームに使える。
PS4はXboxよりALUが多くなるけど、心配はいらない。
- Same resolution (1080p) so PS4 is faster like-for-like in this case

HDR標準

2つの主要な標準
- Dolby Vision
- HDR10
Frostbiteは両方サポート可能。追加拡張も比較的簡単。

各ゲームでライセンス交渉をするので、特定のゲームに対してあれこれいうことはできない。

ディスプレイマッピングの”scanout shader”は、単なるエンコーディング/マッピング処理なので、どのフォーマットでも簡単にプラグインできる。

Dolby Vision

利点
- 12ビット信号で、HDMI 1.4b互換。
- ディスプレイマッパーを書かなくてすむ。
- ディスプレイ横断的な標準化(Dolby調整済みディスプレイマッパー)
- ローエンドなパネルでもいい具合。
欠点
- メタデータ生成とフレームバッファエンコーディングの追加コスト。
- Framebuffer encoding prevents overlays blending on top
- 多くの2016年発売のディスプレイでは対応していない。

Dolby Visionはカスタムなエンコードされたフレームバッファを使う。

メタデータ(例:最小・最大・平均輝度)を毎フレーム送ってやる必要がある。

Dolbyが各パネルに最適化されたディスプレイマッピングを作るので、複数のディスプレイに渡った見た目の標準化が行われる。

HDR10

利点
- 現時点でより普及している。
- カスタムフレームバッファエンコーディングなし。オーバーレイが動作する。
- ソフトウェアディスプレイマッピングを安価にできる。
欠点
- 製造元にまたがったディスプレイマッピング標準化は無し。
- ゲームが自身のディスプレイマッピングでこれをおこなう。
- 10ビット。

共通性(commonalities)

EOTF(または、ガンマカーブ)。
最大、最小、主要な(mastering)輝度。
色域
同じマスタコンテンツが両方で動作する。
1つのディスプレイマップがそれぞれに対応する。

プラットフォーム対応

PS4、PS4 Pro: HDR10
XBox One S: HDR10
PC: HDR10、Dolby Vision
- HDMIメタデータを扱うGPUベンダのAPIが必要。
- DX11: 排他的フルスクリーンで”just works”
- DX12: 非排他的フルスクリーン
  - デスクトップコンポジタがスケールやオーバーレイを追加できる
  - Dolby Visionで問題を生む可能性がある。
  - 様々な関係者たち(parties)が改善しようと動いている。

SDRディスプレイも忘れないで

大量のSDRディスプレイ。
- 今日の市場では多数派。
SDRバージョンを素晴らしく見せるひつようがある。
- コンテンツはHDRでマスタリングされている。
- FrostbiteではHDRがリファレンスバージョンである。
- 我々は自身のディスプレイマッピングを最終段で使う。
- ディスプレイマッパーを調整する。
ディスプレイが過度に明るくすることを確かめる。

次なる一歩

HDRビデオ

高ビット深度ビデオ
- デコードのパフォーマンスオーバーヘッド。
- ファイルサイズとストリーミングオーバーヘッド。
マーケティング要素。
- 同じビデオの複数バージョン。
広い色域のサポートが必要。

広い色域

やることいっぱい。
- ランタイムの色域の拡張。
- すべてのアセットにメタデータを追加。
- エディタへの色管理を追加。
- DCC間でメタデータの維持。
どこから始めるか
- ディスプレイから逆順に手を付ける。
- カラーグレーディングを広い色域に変換する。

“単なる”レンダリングではない。Frostbiteの様々な部分の協力が必要になる。

特にメタデータの維持管理がチャレンジング。

まずは、すべての”色”のアセットに色域を割り当てて管理する必要がある。

DCCパッケージはこれをサポートしているかもしれないししていないかもしれない。異なるアプローチが必要になるかも。

“TV back”からエンジンをアプグレードすることから始めようかと。

色域削減のメモ

色域拡張はささいなこと。
- 線形空間で3x3行列をかける。
色域削減は色域外の色を生む可能性がある。
- 負数をクリップすれば色相シフトが起こる。
- 3x3行列をかける前に対象の色域に色をマップする必要がある。
処理空間としてのICtCpの調査を提案する。
- 彩度スケーリングは知覚的に色相線形。
- 対象の色域にフィットするように飽和を調整する。

おわりに

アセット内で色を保証する。
- 色相を変えるクリッピングやトーンマッピングに関連しない。
HDRでマスタリングする。
- トーンマップをできるだけパイプラインの後段に移動する。
- 各ディスプレイに応じてトーンマップを変える。
無相関な空間を検討する。
- 方法はRGBだけではない。
すべての標準をサポートすることを目的とする。
- SDRもわすれないで。