まんぼう日記

takataka's diary

某誌に投稿した論文の修正原稿を提出しました

某学術誌に画像検索の論文を投稿中.これまでの進行はこんな具合…

  1. 2013年7月15日に投稿.
  2. 2014年3月17日にMajor Revisionとのお達しが下る.修正原稿の提出締め切りは6月14日.
  3. ぼちぼち修正して締め切り2日前の今日,無事提出.

今度は何ヶ月待たされるのやら.ああ,リジェクトされませんように.

 

査読者二人の反応は,ひとりは「すげー興奮する研究だー,ちょー面白い,でもちょっと修正してほしいとこあるから Minor Revision ね」,もうひとりは「1万枚の画像の実験で large-scale と主張するのはいかがなものでしょう.例えばあの人たちの研究では1億枚で実験してますよね.それに検索時間も測定して比較すべきでしょう.Major Revision が妥当と考えます.でもこれらが解決するなら good paper になるでしょう」って感じで,かなり肯定的なものでした.

 

そういうわけで,「がんばって修正原稿の準備しよー」ということに.ただ,この冬はいろいろあって心身ともへろへろやった上,仕事が忙しい4月5月に大規模な実験せなあかんっちゅうことで,「リジェクトされんでよかった」とほっとしつつも,「あと3ヶ月であれもこれもやれってか,うぎゃあああ」でしたが (^^)

 

以下,そんなこんなの追加実験&論文修正の記録.

 

3月下旬—画像100万枚の収集

まずは,追加実験のために大量の画像を集める必要がありました.上記の1億枚の画像データは公開されてなかったので,別の研究機関が公開している1千万枚のデータセット(申し込んだら画像を保存したHDDを送ってもらえるって段取り)をもらおうと,管理してる研究者にメイルを送ってみました.が,数日待っても返事がもらえません.待ってる時間が惜しいので,同じ所にあった100万枚のデータセットの方(こちらは画像ダウンロード用スクリプトが公開されていて,自分で画像をダウンロードする段取り)のダウンロードも進めることに.結局,この100万枚の方で実験をすることにしました.100万枚なら large-scale と言っても許してくれる…やんなあ.自宅と大学のPCを何台も使っても,ダウンロードだけで1週間かかりましたがな.

 

4月上旬—前処理 & 10万枚で予備実験

次は,画像から特徴を抽出する前処理です(ほんまは同時進行でしたが).1枚あたり数秒かかるんですが,1枚1秒として1プロセスで処理してたら100万秒 = 278時間かかる計算.ちゅうわけで,自宅大学あわせて4台のPCをフル稼働.自宅では,Mac ProのSSDを2台のMacBook Proにネットワーク越しにマウントさせてたんですが,これが不安定で(AFPのせい?)数時間で固まるもんやから,夜中に起きて再接続したり….結局これまた1週間かかりました.

 

そんな作業がある程度すすんだ段階で,10万枚を使って予備的な実験をやってみました.前からもってる画像にこの10万枚を加えて大きなデータベースを作って,既存画像の方の類似画像をクエリとして検索精度を測るんですが,結果出るまで超どきどき.これでいい結果出えへんかったら100万枚でいけるわけないですからねぇ.で,結果は…データベースの画像枚数を増やすと我々の手法は精度が落ちるけれど,比較対象の手法の方も同じ傾向で,我々の方が常により高い精度を得られる,というすてきなもの.まだ,我々の手法の前半部分,符号化なしの場合のみやけど…ひゃっほう (^^)

 

4月中旬—100万枚で検索精度を評価する実験

100万枚で実験する準備が整ったので,本実験を開始.順調.後半部分を加えた符号化あり条件でも実験.こっちもいい感じ.画像の特徴を1画像あたり300から400バイト程に符号化する条件では,提案手法の精度を表す値(0から1で1が最良)が 0.7 弱なのに対して,比較対象の手法では 0.4 弱.「圧倒的じゃないか,我が軍は」…後で彼と同じ目に遭いそうになります(^^)

 

4月下旬—原稿の修正を始める

予定の追加実験のおよそ半分ができたので,その部分の原稿の修正を開始.残りの実験の計画やそっちの方の原稿修正の計画を練ったりも同時進行.ちなみに,再提出までの2014年度前期授業期間中はだいたい次のような行動でした.

  • 月曜: 終日授業の準備など.
  • 火曜: 朝から3コマ授業,その後は授業の後始末と準備.
  • 水曜: 学科会議+教授会の日はほとんどそれで終わり,会議のない日は研究.でも教授会中にこっそり…リモートで実験スクリプト起動したり結果を集計したり… (^^;
  • 木曜: 午前中は事務仕事など,午後は3コマ授業.
  • 金曜: 授業等はないので,終日研究,ときどき学会関係のお仕事.
  • 土曜: 同じく.ときどき終日大学のお仕事.
  • 日曜: 同じく.ただし金土日のうち半日はお休み(買い物,てくてく,昼寝,etc.).

実際はこんなに整然としてなくてもっとぐだぐだでしたが.なんかこうして書いてみると仕事でいっぱいいっぱいな感じがしなくもないですが,大学の行き帰りは歩くことが多くて,だいたい毎日2時間程度は運動&気分転換してました.帰ったらへろへろで夕食の準備,食べて風呂入ってばたんきゅーな毎日.

 

GW—検索時間を測定する実験の準備

ゴールデンウィーク中は授業もなくて実験がはかどる…ということならよかったんですが,火曜日は2回祝日あったけどどっちも授業実施日(;_;),木曜は平日,ちうわけで普段とほとんど変わらず.

 

これまでの実験のプログラムは Python で組んでましたが,検索に要する時間を計測する実験のため,その部分をC言語で書き直し.さらに,同じ条件で実験するため,比較対象としている手法もCで実装.これが後で波乱を招くことに.

 

5月中旬—検索時間測定実験 & more

検索時間測定用のプログラムのデバグも終わって実験開始.提案手法と比較手法で,検索精度が同じ位になる条件で比較すると,100万枚のデータベースからの検索で,1クエリの処理に要するCPU時間は0.37秒 vs 1.4秒.データベース画像の符号長が同じ位になる条件で比較すると,0.59秒 vs 1.4秒. これはこれで良い結果なんですが,実験結果を精査すると,比較対象の方の精度が大幅に向上していることが発覚.どゆこと? /(?_?)

 

必死であれこれ調べたり実験してみた結果,「比較対象の論文の著者らは,我々が引用した条件の場合に限って,誤ってより精度が低くなるような設定で実験してその結果を報告しちゃってたみたい」という結論に….4月中旬の 0.7 vs 0.4 というのも,たかたかが実装したプログラムでの実験では 0.7 vs 0.65 くらいになってしまいました.しかも一部の実験条件では負けてるし….まあでも精度が高い方の条件では精度差は縮まったとはいえまだ勝ってるし,符号長や検索時間で比較しても勝ってるし.というわけで,気を取り直して,後で査読者へのお返事を書く際にその辺しっかり説明することにして,先へ進むことにしました.

 

上記と同時進行で,査読者からのコメント「この手法のどの部分がどれくらい性能に寄与してるのか調べてね」に対応するための実験も.とある確率モデルに制約条件を加えたり近似したりして提案手法を導出してるのですが,これらの制約や近似は,現実的な計算コストでの検索を実現するために必要なだけでなく,検索精度の向上にも効いている(制約や近似のないモデルの方が精度が低い)というちょっと面白い結果に.理論的な面から何か言えそうな香りがしますが,今後の課題.たかたかの頭では説明&解明できなさそうやけど.

5月下旬—原稿書き書き

実験結果はすべて出揃って,論文修正の方針も定まったので,ひたすら原稿書き書き.

 

6月上旬—最終チェック

原稿を仕上げるとともに,査読者へのお返事を書く.結局,初稿で8.5ページだったものが今や11ページ目一杯.既存部分も一部セクションは全面書き直し.念入りに見直して,ついに完成.

 

そして,今日にいたる

というわけで.これらの過程では,たくさんの方々の暖かい声が大変励みになりました.こんな所に書くのもなんですが,深く御礼申し上げます.ありがとう!そして,ありがとう!… や,ほんまありがとう.

 

これでリジェクトになったら…ブログのねたになったということでよしとしよー (^^)

 

その後のお話はこちら: はやぶさ2とTPAMI論文 - まんぼう日記