ストロボで動きが止まる物理的根拠と限界

Share

ストロボ(フラッシュ)を使えば動きが止まる。写真撮影における基本的な常識だが、閃光時間の実測値を確認すると、メカニカルシャッターの最高速や電子シャッターの速度と比べて意外と遅い。にもかかわらず、なぜストロボ撮影では被写体の動きが止まって見えるのか。本記事では、閃光時間の実測値とセンサー上の像移動量を定量的に計算し、「ストロボで動きが止まる」という現象の物理的根拠と限界を検証する。

閃光時間の定義

ストロボの閃光は瞬間的ではなく、急峻に立ち上がった後、減衰しながら持続する。この持続時間を表す指標として、国際標準化機構(ISO)の規格で以下の2つが定められている。

  • t0.5: ピーク強度の50%以上が維持される時間
  • t0.1: ピーク強度の10%以上が維持される時間

メーカーのカタログではt0.5が記載されることが多いが、t0.5はピーク付近の一部しか反映していない。t0.5の時間外にもなお相当量の光が放出されており、それが動体ブレに寄与する。実際の動体ブレを評価するには、t0.1の方が実態に即した指標である。

IGBT制御と出力による閃光時間の変化

現代のクリップオンストロボの多くはIGBT(絶縁ゲートバイポーラトランジスタ)で閃光管への通電を制御している。出力を下げる際にはIGBTが閃光管の放電を早期に遮断するため、出力が低いほど閃光時間が短くなる。

Canon 580EX、Nikon SB-80DX、Yongnuo YN560等の実測値(t0.1基準)を総合すると、IGBT制御のクリップオンストロボにおける目安は以下のとおりである。

  • 1/1出力: t0.1 ≈ 1/250〜1/310 s
  • 1/4出力: t0.1 ≈ 1/2000〜1/2800 s
  • 1/16出力: t0.1 ≈ 1/5200〜1/8000 s
  • 1/64出力: t0.1 ≈ 1/10000〜1/16000 s
  • 1/128出力: t0.1 ≈ 1/20000〜1/23000 s

注目すべきは、フル出力でのt0.1が1/250〜1/300 s程度と、一般的なX同調速度(1/200〜1/250 s)と大差ないほど遅い点である。一方、1/4出力以下にすればt0.1は1/2000 sを超え、動体のブレ抑制に実用的な速度となる。

なお、スタジオ用モノブロックストロボの中にはIGBTによるテール遮断を行わない電圧制御方式の機種があり、そうした機種では出力を下げてもt0.1がほとんど変化しない、あるいはむしろ長くなる場合がある。動体撮影に使用する場合はストロボの制御方式とt0.1の仕様を事前に確認すべきである。

センサー上の像移動量の計算

ストロボ光で動体ブレが生じるかどうかは、閃光時間中にセンサー上で被写体の像がどれだけ移動するかで決まる。環境光が無視できるストロボ主光源の撮影では、シャッター速度は動体ブレに関与せず、閃光時間が実質的な露光時間となる。

光軸に垂直な方向に速度 \(v\) で移動する被写体を、撮影距離 \(d\) 、焦点距離 \(f\) で撮影するとき、薄肉レンズ近似( \(d \gg f\) )でのセンサー上の像移動速度は以下のとおりである。

\[ v_{\text{sensor}} = \frac{f \cdot v}{d} \]

閃光時間 \(\Delta t\) における像移動量は次式で求められる。

\[ \Delta x = v_{\text{sensor}} \cdot \Delta t = \frac{f \cdot v}{d} \cdot \Delta t \]

計算例1: ポートレート撮影(歩行する被写体)

  • 被写体速度: 1.5 m/s(歩行)
  • 撮影距離: 3 m
  • 焦点距離: 85 mm
  • 閃光時間: t0.1 = 1/2500 s(1/4出力の典型値)

\[ \Delta x = \frac{85 \times 1.5}{3000} \times \frac{1}{2500} = 0.017 \text{ mm} = 17 \text{ μm} \]

フルサイズセンサー(横幅36 mm)で4500万画素(横約8200 px)を仮定すると、ピクセルピッチは約4.4 μmであり、この像移動量は約3.9ピクセルに相当する。

計算例2: 走行する被写体

同じ光学条件で、被写体速度を8 m/s(走行)に変更する。

\[ \Delta x = \frac{85 \times 8}{3000} \times \frac{1}{2500} = 0.091 \text{ mm} = 91 \text{ μm} \approx 21 \text{ px} \]

t0.1が1/2500 sであっても、走行する被写体では20ピクセル超のブレが生じうる。

計算例3: ステージ上のダンサー

  • 被写体速度: 3 m/s(激しい動き)
  • 撮影距離: 8 m
  • 焦点距離: 70 mm
  • 閃光時間: t0.1 = 1/2500 s

\[ \Delta x = \frac{70 \times 3}{8000} \times \frac{1}{2500} = 0.0105 \text{ mm} = 10.5 \text{ μm} \approx 2.4 \text{ px} \]

撮影距離が大きくなると像移動量は大幅に減少する。

なぜ「止まって見える」のか

上記の計算ではt0.1の全時間にわたって均一に光が照射される前提だが、実際にはいくつかの要因により、知覚されるブレは計算値よりも小さくなる。

閃光プロファイルの非均一性

ストロボの閃光強度は時間的に均一ではなく、ピーク直後に集中している。センサーに記録される像は、各時刻の光強度で重み付けされた合成である。ピーク付近の短い時間に大部分のエネルギーが集中するため、像の形成に実質的に寄与する「有効露光時間」はt0.5よりもさらに短くなる。t0.1で計算したブレ量は、実効的なブレの上限値とみなせる。

鑑賞条件による閾値

ブレが「見える」かどうかは、最終的な出力サイズと鑑賞距離に依存する。フルサイズセンサーにおける標準的な許容錯乱円は約30 μm(A4プリント、視距離25〜30 cm想定)である。計算例1の17 μmはこの閾値を下回る。

さらに、SNSやWeb用途では長辺1200〜2000 px程度にリサイズされることが一般的であり、センサー上の数ピクセルのブレは出力画像上で1ピクセル未満に縮小される。この条件下では、計算例2の21ピクセルのブレでさえ大幅に軽減される。

撮影技術の寄与

ダンスやスポーツのストロボ撮影では、ジャンプの頂点やターンの切り返しなど、被写体速度がほぼゼロになる瞬間を狙ってシャッターを切る技術が広く用いられている。被写体速度がゼロであれば閃光時間にかかわらずブレは発生しない。

ブレが問題になる条件

以下の条件が重なると、ストロボ撮影でもブレが顕在化する。

  • フル出力(1/1)での使用: t0.1が1/250〜1/300 s程度まで伸びる。歩行速度(1.5 m/s)でも85 mm / 3 mの条件で約170 μmのブレが生じ、許容錯乱円を大きく超える
  • 望遠レンズかつ近距離: 像倍率 $f/d$ が大きくなり、像移動量が増大する
  • 大判プリントや高解像度ディスプレイでの鑑賞: 許容錯乱円が実質的に小さくなり、微細なブレが視認可能になる

これらの条件に対応するために、Profoto等の高価格帯機種にはIGBTの制御を最適化したFreeze modeなどの高速閃光モードが搭載されている。高速閃光モードを備えた機種が高価格帯に集中しているのは、フル出力に近い光量を維持しながら閃光時間を短縮するには、大容量IGBTの高精度制御や放電回路の設計に高いコストがかかるためである。

まとめ

ストロボの閃光は物理的に「瞬間」ではなく、有限の持続時間を持つ。特にフル出力ではt0.1が1/300 s程度と、動体のブレ抑制には不十分な速度である。しかし、出力を下げることでt0.1が大幅に短縮されること、閃光プロファイルが非均一であること、一般的な鑑賞条件ではリサイズにより微細なブレが消失すること、そして撮影技術により被写体速度を最小化できることが組み合わさり、多くの実用的な撮影場面ではブレが知覚閾値を下回る。

「ストロボで動きが止まる」は無条件に成立する法則ではなく、出力設定、撮影条件、鑑賞条件に依存する近似的事実である。動体撮影で確実にブレを抑えたい場合は、出力を1/4以下に抑えてt0.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