パフォーマンス

フォルダーを開いたときに起きること

Fotollectionは写真フォルダーを丸ごと読み込みません。各ファイルから読むのはEXIF（日付、カメラ、撮影地）と、どのカメラもファイルに保存している小さなサムネイルだけです。1000枚で0.12秒、コードを書く前に決めた1秒の目標を大きく下回ります。その後バックグラウンドで、Fotollectionが軽快なままでいられるよう2つのスレッドで、より鮮明な400 pxのサムネイルを作ってディスクキャッシュに入れるので、もう一度開いたフォルダーはすぐに表示されます。5035枚では、読み込みに383 ms、埋め込みサムネイルに236 msかかりました。

プレビューの17 msの内訳

設定を変えると、プレビューはメモリー内にある写真の2048 pxコピーから描き直され、フルサイズのファイルからは決して描きません。所要時間16.7 msのうち、トリミングとLanczosフィルターでのリサイズが9.7 ms、日付が0.1 ms未満、画面用のプレビューJPEGエンコードが7.0 msです。このエンコーダーは測定しながら調整しました。書き出しと同じ設定（フルの色解像度と最適化したテーブル）では16.2 msかかりました。画面にはそれらは必要ないので、プレビューは色情報を半分にして標準テーブルを使い、書き出しはフルカラー（4:4:4）で作ります。もっと軽いリサイズフィルターも試しましたが、このプロセッサーではかえって遅く（12.5 ms）、Lanczosのままにしました。

ネイティブコードとブラウザー

同じ処理（デコード、2:3にトリミング、日付、品質95のJPEG）を、同じ95枚の写真で、FotollectionとChromium（コアごとに1つのワーカー）で実行しました。書き出しの速さは同じで、毎秒18.0枚対17.9枚。ブラウザーは遅いという最初の仮説は否定されました。ネイティブコードの強みは別のところにあります。ブラウザーのエンコーダーが色情報を半分にするのに対し、Fotollectionはフルの色解像度4:4:4でファイルを書き、各写真のカラープロファイルを保ち、ファイルをディスクに直接書き込み、メモリー使用量は4分の1少なく済みました（1.35 GB対1.78 GB）。その後、プリント用エンコーダーはさらに速くなり、16 MPで毎秒23.5枚です。

達成できなかった2つの目標と、見つかったこと

この20 MPのファイルでは、最初の実行で2つの目標を達成できませんでした。書き出しは毎秒7.6枚、メモリーのピークは2.14 GBで、2 GBの上限を超えていました。1枚の写真の各段階の時間を測ると、時間の行き先が分かりました。デコード約100 ms、トリミング2 ms、プリントのエンコード203 ms。プリント用エンコーダーは2回目のパスでテーブルを最適化しており、そのために画像のすべての係数をメモリーに保持していました。1枚あたり約160 MB、同時6枚で約1.5 GB、それでファイルが小さくなるのはわずか0.9% です。標準テーブルならファイルを帯状に書けます。138 ms、レンダリング画像に対する誤差は同じで、増えるのは数キロバイトだけです。

メモリーの一部は、そもそもFotollectionのものではありませんでした。ベンチマークはサムネイルを全コアで作っていましたが、Fotollectionは2つのバックグラウンドスレッドを使います。さらに自身のプレビュー測定を書き出し中も保持していました。Fotollectionと同じ動き方で測ると、書き出し開始前は0.35〜0.39 GBです。v0.9.7からは、同時に処理する枚数を書き出す中で最大の写真にも合わせる（非常に大きな写真なら減らす）ので、どんなサイズでもピークは上限を下回ります。このフォルダーでは毎秒10.1枚、1.31 GBです。

Web編集ツールからのプリントが平板に見える理由

テストでは、カメラの写真20枚と、そのDisplay P3版（最近のスマートフォンやMacの広い色空間）5枚をFotollectionの実際の書き出しで書き出し、両方のファイルを独立したデコーダーで読み込みます。カラープロファイルを通してCIELABに変換し、元の写真とピクセルごとに比べます。一般的なWeb編集ツールの書き出しにも同じ比較を行います。プロファイルを削除し、2000 pxに縮小してからプリント用に拡大し直し、品質80、色情報を半分（4:2:0）にして保存したものです。

平板に見える原因は2つです。2000 pxへの縮小とラボ用の再拡大で、プリントをシャープに見せる細部の87% が捨てられます。そしてカラープロファイルを削除すると、Display P3の写真をsRGBとして読むことになり、彩度の13% が失われます。Fotollectionはプロファイルを保持し（25ファイル中25）、写真のフル解像度、フルカラー（4:4:4）、品質95で書き出します（測定時の値。v0.13.0からの標準は90で、それでも見て分かる差を下回ります）。大きめの誤差は、どのJPEGも最も苦労するシャープなエッジにだけ現れます。今後の課題：実際のiPhoneのHEICファイルと、分光測色計で測ったプリント。

センサーが実際に記録しているもの

カメラのセンサーは、フォトサイト（photosite）と呼ばれる小さな井戸が何百万個も並んだ格子です。シャッターが開いている間、それぞれが当たった光を集めて電荷に変え、閉じると変換器が各電荷を数値にします。この関係はリニアで、光が2倍なら数値も2倍です。人の目はまったくリニアではなく、明るさを比率で判断します。だからRAWファイルは現像するまで暗く平板に見えるのです。

この格子を読み出すセンサーは2種類あります：

• CCD（charge-coupled device、電荷結合素子）は、各フォトサイトの電荷を1行ずつ、チップの端にある1つの増幅器へ送ります。初期のデジタルカメラや多くの初期の中判デジタルバックのセンサーで、画像はきれいですが、読み出しが遅く消費電力が大きいものでした。
• CMOS はフォトサイトごとに増幅器を持ち、多くを同時に読み出します。より速く、消費電力が少なく、安く作れるため、今ではほぼすべてのカメラとスマートフォンに使われています。多くのCMOSセンサーは行を順番に読み出すため、電子シャッターで撮った速い被写体が斜めに歪むことがあり（これがローリングシャッター）、はるかに速く読み出す積層型（stacked）センサーでは歪みが少なくなります。

この数値はJPEGよりずっと多くの段階を持ちます。カメラはフォトサイトごとに12または14ビット、つまり4096または16,384段階を記録し、JPEGが保つのは8ビット、256段階です。この余分な段階のおかげで、シャドウを持ち上げたり明るい空を抑えたりしても、トーンジャンプが出ません。そして光がないことはゼロでもありません。どのセンサーも、黒付近のノイズが切り捨てられないよう、小さなオフセット、つまりブラックレベルを加えます。Nikon D750のサンプルでは黒が600、センサーが記録できる最大値であるホワイトレベルが15,520です。どのRAW現像でも最初の仕事は、この2つの数値を0と1に合わせることで、カメラによってはカラーフィルターの位置ごとにブラックレベルが違うため、位置ごとに別々に行います。

色は各フォトサイトの上のフィルターから生まれる

フォトサイトが測るのは届いた光の量だけで、色は測りません。色を見るために、センサーはカラーフィルターアレイで覆われています。各フォトサイトの上に小さな赤、緑、青のフィルターがあり、それぞれがスペクトルの一部だけを数えます。

• Bayer 配列は、1976年にKodakのBryce Bayerが特許を取ったもので、2 × 2の正方形を繰り返します。赤1、緑2、青1です。フォトサイトの半分が緑なのは、人の目が細部の大部分をスペクトルの中央から感じ取るためで、緑がシャープさの大半を担います。ほぼすべてのカメラがこの配列を、4つの向き（RGGB、BGGR、GRBG、GBRG）のどれかで使い、その向きはファイルが示す必要があります。
• X-Trans はFujifilmが2012年から使う配列で、6 × 6の正方形を繰り返し、どの行とどの列にも赤、緑、青があります。不規則な配置のおかげで、細かい繰り返し模様に色モアレが出にくく、Fujifilmは多くのセンサーが備えるローパスフィルターを省けます。その代わり、再構成は難しくなります。
• その他の方式：モノクロセンサーにはフィルターがまったくなく、すべてのフォトサイトが細部をすべて捉えます（LeicaのMonochrom）。SigmaのFoveonはシリコンの深さごとに色を吸収する3層を重ねます。多くのスマートフォンは同じ色のフォトサイト4つをまとめ（Quad Bayer）、暗い場所ではひとつとして読み出します。

つまり24 MPのBayerセンサーは2400万個の数値を記録し、それぞれが1色だけです。どのピクセルも3色のうち2色が欠けています。このモザイクから画像を作るのがデモザイクの仕事で、下で説明します。

RAWファイルの中身

JPEGは完成した画像で、カメラがすでにすべての判断を下しています。RAWファイルは、その判断の前のセンサーの数値を、後で判断するために必要なものと一緒に保存しています：

• サンプルそのもの（フォトサイトごとに1つ）と、それぞれがどのカラーフィルターの下にあったか
• ブラックレベルとホワイトレベル
• 有効領域（光を受けたフォトサイト。周囲の数行と数列は黒を測るためにわざと覆われています）と、カメラのデフォルトのトリミング
• 撮影時にカメラが選んだホワイトバランス
• このセンサー固有の赤、緑、青が、人の見る色とどう対応するかを示すカラーマトリクス
• カメラ自身が自分の色とトーンで作ったJPEGのプレビューと、EXIFデータ

メーカーごとに独自の形式があり、多くはTIFFベースで、一部は非公開です。CR2とCR3（Canon）、NEF（Nikon）、ARW（Sony）、RW2（Panasonic）、ORF（Olympus）、RAF（Fujifilm）。DNG はAdobeが公開している形式（バージョン1.7）で、Ricoh、Leica、Pentax、多くのスマートフォンが使います。このページはその規則に従っています。

FotollectionはDNGを仕様から書いた独自のリーダーで読み、ほかの形式はFotollectionに組み込んだLGPLのライブラリーrawlerで展開します。グリッドのサムネイルはセンサーのデータにまったく触れず、ファイル内のプレビューから9〜32 msで作られます。だからRAWのフォルダーもJPEGのフォルダーと同じ速さで開くのです。

デモザイク：欠けた2色を計算する

各ピクセルで欠けている2色を周りから再構成することをデモザイクと呼び、RAW写真のシャープさとクリーンさを、ほかのどの工程よりも左右します。どの方法も同じジレンマを抱えています。周囲を平均すれば平坦な部分では安全ですが、エッジをまたぐと2つの異なる面が混ざります。どの隣同士が同じものに属するかを見極めることが腕の見せどころです。

• バイリニアは、各色の最も近いフォトサイトを単純に平均します。あらゆる方法の比較基準で、柔らかく、赤、緑、青をわずかに違う位置で平均するため、シャープなエッジに沿って色のにじみが出ます。
• Malvar–He–Cutler（2004年）はこの平均から始め、固定の5 × 5フィルターで、そのフォトサイトが見た色の細部を使って補正します。よりシャープで、しかも非常に高速です。Fotollectionはv0.10.0までこれで現像していました。
• PPG（patterned pixel grouping）は、まず画像の変化が最も少ない方向を判断し、その方向にだけ補間します。rawlerが使う方法で、v0.10.0まではWindows版とLinux版のFotollectionでもほとんどの形式に使っていました。
• RCD（ratio corrected demosaicing、Luis Sanz Rodríguezによる）は色の差ではなく比率で処理し、明るい部分でも暗い部分でも崩れにくく、細部でエラーが少ないことで知られています。darktableとRawTherapeeも備えています。
• Markesteijn はFrank MarkesteijnにちなむX-Trans用の方法で、1パス、またはより遅くクリーンな3パスで動きます。
• v0.10.0以降のFotollectionのデモザイクは、方向の判断をRCDから取り入れ、緑を両側から推定してその点自身の色で補正し（HamiltonとAdamsの方法）、それぞれの側の変化の大きさで重みづけします。最初にRCD自身の比率ステップを実装しましたが、テストチャートで成績が悪かったため、勝った方を独自の名前で出荷しています。

方法が推測を誤ると、4つの典型的な形で現れます：

• ジッパー：シャープなエッジに沿って明暗のピクセルが交互に並ぶ。方法がエッジの両側から隣を取ってしまったとき
• 迷路：平坦な部分に出る細かい虫食い状の模様。Bayerの正方形の2つの緑が完全には同じ値を読まないとき（隣接する色の違う行にあり、多くのセンサーで1〜2% ずれます）
• 偽色：実際は灰色の細部、たとえば布、髪、レンガの壁、遠くのフェンスに出る色の点やにじみ
• モアレ：カラーフィルターが標本化できるより細かい、非常に細かな繰り返し模様に出る色の波

評価の方法。人の目はシャープに見える結果にだまされやすいので、すべての方法を、正解が正確に分かっている画像で採点します。コンピューターが768 pxのテストチャートを5枚描きます。ゾーンプレート（外側に向かって細かくなり、緑のフォトサイトが保てる最も細かい細部に達する同心円）、72本のスポークのジーメンススター、灰色の上に3方向で置いた飽和色の帯、なめらかなグラデーション、そして2つの緑が2% ずれた平坦な灰色です。それぞれをBayerセンサーが記録するであろう形に変換し、デモザイクして、元の画像と比べます。PSNRは全体の誤差をデシベルで測ります（大きいほど良く、6 dBごとに誤差が半分）。偽色は灰色のチャートに現れる色の平均、エッジ誤差はエッジから2 px以内の平均誤差です。

Malvarは論文どおり、細かい灰色の細部でバイリニアより約4 dB優れていますが、強い色同士のエッジでは劣ります。補正がある色の細部をほかの色に借り、色が一緒に変化すると仮定するためで、灰色の壁の赤い看板はそうなりません。どちらも迷路を消せません。迷路はデモザイクの問題ではなく2つの緑の差で、その前にそろえておく必要があるからです。v0.10.0からの処理の流れは、こうした穴をふさぎます。各点がまだ測った値だけを持っているうちに固着ピクセルと緑のずれを直し、方向に応じたデモザイクで色を再構成し、色差に小さなメディアンをかけて残った偽色を消します。テストチャートではすべての項目で勝ち、例外はゾーンプレート全体のPSNRだけで、どの方法もエイリアスが出る最も細かい細部の近くでMalvarより0.8 dB低くなります。それでも偽色はそこでも半分になります。実際の9ファイルでは、どのBayer機の現像もカメラ自身のJPEGに同じかそれ以上近づき、24 MPで約180 msかかります。Malvarの40 msと比べて1枚あたり数十分の1秒長くなりますが、その分細部のきれいなプリントになります。

カメラの色からあなたの色へ

カメラの赤、緑、青は、画面の色と同じではありません。センサーごとにフィルターの色素が違い、人の目の錐体とは違う形で重なり合っています。ファイル内のカラーマトリクスがカメラの色を CIE XYZ（1931年に定められた人の色覚の標準モデル）に変換し、そこから多くの画面と写真ラボの色空間である sRGB に変換します。

• 最初はホワイトバランスです。赤と青にゲインをかけ、シーンで白いものがニュートラルに見えるようにします。カメラは選んだゲインを記録しており、Fotollectionはそれをデモザイクの前に適用するので、上の方法が使う色差は小さいままです。
• DNGはふつうマトリクスを2つ持っています。ひとつは暖かい白熱灯、もうひとつは昼光で測ったものです。写真に合うのはその間で、現像はホワイトバランスから撮影時の光を色温度として計算し、2つを混ぜます。Fotollectionはほかの形式でも、rawlerがカメラのモデルごとに知っているマトリクスで同じことをします。
• これはすべて、どのカーブよりも前に、センサー自身のスケール、つまりリニア光で行います。色の混合、スケーリング、リサイズはリニア光で行うと物理的に正しい結果になり、カーブの後で行うとエッジが暗くなり、色がずれます。

カメラ本来のルック。カメラ自身のJPEGはニュートラルではありません。どのメーカーも独自のコントラスト、色、肌のトーンを加えていて、そのルックは人がブランドを選ぶ理由の一部です。v0.10.0から、RAW写真はニュートラルな表示で開きます。センサーのマトリクスに忠実で、レンズの周辺減光とカメラが選んだ露出を反映したものです。Like the camera’s JPEG はRAW写真の RAW colour カードにあり、ワンクリックで1枚にも、すべてのRAWにも一度に適用できます。（v0.10.0までは、すべてのRAWをカメラのJPEGに合わせていました。当時保存したプロジェクトはそのルックを保ちます。）この選択は、カーブとマトリクス、またはチャンネルごとのカーブという2通りでカメラのJPEGに合わせ、そのファイルでより近づいた方を残します。Nikon D750では差が半分になり、ΔE2000で2.26から1.16になりました。グリッドのサムネイルは、Lightroomと同じくカメラ自身のプレビューを使います。

トーン：リニアな数値から画像へ

リニアな数値は画面で暗く色あせて見えます。光が2倍になると、センサーは2倍の数値として記録しますが、私たちには1段分明るくなったようにしか見えないからです。トーンカーブがセンサーのスケールを画像に変えます。中間グレーの位置を決め、シャドウを持ち上げ、ハイライトを一気に切らずになだらかに丸め、画像のコントラストを決めます。その後、画像はsRGBカーブ（いわゆる「ガンマ」）で保存され、JPEGの256段階のうち多くを、目が段差に最も敏感なシャドウに割り当てます。

カメラがJPEGで行う補正のうち2つはRAWデータに含まれておらず、どちらもプリントに影響します：

• 周辺減光：どのレンズも隅に向かって暗くなります。Fotollectionは、カメラが隅をどれだけ明るくしたかを、カメラ自身のプレビューから放射方向のゲインとして測ります。最初にDNGの現像をカメラのJPEGと比べたとき、中央は約4 L* 明るすぎ、隅は1.5暗すぎました。放射方向のゲインで差は ΔE 3.8から2.67に縮まり、写真のどの部分も ±0.5 L* 以内に収まりました。
• 歪曲：レンズのわずかな樽型や糸巻き型の歪みです。マイクロフォーサーズのカメラ（Panasonic、Olympus）はカメラ側で補正する前提で設計され、ファイルにその方法が記録されています。Macではこれらのファイルを補正を適用するmacOSが現像し、独自の現像での補正は予定しています（FR-085）。

FotollectionのRAW現像、ステップごと

プリントプレビュー、ズーム、書き出しの裏にあるフル現像では：

1. 判別：形式はファイル名ではなく先頭のバイトから判別するので、名前を変えたファイルや、ただのTIFFに見えるRAWも正しく読めます。
2. 読み込み：センサーの数値。DNGは独自のリーダーで、ほかの形式はrawlerで展開します。大きすぎるファイルや壊れたファイルは、1ピクセルもデコードする前にエラーコード付きで拒否します。
3. レベル：黒を0、白を1に。カラーフィルターの位置ごとに、有効領域の隅から数えて。
4. ホワイトバランス、続いてデモザイク：最初に固着ピクセルと緑のずれ、次に方向に応じたデモザイク、最後に偽色のメディアン（X-TransのMarkesteijnはv0.15.0で登場予定）。
5. 色：カメラのマトリクスを撮影時の光に合わせて混ぜ、リニア光で。
6. トーンとルック：カメラのプレビューに合わせ、周辺減光も含めて。
7. ここからはRAW写真もほかの写真と同じです。トリミング、日付、フレーム、プリントサイズ、カラープロファイル。フル解像度、4:4:4、品質95で書き出します。

いくつかの規則は全体を通して守られます。現像は一度に1つだけ、すべてのプロセッサーコアに分散して動き、ウィンドウ自身のスレッドでは決して動かないので、30 MPの写真を現像中でもFotollectionは反応します。書き出しは常にプロセッサーで行うので、プリントはどのコンピューターでも同じになります。グラフィックカードが速くするのは編集中に見えるものだけです。そしてコードは私たち自身のもので、ほかのプロジェクトからコピーせず、公開された仕様と論文から書き、検証しています。上の合成チャート、9機種のRAWファイル9点（CC0、raw.pixls.usより）、そしてファイルをわざと切り詰めたり壊したりして、壊れたファイルがクラッシュではなくエラーになることを確かめています。

v0.10.0から：すべてのBayer機に独自の現像。rawlerはファイルを展開するだけで、残りはFotollectionが行います。9つのサンプルファイルのフル現像、3回の中央値、同じノートパソコンで。よりクリーンなデモザイクを持つ私たちの現像と、rawlerのよりシンプルな方式、そしてmacOSの比較です：

私たちの現像は、よりクリーンなデモザイクと合わせ込んだ色のためにrawlerより0.1〜0.25秒長くかかりますが、ほとんどのカメラでmacOSより速いままです。現像は1枚につき1回だけで、その後はスライダーが保持したコピーを4〜11 msで処理し直します。Macでは、PanasonicとOlympusのファイルは、独自の現像が歪曲を補正できるようになるまで、レンズ補正のためmacOSのままです。S5のグレーのパッチはrawler経由よりもニュートラルになります（色のずれ1.42対2.43、0が完全なグレー）。次はMarkesteijnによるFujifilmのX-Trans、その後はプロセッサーの結果を基準にしたグラフィックカードでのプレビュー現像です。