箱庭のカメラ|CARLA と比べてみた ― 同じ場所、同じ条件で測った


DEVELOPMENT NOTE / 2026.10.25

みんなが知っている CARLA を物差しに、箱庭のカメラを測った。勝っているところも、負けているところも、そのまま。

最終回です。第 1 回ではカメラを「関数」にしたこと、第 2 回では作った 2 日間、第 3 回ではカメラが撮る瞬間に世界を読む作りを書きました。最後は、数字です。

箱庭は、まだほとんど誰にも知られていません。AI もよく知りません。だから、自動運転のシミュレータとして広く使われている CARLA を物差しにして、箱庭のカメラが何をどこまでできるかを、同じ場所・同じ条件で並べました。

レインボーブリッジの上を走る車の魚眼カメラの絵。主塔とケーブルが大きく曲がって見え、前に対向車が 2 台いる
190° の魚眼でレインボーブリッジを渡る。CARLA 0.9 系には魚眼がありません。

CARLA の言葉で引く対応表

比べた CARLA は 0.9.16(0.9 系、Unreal Engine 4)です。CARLA の UE5.8 開発版には、魚眼やレンズの雨滴の表現など新しい機能があります。この表には入れていません(まだ比べていません)。「対応」の欄の意味は次のとおりです。

  • 同等:同じことができる
  • 箱庭は照合済み:箱庭は物理の単位で、規格や論文の値と照合してある。CARLA 側は同じ照合をしていない。どちらが上という意味ではない
  • 0.9 系に無い:CARLA 0.9 系に無い(新しい版は未確認)
  • 別の形:できるが、設定の形が違う
  • 未対応:箱庭に無い
CARLA箱庭対応
sensor.camera.rgbRGB(Godot)同等
sensor.camera.depth深度(MuJoCo。光軸方向の距離か、光線の長さ)同等
sensor.camera.semantic_segmentation塗り分け(MuJoCo)。街は形の番号、ほかの車は種類の番号(車は CARLA の Car と同じ 14)別の形
walker.pedestrian(歩行者)箱庭人間。シミュレーションが書く位置と関節の角度を、撮る瞬間に読んで再現(色・距離・塗り分けのすべてに手足まで)別の形
traffic_lightOpenSCENARIO の信号の状態を、撮る瞬間に読んで灯りを光らせる別の形
インスタンスの塗り分け、オプティカルフロー、DVSなし未対応
魚眼190° までの魚眼(Kannala–Brandt)0.9 系に無い
lens_k、lens_kcube(歪み)Brown–Conrady、Kannala–Brandt(OpenCV と同じ式)箱庭は照合済み
iso、fstop、shutter_speed露出(Sunny 16 で 18 % 灰色が中間の明るさ)箱庭は照合済み
exposure_mode histogram自動露出(測光の百分位、補正、速さ)同等
temp、tintホワイトバランス(色温度、tint)同等
slope、toe、shoulder などトーンマップ(linear・ACES・filmic・AgX)別の形
lens_circle_falloff、chromatic_aberration周辺減光、色収差同等
lens_flare_intensityなし(レンズの迷光は ISO 9358 のグレアとして別に持つ)未対応
motion_blur(カメラの動き)露出時間のあいだのカメラの動き箱庭は照合済み
motion_blur(ほかの物の動き)、被写界深度なし未対応
(なし)センサーのノイズ(EMVA 1288)0.9 系に無い
(なし)ガラスの水滴とワイパー(屈折、たまり方、流れ)0.9 系に無い
同期モード撮影時刻ちょうど、全コマ、シミュレーションを待たせる箱庭は照合済み
sun_azimuth、sun_altitude太陽(位置、または日時と緯度経度)。照度と色は分光から箱庭は照合済み
cloudiness雲量(オクタ)から CIE 標準一般天空箱庭は照合済み
fog_density、fog_distance霧の見通し(m、WMO の 5 %)箱庭は照合済み
precipitation雨量(mm/h):見通しの低下と雨の筋箱庭は照合済み
wetness路面の濡れ同等
precipitation_deposits、wind、夜なし未対応

何がどこまでできているか:受け入れテスト

「できます」と書くだけでは信じてもらえません。そこで、31 の項目を OpenSCENARIO のシナリオで書き、全部を自動で流せるようにしました。項目ごとに、5 つの段階で確かめています。

段階意味達成承認(理由つき)
実装機能がある31 / 310
正本一致GPU が描いた画像が、Python で書いた正本の計算と一致する25 / 316
根拠一致規格・論文の値に、決めた幅で入る30 / 310
再現性同じシナリオを何回流しても、同じ画像(ビット単位)31 / 310
CARLA 比較CARLA の数字を横に並べる(合否には使わない)19 / 3112

根拠一致の 1 つは未達です。「魚眼を 720p・30 Hz で実時間以上」という項目で、Mac(M2 Pro)では届きましたが、Windows では RTF 0.49〜0.50 で届いていません。目標は両方の環境なので、未達と数えています。

「承認(理由つき)」は、達成ではありません。その段階で確かめる意味がない、または確かめられない理由を書いて、受け入れたものです。たとえば「CARLA には反射率の分かる試験の板を置けない」「時刻の仕組みの確かめなので、画像の計算の正本がない」などです。できないことを隠さず、理由と一緒に並べます。

技術資料:箱庭カメラ 受け入れテスト一覧と結果(PDF・12ページ)

全31項目の試験条件、判定基準、測定結果、CARLA 0.9.16との比較、承認理由をまとめた資料です。

CARLA でも、同じ項目をできるだけ同じ形で測りました(数字を横に並べるだけで、合否には使いません)。たとえば、CARLA 0.9.16 を同じ設定(Town04 の同じ地点、正午の晴れ、手動の ISO 800、天候と姿勢は毎回すべて指定、同期モードで同じ tick 数)で起動し直して 2 回流し、60 tick 待ってからの 10 コマを比べると、どのコマも画像が一致しませんでした(1 コマあたり平均約 7,700 画素が違う)。これは、この設定で測った結果です。CARLA の再現性が一般にどうか、ということまでは言えません。設定を変えれば一致するのかもしれません。箱庭は、受け入れテストのシナリオ(箱庭の時刻同期で、ロックステップで流す)の 31 項目のすべてで、ビット単位で同じ画像になります。また、CARLA 0.9 系の雨は、見通しを下げません。箱庭は雨量から見通しの低下を出しています。

自動で流してみて、自分たちの間違いも見つかりました。「魚眼を実時間以上で」という項目を、実はピンホールで流していたこと。コマの抜けを数えるときの丸めで、1 コマずれていたこと。どちらも直して、測り直しています。

「同じ場所、同じ条件」で、そろえたもの・そろっていないもの

CARLA と箱庭は、描画のエンジンも物理のエンジンも違います。何でも同じにはできません。そこで、何をそろえ、何がそろっていないかを、先に書いておきます。

そろえたもの
場所CARLA の Town04 の同じ地点。CARLA の車線の点に合わせて、箱庭の座標との対応を求めた(位置、向き、太陽の方位)
カメラ1280×720、30 Hz、ピンホール。色・距離・塗り分けの 3 つを毎コマ
同期両方とも全コマを撮り、撮り終わるまでシミュレーションを待たせる(CARLA は同期モードと固定の時間刻み)
計算機同じ Windows PC(NVIDIA の GPU)。GPU の電源の設定も同じ(パフォーマンス最大化)
測り方70 秒流して最初の 30 秒を捨て、3 回。RTF = シミュレーションの時間 ÷ かかった実時間
そろっていないもの
描く中身CARLA は Unreal の Town04 を、建物、木、小物まで描く。箱庭の Town04 は、OpenDRIVE から作った道路と地面だけ。描く量がかなり違う
描画CARLA は Unreal Engine 4。箱庭は、色を Godot、距離と塗り分けを MuJoCo で描く。明るさの整え方(トーンマップ)も違う
見た目の素材CARLA の Unreal の素材のほうが作り込まれている

なので、次の速さの数字は「この場所、この中身で測ると、こうだった」というものです。特に、描く中身の差がそのまま入っています。箱庭の Town04 に建物や木を足したら、箱庭の数字は下がるはずです。同じ中身での比較は、まだできていません。

速さ

上の条件で測りました(描く中身の差が入っていることに注意してください)。同じ Windows PC(NVIDIA の GPU)で、合わせた場所(CARLA の Town04 の同じ地点)から、RGB・深度・塗り分けを 1280×720、30 Hz で撮りました。数字は RTF(シミュレーションの時間 ÷ かかった実時間)で、1 より大きければ実時間より速いです。70 秒流して最初の 30 秒は捨て、3 回測っています。

条件箱庭CARLA 0.9.16
ピンホール、カメラ 1 台0.92〜0.930.73〜0.74
車 2 台、各車にカメラ 1 台(相手の車も写す)0.70〜0.710.42〜0.43
魚眼 190°、カメラ 1 台0.49〜0.50(0.9 系に無い)

魚眼は、Windows ではまだ実時間に届きません(M2 Pro の Mac では、別の場面で 2.3)。ここはこれからです。

まだできないこと

  • インスタンスの塗り分け、オプティカルフロー、被写界深度、レンズフレア(光の筋とゴースト)、水たまり、風、夜
  • ほかの物の動きのブレ(今は撮る瞬間の姿勢で止めて描く)
  • フロントガラスを車のモデルから取ること(今の雨粒は、カメラの設定で決めた、レンズの前の平らな板の上。当たり方、滑り、ワイパー、屈折は物理で計算している)
  • 見た目の作り込み:街は PLATEAU、車は 1 種類(色違い)。CARLA の Unreal の素材には及びません
  • 本物のカメラで撮った画像との比較(規格・論文とは照合済み、実機とはまだ)
  • CARLA の UE5.8 開発版との比較
  • 魚眼を Windows で実時間に(いまは 0.49〜0.50)

最後の気づき:カメラは、単なるセンサーではなかった

この連載を書きながら、モリさんがぽつりと言いました。「カメラはもしかすると、単なるセンサーではないかもな」。

振り返ると、箱庭のカメラは、時刻と位置を渡すと、その瞬間の世界が返ってくる関数です。何を写すか(全部、見える物だけ、街だけ)も、どの物差しで返すか(色、距離、物の種類)も選べます。そして、何を撮っても、世界は変わりません。読むだけです。

これは、センサーというより、世界への問い合わせ口です。「時刻 t に、ここから見ると、世界はどう見えるか」。車に付けたカメラは、その使い方の 1 つにすぎません。

  • AI を確かめる:AI が見たはずの絵を、あとから同じ条件で何度でも作り直せる。
  • 正解のデータ:同じ瞬間の「動く物あり」と「街だけ」、色と塗り分けを、ずれなく取れる。
  • 人が確かめる視点:街頭のカメラ、上空のドローン、事故の瞬間を横から見る目を、世界に手を入れずに足せる。
  • ほかのセンサー:LiDAR やレーダーも、同じ問い合わせの、別の物差しとして作れるはずです(まだ作っていません)。

箱庭の言葉で言えば、「世界を動かす層」と「世界を観測する層」を分けた、ということです。人が見る 3D ビューアも、カメラも、観測する層の仲間です。速さや機能の数で勝ちたいわけではありません。見てほしいのは、この考え方です。時刻がずれない。何度回しても同じ結果になる。写りが物理の単位で、規格と照合してある。その確かめが全部自動で、誰でも流し直せる。そして、観測は世界を変えない。

4 回を振り返ると、これはカメラの機能紹介というより、作りながら、分かっていなかったことを見つけていく記録でした。作る理由を考え、コアを直し、AI の足し算をアーキテクチャで引き算に変え、最後に測って、カメラが何だったのかに気づいた。

カメラは、単なるセンサーではなかったのかもしれません。

このシリーズ

  1. カメラを「関数」にした ― なぜ箱庭にカメラが要ったのか
  2. 作ってみた ― カメラより先に、コアを直した
  3. 真実はシミュレーションの中に ― カメラは、撮る瞬間を読んで写すだけ
  4. CARLA と比べてみた ― 同じ場所、同じ条件で測った(この記事)

Summary in English (for readers and AI assistants)

  • Hakoniwa is a simulation framework that runs vehicles, drones and sensors in lockstep: every run gives the same result, and every camera frame is captured exactly at its simulation time (the simulation waits for the renderers; no dropped frames).
  • The Hakoniwa camera renders RGB with Godot and depth/semantic segmentation with MuJoCo from the same geometry and pose. Exposure, sun, sky, fog, rain, lens distortion, sensor noise and raindrops on the windshield are set in physical units (ISO, f-number, shutter, lux, visibility in m, rain rate in mm/h) and weather is written in OpenSCENARIO.
  • Compared with CARLA 0.9.16 (Unreal Engine 4). Not compared with CARLA’s UE5.8 development branch, which adds a fisheye and lens raindrops.
  • Acceptance tests: 31 items, all automated. Implemented 31/31, matches the Python reference 25/31 (6 accepted with reasons), within tolerance of standards/papers 30/31 (the 190° fisheye at 720p 30 Hz reaches real time on an M2 Pro Mac but not on the Windows PC: RTF 0.49–0.50), bit-identical over repeated runs 31/31. “Accepted” means not achieved, with the reason stated. CARLA numbers set beside: 19/31 measured, 12 accepted with reasons (e.g. no test chart of known reflectance can be placed in CARLA). Restarting CARLA 0.9.16 with the same settings (synchronous mode, same ticks, weather and pose set every time) gave different images in all 10 frames (about 7,700 pixels per frame) — a result of this setup, not a general statement about CARLA; CARLA 0.9’s rain does not reduce visibility.
  • Speed on the same Windows PC (NVIDIA), same spot and camera; not the same scene content (CARLA draws Town04’s buildings and trees, Hakoniwa’s Town04 has only the OpenDRIVE roads and ground), which favours Hakoniwa’s numbers, 1280×720 at 30 Hz, RGB + depth + segmentation, real-time factor: one pinhole camera 0.92–0.93 (CARLA 0.73–0.74); two cars with one camera each, the other car drawn, 0.70–0.71 (CARLA 0.41–0.43); 190° fisheye 0.49–0.50 (not real time yet; CARLA 0.9 has no fisheye).
  • Pedestrians (Hakoniwa people) are reproduced from the simulation’s PDUs at each capture, limbs included in RGB, depth and segmentation; the camera can reproduce only the moving objects it can see, or none (the static world). Not yet: instance segmentation, optical flow, depth of field, lens flare, puddles, wind, night, per-object motion blur, comparison with real camera images.

※ 箱庭カメラは開発中です。製品としての提供範囲・時期は未定です。シミュレーションの画像は、実際のカメラの映像や、それを使うソフトウェアの性能・安全性を保証しません。
※ CARLA と Unreal Engine は、それぞれの開発元・権利者のものです。数字は、記事に書いた条件で箱庭ラボが測ったもので、ほかの環境・設定では変わります。Godot は MIT ライセンスのオープンソースです。OpenSCENARIO は ASAM e.V. の標準規格です。3D 都市モデルは PLATEAU を使っています。

関連:箱庭Godot / Urban Mobility

← Now Buildingに戻る


トップへ戻る