-
Notifications
You must be signed in to change notification settings - Fork 42
ja_FAQ
IkaLog に関して使おうとした人がハマったケースや疑問などをまとめています。全部読むのは大変かもしれませんが、まずは太文字（Q）部分だけでも、何が書いてあるかを目を通しておくとよいでしょう。
任天堂の WiiU 用ソフト「スプラトゥーン」の画面をリアルタイム解析して、 いろいろなことができるソフトです。
- 勝ち／負け、ステージ、ルールを時系列にログファイルへ蓄積
- マッチ終了時のスクリーンショットを保存
- Twitter, Slack, stat.ink にプレイ状況をリアルタイム投稿
- アマレコTV, OBS などの録画ソフトの録画開始・停止を自動制御、ファイルをリネーム
動作原理を知りたい方は 「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側 まで。
C- から S+ まで幅広くご利用いただけます。
なお、2016年2月現在、レベル10未満でガチマッチの解放がされていないと（ガチマッチ解放後と画面表示形式が異なるため）ロビー種別の判定に失敗する不具合があります。とはいえレベル10未満で IkaLog が使えないわけでもありません。
IkaLog と stat.ink の関係は？
IkaLog は @hasegaw が開発をはじめたスプラトゥーンの画面解析ツールです。対して stat.ink は @fetus-hina が提供している Web ベースの戦績記録データベースです。 stat.ink については stat.inkのFAQ を見てみてください。
IkaLog は stat.ink をサポートしています。 IkaLog で認識したゲームの結果（スクリーンショット、詳細な情報）を stat.ink に投稿し、 stat.ink サイト上でそのゲームをレビューできます。
IkaLog自体は2015年6月頃にプロジェクトを開始し、8月に公開しました。 stat.ink は IkaLog （のようなツール）の戦績を記録するため2015年9月末に立ち上がりました。 IkaLog では、これと同時に stat.ink への投稿機能を追加しました。
現在の IkaLog は stat.ink との連携にフォーカスしており IkaLog の認識結果をフルに活用できるのは stat.ink と組み合わせた場合のみです。 IkaLog は stat.ink をアテにした作りになっています。同時に、 stat.ink では IkaLog から投稿したデータをベースにスプラトゥーンの各種統計情報をまとめています。
Windows、Mac、そしてLinuxで動きます。
推奨構成:
- SandyBridge (2011年発売) 以降のプロセッサ 最低2コア
動作報告があった構成
- IvyBridge 1.25GHz 2コア (開発者のMacBook Air)
- CPU: Core2Duo ( E4600 2.4GHz ), Memory: 8GB, HDD: 930GB, OS: Windows10
ひたすらレギュラーマッチ
性能に関する考慮点
- 使いたい機能や同居させたい処理によって負荷は変わります。 IkaLog 単体か、他のツール（アマレコ、OBS、FaceRig、その他ストリーミングソフトを実行する、など）
- Windows と Mac であれば Windows 上のほうがちょっとだけ負荷が低いようです (ビデオキャプチャやウインドウシステムのオーバーヘッドなどが主な理由かと思います）
フレームスキップについて
- 2016年1月26日までの IkaLog は、その環境で処理できる最大フレーム数を処理します。このため、とっても速いPCであれば、できるだけたくさん分析を試みるので IkaLog の負荷もあがっていました。
- 2016年1月28日版以降の IkaLog では負荷を下げるための対策が入りました。秒間10フレームを限度にフレームスキップを積極的に行います。
- 2016年1月28日版以降では、ユーザ報告によれば Core2Duo 2.4GHz 環境で、 IkaLog + アマレコの録画（コーデック不明）が共存できているとのこと。
Windows PC と組みあせて IkaLog を使いたいだけの方向けに WinIkaLog を用意しています。適当にダウンロードして動かせば、それなりに動くはずです。できるだけ簡単に済ませたい方は WinIkaLog の利用を検討してください。
IkaLog は GitHub上 でオープンソースプロジェクトとして開発されています。 Python 3.4 ベースで開発されており、依存ライブラリを揃えて、はじめて動作します。Windows 上でも、 Python+OpenCV他の環境を自力構築し GitHub からレポジトリをクローンできれば IkaLog.py を使ったり、 WinIkaLog よりも早くアップデートしたり、気に入らない変更点やバグを自分で修正しながら利用することが可能です。
Mac 上では現状 homebrew などを利用して Python+OpenCV他の環境を自力構築し GitHub からレポジトリをクローンし、設定ファイルを作って CUI 版の IkaLog.py を実行できるユーザを想定しています。 Linux でも同様です。
WinIkaLog については配布サイト から入手してください。気まぐれで更新しています。
IkaLog はGitHub上からクローンしてください。
もともと IkaLog はプログラムがわかる人でないと使えないような代物でしたが、いちおう多くの人が気軽に使えるように WinIkaLog というパッケージを出したり、設定画面などを後付けしたりして導入の敷居は下げたつもりです。 WinIkaLog を試しても難しい、うまくいかない、ということなら周りのお友達に相談したりするか、場合によってはあきらめたりしてください。
Windowsの場合はDirectShowフィルタドライバ(32bit)を持ったHDMIキャプチャデバイスを組み合わせて利用できます。細かいことはよくワカリマセン、ということであればHDMI キャプチャデバイスの選び方 にあるリストから選んだりしてください。
MacOS Xの場合はAVFoundationを介してアクセスできるHDMIキャプチャデバイスに対応していますが、現状対応できているものは Blackmagic Design の UltraMini Studio Recorder, Intensity Shuttle のみです。自分で苦労せずに IkaLog + MacOS X の組み合わせで利用したければ このどちらかを入手してください。
もちろんあなたが自分で、 AVFoundation をつかってキャプチャしたデータを Objective-C およびC言語のクラスでラップし、 IkaLog がつかっている Python 上の NumPy に画像データを入力できるプログラムを書けるのなら止めませんし、挑戦されるのであれば、 Pull Request に期待しています。
あなたは冒険家ですね。
キャプチャデバイスは非圧縮データを転送するモデルであれば〜150MB/s、圧縮データを転送するモデルでも1MB/s程度のビットレートでかなりリアルタイムなデータ転送を要求します。また対応するUSBホストコントローラによる相性も多いですし、個人的には、仮想マシン上で動かすのは無謀だと思います。 きわどい構成でキャプチャ環境を作ること自体が目的でなければ、Mac+IkaLogの動作実績があるデバイスをHDMI キャプチャデバイスの選び方 から確認してください。
Webカメラ対応については開発者の間では相当に優先度が低くなりましたので、今後のアップデートでも「ないもの」として考えてください。
HDMIキャプチャデバイスでなくWebカメラを利用したいケースというのは、「HDMIキャプチャデバイスに対しての支出をしたくない」ということ、ですよね。確かにHDMIキャプチャデバイスは安いモノで6000円〜高いモノで30,000円、HDMIスプリッタも安いものを探せば2,000円〜高いと10,000円超え、ケーブルは安い1mものなら500円〜高いものなら5,000円ぐらいします。
ですが、これまで開発してきたところ、以下のことがわかりました。
- IkaLog が処理できる画質を得られる Web カメラは 6,000円〜10,000円クラスの高級なものが必要
- これまでの認識率は同然キープできない
- テレビの光り具合や環境光（照明）の影響を受けて精度が変化する
- 現在の IkaLog の機能を全部実装するのは難しいし、無料のソフトウェアとして作るには割に合わない
Webカメラがに6,000円〜10,000円の支出ができるのなら、その価格帯で購入できる HDMI キャプチャデバイス（例： MonsterX3A）もあります。 HDMIキャプチャデバイスではなくWebカメラを購入するユーザーのために、開発者サイドが開発および調整に時間を持ち出す、というのは、開発側のコストメリットも見合いません。仮にある程度動くようにしたところで、頑張って高級な Web カメラを購入したユーザが「認識率が悪い」と不満を抱えることにもなるでしょう。このため、使いたい人と作る側の両方のコストを考えると” Web カメラに対応すれば安く IkaLog が使える”とは言えません。
HDMI キャプチャを使わなければ細かな戦績（ゲーム内のキル・デス・スペシャルなどのイベント検出など）ができなくなるため、取得できる情報が限られます。そうなると IkaLog にこだわらず、 イカレコ や イカキロク を活用したほうがいいかもしれません。
このような理由から、現在の IkaLog は「Webカメラ対応」よりもHDMIキャプチャデバイスの所有しているからこそ可能な「試合中のイベント情報の取得」にフォーカスしつつあります。
WinIkaLog ではそのような使い方を想定していません。 IkaLog CLI だとできます。
Mac OS X 上で AVT-C875 により録画したファイルを自動処理するために作られた IkaWatcher が GitHub レポジトリ上にあります。 WinIkaLog にはこの機能はありません。
『MSVCR100.DLL が見つからなかったため、アプリケーションを開始できませんでした。
アプリケーションをインストールし直すとこの問題が解決する場合があります。 』
IkaLogが必要とするランタイムがシステムにインストールされていません。以下のランタイムをインストールすると解決します。
Microsoft Visual C++ 2010 Redistributable Package (x86)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xae in position 9: invalid start byte
何故か、お使いの Python 3 が utf-8 を扱えていません。 Python 3 のインストールを見直してください。
utf-8 が扱える Python かどうかは下記要領で確認できます。
$ python3
Python 3.4.3 (default, Jul 13 2015, 12:18:23)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getdefaultencoding()
'utf-8'
>>>
$
上記のとおり utf-8 となっていても問題が発生する場合は IkaLog に想定しない文字列データが入力されている可能性があります。
IkaLog が使用する OpenCV3.0 + cv2 モジュールの組み合わせで非ASCII文字（漢字を含む全角文字なんでも）を含んだパスにアクセスできない問題があることがわかりました。 e2236ccc (Jan 23, 2016) で修正済です。最新の IkaLog であればこの問題は発生しません。
仕様です。入力がちらついているわけではありません。
たぶんバグです。原因調査中ですがまだ原因箇所がわかっていません。が、実用上問題はないようです。
「WinIkaLogが起動してすぐに終了した時にエラーメッセージが全く読めない」という声が多かったため、そのような挙動に変えてみました。 もともとそうしなくてもコマンドプロンプトから実行すればウインドウは消えないのですが、そういう状況になったときにログが読めない人が多かったためです。
Skype などのアプリケーションが、起動した段階でキャプチャデバイスに初期化してしまい、 IkaLog がキャプチャデバイスの初期化に失敗することがあります。これは「ひとつのソフトからしかキャプチャデバイスを使えない」キャプチャデバイスのドライバの制約です。
IkaLog を起動した後に Skype （など）を起動すれば大丈夫かもしれません。
結論: 使えません。 IkaLog はアナログキャプチャデバイスを想定していません。
以前の IkaLog は HDMI キャプチャを前提とつつも、任意の解像度のキャプチャデータを扱えるようにしてありました。しかし連携先となる stat.ink の分析内容が細かくなり、誤認識によって全体の統計データへ影響を及ぼすことを鑑みて、現在の IkaLog は、入力仕様を満たしているかを簡単にチェックしています。
アナログキャプチャデバイスのデータを、工夫して IkaLog にデータを入力した場合、想定する解像度が満たされないほか、画面オフセットが生じたり、色が再現されずに、認識すべきものの取りこぼしや数値・ブキの誤認識につながります。もし stat.ink などへ投稿する場合は全体の統計にゴミデータを投稿することになります（stat.ink は特に数字について IkaLog の認識精度を信じてくれており後からの編集を想定していません）。 stat.ink でデータをすべてプライベートマッチ扱いに変更することで stat.ink への影響を防ぐなどの対応をお願いします。
あなたはラッキーですね。 D4 規格であれば 720p で入力できますので HDMI でなくとも IkaLog の入力ソースとして利用できます。
Windows 上でビデオキャプチャデバイスを使用するとき、（特に使用開始・停止したとき、 複数のアプリケーションから同じキャプチャデバイスを使用しようとしたときなどに） Windows が OS ごとクラッシュすることがあります。原因はよくわかりませんが DirectShow や、キャプチャデバイスのドライバ側での排他制御がおかしいのだと思われます。
IkaLog 側で問題解消することはできませんのでデバイス製造元などに相談してください。
ビデオキャプチャのドライバは初期化できたと言っているものの、ビデオキャプチャからの入力データが壊れていることを示します。 IkaLog までビデオ信号が届いていないとお考えください。
- ドライバの再インストール、デバイスの再接続、システムの再起動、ドライバ側の設定変更などで改善することがあります。
- アマレコTVとアマレコLive!のインストール／バージョンアップ失敗での報告例があります。
アマレコTVがキャプチャデバイスを使っている場合、IkaLogはそのキャプチャデバイスを使えません。アマレコLiveを設定し、アマレコLiveから映像をお裾分けしてもらえる設定になっているか、を改めて確認してください。
アマレコTV、アマレコLiveの設定が正しいのに画面が真っ黒だったり「SampleCB() - buffer sizes do not much」と表示される場合、アマレコTVとLive!のバージョンが食い違っているなどアマレコ側の問題の可能性が高いです。一度PC上からアマレコをぜんぶ削除してインストールし直してみるなどしてみてはいかがでしょうか。
アマレコLiveの解像度設定が 1280x720 になっていること、アマレコTV/Live! で変に画像をクロッピングなどしていないかを確認してください。これらが原因でIkaLogへ入力される画像が想定外になるケースがあります。
アマレコTVのデフォルト設定ではマウスのホイールボタンに「アスペクト比切り替え」が設定されています。つまり、アマレコTVのウインドウがアクティブな状態でホイールボタンに触れると、本来WiiUの出力アスペクト比であろ 16:9 から 16:10, もしくは 4:3 などに変化することを意味し、アマレコLiveはこの設定によって出力映像が変わるため IkaLog も影響を受けます。
- アマレコTVのウインドウを右クリックしてアスペクト比が 16:9 になっているかを確認してください
- アマレコTVのホットキー設定にてマウスホイールボタンに割り当てられたアスペクト比変更を無効にすることをオススメします。
IkaLog がキャプチャデバイスを認識できない、しかしキャプチャデバイスのバンドルソフトなどででは表示ができるというケースで、画面上の Wii U 画面を入力として使える”緊急手段”です。
スクリーンキャプチャは下記理由から利用を強くオススメするものではありません。あくまでも本当にないと困る方向けの救済措置です。
- 通常よりCPU負荷が高くなる
- ブキなどの誤認識が増える
- Wii U 画面より手間に表示されたウインドウが映り込むことがある
どうしてもスクリーンキャプチャを使う必要がある場合は、下記手順で操作します。
- オプション → ビデオ入力 のタブで、「Windows デスクトップに映っている WiiU 画面を介してキャプチャ」を選択し、下の Apply ボタンを押します。
- 念のため WinIkaLog を再起動します。
- WiiU を起動しデスクトップにプレビューを映しておきます。
- WiiU ゲーム中にホームボタンを押すと表示される「ポーズ画面」を出します。
- ポーズ画面が見えている状態で WinIkaLog 入力ソース設定内のキャブレーションボタンを押します。
上記手順で、問題がなければキャリブレーションが成功します。
- 1280x720 、 1920x1080 、もしくはデスクトップ全体にWiiU画面が表示される場合の3パターンのみを許しています。
1270x710 など、想定解像度から一定以上外れた場合は IkaLog が動作を拒否します。これはブキ認識が数値認識の精度に影響が出るためです。 - 1280x720 が 1279x719 など微妙にずれたサイズで認識されることがありますが、これであれば誤差の範囲であり問題ありません。
解説動画 を見るとイメージがわきやすいかもしれません。
プレビュー画面に対して C キー入力するとキャリブレーションが走ります。
Elgato のデバイスは DirectShow フィルタを持っているようですが、ほとんどのアプリケーションで DirectShow の映像ソースデバイスとして認識できません。 IkaLog もそのひとつです。回避策としては次のものがあります。
- デスクトップキャプチャを経由する。 IkaLog のデスクトップキャプチャ機能、アマレコのデスクトップキャプチャ機能、XSplitのデスクトップキャプチャ機能などを介して強引にキャプチャします。入力解像度や入力範囲の設定にミスがある場合ただしく認識しなくなることがありますので強くオススメする手段ではありません。
- XSplit を経由する。 XSplit はなぜか Elgato のデバイスをきちんと認識できるようです（メーカーと一緒に何か対応をしているように見えます）。ただし XSplit は無償モードだと画面上にウォーターマークが入りステージや戦績の認識に支障をきたすため、IkaLogにきちんと認識させるためには有償のサブスクリションに契約する必要があります。
- AVT-C875 などの推奨デバイスに買い換える。経済的に余裕があって本当にモチベーションがあるのなら、申し訳ないですが、ユーザ側にて札束で殴ることも考えてください。
- ソフトウェア開発が可能な方でこの問題に取り組んでくれる方がいらっしゃれば歓迎します。
入力デバイスの設定がまちがっている可能性が高いです。 AVT-C875 の場合 Stream Engine というソフトウェアをインストールし、 IkaLog もしくはアマレコTVなどからは LGP Stream Engine を入力デバイスとして選択する必要があります。
以下の設定をベースに見直してみてください。
[AVT-C875でスプラトゥーンをキャプチャしてみたメモ(IkaLogとWebRTC)] (http://mzsm.me/2015/09/23/hdmi-capture-avt-c875/)
- Wii U の画面設定で確実に 720p 出力に固定してください。 1080p 出力の設定になっていた場合に認識精度が恐ろしく落ちたケースの報告があります。
Windows: Blackmagic Design 社のご協力を得て Decklink 10.5 + IkaLog の DirectShow インプットで動作するようにできました。 ダメな場合はアマレコTVに一度入力し、Live!機能でIkaLogに映像を入力してみてください。
Mac: AVFoundationCapture を介してこれらのデバイスから入力できます。
Linux: GStreamer 経由でビデオ入力できることが確認できています。
キャプチャデバイスのドライバが複数のアプリケーションからの同時利用を想定していないことが原因です。
キャプチャデバイスから アマレコTV に入力し、アマレコLive!機能でIkaLogおよびOBSに再配信すればうまくいくようです。
環境によってはアマレコLive!の出力（Amarec Video Capture）がOBSから認識できない場合があります。 この場合 OBS Multi Platform であればアマレコの出力ウインドウおよびデスクトップサウンドを入力ソースとして指定することで OBSに入力できます。
IkaLog がキャプチャデバイスを手放すことができず、プロセスを殺せなくなることがあります（開発者も一度だけ経験しました）。おそらくキャプチャフレームワークやキャプチャデバイスのデバイスドライバ側に何らかの癖があるのだと思われます。少なくとも IkaLog には、そのようなシチュエーションで無理に生き延びようとする処理は入っていません
IkaLogがゲームの開始／終了のタイミングで録画ソフトの ON/OFF を制御するだけの機能です。あくまでも IkaLog がやることは録画ソフトの ON/OFF だけですので、録画ソフトが動く状態を作るのはユーザの責任です。
アマレコＴＶ３の録画ショートカット Ctrl-Z を代わりに押してくれるスクリプト ControlAmarecTV.au3 を同梱しています。IkaLogからこのスクリプトを実行させることで、アマレコＴＶの録画ショートカットが操作されます。
アマレコＴＶ３と IkaLog を共存させるためには、アマレコLive!を設定氏、一度キャプチャ映像をアマレコに入れた後、アマレコからLive!機能を通してIkaLogに分けてもらう必要があります。IkaLogでキャプチャデバイスを直接掴むとアマレコで録画できません。
アマレコ４への対応はしていませんが、軽微な修正で動作するようです。 https://github.com/hasegaw/IkaLog/issues/406
OBS Classicの録画ボタンを代わりに押してくれるスクリプト ControlOBS.au3 を同梱しています。IkaLogからこのスクリプトを実行させることで、OBSの録画ショートカットが操作されます。
OBS と IkaLog を共存させるには、アマレコに一度キャプチャ映像を入力し OBS と IkaLog に分配する等、工夫する必要があります。そのようにすることで、キャプチャ出来ている方がいらっしゃるようです。開発者の環境では何故か OBS からアマレコLive!の出力が見えないため、アマレコのウインドウを OBS でキャプチャするようにしたら、うまくいきました。
OBS Multiplatform もしくは OBS Studio と呼ばれている新しい OBS には対応していません。 ControlOBS.au3 のウインドウ検出／制御部分を更新すれば動くようになると思います。修正された方いらっしゃれば是非教えてください。
- アマレコ3 または OBS Classic で録画できることを確認します。
- AutoIT3 をインストールします。
- アマレコ3の場合は Ctrl-Z で録画操作が可能なことを確認します。
- コマンドプロンプトから IkaLog の tools\ControlAmarecTV.au3 start もしくは tools/ControlOBS.au3 start を実行してみます。 start を付けて実行するとレコーダーソフトウェアが操作されて、録画がはじまるはずです。録画が始まらなければ何か問題があります。コマンドプロンプトの使い方は別途調べてください。
- 録画開始がうまくいったら、 tools\Control****.au3 stop を実行してみます。 stop を付けて実行するとレコーダーソフトウェアが操作されて、録画が停止されるはずです（何秒か経ってから停止します）。録画が止まらなければ何か問題があります。
- IkaLog の Video Recorder にて使いたいスクリプトを設定してください。 IkaLog から start, stop の操作が行われます。
利用環境によっては https://github.com/hasegaw/IkaLog/issues/132#issuecomment-241006313 で議論されているように autoit3.exe のフルパスを指定しないとスクリプトが実行できないようです。
にを stop もしくは start というオプションを付けて実行してみます。スクリプトが正しく
Wii U の画面設定で画面サイズを最大化していないと認識できなくなります。
Wii U は、画面のフチが切れる（いわゆるオーバースキャン）テレビの場合に、画面イメージを縮小してテレビに出力する機能があります。この機能で Wii U の画面がぴったりテレビに合うように設定した場合、Wii U からのビデオ信号は上下左右に黒色のマージンが入った状態になります。 IkaLog はこの状態を想定していません。
- ほんのちょっとだけ視野角が狭くなりますが、 IkaLog を利用するためには Wii U 側の画面設定で画面サイズを最大化してください。
- テレビ側にオーバースキャンをしない設定があることがあります。この場合は Wii U 側の設定で画面を最大化していても、テレビの設定を変更すればきちんとすべて見えるようになります。テレビ側に設定項目がないこともあります。
- PC用のディスプレイを利用する場合はまずオーバースキャンの影響は受けません。
- 画面を最大化するとテレビでフチが切れてしまう場合でも、 Wii U の出力画面を HDMI-RGB 変換アダプタなどで変換し液晶テレビなどへ入力するとオーバースキャンがされなくなることがあります。
アマレコLive! で映像が入力できているが認識されない、突然認識されなくなった もあわせて確認してください。
IkaLog を起動した状態でステージを「さんぽ」し、水に溺れてたり場外に落ちたりしてみてください。
- 何らかのツールを用いて Wii U の 1080p/720p の映像を 720p 以下にダウンスケールした後に 720p にアップスケールした場合に問題が発生することがあります。このような形での利用は保証外です。
- ビデオキャプチャの信号が間違いなくきれいに入力できている、それでも数字を読み間違えるというケースは数字が出ているスクリーンショット（フルサイズ、劣化なし）を開発者に提供していただくことで改善の検討が可能です。とはいえ数字認識ミスは多くの場合環境側に問題があるため、まずはセットアップが正しいかを見直してください。
あわせて ブキ画像の認識率がひどい も確認してください。
IkaLog のブキ認識の精度については 2015年12月27日に投稿されたブキ画像の認識状況 をご確認ください。これは IkaLog ユーザが stat.ink に投稿したスクリーンショットをもとに、 IkaLog がどのようにブキを認識しているかで整理したものです。 IkaLog のブキ認識率は 99% を余裕で越えていますが、特定ユーザの環境に偏って誤認識が多発しています。
気まぐれにブキの誤認識内容を調査していますが、このようなものが見受けられます。
- IkaLog へ画像が 1280x720 で入力されているが、その画面が左右上下に数ピクセルずれている（オフセットされている）。
このケースは現在の IkaLog では、ある程度自動検出・補正するようになりました。 - IkaLog へ画像が 1280x720 で入力されているが、その画面内容が、デスクトップ上に本来の大きさの 105% ぐらいで表示されたものの一部の切り取りである。
デスクトップキャプチャソフトウェアで取り込む際の範囲指定がおかしいことにより発生します。この手の入力による IkaLog での動作は未定義です。 IkaLog のアップデートによる対応予定はありません。 - IkaLog へ画像が 1280x720 で入力されているが、ボケている。
アナログベースのキャプチャユニットを使って無理やり 720p 相当画面として IkaLog に入力したり、アマレコTVなどの設定の問題でダウンスケールされている場合に発生します。この手の入力による IkaLog での動作は未定義です。 IkaLog のアップデートによる対応予定はありません。
一緒に開発できる仲間はいつでも大歓迎です。
是非開発して Pull Request をお願いします。
CaptureDevices ご確認ください。
以下のデバイスは AVFoundationCapture クラス経由で利用できます。
- Blackmagic Design UltraStudio Mini Recorder (Decklink 10.5 と組み合わせて確認)
- Blackmagic Design Intensity Shuttle USB3.0 (Decklink 10.5 と組み合わせて確認)
- おそらく他の BMD 製ハードウェア + Decklink 10.5 でも使えると思います。
個人的には、Mac/Windowsの両方をお持ちの方には Intensity Shuttle (USB3.0版）がオススメです。Mac/Windowsの両方に対応しており、HDMIパススルーもできます。
OpenCV のビデオ入力機能を使った CVCapture では Decklink が想定する「正確なフレームレート設定」ができないため初期化できないことがわかっています。必ず AVFoundationCapture を使ってください。
CamTwist, ManyCam などのアプリケーションでも動作するかもしれませんが、開発者が手元で試しているかぎりうまく動作していません。ところで ManyCam は勝手にアドウェアをインストールされたのでご注意ください。
IkaLog のインプットソースとしては使えません。今ですと IkaWatcher で、録画したファイルを自動的に処理するという手があります。
現状、 Windows でいうアマレコTV/Live! にあたるソフトウェアが存在しないため実現できません。
Open Broadcaster Software を改造して、 OBS のフレームを IkaLog に奪うためのパッチは Proof of Concept のレベルで作成しています。これをベースに開発に協力してくださる方がいらっしゃれば歓迎します。
キーワード（作業にあたって必要となるであろう知識）: AVFoundation, C, C++, Objective-C, ピクセルフォーマット／コーデックに関する基礎知識, avformat ライブラリ, pthread, 共有メモリとプロセス間通信など
※ 上記についてすべてプロフェッショナルである必要は全然ありませんが、自立的に課題解決ができる方を求めています。
Py2App というツールを使えばできそうですがユーザ数が圧倒的に違う（現在 Windows:Mac = 4:1 程度）ので大きなモチベーションがありません。 OS X 向けバイナリビルドを提供するための準備をしてくださる方がいれば協力したいです。
IkaUI の開発はもともと OS X で行っていましたが、当時はOS X対応のリアルタイムキャプチャデバイスが手元にありませんでした。現在はOS Xで使えるキャプチャデバイスが入手できていますし、 AVFoundation からのビデオ入力やソース列挙などもできるようになっているので、やる気のある人がいれば対応できる段階にあります。
ユーザからの報告によるとアマレコTVのウインドウ枠表示モード／非表示モード（画像のみ）でメッセージを送信すべきウインドウハンドルが異なるとのことです。現状、同梱している AutoIT スクリプトはそのあたりをうまくハンドルしていません。どちらでも動くように修正できたら是非 Pull Request をお願いします。
Windows Vista 以降では別の権限で動作するアプリケーションへの干渉が許されないそうで、 IkaLog の実行権限とアマレコTVの実行権限が異なる場合にアマレコTVへのショートカット操作が失敗することがあります。この場合は IkaLog と アマレコTV を同じ権限で実行すると回避できるそうです。
アマレコで使用する録画コーデックの選択により IkaLog の連携機能が動くかどうか変わる、といった情報が流れていることがありますが、 IkaLog がアマレコに干渉するのは「決められたキーボードを押したことにする」だけで、その先のアマレコの動作には関知しません。言い換えれば、貴方がアマレコを操作して録画できない状態では、 IkaLog がキーボードを押したことにしても、当然ながら録画できません。
Open Broadcaster Software 制御スクリプトが現状対応しているのは第１世代の Windows 専用 OBS のみです。第２世代である OBS Multiplatform 版を想定していません。OBSMP 対応スクリプトを作成し直せば解決するのですが、元気のあるかたの Pull Request お待ちしています。
Windows Vista 以降では別の権限で動作するアプリケーションへの干渉が許されないそうで、 IkaLog の実行権限とOBSの実行権限が異なる場合にOBSへのショートカット操作が失敗することがあります。この場合は IkaLog と OBS を同じ権限で実行すると回避できるそうです。
AutoIT はダウンロードしてきてインストーラを実行すればインストールするだけで大丈夫です。これが面倒、難しいと思われるのであればビデオレコーダとの連携は厳しいかもしれません。
どうして AutoIT のスクリプトにしているか、について簡単にまとめておきます。
AutoIT はその名の通りコンピュータの操作を自動化するためのスクリプト言語で、 Windows アプリケーションを横から操作するスクリプトを簡単に作成できます。このため IkaLog 開発者も普段は AutoIT を利用していないところで、頑張ってそこだけ AutoIT で書いています。
IkaLog の中にがっちり他のアプリへの連携コードを埋め込むことは可能です。ただ、私はそれをやりたくありません。私は Open Broadcaster Software が使えればいいですが、アマレコを使いたい人もいます。違うアプリを使っている人もいるかもしれません。レコーダの操作機能を IkaLog 本体から切り離しておくことで、ユーザが自分の好きなレコーダと組み合わせられ、開発側も苦労しないで良いようにしています。もちろん、これは「誰にでも簡単に使える」というコンセプトではありません。
レコーダ制御のカスタマイズ例
- IkaLogの自動録画機能を自分好みにしてみたメモ (そどこさん)
IkaLog は”プレイヤー自身の目線から”スプラトゥーンのゲームを、可能な限りフェアに処理するポリシーで作っています。
- 画面に表示されないものは分析できませんし、画面に表示されても簡単に認識できないものも分析できません。
- 画面表示形式がかわった場合は、変更にあわせて修正が必要です。そのかわり、開発開始から現在、そして将来まで、任天堂の知的財産である非公開プロトコル、アルゴリズム、ゲーム内に含まれる暗号鍵などを解析したり抽出したりする必要はありません。
開発に用いている Python 言語はオブジェクト間で情報を隠すのが難しい言語です。このため、うかつに IkaLog が外部のプログラムを自分に組み込むと、 stat.ink や Twitter などの認証情報を盗んでイタズラするようなコードも簡単に書けてしまうというリスクがあります。このため、プラグインの動的ロードは WinIkaLog では行わない方針としました。
- IkaLog を CLI で動かす場合は IkaLog が Python コードなので自由にカスタマイズすればいいと思います。
- WinIkaLog でも WebSocket Server を有効化すると IkaLog から色々なデータが取れますよ。
例 IkaLogと連携してニコ生にコメントを投稿するNCVプラグインを作ってみた
例 kaLog の stat.ink 投稿の URL を Slack に自動で貼る
IkaUI (IkaLog の GUI) 、およびそれをベースに「ダウンロードしただけで使える」 WinIkaLog は自分で Python 3, OpenCV, Numpy などの実行環境構築や IkaConfig.py の設定ができない人のために用意しました。技術スキルがある人なら無くても困らないものですが、そこまでの技術力がなくても使いたいという人に使ってもらえればと思っています。ただ IkaUI はやっつけで作っているので、決して使いやすいものではありません。実は、 IkaLog のすべての機能が使えるわけでもありません。IkaLog メイン開発者の興味はどちらかというと Windows 環境での UI よりも「スプラトゥーンのゲームをどう画面認識するか」に向いていて IkaUI のアップデートは停滞しています。
IkaUI の修正のプルリクエストなど歓迎です。いつまで IkaLog が使われるのかという話もありますが、 UI を作り直すのなら Web ベースにしたいなと思っています。一緒に取り組んで下さる方がいればお知らせください。
IkaLogはリアルタイムにプレイを有利にする機能はありません。テクを磨きましょう。
（本当に現時点でいるのかは知りません）
IkaLog を使ってリアルタイムに補助情報を得るよりも、自分の目でテレビから情報を吸い上げ、ゲームパッドのマップに注意して、様々な強ブキをシチュエーションごとに使いわけられるようになり、ゲーム開始時に自・相手チームのブキ構成を見てサブやスペシャルを把握し、ステージでも有利な立ち回りをきちんと抑える。ホコやヤグラであれば自分たちのポイントと相手のポイント、現在の目標物がどこでどうなっているかをきちんと意識し続ける。これらをきちんとやったほうが勝率に貢献します。がんばってください。
IkaLog 開発開始当初から、 IkaLog がゲームバランスを崩すものであってはならないと考えて開発をしています。このため IkaLog を単純に利用してもリアルタイムに有利になるような情報は得られません。
IkaLog がスプラトゥーンの通信をキャプチャするソフトであったら、改造により「自分の目には見えていない相手がどこにいるかを知るな」どズルをする余地もあったでしょう。しかし、IkaLog をどれだけ改造しても、HDMIからビデオ信号をとっている限りは相手のイカがどこにセンプクしているか等の情報は一切取得できません（表示されていないのですから当然ですね）。この観点からも、 IkaLog はあくまでユーザに見えている情報をまとめる機能しかなく、決定的なチートツールの土台にはなり得ません。
IkaLog が持つ現在のコードを改造して優勢になるのは、作った本人から見てもけっこう大変な作業です。もし、とても強くなれるような戦闘支援ができていたら開発者の私は S+ になっているでしょう。
IkaLog の修正を提案してくれた方でも、メイン開発者以外でスプラトゥーンの画面認識エンジンそのものに対して手を入れてきた人は2016年1月時点では一人もいません。つまりは、表面上はメイン開発者以外誰も IkaLog の画面認識コアをいじっていないのです。新しい要素の画像処理や画面認識はなおさら、ただのコピペでは済まず、また対戦中の画像認識はリザルト画面の認識よりもコードが複雑になります。誤認識などに対してどう振る舞うかなどを考え始めるとけっこうな時間を使います。 IkaLog のソースを読んだりちょっといじってみた程度でそう簡単にゲームバランスを崩せるものは作れないと思います（その時間があったらその人は普通にスプラトゥーンをプレイしてしまうでしょう）。
このため、本当にスプラトゥーンで強くなりたいプレイヤーはリアルタイムで優勢になるべく IkaLog を改変するために、それほど大きな時間をつぎ込むとは思っていません。そこまでやる人がいるなら、まあひとつ「技術S+」として認めてあげてもいいのではないでしょうか。
IkaLog は、ずっとスプラトゥーンの画面がないか探しています。ゲームプレイ中（試合中）であれば試合中に必要な認識だけをすればいいのですが、そうでない場合はゲーム開始時のステージ／ルール名が出ていないか、ロビーにいないか、リザルト画面が表示されていないかなど様々な状況を想定した認識処理を行い、ゲームの状況をとりこぼさないようにしています。
このうち、最も負荷が高いのがステージ／ルール名の認識です。たしかステージは１４種類、ルールは４種類、合計で１８種類の画像認識を繰り返し試しています。IkaLogは現状これらをネイティブ解像度（1280x720）で処理するため、画面上に表示されるステージ名・ルール名の全ピクセルに対する行列演算を先の１８種に対して試すということを常にしておりプロセッサパワーを消費します。試合中でないのに CPU 稼働率がちょっと高いんじゃない？という場合はこれらの認識の負荷が見えている可能性が高いです。
なお録画ビデオなどで試すと判るかもしれませんが、これらの認識は結果的にビデオ画質が悪くてもそこそこいい感じに認識してくれるアルゴリズムができています。作りを変えれば負荷を落とすことは可能かと思いますが、下手に負荷低減策を入れると認識率が下がり「IkaLogの認識がガバガバ。前より認識率が下がった」とか不満を持たれる原因にもなり得ますので、無理して手を入れるまでには至っていません。
きっと貴方のツイートの S/N 比が低下したのでしょう。道具をどう使うべきかを判断するのは貴方です。
スプラトゥーンの試合は３〜５分に１セット終わり、IkaLogにツイートさせるとそのペースで投稿することになります。ライトな Twitter ユーザにとっては spam 以外の何物でもありません。使い方次第ではただの迷惑なので、まわりのフォロワーがストレスに感じない程度に楽しんでください。
- IkaLog の Twitter 連携をいっぱい楽しみたい場合は専用の Twitter アカウントを作成したほうがいいかもしません。
- デフォルトで Twitter 連携投稿は専用アカウント @_ikalog_ へのリプライとして投稿されます。つまりは @_ikalog_ をフォローしているユーザにしか TL に現れません。 IkaLog の連続投稿に対して理解がない人がフォロワーにいるなら、この設定を維持することをお勧めします。他のプレイヤーの戦績を TL に表示したい場合は @_ikalog_ をフォローしましょう。
- ハッシュタグ #IkaLogResult をミュートしてもらえば IkaLog の機械的投稿が見えなくなります。
- 追加メッセージ欄などでうかつに多くの方がフィルタに利用しているハッシュタグを付け投稿するような事はやめてください。貴方の IkaLog の自動ツイートに興味がある人は貴方以外にそういません。この場合、もはやただの迷惑行為であり Twitter アカウントの凍結などの原因になり得ます。
すみません。 QA をしてくれる方も募集しています。