ストリートビューの画像の水平について

Even if we upload an image that is properly leveled, processing within the Street View server can cause the image to tilt.

ストリートビューには画像の水平が取れていないものがたくさんありますよね。
私もそのようなストリートビューをたくさん作ってきました。

私のカメラが傾いていることによって傾いたストリートビューが作られるのであれば、私は画像の傾きについて責任を持たなければなりません。
しかし、ストリートビューの画像は、ストリートビューサーバー内での判断によって、私の意思に関わらずに回転させられています。

私が傾いた画像をアップロードした際には、その機能には助けられています。
しかし、私が正しく水平を保持した画像をアップロードしても、ストリートビューサーバー内での処理によって傾けられてしまう事態もあります。

以下は、不本意に傾けられてしまった写真の実例です。
このストリートビューは、ストリートビューアプリのVideoモードでアップロードして作成しました。
https://goo.gl/maps/tu4L68wBKoYkJLWQ9

2020年12月18日に上記のストリートビューを閲覧した際の様子を、キャプチャしました。

しかし元のVideoでは、上記のストリートビューの水平は、その時刻の前後も含めてほぼ正しい状態を保てています。

同じ場所のストリートビューを、静止画を撮影することによって作成しました。
https://goo.gl/maps/vkr9N3Jqf7mUUEFt6
THETA Z1で撮影した静止画は、撮影時に天頂補正がなされています。

この例では、ストリートビューアプリのVideoモードでアップロードした動画の処理において、画像が15度程度回転させられてしまっているようです。
なぜこのように回転させられてしまったか、その理由をいくつか推測しました。

(1)この写真内のみでの判断の場合
(1a) 輝度や色合いなどで空と地面との判断(水平線の判断)をしている

(2)前後のフレームとの比較による場合
(2a) 座標ごとの地面の標高が異なるのに、隣接フレームが同一水平面上にあるように「画像の繋がり」の処理がなされた
(2b) 座標ごとの地面の標高が異なるのに、隣接フレームが同一水平面上にあるように「地面が水平である」ような処理がなされた

たぶん、これらを複雑に考えて、ストリートビューサーバーとして「適切な水平」である方向へと変更されているのだと想像しますが、
うまく行っていない場合も多いです。


実例を見て検証していきます。

◆(例1) 瀬戸町の森林公園(静止画)前述のもの
https://goo.gl/maps/Q8f2PpVMqEZcM49j7

アップロード方法 : SV App、静止画
アップロードした画像の水平 : OK
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : たぶんOK。違和感感じず
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : OK

◆(例2) 瀬戸町の森林公園(動画)前述のもの
https://goo.gl/maps/FtkRnSMvdztAiBTV8

アップロード方法 : 2020年12月、SV App、Video
アップロードした画像の水平 : OK (元の動画 : https://youtu.be/QcMtuffbc-k?t=129 )
MapsWebでの見え方 : 青線のはず、現在は一時的に見えていない
MapsWebでの画像の水平 : NG(15度くらい傾いている)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG
Mapsアプリでの標高の取り扱い : OK(シェブロン矢印が水平になってしまっているが、画像が傾いていることによりほぼ正確に次の画像の方向を示せている)

◆(例3) 熊山駅
https://goo.gl/maps/ycLGbqAnXtqQ71dC8

アップロード方法 : 2018年2月、SV App、Video
アップロードした画像の水平 : NG(カメラを45度傾けて撮影した。元の動画 : https://youtu.be/vrxz630fvbU )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG(隣の写真が45度上下にずれている)

◆(例4) 金山寺
https://goo.gl/maps/yEqeEu1wMbQ5VvmW9

アップロード方法 : 2018年8月、SV App、Video
アップロードした画像の水平 : NG(カメラを90度傾けて撮影した。元の動画 : https://youtu.be/dPaAng1S10s?t=119 )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

◆(例5) 大瀬崎
https://goo.gl/maps/npEkovSj8yZ5RL4p7

アップロード方法 : 2018年3月、SV App、Video
アップロードした画像の水平 : OK(元の動画 : なし )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG
Mapsアプリでの標高の取り扱い : OK(緩い斜面なので細かい違いはわからない)

◆(例6) 寄島町ラウンドアバウト
https://goo.gl/maps/Eg3Nr5b8QkfwDk7b6

アップロード方法 : 2018年3月、SV App、Video
アップロードした画像の水平 : NG(元の動画 : https://youtu.be/qkN2Afg69f4?t=203 )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

◆(例7) 日吉大社1
https://goo.gl/maps/YVtr5FaP98wJrMNv6

アップロード方法 : 2019年1月、SV App、Video
アップロードした画像の水平 : NG(元の動画 : https://youtu.be/PZQ4f0ISyn8?t=20 )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元の動画のまま。たまたま一致しているだけかも知れません)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG
Mapsアプリでの標高の取り扱い : NG

◆(例8) 日吉大社2
https://goo.gl/maps/fi8NbuFUWzgKR8WD7

アップロード方法 : 2019年1月、SV App、Video
アップロードした画像の水平 : NG(元の動画 : https://youtu.be/8jAMpCCu6Wo?t=42 )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元の動画とは逆)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG
Mapsアプリでの標高の取り扱い : OK

◆(例9) 三江線1
https://goo.gl/maps/DKYLeLsskx2EVZ6aA

アップロード方法 : 2018年3月、SV App、Video
アップロードした画像の水平 : NG(元の動画 : https://youtu.be/pTuVODCB22c?t=88 )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元の動画より大きく傾いている)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG
Mapsアプリでの標高の取り扱い : NG

◆(例10) 三江線2
https://goo.gl/maps/DPTxqavkvCfaUkq39

アップロード方法 : 2018年3月、SV App、Video
アップロードした画像の水平 : NG(元の動画 : https://youtu.be/pTuVODCB22c?t=180 、上記と同じビデオです )
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

◆(例11) 鶴市トンネル
https://goo.gl/maps/zrwvQAN7s7cHgqt7A

アップロード方法 : 2018年7月、SV App、静止画(動画で撮影しましたが、私がフレームに分解してから、ストリートビューに静止画で提供しました)
アップロードした画像の水平 : OK
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : たぶん NG、トンネル内は水平なのに、画像があたかも山肌の地表面の標高に存在するように扱われている。パンケーキ型矢印の表示位置と、写真間移動の際のスムージング処理によって推測出来ます。
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG(シェブロン矢印は水平だが、アニメーションは標高差があるときの動きをする)

◆(例12) 小手島
https://goo.gl/maps/sBSJhdLCw7CGUtu18

アップロード方法 : 2018年5月、SV App、静止画
アップロードした画像の水平 : OK
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : OK

◆(例13) 小和田駅たかせはし
https://goo.gl/maps/ZN6cPLohCxgVGzyd8

アップロード方法 : 2018年3月、SV App、静止画
アップロードした画像の水平 : NG(カメラを45度傾かせている)
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

◆(例14) 象頭山
https://goo.gl/maps/91cqpeWWn437pEfV7

アップロード方法 : 2016年9月、SV App、静止画
アップロードした画像の水平 : NG(カメラを45度傾かせている)
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

◆(例15) 釈迦院御坂遊歩道3333段石段
https://goo.gl/maps/CrTmKikV6j6Wt23f9

アップロード方法 : 2018年11月、SV App、静止画
アップロードした画像の水平 : OK
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG(シェブロン矢印は水平になっている。しかし標高差があるのだから斜めに移動すべき)

結論 :
わけわからん。
処理の方法が日々異なっていて、中の人の手作業による判断も加わっていそうであると推測できるため、どのようにすれば高低差のある土地や左右の景色の差が大きい場所で正しく閲覧できるストリートビューを作成できるのかが私には全く分かりません。
しかし、私が適切な処理をしているならば、もしかしたら何年後かには正しくなっているかも知れません。そして、もしかしたらある日勝手に削除されているかも知れません。
すべて中の人の思し召し次第です。
青線化のロジックの異常ではなくて、SV Appのビデオモードの処理だけに発生している異常であるような気もします。

撮影時の条件も複雑です。
カメラが鉛直方向からずれた状態で撮影した場合、景色自体が水平判断を誤らせるような場合、そしてそれらの程度や時間軸上・空間上での変化の推移など、パラメータは多岐に渡ります。
とてもすべてを網羅した実験や経験は出来ません。
やはり、本来は処理方法の仕様を明らかにして欲しいと思います。

このように結論づけて、この考察を終わります。

新しいヘルプセンターに、この件を質問してみました。

https://www.facebook.com/groups/GoogleStreetViewTrustedPhotographers/permalink/1802724919903213/?comment_id=1809590145883357

おおまかには、以下のような推測ができます。
なお、今回の議論ではすべて、Google Maps Web で青線として表示されているSVについてのみ言及しています。

またもうひとつの前提(私の推測)として、画像の標高には、Google Maps Webでのその地点の地面の標高が採用されているようです。
橋の上で撮影した画像でも、その下の谷底が画像の標高として使われているようです。

◆SV AppからVideoモードでアップロードしたSV
カメラの移動方向(進行方向)が水平であるかのように回転させられます。
上り坂でも下り坂でも、自動車や自転車でその道を走った場合車体の向きが水平であるように回転させられます。
つまり、30度の上り坂の場合には、画像が、水平から30度傾くように回転させられてしまいます。

ただし、進行方向だけの情報では進行方向に垂直な方向(横方向)の水平の推測は出来ません。
横方向については、画像の内容によって水平の判断がなされているようです。

この「水平の判断」は、画像内のオブジェクトの情報は判別できていないと考えられます。
明るさなどの情報の変化が大きい方向が水平線の方向であるのだと簡易的に判断しているように感じています。

◆SV Appから静止画でアップロードしたSV
画像の内容で判断して、画像の水平が保たれるように回転させられるようです。
しかし、こちらの水平の判断のロジックは、動画の水平判断のロジックよりも優れているようです。人間が水平だと思う方向に近いものが採用されています。

事例を追加します。

◆(例16) ベタ踏み坂
https://goo.gl/maps/ao9fZNgdgVaq8S2H8

アップロード方法 : 2020年3月、SV App、Video
アップロードした画像の水平 : NG
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元のVideoの傾きと同じになっている)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG(元のVideoの傾きと同じになっている)
Mapsアプリでの標高の取り扱い : OK

◆(例17) 福岡空港東側の坂
https://goo.gl/maps/1Kuk38Cm3AYaWJk4A

アップロード方法 : 2019年3月、SV App、Video
アップロードした画像の水平 : NG
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元のVideoの傾きと同じになっている)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG(元のVideoの傾きと同じになっている)
Mapsアプリでの標高の取り扱い : OK

◆(例18) 東平尾公園の坂
https://goo.gl/maps/GMYcYBEnveSySEbx5

アップロード方法 : 2020年6月、SV App、Video
アップロードした画像の水平 : NG
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : NG(元のVideoの傾きと同じになっている)
MapsWebでの標高の取り扱い : OK
Mapsアプリでの画像の水平 : NG(元のVideoの傾きと同じになっている)
Mapsアプリでの標高の取り扱い : OK(少しあやしい)

◆(例19) 鳴淵ダム堤体
https://goo.gl/maps/8jbazZuoPMnqJu8X9

アップロード方法 : 2020年8月、SV App、Video
アップロードした画像の水平 : OK
MapsWebでの見え方 : 青線
MapsWebでの画像の水平 : OK
MapsWebでの標高の取り扱い : NG(水平に並んでいる画像間移動が、ダム堤体がない場合の地面の標高差に従って移動しているようにアニメーション処理されている)
Mapsアプリでの画像の水平 : OK
Mapsアプリでの標高の取り扱い : NG

Webでの矢印の向きは、画像の内容に対して正しいが、
矢印によって移動するときのアニメーションは、画像の内容での接続方向ではなくて、標高の情報に従って斜めに移動しているように感じます。

画像の水平に関する私のコメント(「Google Maps Help」)のリンクを貼っておきます。
https://support.google.com/maps/thread/19562629?msgid=20309322

On December 30, 2020, I received the following answer from SV Trusted Help:
“The engineers are looking into this issue. I will contact you as soon as I receive any update about it.”

And to date, I have not received any new contact regarding this matter.
So I urged them to answer again today.

I got an answer from SV Trusted Help.
It seems that their engineers are still investigating this matter.
And they have asked me for new examples of this symptom.
I have already provided enough specific examples so I can’t understand why new examples are needed.
I think this is just their strategy to waste my time and let me give up on my pursuit.

But I’ve also gotten a lot of examples of this symptom this year, so it’s easy to meet their demands.
I answered as follows :

Yes, the same symptoms are still occurring in the video processing yet, so I have as many concrete cases as I shot the slopes.
I kept the camera perpendicular to gravity, not to the slope when I had shot SVs below :

https://goo.gl/maps/S16BJvGPYgBKZqXZ8
https://goo.gl/maps/tSqjt728aMjq4HZ79
https://goo.gl/maps/pBLTmowYCJzQcVY67
https://goo.gl/maps/jhx5HYPq17BYy16s8
https://goo.gl/maps/JDDGbLcesDbptCMi6

As you can see, even if I keep the camera horizontal, there is no way to convey that horizontal information to the web version of the SV.

However, as per consultation number [9-7099000031350], in my environment, the SV App no longer recognizes THETA on all combinations of two smartphones and two THETA Z1s.
So, fortunately, it is impossible for me to have any new symptoms about this Topic, as I can’t shoot 360-degree Video with the SV App until the symptom is cured.

https://www.localguidesconnect.com/t5/General-Discussion/The-SV-App-stopped-recognizing-THETA-Z1/m-p/2855338#M1070714

“Because technicians need the latest information to investigate, please report a new example when you are able to shoot 360-degree videos with the SV app again.”
I received the answer from SV Trusted Help.

I understand that the answer means that they do not have any intention of examining the cases that can be confirmed at present at all.
They seem to buy time by even taking advantage of their other obstacle.

I made the request again as follows.

――――

Do you believe that the SV server creating a slanted SV like the current one is processing correctly, or are you aware that it’s wrong? First, give your views on that.
I feel that the examples I have shown so far are sufficient to understand the symptoms and that no newer examples are needed.

If you or the engineers don’t notice the anomaly when you look at the information I’ve sent or the URL link I sent in the last email, then your senses are out of sync with me.
In Video, the image that had the correct horizontal direction was purposely tilted by a mysterious process in the SV server and published on the Web.
And I have already sent you a guess of the cause of the tilt.

If you believe that tilting the image in the wrong direction, as it is now, is the right thing to do, then it’s totally useless for me to send you a new example.
But if you still don’t understand the symptom (the meaning of the case that I find it abnormal), I think it may be helpful to you to keep sending cases from me.

If so, I’ll send you a ton of new examples after I am able to shoot with the SV App again.

I got a reply from SV Trusted Help.
Since it is an important wording, I will quote it as it is.
「As you know, I can only relay the information that is passed on to me from the engineering or technical support teams. I am not the one who can resolve this issue. 」

I understood that they were just forwarding my email without understanding the nature of the failure.

I replied as follows :

OK, it’s the same as Vicl1 (your former leader in the SV Moderator era) said since last year that your organization doesn’t scrutinize or fix the content.
I understand the operating policy of your organization.
I also think that your organization’s consistent management way should be respected.

That fact means that you and the technicians have yet to determine whether what I’m pointing out is legitimate or off-target.
So, as I mentioned in the previous comment, I will continue to send cases to SV Trusted Help until you and the engineers understand the meaning of the case, according to your needs.

I received a thank-you reply.

「Thank you for your understanding. If you have any new information or you have encountered another issue, you can always send it to me and as usual I will forward it to our engineers.」

For SV created by video processing on the SV server, the zenith direction is determined from the content of the image (frame) itself.
So even if I upload a video that is swaying in the zenith direction, it will still create the correct zenith SV.

However, on slopes and places where the scenery varies greatly depending on the orientation, the SV server may make a mistake in determining the direction of the zenith.
It is not the difference caused by whether the shooting location is a road or a hiking trail. It also doesn’t matter if the direction of tilt coincides with the direction of travel of the camera or if it is 90 degrees sideways.

Even if the user keeps the camera exactly horizontal and shoots, the Street View server will change its zenith on its own.

The same set of photos were uploaded in two ways, the still image processing and the video processing, and the state of zenith correction is shown.

What was made into a blue line by Video processing (processed as a GoThru’s Blue Line type tour)
https://goo.gl/maps/w1eGS7qPnhSK6Ea3A

Uploaded by still image processing (processed as a Google Business type tour of GoThru)
https://goo.gl/maps/zG9GPDYWguT9hUMFA

I browsed these two on Google Maps Web and took a screen capture.

In this way, SV with still image processing becomes images with the zenith direction as I intended.
However, the SV created through the Video processing of the SV server misunderstands that the direction in which the stairs extend is horizontal as if it was judged that the hemisphere of the dark image is on the ground side and the hemisphere of the bright image is on the zenith side. Then they created SV with the wrong zenith direction.

This is a symptom that Video processing has been around since the early days when it was added to SV.
Example taken in March 2018: https://goo.gl/maps/EFMqNwpX83mWSBbz7

Example taken in January 2019: https://goo.gl/maps/owjsAfdcszjmWUFg9

In addition, the SV uploaded by Video is still undergoing minor correction work on the Google side, even after many years have passed since it was uploaded.
Here is an example where the zenith has been shifted in a worse direction than it was two years ago.
https://www.localguidesconnect.com/t5/General-Discussion/By-SV-changing-to-handle-the-POST-date-more-preferentially-than/m-p/3070379/highlight/true#M1189599

I reported these tilt issues to the Street View Trusted Help last December and encouraged them to improve.
https://www.facebook.com/groups/GoogleStreetViewTrustedPhotographers/permalink/1802724919903213/?comment_id=1809590145883357
https://www.localguidesconnect.com/t5/General-Discussion/ストリートビューの画像の水平について/m-p/2820814/highlight/true#M1051237

And after that, I urged them to answer several times.
Occasionally, I received answers like “Send us more cases to help engineers understand the symptoms.”
I have already shown them a large number of cases.
But even after more than eight months, I still haven’t received a meaningful answer.

I’m willing to receive the answer, “This is the correct feature of Street View.”
If this is a specification of Video processing, I can think of measures to prevent it.
But I’m disappointed by the Street View Trusted Help team and the engineers who have been neglecting the bug for more than half a year.

I’ll put a link to a related article.
https://www.localguidesconnect.com/t5/日本語/ストリートビューカーを作りました/m-p/704299#M2176
https://www.localguidesconnect.com/t5/General-Discussion/ストリートビューの画像の水平について/m-p/2819734#M1050648

勝手に傾けられてしまう事例を追加しました。
https://www.facebook.com/shotaro.igami/posts/4252019948240791?comment_id=4252112778231508

Finally, there was a case occurred where the image was tilted nearly 90 degrees.
https://www.localguidesconnect.com/t5/General-Discussion/Street-View-Video-Mode-AI-may-Rotates-Photos-90-Degrees-Wrongly/m-p/3153724/highlight/true#M1236177

In July 2022, I wrote the following sequel to this matter.
https://www.facebook.com/groups/GoogleStreetViewTrustedPhotographers/posts/2256412781201089/