MacのQuickTimeで映像が色褪せする現象を回避する

なぜ色褪せが起きるのか

macOSのQuickTime Playerで動画ファイルを再生すると、VLCやWindows環境で再生した時に比べて映像が “色褪せ” て見えるという声をよく聞きます。私もその経験があるのでこの悩みはよくわかります。現実として、そのような動画ファイルはMac環境においてはVLCで再生すれば本来想定されたであろう「正しそうな」色で映ることが多いため、まるでQuickTime PlayerやApple製ソフトウェアに問題があるかのように錯覚してしまいます。しかし、色褪せ現象が起きる原理に目を向けると、これはそう単純な話ではなく、Apple製ソフトウェアが一方的に悪いわけでもなさそうだという構造が見えてきます。

私はデジタル映像編集のプロではないので詳しい事柄までは解説できませんが、調査したところ、考えられる原因として次の事柄が見えました。

1. QuickTime PlayerをはじめとしたAVFoundationベースのソフトウェアはシステムレベルのカラーマネージメント処理（ColorSync）を施すため、映像素材側のエンコード設定次第では本来想定しないカラーが再生環境で出力され得る。
2. VLC、そしてWindows環境の多くのソフトウェアは伝統的にカラーマネージメントに非対応、カラーをsRGB相当（BT.709）で描画している。
3. Mac環境で「ITU H.273コードポイント」¹を直接操作できるソフトウェアが少ない。

この条件下では次のようなことが起きます。

► 映像素材がsRGB相当（BT.709）で制作されている場合：

1. 再生環境がsRGB相当のカラーを描画する場合、入出力の想定カラーが一致するので、色褪せ・色ずれが起きない（sRGBディスプレイ環境など）。
2. 映像のカラーマネージメントに非対応なVLCやWindows環境の標準的なアプリでは、入出力がsRGBで一致するので、たまたま色褪せが起きていない。
3. システムレベルでカラーマネージメントを標準実施するmacOSやiOSでは、映像素材とプロファイルによっては逆に色褪せて見えてしまうことがある。
4. Windows環境でも、動画に対してカラーマネージメントを施すソフトウェアでは、macOSと同様に色褪せて見える可能性がある。

AVFoundationはAppleプラットフォームのネイティブアプリ向けのマルチメディア基盤なので、ネイティブの設計思想で作られたアプリであればあるほど、MacやiPhoneで再生する映像が色褪せしやすい、というジレンマが起きています。同様に、Windows向けのカラマネ対応ソフトウェアにおいても色褪せが起きるというわけです。逆に言えば、“色褪せ” は映像の制作者にとっては想定されたものではないが、技術的には正しくカラマネ処理された結果である、というような見方もできます。

どれが正しい色なのかはさておき、構造的にはこういうことになってしまいます。

色褪せを回避、あるいは修復する対処療法

条件が限られますが、私が制作したスクリプトを使えば、映像素材を再エンコードすることなく、非破壊で “色褪せ” を回避・修復することができます。AVFoundationベースのネイティブアプリにおいても、元々想定されたであろう色味で映像を再生することができます。要するに、QuickTime Playerで開いても色褪せなくなります。

今回紹介する方法は、次のような映像素材を想定します（カメラの撮影素材やOBSによるキャプチャ映像など）。

• 映像素材特性:
  • BT.709としてエンコードされている
  • HDTVやWeb動画を想定
• 映像コンテナ／コーデック:
  • QuickTime (mov)、MPEG-4 (mp4)
  • AVC (H.264)、HEVC (H.265)、Apple ProRes 422
  • ※その他のフォーマットでは未検証

コードポイントを12-13-1に書き換える

コードポイントとは、「ITU H.273コードポイント（Coding Independent Code Points）」とも呼ばれ、映像に関する3種類のカラー情報—Color primaries（色の範囲）、Transfer function（ガンマカーブ・明るさ）、Matrix coefficients（YUV/RGB変換行列）—を数字と区切り文字で示します。例えば「1-1-1」や「1:1:1」のような表記をします。QuickTime Playerではインスペクタに「コードポイント」として表示されます。

動画ファイル中のコードポイントを “12-13-1” に書き換えることで、Macのようなワイドガマットかつカラマネが効いている環境においても、その映像をsRGB環境（VLCや標準的Windows）での見た目で表示することができます。

12-13-1の意味はそれぞれ、12:色の範囲をDisplay P3と解釈させる、13:ガンマカーブをsRGBと解釈させる、1:変換行列をBT.709と解釈させる、になります。macOSでのBT.709/HDTV映像は通常1-1-1で表されるのですが²、別のコードを使って半ば無理やりにsRGBのガンマカーブで読ませることで、非破壊のカラー表示変更を行えるというわけです。

patch_nclx.pyスクリプト

次のスクリプトファイルpatch_nclx.pyを手元に用意して、TerminalでPython3として実行すると、対象の動画ファイル中のコードポイントを任意の値に書き換えられます。Python3の導入方法は割愛します。

python3 patch_nclx.py video.mov 12 13 1

最終書き出しした動画ファイルに対して実行してください。中間ファイルや素材ファイルに適用してしまうと、逆に編集後に色がおかしくなる場合があります。

スクリプトを実行したら、その動画ファイルをQuickTime Playerで開いて確認してみてください。色味がVLCでの再生時と同じなら成功です。インスペクタでもコードポイントが表示されているはずです。より詳細にタグを調査するならffprobeを使う方法もあります。

このハックは標準的にカラーマネージメントが効いているmacOSネイティブ環境だから使える技で、カラーマネージメントを行わないVLCや標準的Windows環境ではおそらく効果がないか、限定的な効果となるでしょう。しかし、それはかえって都合が良いのです。今回の場合はsRGBに固着する環境側の見た目に合わせたいだけなので、VLC等でコードポイントが無視されていても問題はありません。これによって、MacとWindowsどちらでも同じ色味（sRGB）で再生できる動画ファイルを作ることが可能です。

補足情報

厳密には、色空間の情報はコンテナ（mov, mp4）が持つNCLC/NCLXタグと、映像ストリーム内に書き込まれる別の情報とがあり、本来は両者一致していなければならないもののようなのですが、技術的には両者不一致の動画ファイルも作ることができます。すでにエンコードされた映像ストリーム内の情報を書き換えるには再エンコードが必要となるため、非破壊での書き換えはできません。QuickTime Player / AVFoundationは両者不一致でもコンテナ側のタグを優先して解釈するようなので、このように非破壊での色空間変更を実現できます。色空間情報の不一致を認めなければならない点はありつつも、非常に低コスト、かつ現実的な方法だと思います。

コードポイントの書き換えのほか、動画ファイルに直接sRGBカラープロファイルを埋め込む方法もあります。QuickTime (mov)やMPEG-4 (mp4)にはそのための構造が備わっており、実験したところでもこれはうまくいきました。しかし、カラープロファイルのデータ分の容量が増えることに加え、タグの範疇を超えたビットの書き換えが必要になるため、少なくともスクリプトを使った方法としては現実的にやや難あり、という評価を下しました。実用性はありますが、NCLC/NCLXタグを書き換える方がよっぽど低コストで安全です。

Final Cut Proで扱う場合

Final Cut Proのインスペクタには映像クリップのコードポイントを扱う設定項目があります。素材ファイルに12-13-1に書き換えたクリップを読み込むと、カラーマネージメントで再解釈された色からエンコードされるので、破壊的な変更になる可能性があります。Final Cut Proを扱うような場面は中間成果物を編集するような時でしょうから、コードポイントを一旦1-1-1に戻すか、「色空間の上書き」メニューから「Rec. 709」などのプリセットを選び直す等の対応が必要かもしれません。

基本的には、コードポイントの書き換えを実施するのはプロセスの最後に行うべきでしょう。