星の光がフィルムに届くまで

Share

デジタルカメラで星空を撮るのは、ある意味で素直な作業だ。ISOを上げて、シャッターを開けて、センサーに光を溜める。露光時間を2倍にすれば、記録される光の量も2倍になる。比例関係がきちんと成り立つ。

フィルムでは、そうはいかない。

相反則不軌という厄介者

フィルムの感度には、教科書通りにいかない領域がある。相反則不軌(reciprocity failure)と呼ばれる現象だ。

通常、フィルムの露光は「光の強さ × 時間」で決まる。これを相反則(reciprocity law)という。ISO 400のフィルムで、ある絞りとシャッター速度の組み合わせが適正露出なら、光の強さを半分にしてシャッター速度を2倍にしても、同じ露出が得られるはずだ。

しかし、露光時間が長くなると、この法則が崩れる。フィルムの感光乳剤に含まれるハロゲン化銀の結晶は、光子を受け取って潜像核を形成するが、光子の到達間隔が長くなりすぎると、形成途中の潜像核が安定する前に崩壊してしまう。つまり、弱い光を長時間当てても、計算通りには感光しない。

星空撮影では、これが致命的に効いてくる。計算上は30秒で適正露出になるはずの場面でも、相反則不軌の補正を加えると、実際には2分、3分、場合によっては10分以上の露光が必要になることがある。

厄介なのは、この補正量がフィルムごとに異なることだ。Fujifilm Velvia 50は相反則不軌が比較的小さく、長秒露光に強い。Kodak Portra 400は中程度。Kodak Ektar 100は長秒で色がシフトしやすい。フィルムを選ぶ時点で、星空撮影の戦略が変わる。

銀粒子が作る光の滲み

フィルムで撮った星空には、デジタルにはない独特の質感がある。明るい星の周囲に、柔らかな光の滲みが現れるのだ。

これはハレーションと呼ばれる現象だ。フィルムの感光層を通過した光が、ベースフィルムの裏面や内部で反射し、再び感光層に戻ってくることで生じる。銀粒子が光を散乱させる効果も加わって、明るい点光源の周囲にぼんやりとした光の輪が生まれる。

デジタルセンサーではこの反射がほとんど起きないため、星は鋭い点として記録される。正確ではあるが、肉眼で見た星のまたたきの印象とはやや異なる。フィルムの滲みのほうが、むしろ見た目の記憶に近いと感じる人もいる。

CineStill 800Tというフィルムは、この効果を意図的に強調している。映画用フィルムからハレーション防止層(remjet)を除去して写真用に転用したもので、点光源の周囲に赤みを帯びた特徴的なハロが出る。街灯や信号機を撮ると派手に滲むことで知られているが、星空に使うと、明るい恒星の一つ一つが小さな光の花のように写る。

科学的な正確さとは無縁だが、フィルムで撮る星空の魅力はむしろそこにある。「正確に記録する」のではなく、「光を解釈する」媒体としてのフィルムの性格が、星空という被写体でもっとも際立つ。

大気のゆらぎ

星がまたたいて見えるのは、星自身が明滅しているからではない。大気のゆらぎだ。

シンチレーションと呼ばれるこの現象は、大気中の温度差によって屈折率が不均一になり、星からの光の経路が微細に変動することで起きる。地上に近い望遠鏡ほど大気の影響を強く受けるため、天文台が標高の高い乾燥した場所に建てられるのはこのためだ。

写真においては、シンチレーションは星像のにじみとして現れる。短い露光では星が点にならず微妙に広がり、長い露光では大気のゆらぎが平均化されてかえって均一な像になる。フィルムの場合、先述のハレーション効果と相まって、シンチレーションの影響が独特の柔らかさとして画面に残る。

夜空の暗さを測る

星空撮影の成否は、空の暗さに大きく左右される。デジタルであれフィルムであれ、それは変わらない。

Sky Quality Meter(SQM)という装置を使えば、夜空の明るさを数値化できる。単位は「等級毎平方秒角」で、数値が大きいほど暗い空を意味する。都市部ではSQM値が16から18程度、優れた観測地では21.5以上に達する。

ボートル・スケールと併せて使えば、撮影地の選定に役立つ。フィルム撮影では露光時間が長くなるぶん、光害の影響をより強く受ける。デジタルなら後処理である程度のかぶりを除去できるが、フィルムでは撮影時点で空の暗さが画質を決定する。

ピントという難題

フィルムカメラで星にピントを合わせるのは、想像以上に難しい。

まず、レンズの無限遠マークは当てにならない。多くのレンズで、無限遠マークの位置は実際の無限遠焦点と微妙にずれている。温度変化による金属部品の膨張、製造時の個体差、経年変化。理由は様々だが、マークを信じてそのまま撮ると、わずかにピントが外れた甘い星像になる。

デジタルカメラなら、ライブビューで明るい星を拡大してピントを追い込める。しかしフィルムカメラには背面液晶がない。光学ファインダーで星を確認しようにも、暗い星はファインダー越しにはほとんど見えない。

そこで使われるのが、アナログな手法だ。事前に明るい時間帯に遠景でピントを合わせ、その位置にテープでマーキングしておく。あるいは、レンズの前面に爪を当てて、そのわずかな感触を頼りに無限遠の位置を記憶しておく人もいる。現場で月や明るい惑星にピントを合わせてから構図を変えるという方法もある。

どれも、デジタル時代の感覚からすれば原始的に見える。しかし、この手探りの過程そのものが、フィルムで星空を撮る行為の本質的な部分でもある。レンズは一本でいいで書いた「制約が選択を減らし、集中を生む」という話と通じるものがある。選べないからこそ、残された手段に全神経を注ぐ。

不便さの先にあるもの

フィルムで星空を撮ることに、合理的な優位性はほとんどない。相反則不軌で露出計算は複雑になる。ピント合わせは困難を極める。その場で結果を確認できない。高感度フィルムは粒子が荒い。36枚撮りのフィルム1本で、撮れる枚数はデジタルの比ではない。

それでもフィルムで撮る人がいるのは、たぶん、不便さの中にしか生まれない何かがあるからだ。

シャッターを開けている数分間、カメラの横でじっと待つ。露出が合っているかは現像するまでわからない。その不確実さの中で、空を見上げている時間がある。デジタルで撮って背面液晶を確認して、また撮って、という反復作業とは違う種類の時間の使い方がそこにある。そこにいなかった人たちで書いたように、記録という行為は、その場にいることと引き換えに成り立つ側面がある。フィルムの長秒露光は、その引き換えを強制的に引き延ばすことで、逆説的に「その場にいる」時間を生み出している。

フィルムの銀粒子が散乱させた光は、デジタルのピクセルとは違う形で星空を記録する。それが「正しい」記録かどうかは、あまり重要ではない。自分の目で見た星空の記憶に、どちらが近いかという問いに、一般的な正解はないのだから。

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