写真の物理学 ㊳ Log収録とシネマカラーサイエンス

Share
📐
写真の物理学シリーズ ㊳
このシリーズでは、写真にまつわる現象を物理学の言葉で記述する。「なんとなくそうなる」を「なぜそうなるか」に変換することが目的である。

映画制作の現場では、カメラの出力を「Log」で収録し、「LUT」を通して色を変換する。写真の世界ではRAW現像が当たり前になったが、動画の世界ではLogという独自の符号化体系が発展してきた。本稿では、Log収録がなぜ必要なのかをリニア符号化の物理的限界から説明し、ACES、各社Log曲線、LUT、カラーグレーディングの信号処理までを体系的に導出する。

リニア収録ではシャドーの階調が失われる

光電効果とフォトダイオードで述べたとおり、デジタルセンサーの応答は線形(リニア)だ。光量が2倍になれば出力信号も2倍になる。このリニアな信号をそのままデジタル値に符号化すると、深刻な問題が生じる。

10ビットのリニア符号化(1,024段階)で14ストップのダイナミックレンジ(ダイナミックレンジとビット深度参照)を記録する場合を考える。最も明るい1ストップ(最上位の露光域)は、コード値512から1,023までの512段階を占める。次の1ストップは256段階。その次は128段階、64段階、32段階と半減していく。

$$ \text{Stop } n \text{ のコード値数} = \frac{2^{N}}{2^{n}} = 2^{N-n} $$

ここで $N$ はビット深度、$n$ はストップ番号(最も明るいストップを1とする)である。10ビットで14ストップを記録しようとすると、最も暗い4ストップには合計で1段階未満しか割り当てられない。シャドーの階調は実質的にゼロだ。

全コード値の半分が最も明るい1ストップの記録に使われている。ミドルグレー(18%反射率、最大露光の約7ストップ下)付近には10ビットリニアでわずか8段階程度しか割り当てられない。これでは後処理でシャドーを持ち上げた瞬間にバンディング(トーンジャンプ)が露呈する。

この問題の本質は、センサーの物理応答と人間の知覚の間にある非線形性のギャップだ。センサーは光量に線形に応答するが、人間の視覚は視覚の知覚心理物理学で詳述したウェーバー・フェヒナーの法則に従い、刺激強度に対して対数的に反応する。明るさの知覚的な「等間隔」は、物理量では等比的な間隔に対応する。リニア符号化はこの知覚構造を無視しているために、暗部の階調を致命的に浪費するのである。

写真のRAW現像においても、この問題は存在する。ただしRAWファイルはRAW現像の信号処理で述べたように12ビットないし14ビットという大きな器で記録するため、ミドルグレー付近にも十分な段階数が確保される。一方、動画は10ビットのビット深度で広いダイナミックレンジを扱わなければならない。ここにLog符号化の必然性がある。

Log曲線の数学

Log符号化の基本的な発想は単純だ。ガンマとトーンカーブの知覚心理物理学で論じた知覚均等性の原理に従い、対数関数を用いてリニアな露光値を知覚的に均等な階調に再配分する。

対数関数による知覚的均等化

対数関数の本質的な性質は、等比の入力変化を等差の出力変化に変換することだ。

$$ \log_{10}(2x) - \log_{10}(x) = \log_{10}(2) \approx 0.301 $$

光量が2倍(1ストップ)になるたびに、対数値は約0.301だけ増加する。これにより、各ストップに割り当てられるコード値の数がほぼ均等になる。10ビットで14ストップを記録する場合、Log符号化ではストップあたり約73段階が均等に配分される。リニア符号化で最暗部に1段階未満しか割り当てられなかったのとは対照的だ。

一般的なLog符号化の数式

シネマカメラのLog曲線は、リニアドメインの信号 $x$ を対数ドメインのコード値 $t$ に変換する区分的関数として定義される。一般形は次のとおりだ。

$$ t = \begin{cases} c \cdot \log_{10}(a \cdot x + b) + d & (x > \text{cut}) \\ e \cdot x + f & (x \leq \text{cut}) \end{cases} $$

ここで $a$, $b$, $c$, $d$, $e$, $f$ はカメラメーカーと露出指数(EI)によって決まるパラメータ、$\text{cut}$ は線形区間と対数区間の切り替え点である。

低輝度域に線形区間を設ける理由は、$\log_{10}(x)$ が $x \to 0$ で $-\infty$ に発散するからだ。物理的には、ノイズの物理学で論じたセンサーのノイズフロア付近の信号に対して対数変換を適用すると、ノイズが不均衡に増幅されてしまう。線形区間はこの発散を防ぎ、関数の連続性と微分可能性を保証する。色空間の数学で導出したsRGBの伝達関数が低輝度域に線形区間を持つのとまったく同じ設計思想だ。

逆変換(デコード)は次の式で与えられる。

$$ x = \begin{cases} \dfrac{10^{(t - d) / c} - b}{a} & (t > e \cdot \text{cut} + f) \\[8pt] \dfrac{t - f}{e} & (t \leq e \cdot \text{cut} + f) \end{cases} $$

各社Log曲線の比較

主要なシネマカメラメーカーは、それぞれ独自のLog曲線を開発している。数学的な構造は共通しているが、パラメータの設計思想が異なる。

ARRI Log C

ARRIのLog C(Cは歴史的なCineonログに由来する)は、シネマ業界で最も広く参照されるLog曲線だ。

Log C3(ALEXA Classic/Mini/LF世代)の符号化式は上述の一般形と同一であり、パラメータ $a$ から $f$ および $\text{cut}$ は露出指数(EI 160からEI 3200)ごとに異なる値を取る。EI 800(標準設定)における10ビットエンコードでは、ストップあたり約73から78コード値が割り当てられる。

2022年に発表されたLog C4(ALEXA 35世代)では、曲線の設計が刷新された。Log C4では対数曲線のガンマ(傾き)がEIによらず一定であり、EIに応じて変化するのはセンサー信号に乗じるリニアゲイン係数のみである。Log C3では対数区間のパラメータ全体がEIごとに変動していたのに対し、Log C4のこの設計はVFXパイプラインでの取り扱いを大幅に簡素化した。Log C4はLog C3よりも広いダイナミックレンジ(17ストップ以上)に対応し、新しいARRI Wide Gamut 4(AWG4)色域と組み合わせて使用される。

Sony S-Log3

ソニーのS-Log3は、特性曲線の物理的意味で論じたCineonログ曲線の特性を踏襲して設計された。S-Log2が中間調から高輝度域の階調再現に優れていたのに対し、S-Log3はシャドー域からミッドトーンにかけての階調をCineonに近い特性で再現する。

S-Log3の設計上の特徴は、フィルムスキャンのワークフローとの互換性を重視した点にある。カラリストがフィルムネガのスキャンデータで培った経験則をそのままデジタルシネマに持ち込めるように、曲線の形状がCineonの特性に近づけられている。S-Log3はEI範囲全体で単一の変換式を使用する。S-Log2と比較してシャドーからミッドトーンにかけての階調配分が改善されており、同じセンサーのダイナミックレンジをより効率的に活用できる。

Panasonic V-Log

パナソニックのV-Logは、Cineonカーブに基づいて設計されたLog曲線であり、ARRI Log Cと類似した応答特性を持つ。V-Log LはGH4(有償ファームウェア)およびGH5以降の民生機にも搭載され、比較的小規模な制作環境でもLogワークフローへのアクセスを可能にした。

V-Logの特筆すべき点は、ARRI Log Cとの互換性を意識した設計にある。両者の曲線形状が類似しているため、ARRI用に作成されたLUTの一部がV-Log素材にも近似的に適用でき、マルチカメラ撮影時のカラーマッチングが容易になる。

Canon Log 3

キヤノンのCanon Log 3は、Cinema EOSシリーズ向けに設計されたLog曲線であり、Canon Log、Canon Log 2に続く第3世代にあたる。Canon Log 3はCanon Log 2とほぼ同等のダイナミックレンジ(約14+ストップ)を保持しつつ、シャドーからミッドトーンにかけての特性をCineon的な挙動に近づけている。8ビット収録でもバンディングが生じにくい設計が特徴であり、Canon Log 2が10ビット以上の収録を前提としていたのとは対照的だ。

各曲線の共通点と相違点

すべてのLog曲線に共通するのは、次の設計原理だ。

  • 対数関数をベースに、各ストップにほぼ均等なコード値を配分する
  • 低輝度域に線形区間を設けて、ノイズフロア付近の発散を防ぐ
  • 18%ミドルグレーの配置がカーブの中間域に来るように調整されている

相違点は主にパラメータの選択にある。各メーカーのセンサー特性、ノイズフロア、ダイナミックレンジに応じて、$a$ から $f$ の値が最適化されている。これらのパラメータの違いが、同じLog素材でもメーカーごとに異なる「色の癖」を生む。この癖を吸収し、共通の座標系に持ち込むのが、次に述べるACESの役割だ。

LUT(ルックアップテーブル)の数学

1D LUTと3D LUTの原理

LUT(Look-Up Table)は、入力値を事前に計算された出力値にマッピングするデータ構造だ。色変換の文脈では、ある色空間やトーンカーブから別のそれへの変換を、数学的な演算ではなくテーブル参照で実現する。

1D LUTは、R・G・B各チャンネルを独立に変換する。入力値 $r$ に対して出力値 $\text{LUT}[r]$ を返すだけの単純なテーブルだ。ガンマ補正やトーンカーブの適用は1D LUTで十分に実現できる。ただし、1D LUTではチャンネル間の相互作用を表現できない。たとえば「赤の値が高いときに青を抑える」といった変換は不可能だ。

3D LUTは、$(R, G, B)$ の三次元入力を $(R', G', B')$ の三次元出力にマッピングする。3D LUTの内部構造は、RGB空間を格子(ラティス)に分割し、各格子点に出力値を格納したものだ。

格子サイズが $n$ の3D LUTは $n^3$ 個のエントリを持つ。たとえば格子サイズ33の3D LUTは $33^3 = 35{,}937$ エントリである。格子サイズ65では $65^3 = 274{,}625$ エントリとなり、メモリ使用量は約8倍に増加する。

補間手法

入力値が格子点に正確に一致することはまれであるため、格子点間の値は補間で求める。主要な補間手法は以下の三つだ。

三線形補間(Trilinear Interpolation)は、入力点を含む最小の立方体(格子セル)の8頂点から、3軸方向に順次線形補間を行う方法だ。計算量は少ないが、精度は限定的である。

四面体補間(Tetrahedral Interpolation)は、格子セルを6つの四面体に分割し、入力点が属する四面体の4頂点から補間する。三線形補間が立方体の8頂点すべてを用いるのに対し、四面体補間は入力点が属する四面体の4頂点のみを用いる。三線形補間ではセル内部の対角面で補間関数の不連続が生じうるが、四面体補間ではこの不連続が構造的に回避されるため、格子点間の遷移が滑らかになり、バンディングが軽減される。現在の業務用カラーコレクタの多くがこの方式を採用している。

三次補間は、格子セルの周囲の点も含めた多数の点から三次多項式で補間する方法だ。精度は最も高いが、計算コストが大きい。

3D LUTの精度は格子サイズと補間手法の組み合わせで決まる。四面体補間は三線形補間と同等の品質をより小さな格子サイズで達成できるとされており、格子点間の遷移の滑らかさから、同じ格子サイズであれば四面体補間のほうがバンディングを抑制しやすい。

LUTの限界

3D LUTはあらゆる色変換を近似できる万能なツールだが、根本的な限界がある。LUTは離散的なテーブル参照であり、入力と出力の間の数学的構造を保持しない。色空間変換を3x3行列で正確に表現できる場合でも、LUTはそれを格子点と補間で近似しているにすぎない。格子の解像度が不足すると、階調の不連続やバンディングが生じる。

したがって、正確な数学的変換が利用できる場合(たとえばリニアな色空間変換やガンマ補正)は、LUTよりも解析的な数式で処理するほうが正確だ。LUTの真価は、解析的に記述困難な複雑なルック(フィルムエミュレーションやクリエイティブグレード)を効率的に適用できる点にある。

ACES(Academy Color Encoding System)

ACESとは何か

ACESは、アメリカ映画芸術科学アカデミーが開発したカラーマネジメント体系だ。異なるカメラ、異なるディスプレイ、異なるワークフローの間で、色情報を一貫して管理するための共通言語を提供する。

映画制作の現場では、同一のプロジェクト内でARRI、Sony、REDなど複数のカメラが使われることがある。各カメラは独自の色空間とLog曲線を持ち、素材ごとに色の特性が異なる。これらを統一的に扱い、最終的にどのディスプレイ(映画館のDCIプロジェクタ、家庭用テレビ、スマートフォン)にも適切に出力するためのフレームワークがACESだ。

ACESの色空間群

ACESは用途に応じて複数の色空間を定義している。すべてAP0またはAP1と呼ばれる原色セットに基づく。

ACES2065-1(AP0)は、ACESの最も広い色空間であり、アーカイブおよびデータ交換用に設計されている。AP0原色は色とは何かで導入したCIE標準観測者の等色関数が張る色度図のほぼ全域を包含するように選ばれており、人間が知覚可能なすべての色を正の座標で表現できる。エンコーディングはシーンリニア(線形)だ。

ACEScg(AP1, リニア)は、VFX/CGI作業用に設計された作業色空間だ。AP1原色はAP0よりも狭いが、実用上十分に広い色域を持つ。AP0が極端に広い色域を持つがゆえに数値的に不安定になりうる問題を回避するために、AP1が導入された。リニアエンコーディングであるため、ライティング計算やコンポジットなど物理的な光の演算に適している。

ACEScc(AP1, 純対数)は、カラーグレーディング用の対数色空間だ。AP1原色を対数関数で符号化しており、カラーコレクタのツール(リフト、ガンマ、ゲイン)が直感的に動作する。純粋な対数関数であり、黒付近にトー(toe)を持たない。

ACEScct(AP1, 対数+トー)は、ACESccの変種であり、黒付近にトーを追加したものだ。このトーにより、リフト操作(暗部の持ち上げ)の応答がフィルムスキャンのログ曲線(Cineon、ARRI Log Cなど)に近くなる。カラリストの多くがフィルム時代から蓄積してきた操作感覚をデジタルワークフローに持ち込めるように設計された。ACEScctはACES 1.0.3仕様で追加された。

ACEScctがACESccより「霧がかった(milky)」リフト応答を示すのは、トーの存在が黒近傍のコード値を持ち上げているためだ。ACESccでは純対数関数により黒が負のコード値まで深く沈むが、ACEScctではトーによって最小コード値が正の領域に持ち上がり、銀塩写真の化学で述べたフィルムネガのベース濃度(Dmin)に近い振る舞いをする。

ACESの変換パイプライン

ACESのワークフローは、次の段階的な変換で構成される。

  1. IDT(Input Device Transform): 各カメラの色空間からACES2065-1への変換
  2. 作業色空間への変換: ACES2065-1からACEScg(VFX用)またはACEScct/ACEScc(グレーディング用)への変換
  3. クリエイティブ処理: カラーグレーディング、VFX合成など
  4. RRT(Reference Rendering Transform): シーン参照データからディスプレイ参照データへの基本的なトーンマッピング
  5. ODT(Output Device Transform): 特定のディスプレイ特性に合わせた最終変換

ACES 1.1ではHDR出力向けにRRTとODTが「Output Transform」として統合され始め、ACES 2.0ではこのOutput Transformのレンダリングアルゴリズムが全面的に刷新された。

IDT(Input Device Transform)

IDTは、各カメラ固有の色空間とトーンカーブをACES2065-1色空間に変換する。数学的には、Log曲線のデコード(リニア化)と色空間変換行列の積で表される。

ARRI ALEXA 35のLog C4からACES2065-1への変換を例に取る。

$$ \mathbf{RGB}_{\text{ACES}} = M_{\text{ACES}} \cdot f^{-1}(\mathbf{RGB}_{\text{LogC4}}) $$

ここで $f^{-1}$ はLog C4のデコード関数(対数ドメインからリニアドメインへの逆変換)、$M_{\text{ACES}}$ はARRI Wide Gamut 4からACES AP0への $3 \times 3$ 色変換行列だ。

IDTの本質は「カメラの癖を消す」ことにある。異なるカメラの素材をすべてACESという共通座標系に持ち込むことで、カメラ間の色の差異が吸収される。IDTは各カメラメーカーが自社のセンサー特性に基づいて提供するのが一般的だ。

ODT(Output Device Transform)

ODTは、ACES色空間のデータを特定のディスプレイデバイスの特性に合わせて変換する。シーン参照のリニアデータには、現実世界の輝度範囲(0からほぼ無限大)が含まれうるが、ディスプレイの表示能力は有限だ。ODTはこのギャップを埋める。

具体的には、ODTは次の処理を行う。

  • トーンマッピング: シーンのダイナミックレンジをディスプレイの表示範囲に圧縮する。ハイライトのロールオフ(滑らかな飽和)とシャドーのトー(暗部の持ち上がり)を適用し、自然な見映えを実現する。
  • 色域マッピング: ACES AP0/AP1の広い色域をディスプレイの色域(Rec.709、DCI-P3、Rec.2020など)にマッピングする。色域外の色は知覚的に妥当な方法で色域内に収める。
  • 伝達関数の適用: ディスプレイの物理学で詳述したディスプレイの特性(ガンマ、PQ、HLGなど)に合わせた符号化を適用する。

同じACESマスターデータから、映画館向け(DCI-P3、ガンマ2.6)、家庭用テレビ向け(Rec.709、BT.1886)、HDRテレビ向け(Rec.2020、HDRとトーンマッピングの数学で導出したPQ ST 2084)など、異なるODTを適用するだけで複数の配信フォーマットを生成できる。これがACESの最大の実用的価値だ。

カラーグレーディングの信号処理

カラーグレーディングの基本操作であるリフト(Lift)、ガンマ(Gamma)、ゲイン(Gain)は、信号処理の観点から明確に定義できる。

ゲイン(Gain)

ゲインは信号に定数を乗じる操作だ。

$$ \text{out} = G \cdot \text{in} $$

$G > 1$ で画像全体が明るくなり、$G < 1$ で暗くなる。黒($\text{in} = 0$)はゲインによらず黒のまま保持される。ASC CDLにおける「Slope」がこれに対応する。

オフセット(Offset)

オフセットは信号に定数を加算する操作だ。

$$ \text{out} = \text{in} + O $$

$O > 0$ で画像全体が持ち上がり(黒が浮く)、$O < 0$ で全体が沈む。ASC CDLの「Offset」がこれに相当する。

パワー(Power / Gamma)

パワーは信号のべき乗を取る操作だ。

$$ \text{out} = \text{in}^{\,p} $$

$p < 1$ でミッドトーンが持ち上がり(画像が明るくなり)、$p > 1$ でミッドトーンが沈む。黒($\text{in} = 0$)と白($\text{in} = 1$)はパワーによらず固定される。これがASC CDLの「Power」であり、グレーディングツールの「Gamma」に対応する。

リフト、ガンマ、ゲイン(LGG)

ビデオグレーディングツールでは、上記のSOP(Slope, Offset, Power)とは異なる操作体系として「リフト、ガンマ、ゲイン」が広く使われている。

リフトは黒レベル(シャドー)を調整する。白のクリッピングポイントを固定したまま、黒のクリッピングレベルだけを上下させる。SOPのオフセットが全コード値を一様にシフトするのとは異なり、リフトはハイライトへの影響が小さく、シャドーに集中した操作だ。

ゲインはハイライトを調整する。黒レベルを固定したまま、白のクリッピングポイントを上下させる。SOPのスロープが黒レベルも連動して変化させるのとは異なり、ゲインはシャドーへの影響が小さい。

ガンマはミッドトーンを調整する。パワー関数と同様に、黒と白を固定したまま中間調の明るさを操作する。

LGGの挙動はASC CDLのSOP仕様には標準化されておらず、ソフトウェアやハードウェアの実装ごとに微妙に異なる。これは、LGGがビデオグレーディングの慣習から生まれた操作概念であり、厳密な数学的仕様に基づいて策定されたものではないことに起因する。

シーン参照とディスプレイ参照

カラーグレーディングのワークフローには、二つの根本的に異なるパラダイムがある。

ディスプレイ参照ワークフロー

歴史的に先に確立されたのはディスプレイ参照ワークフローだ。カメラの出力をまずディスプレイの色空間(Rec.709など)に変換し、その上でグレーディングを行う。

ディスプレイ参照の利点は、モニターに映っている画がそのまま最終出力に近いことだ。カラリストは「見たまま」の状態で作業できる。しかし、ディスプレイ変換の段階でシーンのダイナミックレンジが圧縮されてしまうため、グレーディングの自由度は制限される。ハイライトの飛びやシャドーの潰れは、変換時にすでに情報が失われている。

シーン参照ワークフロー

シーン参照ワークフローでは、カメラのLog/RAWデータをリニアまたはLog色空間のまま保持し、ディスプレイ変換(CST、LUT、ODT)をノードツリーの最終段階に配置する。グレーディングはディスプレイ変換の「手前」、つまりシーンの物理的な光情報が保持された状態で行われる。

この方式の本質的な利点は、グレーディング操作がシーンの元の情報に直接作用する点にある。ダイナミックレンジの圧縮はまだ行われていないため、ハイライトの復元やシャドーの詳細な操作に大きな余地がある。

ACESはシーン参照ワークフローの代表例だ。グレーディングはACEScctやACEScg(シーン参照色空間)で行い、Output Transformが最終段階でディスプレイ特性に合わせた変換を適用する。

DaVinci Resolveなどのグレーディングソフトでは、YRGB Color Managed(カラーマネージド)ワークフローがシーン参照に対応し、従来のYRGBワークフローがディスプレイ参照に対応する。シーン参照ワークフローでは、異なるカメラの素材を同じ作業色空間に統合でき、SDR/HDR/シネマなど複数の出力を一つのグレーディングセッションから生成できる。

シーン参照とディスプレイ参照の区別は、写真におけるクロマサブサンプリングで論じたRGBとY'CbCrの関係にも通じるものがある。どの座標系で処理を行うかによって、操作の物理的正しさと自由度が決定的に変わるのだ。

CDL(Color Decision List)

ASC CDLの数学

ASC CDL(American Society of Cinematographers Color Decision List)は、一次的な色補正のパラメータを標準化した規格だ。異なるメーカーの機器やソフトウェア間で、基本的な色補正の設定を正確に受け渡すために策定された。

CDLの数学は極めて単純だ。R、G、B各チャンネルに対して、3つの操作を順に適用する。

$$ \text{out} = (\text{in} \times S + O)^{\,P} $$

ここで $S$ はスロープ(Slope)、$O$ はオフセット(Offset)、$P$ はパワー(Power)であり、それぞれR、G、Bチャンネルごとに独立した値を持つ。合計9つのパラメータだ。

CDL 1.2仕様では10番目のパラメータとして彩度(Saturation)が追加された。彩度の適用はR、G、Bを組み合わせた演算であり、SOPの後に適用される。

$$ \text{luma} = 0.2126 \cdot R' + 0.7152 \cdot G' + 0.0722 \cdot B' $$

$$ \text{out}_c = \text{luma} + \text{Sat} \cdot (R'_c - \text{luma}) $$

ここで $R'$, $G'$, $B'$ はSOP処理後の値であり、ルマ係数はRec.709の輝度係数に一致する。彩度 $\text{Sat} = 1$ で変化なし、$\text{Sat} = 0$ で完全なモノクロ、$\text{Sat} > 1$ で彩度増強だ。

CDLの役割

CDLの力は、その単純さにある。わずか10個の数値で一次的な色補正が完全に記述できるため、撮影現場のDIT(Digital Imaging Technician)がセットでプレビューグレードを施し、そのパラメータをCDLファイルとしてポストプロダクションのカラリストに引き渡すことが可能になる。

CDLは一次的な色補正のみを扱い、セカンダリー補正(特定の色域やマスクに限定した調整)やノードベースの複雑なグレーディングは表現できない。その制約こそが互換性の源泉だ。

まとめ

Log収録とは、対数関数を用いてリニアな露光値を知覚的に均等な階調に再配分する符号化方式だ。リニア符号化が暗部の階調を構造的に浪費するのに対し、Log符号化は各ストップにほぼ均等なコード値を配分することで、限られたビット深度の中でダイナミックレンジを最大限に活用する。

ARRI Log C、Sony S-Log3、Panasonic V-Log、Canon Log 3はいずれも同一の数学的構造(対数区間と線形区間の区分的関数)を持ち、パラメータの設計思想のみが異なる。これらの差異を吸収し、共通の色空間で作業するための体系がACESだ。ACESはIDTで各カメラの色特性を標準色空間に変換し、ODT(Output Transform)で各ディスプレイの特性に合わせた出力を生成する。

カラーグレーディングの基本操作(リフト、ガンマ、ゲイン)は信号処理の基本的な演算(加算、乗算、べき乗)に還元でき、ASC CDLはその中核をわずか10個の数値で標準化している。シーン参照とディスプレイ参照という二つのワークフローの選択は、「どの座標系で処理を行うか」という問いであり、その決定がグレーディングの自由度と物理的正しさを規定する。

Log曲線もLUTもACESも、突き詰めれば「光という物理現象を、人間の知覚に合わせて、限られたビット深度の中に効率的に詰め込む」ための数学的な工夫だ。シネマカラーサイエンスが写真の物理学と共有しているのは、この根本的な問題意識にほかならない。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu