| 前のトピックを表示 :: 次のトピックを表示 |
| 投稿者 |
メッセージ |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Fri Dec 20, 2024 6:59 am 記事の件名: Re: しばらく前から気になっていることがいくつかありますが。 |
|
|
| ts007 wrote: | SonotaCoさん、しばらく前から気になっていることが3つかあります。
1つ目。V3.2以降ですが、添付画像のようにsmaskでdapixを変更しても青いマスクされる星の数が変わりません。調べてみたらV3.2以降からでした。操作方法は、同じにしていますのでソフト上の問題だと思います。
.....
とりあえず、1つ目は、現象がはっきりとしていてバージョンで確かめているのでよろしくお願いします。 |
V3.2というのはV4.32のことですね
smaskのパラメータは slev です。 これはV4.32で、smaskボタンと一緒に一段上に移動しています。
dapixは関係ありません。
| 説明: |
|
| ファイルサイズ: |
30.44 KB |
| 閲覧数: |
15238 回 |

|
| 説明: |
|
| ファイルサイズ: |
30.35 KB |
| 閲覧数: |
15238 回 |

|
|
|
| トップに戻る |
|
 |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Fri Dec 20, 2024 7:20 am 記事の件名: Re: 不具合報告 |
|
|
| 前田 wrote: | SonotaCoさんへ
前田です。
初めて起きた症状ですが、UFOAV4.32であるファイルを選択すると、
それだけで、UFOAが固まってしまい動かなくなりました。(砂時計がでて、他の操作はできる)
タスクマネージャーを見ると、内部では何か処理をしているようです。
Win10で64bitです。対象のクリップは1555MB の4K動画ですが、別のソフトでは正常に再生できます。また、これより大きなファイルでも正常に分析できます。
やはり、このファイルだけが壊れているのでしょうか。
ーーーー
ここに書かれていない新しいバージョンV4.33が公開されていますね。
そちらも試しましたが、同じ症状でした。
何か対処方法があれば、教えてください。 |
お送り頂いたクリップ一式で、症状がおそらく再現できたと思います。
クリップは形式的には正常なようです。
固まってしまうように見える原因は、キャプチャ時に検出された変化pixel (M.bmpにマークされている)が多すぎで、多くの操作でその処理に時間がかかっているだけのように思います。
普通変化検出点は数点から数10点程度なのですが、このクリップ4K画面全面に広がる綺麗なスペクトルがあるため、変化点数は数万点になっているようで、通常の1000倍程度時間がかかっている部分があるのだと思います。
個々の操作で1つ1つゆっくり待っていただけると進むと思うのですが、どうでしょうか。
対処方法があるかどうか検討してみますが、簡単には思いつかないかもしれません。
|
|
| トップに戻る |
|
 |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Fri Dec 20, 2024 9:40 am 記事の件名: Re: 不具合報告 |
|
|
4Kのスペクトル画像などで極めて多い変化点が検出されたクリップでUA4の処理時間が膨大にかかる件ですが...
原因はキャプチャ時の変化点数(今回の例では 422484点)に対してdapixで指定されている値(今回は216)の2乗に比例する回数(422484*216*216 = 約200億回)の処理を行っている点でした。
V4.32以降で導入したdapixは4K時のデフォルトは216になっているのでこうなります。
分析前にdapixを小さな値に設定することで処理時間は短くすることができます。
一度分析した後は M*A.XMLにdapixの値が保存されているので、これを小さくすると処理は速くなります。
具体的には以下のM20241214_224715_JPMZ1_HEA.XMLのdapixの値を216から2に変更すると十分高速になると思います。
場当たり的な処置ですが、とりあえずお試しください。
| 説明: |
| この "216" を "2"にテキストエディタで書き換えます |
|
| ファイルサイズ: |
143.41 KB |
| 閲覧数: |
15219 回 |

|
|
|
| トップに戻る |
|
 |
ts007
登録日: 2004.08.09 記事: 5763 所在地: 埼玉県川越市
|
日時: Fri Dec 20, 2024 5:46 pm 記事の件名: わかりました。 |
|
|
| SonotaCoさん。いつも素早い対応ありがとうございました。よく見たら、ずれていたのですね。習慣で同じ所をクリックしていたので、アイコン名まで確認していませんでした。確かにslevで星のレベルで納得です。疲れていて集中力が落ちていました。ありがとうございました。
|
|
| トップに戻る |
|
 |
前田
登録日: 2004.09.01 記事: 2884 所在地: Miyazai JAPAN (E131.4, N31.8)
|
日時: Fri Dec 20, 2024 10:03 pm 記事の件名: |
|
|
SonotaCoさんへ
前田です。
新しく導入されたパラメータdapixが、悪さをしていたので、これまでの、はでなスペクトルでも異常は起きなかったんですね。
指示通り書き換えると正常に処理できました。
ありがとうございます。
|
|
| トップに戻る |
|
 |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Sun Feb 16, 2025 11:08 am 記事の件名: UA4 V4.35 |
|
|
ジオイド高設定に対応して以下を変更したUFOAnalyzerV4 V4.35 をリリースしました。
1)profileシートにジオイド港 gioidh 欄を追加し、tz欄の位置を移動した。
2)UFOCaptureHD2の出力のM*xmlに gioidh の値がある場合、これを読み込むこととした。ない場合は gioidhを0.0とした(従来と同一の結果となる)。
3)MCSVにgioidhを追加し、MCSVのレコードバージョンをR05B28Gに変更した
4)clicksにgioidhとddegを追加し、SpriteAnalyzerV4にジオイド高を伝えるとともに、観測誤差に基づく自動誤差計算を可能とした。
5)観測地点間距離計算を近似式からWGS84準拠の地心直行座標上の計算に変更した。
(V4.35は既存バージョンの上書きで設定値を引き継ぐことができます。)
gioid高は国内では30m-55m程で通常の計算結果には殆ど影響しません。4K画像同士の組み合わせによるTLE高度測定など精度の高い高度計算が必要な場合にご使用ください。
しかしながら、MCSVは長年に渡り蓄積、再計算される情報ですので、可能であれば早めの移行をお願いします。
ジオイド高設定には以下のサイトで観測点のジオイド高を調べ UFOCaptureHD2 V486以降のprofile設定で設定してください。
(UFOCaptureV2では設定できません。UFOCaptureHD2は1K解像度まではUFOCaptureV2のライセンスキーで動作可能です)
https://vldb.gsi.go.jp/sokuchi/surveycalc/geoid/calcgh/calc_f.html
なお、UFOシリーズ上のAltitude(m)(標高または海抜)には従来通り、観測地の標高+ カメラの地面からの高さ を設定してください。観測地の標高は以下のサイトで地図上の等高線から読み取ってください。
https://maps.gsi.go.jp/
|
|
| トップに戻る |
|
 |
前田
登録日: 2004.09.01 記事: 2884 所在地: Miyazai JAPAN (E131.4, N31.8)
|
日時: Tue Aug 26, 2025 9:40 am 記事の件名: 解析できないケース |
|
|
SonotaCoさんへ
前田です。
4KスペクトルのビデオをUFOAnlyzerV4 V4.34(64bit)で解析した場合に、
上の2024年11月のケースと類似して、解析できないクリップが発生しました。
やはり、変化点がすごく多そうなクリップです。
今回は、1回目の解析が終了せず、
*A.XLMが
生成されません。そのため、前回のdapixを書き換える方法で、対処できません。
ただし、*L.csvは、生成されています。
30秒ぐらい放置しておくと下の画面のようなサブウインドウのようなものが
表示されましたが、やはり、砂時計が回ったままで、反応がなく、タスクの終了でしか、終れません。
何か、対策はあるでしょうか。
| 説明: |
|
| ファイルサイズ: |
1.01 MB |
| 閲覧数: |
1889 回 |

|
|
|
| トップに戻る |
|
 |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Tue Aug 26, 2025 11:46 am 記事の件名: Re: 解析できないケース |
|
|
| 前田 wrote: | 今回は、1回目の解析が終了せず、
*A.XLMが
生成されません。そのため、前回のdapixを書き換える方法で、対処できません。
|
AXMLがない場合にはUA4のディレクトリ視程でデフォルトのprofileとして指定している p*.XMLから dapixの値が読み込まれています。
従って分析時に指定している p*..XMLの中のdapixの値を変更すればよいと思います。
profileが古いバージョンで作らていてdapixがない場合には以下のように dapixを追加すればそれが読み込まれます。
今後のため最近のUA4で小さいdapixを指定してprofileを作り直しておくと良いかもしれません。
読み込まれているかは MaskEditor の auto の中央付近のdapix表示で確認できます
うまくいくでしょうか。
| 説明: |
| dapixの項のついか (先頭にスペースが必要です) |
|
| ファイルサイズ: |
110.08 KB |
| 閲覧数: |
1883 回 |

|
|
|
| トップに戻る |
|
 |
前田
登録日: 2004.09.01 記事: 2884 所在地: Miyazai JAPAN (E131.4, N31.8)
|
日時: Wed Aug 27, 2025 6:52 am 記事の件名: |
|
|
SonotaCoさんへ
前田です。
指示の方法で、dapixを50にして、うまく解析できました。ありがとうございます。
>読み込まれているかは MaskEditor の auto の中央付近のdapix表示で確認できます
これは、使ったことなくて、知らなかったのですが、ここでdapixを変化させても、読み込まれた値が優先されるので、意味がないんですね。
では、どんな時に使うのでしょうか。簡単なら、教えてください。
|
|
| トップに戻る |
|
 |
SonotaCo Site Admin
登録日: 2004.08.07 記事: 13197 所在地: 139.67E 35.65N
|
日時: Wed Aug 27, 2025 7:16 am 記事の件名: |
|
|
| 前田 wrote: | >読み込まれているかは MaskEditor の auto の中央付近のdapix表示で確認できます
これは、使ったことなくて、知らなかったのですが、ここでdapixを変化させても、読み込まれた値が優先されるので、意味がないんですね。
では、どんな時に使うのでしょうか。簡単なら、教えてください。 |
dapixを指定直後にAボタンでそのクリップを分析すればその値が使用されます。
dapixを変化させた後に別の分析済のクリップへ移ってしまうと移ったクリップのAXMLに記憶されている値が読み込まれて上書きされてしまいます。
本来は、ここで指定してSavePしてprofileを作り、以降そのprofileを使うようにしてその後の新しい分析のデフォルトとして使用するためのものです。
|
|
| トップに戻る |
|
 |
前田
登録日: 2004.09.01 記事: 2884 所在地: Miyazai JAPAN (E131.4, N31.8)
|
日時: Thu Aug 28, 2025 10:08 pm 記事の件名: |
|
|
SonotaCoさんへ
前田です。
解説ありがとうございます。
たしかに、今回の未解析のクリップを試しに1つだけフォルダーに入れて読み込むと
読み込んだ時点で、ハングアップしてしまい、解析ができませんでした。
わざわざ、プロファイルの方を修正しないといけないわけがわかりました。
|
|
| トップに戻る |
|
 |
|