fullseye

camera_orientation_from_sun_candidates — GEOCAM sun op

使い方

フレームごとに複数ある「明るい塊」の候補(太陽・白い車・標識・文字が混じる)から、時刻どおりに動く 1 本を RANSAC で選び、(yaw, pitch, roll) と焦点距離を同時に決める → table。固定カメラでは太陽だけが太陽の速さで動く ので、見た目で太陽を決めずに動きで決める(Fintraffic 天候カメラでは見た目の門が 24/24 誤検出だった、2026-09-21)。

仮説 = 時刻差 ≥ min_dt の 2 フレームから候補を 1 つずつ → camera_orientation_from_sun と同じ Wahba の 2 点解。道路カメラの事前知識(|roll| ≤ roll_max_deg、pitch が pitch_range_deg、水平画角が hfov_range_deg)を満たさない仮説は捨てる —— 自由度 4(回転 3 + 焦点距離)に対して候補が多いと、偶然の 3 点で 非物理な姿勢が通るため。票 = 予測位置から tol_px 以内に候補があるフレーム数(地平線下の時刻は投票しない)。実写のブルーム中心は 5〜13 px ぶれる(雲・露出)ので既定 20 px。最良仮説のインライアで焦点距離を 1 次元最適化し、回転を全点で引き直す(2 回)。

濡れた路面に映った太陽の反射も太陽の速さで動く(鏡像)ので、動きだけでは区別できない。反射は画像の下側(路面)に あるから、それを太陽として当てはめると「カメラが上を向く」姿勢(pitch > 0)になる —— 既定の pitch_range_deg の上限 0 は そのための門(道路カメラは上を向かない)。上を向くカメラなら広げること。独立な検算(車線の消失点の仰角 ≈ 0)も勧める。

K を渡せばそれを使う(焦点距離は探索しない)。K=None なら主点は画像中心、fx = fy = f を hfov_range_deg の範囲で探索する —— 公開カメラは内部パラメータが無いのが普通。

Args: candidates: (N, 2) の (u, v)。全フレームの候補を積んだもの(sun_bloom_fit や sun_pixel_position の出力)。 frame_index: (N,) 各候補がどのフレームか(unix_times の添字、整数値)。 unix_times: (F,) 各フレームの UNIX 秒(UTC)。 lat_deg, lon_deg: カメラの位置。 shape: (H, W)。 K: (fx, fy, cx, cy) か None。 Returns: table: yaw_deg / pitch_deg / roll_deg / f_px / hfov_deg / K(4,)/ inlier(N,、1 = 採用)/ n_inliers / n_frames / n_frames_with_candidates / residual_deg(採用点の角度残差 RMS)/ max_residual_deg / residual_px / loo_px(1 点抜き予測誤差の平均)/ loo_max_px / span_h (採用点の時間幅)/ n_hypotheses(事前知識を通った仮説の数)/ at_prior_bound(1 = 答えが事前知識の縁に張り付いている: 信用しない)。 Raises: ValueError: 候補が 2 フレーム未満、事前知識を通る仮説が無い、インライアが 3 未満。

詳しい使い方ガイド

参考(サンプルデータ・文献)

実行できる例(この op を実際に呼ぶ検証済みサンプル)

型が繋がる次の op(table を入力に取れる)

render_skyline_view · camera_orientation_from_skyline

同カテゴリ(sun)

sun_position · sun_pixel_position · camera_orientation_from_sun · sun_bloom_fit


Provenance: geocam.py — GEOCAM operator registry. この per-op ノートは tools/opdocs.py md が自動生成(手編集しない)。

© 2026 Kazufumi Furuse — Fullseye operator documentation. Licensed under Apache-2.0.