AI関連 開発メモ

■学習日記

2018〜2019年はこちら

2020.1.8

RNNで為替予測をやってみたけど案の定の結果だったので、これはとりあえず終了。
色々アイデアはあるけどいずれ。

ただ気になるのは、正弦波を学習したらRNNで予測できるのか?
っていうのでググるとやっている人は多いけど、明確な答えが無いような気がする。
# サイン波すらパラメータに依存するのだったら相場予測なんてありえない?
# AIはパラメータ依存が意外と大きいので、そもそもAIの本質は何なんだ?っていう気持ちも無くもない

現在学習しているのは強化学習。
まだ初歩的なレベルだけど、Q学習について違和感を感じた人が多いのではないだろうか?
Q(s,a) = max(R)
この式だけでは表現できていないけど、簡単に言えば
「今の最良の選択は将来の最善の結果で決まる」
という数式。
言いたいことは解るけど、未知の状態から現在を導くことはできないでしょう?
Q-tableと言うものがあり、それをランダムで初期化して、そこから最適な値にする、
というのはなんとなくわかるんだけど、「現在の選択は未来の状態で決まる」というアホみたいな理論。

アホっぽいんだけど、理屈は別にしてうまくいくようなのでもうしばらく学習してみる。

自分がやりたいのは過去の情報から、未来を予測すること。
完全なランダムならそれは無理だけど、相場のようなものは人を裏切るような動作をする、別の言い方をすると、過去を繰り返すのだけど、(人間の観点から)意外性を持って過去を繰り返すと言うこと。これをAIは学習して予測できるのか?と言うところ。

AIなら人間には見えなかったことを客観的に捉えて、都合良くやってくれそうな気がしていたんだけど、今のところそこまでAIは賢くないというのが私の感想。"insight"的な要素がAIにあると期待していたのだが・・・
それは期待しすぎだとしても、せめて私の雑務を軽減してくれるAIを作るのが最低限の目標。(今のところそれすら見つかっていない)

プログラムを作って自分のやる作業を軽減しよう、でもプログラミングにかかる時間を考えたら自分で作業をやったほうがいいんじゃない?それと同じレベルになっているような気がする。

それでもプログラミングをするか、手作業でやるかはある程度経験すれば判断ができる。
AIもそういう意味で単なる道具ではないだろうか?(そのつもりで始めたけど)

2020.1.20

AIに関してはやや意気消沈気味。
まだ学習レベルが低いので見極めたわけではないけど、現在のAIは特定の処理の人間っぽいことができることくらいかなと。
自分が普段やっている作業の一部をAIに、みたいなことを考えたけど無理っぽい。

今はAIというより、ランダム性とか数理系の方が気になる。
真の乱数を現在のAIに学習させたら平均値を出すのが正解であると思うが、現在のAIに乱数を生成できるのか?
みたいなアホみたいな疑問が気になる。

2020.2.5

現代のAIの利用範囲は限られていると思う。
なので、個人的に使おうと思ったとき、どうやったらいいのか解らない。
自分の個人的な情報はたくさんあるが、それをAIに教え込ませたところで何も出てこないのは明らか。
教師あり学習ならなおさら。

現代のAIの限界をなんとなく解ったつもりでいますが、結局統計学の延長でしか無いのかな、という気がする。

一時期「AI」をキーワードに盛り上がったけど、最近はそれほどでもなくなっている。
まさに20年ほど前に流行った人工知能ブームと同じ。
そのときとはちょっと違うけどやはり適用範囲が限られていると思う。

現代のAIを使ってうまくいくところはあるけど、結局人間がカスタマイズして作った方がうまく行くことの方が多い。

なぜ私がプログラミングをやっているのかというと、自分が楽をしたいから。
楽をしたいのでコンピューターに自分の仕事を教えている。

2020.4.25

今のAIはかなり賢いと思うけど、まだまだかな、やっぱり。
自分が学習したとおりに結果を出してくれたら良いけど、そんなことは確率的に満足できるレベルではない。
例えばOCRで言えば、99%の認識率は高そうに見えるけど、100文字に1文字間違える、というのは許せない。
せめて1,000文字に一文字にならなければ実用性がないと思うだろう。

2020.5.23

しばらくAI学習から遠ざかっていましたが再開。
何となくだけど、ある程度AIに学習させるデータは人間が限定してあげないと理解できないのだろうというのが今の結論。
それだけだったら今のAIはまだまだだな、ということになるけど、ある程度学習させたAIならそいういう学習のさせ方でもいけるかもしれない。でもその「ある程度学習させたAI」ってどうやって作るの?という問題がある。

で、これまでのアプローチは諦め、Yoloを使って物体認識をさせ、その物体があり・なしでその画像が自分が欲しい画像なのかどうかを自動判断する、という方法を試行錯誤中。

デフォルトのYoloは犬・猫・人くらいしか識別できないので(実際はもっとあるけど個人的にはどうでもいいレベル)、自前でデータを作る必要がある。
現在そのための学習をやっている最中。

これが実用レベルになるのであれば、色んな場面で使えるはず。

2020.5.27

時間の合間を使ってcustom Yoloやってますが、ちょっと複雑すぎ。

https://github.com/AlexeyAB/darknet

この通りにやったつもりなのにエラーが出る。
きっと単純なミスをやっているんだろうと思いますが、これだけやることがあったら一つくらいは間違いますよ。
How to train (to detect your custom objects):
に書いてある作業。

しかしこういうのを見ると、世界中のAI科学者・技術者はこんな混沌とした中でやっているのかな、と思う。

自分だったらこんなものは公開しない、と言いたいところだけど、開発したらたまたま良い結果が出たので公開した、一応説明書は書いておくけどあとは頑張ってね、っていうやり方はありだと思う。(それが現時点のAIの世界だろう、昔のソフト黎明期に近い)

今のAIの学習を初めて2年くらい経つけど、未だに自分が学習させて成功した例がない。
学習済みデータを使えばそこそこできるけど、ネットに転がっているデータで自分が使えそうなものは今のところ見つかっていない。(というより、欲しいデータを作った人はいるけど、一般公開していない)

一般公開されている学習済みデータは実用化できる可能性は少ないので、結局自分で作るしかない。
そういう情報を共有できれば良いのに、とだいぶ前から思っているが、、、

2020.5.28

Yolo:
ようやく学習ができるようになった。
できなかった原因は、webにある通りに実行するとpathが間違っているので確実にエラーになる。
そのほかにもエラーがいくつか発生したけど、それはwebや実行時のメッセージが出るので容易に解決。

2020.5.29

Yolo:
学習データはたったの1つしかないのに10時間もかかった。(GPUフル回転)
使った学習データで物体認識させると、全く意図しない結果となった。

AI学習の問題は一体何が悪いのか確かめる方法がなく・・・

それはさておき、Yoloではlabelimgというアノテーションツール(Annotation Tool)を勧めているところもあるので試してみた。
これも前提となる条件があり、グーグル先生に頼らないと使えないツールだった。。
AIの世界は本当に作るだけ作ってあとは使う人の努力、っていうのが許容されているんだなぁ。。
それはさておき、このツールを使ってYolo用の座標データを作ってみたら、自分が手計算で作ったものと全く違っていた。(なんで?)
そのために10時間も無駄な計算をしていたのか・・・(電気代は50円くらい?)

そのデータを使って再度計算中。。

10時間かかるのかと思ったら、1時間もしないうちに終わった。(なんで?)
結果は全然正しくないけど、10時間かけた学習よりは良いかもしれない。
うーむ、次はどうしたら良いのだろう。。
学習データが一つ、っていうのはかなり極端なので単純に学習データを増やせば良いだろうか?

2020.5.30

学習データを11個ほど作り再学習。10時間くらいはかかりそう。
"yolo 自前データ" でググると結構やっている人が多い。
その記事を見ると、手順と結果は書いてあるんだけど、肝心の学習データと学習済みモデルは公開していない。
すべてがそう。
いずれそれでビジネスを、と考えているのなら仕方ないけどほとんどはそうでもない。

2020.5.31

Yolov4でできた!10枚ほど学習させて、認識できるようになった!
やったことは、1時間程度ある動画からある特定の人物を学習し(classは1つ)、全フレームでその人物の認識処理。
著作権の関係でここには載せられませんが、、、学習量が少ないにもかかわらず、期待以上の結果でした。

- 学習に使っていない角度の異なる映像でも認識していた
- 誤認識もあるがその場合は確度の低い値が続く
- 確度の高い誤認識もやや多く感じるが、取りこぼしはなかった(ある条件では重要)
- 人物を認識させた場合、複数の人がいる街頭映像では誤認識しやすい
- 青汁の入ったコップを人間と誤認識していた(笑)

今回の場合は誤認識を取り除く作業をすれば完璧な結果だった。
(もし取りこぼしがあればほとんど使い物にならなかった)
10枚ほどの学習で良好な結果が得られるというのは素晴らしい。
(学習時間は11時間もかかっているが・・・バッチ処理回数を減らせば改善する?)

再び建もの探訪に戻ると、番組内容を認識させるのは難しいので、CMを学習させた方が良いだろう。
各CMの最初のフレームに現れる人物・物体を認識させればほぼ自動処理ができるのではないかと思う。

その前に、デフォルトのYolov4で建もの探訪を認識させると何が認識されるのか見てみた。よく認識しているな、と思うけど、残念ながらこれは今回の用途には使えない。

そこでCMの頭のシーンの人物・物体を認識させれば・・・と実際の映像を見たけどCMの先頭に識別しやすい物体がなかったり、せめて番組の先頭に識別できる物体がなかったり、Yoloだけでは無理そうという現時点の考え。

2020.6.2

建もの探訪はもう一工夫が必要と言うことがわかった。その一工夫を加えれば恐らくほぼ自動的にできるだろう。
それ以外の場合、例えばこの番組は「このパターンを認識させれば」ある程度誤認識があるものの使い物になる気がする。しかし、問題はそのパターンがその場限りだった場合。学習時間に10時間もかかり、その結果が悪いとやり直す必要があると言うこと。・・・そういう場合はYoloは使えないか。これは仕方ない。

もう少し普遍的な、一度学習したらある程度使い回せるもの、かつ厳密性を要求されないような用途、に限られるだろうか。完璧な人間がいないように完璧なAIも存在しない。やはり最終的には人手が必要、完全自動は今のレベルでは無理そう。

例えば、うちのベランダに鳩が時々やってくるが、現在のYoloであれば"bird"と認識してくれるはずなので、画像の座標から方位角などを計算し、水鉄砲で撃退!みたいなことはまさにYoloには向いている。
成功すればしばらくは鳩がやってこないだろうし、失敗しても誰にも迷惑がかからない。
(水鉄砲を制御するのは大変そうだけど)
そこまでやらなくても、「鳩アラート」を出すだけでも役に立ってくれる。
鳩アラートが出たらそばに置いてある水鉄砲で撃退、在宅勤務が続いている今なら非常に有効。
ベランダ菜園をやっている自分としては、冬のムクドリ撃退にも使えそう。

平凡な頭脳ではこの程度しか思いつかないorz
せっかくの面白い技術なんだから何かに使えないだろうか。

2020.6.6

今後の方針
というほど大したことではありませんが、Yoloに関しては、

・認識させたいimage objectのannotationをどれだけ用意できるか
・annotationしたimage objectをいかに学習させるか

これに尽きると思うので、まずは認識させたいimage objectのannotationを時間があるときにちまちまと作って蓄積していくしか無いと思う。
(ネットに転がっていれば良いけど、一般的なものを除けばまずないと思った方が良い)

蓄積した後はそれをどのような組み合わせで学習させたら期待した結果を得られるか、職人的な経験と勘の世界になるのではないかと思う。

電気代は結構かかるだろうなぁ。。

建もの探訪続き、そして結論:

現在はパラメータを調整して、以前貼り付けた図のような結果より改善しているが、境界付近がばたつくので完璧ではなかった。そこへffmpegによるシーンチェンジ検出を追加し、ちょっとしたフィルターを通したところ、100%認識するようになった!素晴らしい。

しかし問題は、CM内容が変わると自信を持って誤認識している。その場合は追加学習をすれば良いだけなので、大した手間はかからないが・・・
それより問題なのは、その都度正しく認識しているのかチェックしなければいけないこと。だったら自動認識の意味が無い。
実用性を考える上で、実運用においてどうやって検証するのか、検証はしやすいのか、そもそも検証は必要なのか、など考慮しなければいけないというのは重要なポイントだと言うことがわかった。

そういうことを考えると、「建もの探訪」のCM判定は私の良い学習材料だったが、AIによる自動化する意味が全くないという結論となりました。(今のAIなんてそんなもんよ)

2020.6.8

Yolov4を使い、録画番組から5種類ほどのオブジェクトを100枚ほどの映像で学習させたけど、凄い。
誤認識がまだあるものの、取りこぼしがなく、だいたい期待通りに動く。
個人的には「取りこぼしがない」というのが重要で、誤認識された「ゴミ情報」は手作業で取り除けば良い。
混同行列で言えば、陽性(TP)と偽陽性(FP)はあるが、偽陰性(FN)が無いと言うこと。

2020.6.9

Yoloについては基本的に実用レベルにあると思うので、もう少し深掘りしてみたい。
理論的なもの・学術的なものに関しては基本、研究者の方にお任せして、理系プログラマーとしてはもう少し実践的な側面で考えてみたい。

2020.6.21

新しいプロジェクトを始めた。

きっかけ:

きっかけはSUUMOで物件を探しているんだけど、なかなか良い物件が見つけられず、物件を見るのが疲れてきた。昨年かなり良い物件を見つけたけど、立地条件だけの理由で見送った。けどそれ以来、それを越えるあるいは同等の物件が見つけられていない。これまで見た物件は一日平均10件だとしても数千件は見ているはず。百件に一件くらい「見学してみようか」っていうのが見つかればいいのだけど、数百件も見て出てこないとさすがに疲れる。
それなら「注文住宅とか半注文住宅にすれば?」というのも選択肢としてはあるのだけど、そこまで時間とエネルギーを使いたいと思わない。自分が欲しい家というのは「こだわりの家」ではなく、ごく普通の家で良いんだけど、「卓球台がおけるスペースがある」これだけ。だから何が重要かというと「間取り」。
SUUMOを見ていてまず見るのは間取り。間取りが悪ければ他の条件はまったく関係ない。
そもそも自分の条件に合う間取りの家というのは非常に少ない。数十件に一件くらいだろうか。
だから、無駄な閲覧を延々と続けることになってしまう。。

何を実現するのか:

ということで、間取りが自分の好みに合ったものかどうかを自動判別するシステム。

どうやって実現するのか:

1. SUUMOに掲載されている画像を取得する
2. 取得した画像から間取りの画像を選択する
3. 取得した間取りから自分の要求とマッチする間取りかどうか自動判別

1.はスクレイピングだけど、Octoparseなるものを見つけて試したところ複雑なページを容易に解析できるので直感的に便利だと思った。しかし、SUUMOのページを見た人ならご存じだと思うが、ページの構成が物件によって微妙に違っており、操作も若干異なり、スクレイピングソフトも当然うまく認識できないときがある。現時点ではそれをどのように解決すべきか検討中。。
※SuumoがOctoparse対策をしていたとしたらここでプロジェクトは終了 or ガチでscriptを書くか(それはたぶんない)

2.についてはようやくここでAIの登場。間取りの画像とそれ以外の画像の判別は恐らく難しくないだろう。ほぼ100%の確率で認識できると思っている。

3.についてもAIでやってみる。恐らくこのプロジェクトで一番興味のあるところで、プロジェクトとして立ち上げた本当の理由。

このプロジェクトを一言で言えば、「自分の好みの間取りを自動判定するAIを作ってみる」

クラス判定するAIになりますが、一応三段階で学習させるつもり。例えば、
1: 論外
2: 可能性はある
3: 基準はクリア
AIは画像情報だけで私の好み・意図を理解できるのか?っていうところですね。

現時点のAIがどうなるかの予測は、平均的な間取り、標準的な間取りというのはある程度存在しており、それがすべてNGと私が学習させたのならほぼ確実にNGとAIは判定してくれると思う。気になるのは私が「基準クリア」と判断する物件はレアなので、それをAIがどういうふうに学習してくれるのか、ではないかと思う。
それを間取りの本質とは関係の無い、「描き方」とかのほうに走ってしまうともうほとんど使い物にならないだろうし、誤認識されるたびに学習させることでどこまで精度を上げられるかではないかと思います。

人生の大きな買い物にそんなところにこだわるのか!?っていうのはあるけど、ちょっとやってみたい。
(自分も何となくこだわるところが違っているような気がするけど、それは趣味・好みの問題なので)
普通に信頼できる不動産屋に行けば色々とアドバイスをもらえるけどね〜

2020.6.23

Octoparseは非常に簡単なんだけど、取得できないページがあると対処が途端に難しくなる。取得方法を分岐によって分けることができるんだけど、その判断方法はページの一部の違いを見つけるしか無い。HTMLをよ〜く見てみないとわからないときがある。
個人的には、「取得できない項目があるときは」みたいな分岐があれば非常に簡単なのだが無いらしい。

こういうツールは型にハマった処理は非常に簡単なんだけど、それからちょっと外れると途端に難しくなる、という典型例。
このOctoparseはインストール時の同意文が中国語だったり、使用説明が怪しい日本語(中国語を自動翻訳?)だったり、Octoparseでググると手前味噌記事がやたらと出てくるし、非常に怪しい。(ScrapeStormも同様)

ということでOctoparseの使用は諦め、Scrapy or BeautifulSoupでやってみることにした。(これも面倒だけど、万能的に対応できるのがいい)

さらっと見てみたところ:

BeautifulSoupはガチガチにHTMLのパース処理を書いていくタイプ。ガチガチと言ってもprimitiveなところはやってくれているっぽいのでそんなに煩雑にはならなさそう。ただ、解析対象のHTMLの構造をしっかり理解する必要があり、その辺の苦労は昔と変わらない。当然、ページリニューアル!なんて言われた日には涙がちょちょギレます。

それに対してScrapyはある程度ひな形ができあがっており、型通りの処理だと差分処理を書けばいけそうな感じ。ただ、目的にはクローリングでは無いのでちょっと無駄が多いかも。

なので、BeautifulSoupで進めようかと思う。

と思ったけど、urllibにはキャッシュ機能が無い。Scrapyのほうがいいかも。

2020.6.26

ScrapyでSuumoから物件のタイトルと詳細URLを出力するコードを書いたら、凄く簡単!

class ScrapySuumoSpider(scrapy.Spider):
    name = 'scrapy_suumo'
    allowed_domains = ['suumo.jp']
    start_urls = ['https://suumo.jp/jj/bukken/ichiran/JJ012FC001/?ar=030&bs=020&cn=9999999&ekTemp=024515920&ekTemp=024506870&ekTemp=024521730&ekTemp=024516490&ekTemp=024505090&ekTemp=024501050&ekTemp=024535270&ekTemp=024500050&ekTemp=024502750&ekTemp=024525060&ekTemp=024525580&ekTemp=024530640&ekTjCd=&ekTjNm=&et=15&fw2=&hb=0&ht=9999999&kb=3000&km=1&kt=5000&kw=1&md=4&md=5&ni=9999999&ra=030014&rn=0245&rnTemp=0245&rnek=024515920&rnek=024506870&rnek=024521730&rnek=024516490&rnek=024505090&rnek=024501050&rnek=024535270&rnek=024500050&rnek=024502750&rnek=024525060&rnek=024525580&rnek=024530640&tb=0&tj=0&tt=9999999&pc=30&po=5&pj=1']

    def parse(selfresponse):
        # 詳細ページへのリンクを取得する
        for link in response.css('.property_unit-title'):
            url = link.css('a::attr(href)').extract_first().strip()
            link_url = response.urljoin(url)
            yield scrapy.Request(link_url, callback=self.parse_detail)
        
        # 「次へ」の検索
        next_page = response.css('p.pagination-parts')
        if not next_page:
            return
        next_url = next_page.css('a::attr(href)').extract_first().strip()
        if not next_url:
            return
        
        next_url = response.urljoin(next_url)
        # 次のページをリクエスト
        yield scrapy.Request(next_url, callback=self.parse)

    def parse_detail(selfresponse):
        yield SuumoScrapyItem(
            url = response.url,
            title = response.css('h1::text').extract_first().strip()
        )

これがすべてではありませんが、一番面倒な解析処理がこんなに短いコードで書けるなんて!

ちなみにここでやっていることは、

これだけの処理をこんな簡単に書けます。素晴らしい〜

プログラミングできる人だったらOctoparseとか怪しいソフトを使うより、Scrapyのほうが断然いいです。
この解析処理だけで言えば、Octoparseで作成する時間とそんなに変わらないはず。
# 昔PerlでHTTP Parserを使ってゴリゴリやっていた時代と隔世の感が

そしてさらに物件紹介の詳細ページを解析してみましたが、これは確かに難しい。Octoparseは検知できないときがあるわけです。

必要な詳細情報は取得できたので、明日はいよいよ本丸の画像取得。Ajaxを使っているっぽい(Octoparse said)ので、Scrapyがどれくらいの実力があるのか試すことができる。→imgタグにJavaScriptを使ってちょっと特殊なことをやっているだけみたい。基本的にimgタグの解析でOK

Scrapyでうまくいけそうと言うことがわかったので、Octoparseという怪しいアプリはアンインストール。

2020.6.27

画像取得もうまくいった。若干小手先の修正を入れないといけませんでしたが。(Octoparseでは無理)

不動産情報・画像取得・保存までやって書いたコードは100行余り(コメント、デバッグコードも全部ひっくるめて)。
たったこれだけでできるなんて素晴らしい〜
(どういうコードを書けば良いのか、実質丸一日くらいはかかったけど)
もう一度似たようなサイトのスクレイピングコードを書けと言われたら30分もかからないはず。
これも素晴らしい〜

画像は千枚程度手に入ったので、それをAIに学習させる。間取り図とそれ以外の識別はそこそこ高い認識率になるのではないかと思う。(多少間違いがあっても良いが、取りこぼしだけは困る)

その次はお気に入りの間取りかどうかの識別能力。まぁ最悪使い物にならなくても間取り一覧の画像ができるので物件探しはかなり楽になるはず。
こういうのを不動産屋が作ってくれたら良いけど、そんな特殊な需要は少ないですからね。。だから作っている。

2020.6.28

まだScrapyのscriptに若干の問題があり格闘していた。どうもよくわかっていないところがあるようでもう少しデバッグが必要。

2020.7.1

Scrapy scriptにはまだ問題があるようだけど、画像データ自体は千枚くらい取得できたので学習してみた。

しかし学習経過がおかしい。二回目のepochでlossが1.4くらいで飽和してしまう。
これまでのCNNをそのまま流用しているのだが・・・
こういうときは学習データに問題があると思うが、なさそう。

千枚では足りないのだろうか?もっと単純な画像を入力するとどうなのだろうか?

2020.7.4

さらに学習データを2倍くらいに増やしたけど、誤差がさらに大きくなって1.69。
こういうときはどうすれば良かったんだっけ?
モデルは複雑だとは思わないし、あとは何をやったら良いんだろうか。。
素直な結果が出るかと思ったら真逆だった。
行き詰まったかなぁ。。

2020.7.25

恐らく、学習用のデータがまだ少ないためだと思われる。現在対象は102個しか無く、非対象は864個。
少なくとも対象の学習用データを増やした方が良いだろう。
PCACA(PCA Color Augment)を使って擬似的に増やしてみる。
Yoloだと100個もあればかなり高い認識率になるが、自分が現在使っているモデルではまったく学習の効果が出てこない。

ただ、PCACAだとcolor augmentationなので、色情報が重要では無い間取り判定ではあまり意味が無いかもしれない。むしろ回転など別のaugmentationのほうが良いかもしれない。
→やはりPCACAはまったく効果がありませんでした
疑似データとはいえ、学習データ数は1万を超えているのでデータ数の問題では無さそう。
別のaugmentationを探してみるか・・・

2020.7.27

間取り認識がまったくうまくいってませんが別の画像認識のために再びYoloをやっている。
分類するクラスが15個、学習データは130個ほどだけど、だいたい期待通りに認識してくれるし、誤認識も納得できるレベルで誤認識する。素晴らしい〜

間取り認識もYoloが使えれば良いんだけど、「このオブジェクトがあれば間取り図だ」という特徴的なオブジェクトが間取り図にはないんだよね。。
あるとすれば、「〜畳」「バルコニー」とかの文字だろうか?
それかトイレやキッチンの略図とか。
そっちの方向にやり方を変えようかな。。

Yoloに頼りすぎるエンジニアリングもどうかと思うけど、Yoloは強力だからな。。
Yoloの問題は計算時間?9時間以上は当たり前@GTX1080

2020.7.28

AI計算をフル稼働しているが、さすがに暑い。
200W級の暖房機をずっと回しているのだから。
逆に冬だと物足りない。

たかが画像の認識のためにどれだけ電気エネルギーを消費するんだと思うけど、昔は200Wまでとは言わないまでも数十WのPCでプログラミングを一日中していたわけだから、、、それに比べたら集中的にエネルギーを使うのはある意味効率は良いのか?

2020.7.29

今日もAI計算フル稼働。タワー型PCの筐体が熱い(45度はある?)
今年の梅雨は気温が低いのが幸い。エアコンの電気代がAI計算に振り替えている感じ。
今はAI用PCをリビングに置いているがリビング全体が暑い感じ。

cloudと比べてどっちが安いんだろう?
自分は勢いでグラボを買ってしまったので今更引き返すことはできないけど、電気代だけを比較したら自前の方が安いはず。だから自前の環境を使えば使うほどcloudより安くなるはず?
Googleは太陽光を使っていると言っても投資回収するには何年もかかるので炭素排出量の削減になっても経済的にはどれほど効果があるのかよくわからない。
仮に自分が太陽光発電にして、その発電エネルギーに応じたAI計算をしたとしても、設備投資を回収するまでには少なくとも10年以上はかかるはず。(厳密に計算したわけでは無いけど、感覚的にそんな感じ)

そもそもその電力料金の差が1年間で「うん万円」ということは無いはずなので、そこまで気にする必要は無いけど。

それよりは、その学習によって自分の時間が節約できることの方が大きい。
例えばAIで自動化された作業を一日当たり10分あるとしたら、1年間で60時間。時給千円だと仮定すると年間6万円の節約なる。

自分はこれで事業を興そうというわけでは無いのでこの計算に意味は無いが、この大雑把な経済的な観点からすればcloudにするかどうかはそれほど重要では無いと言うこと。 →cloudのほうが圧倒的に高い(数十倍以上)ので自前を前提で考えた場合、自動化による時間節約は大きい。(cloudだったらpayできるか不明)

さらには自分が作成した学習済みデータをほかの人に使われたら、学習に使用されたエネルギーは無駄にならずに済む。

現時点の想像だけど、学習データの収集・作成はそれなりに時間がかかるし、AIの学習にも結構時間がかかる。これらがどちらも滞り無く続けられる状態の時は良いけど、ある程度ルーチンができあがると学習時間が支配的になり、もう一台欲しいなぁ、というときにcloudがいいのかも?

理想的には学習済みのデータを学習用データから解析的に求められたら良いのだけどね。
それができたらノーベル賞、は無理としても間違いなくフィールズ賞だけど。
いや、フィールズ賞がノーベル賞を越えるかもしれない。
ノーベルが数学を外したことを後悔するかもしれない。

今のAIは電力エネルギーが必要で、まさに映画Matrixのような世界だけど、それは一時的なもので将来はもっと効率的なやり方を誰かが見つけるかもしれない。
今は数学的なモデルを用いて工学的なアプローチでやっているだけなので、やり方はほかにもまだあるはず。

2020.7.30

電気代を見積もってみる。電気料金が25円/kWhとし、200Wで8時間の計算をすると、1.6kWh => 40円
(ちなみにcloudだと1500円以上!するはず)
これを一ヶ月に20回やるとすると、800円/月。実際20回もやることはないとは思うけど、ピーク時はこれくらいになるとは思う。フル稼働を1年間続けると、9,600円/年。そこそこ良い金額になる。

もしこれを太陽光発電でまかなうとしたら?
300W以上の太陽電池パネル ・・・ 5万円?
UPSなどAC電源切り替え、インバーターなど ・・・2万円?
ほか諸費用 ・・・ 1万円?
合計8万円と仮定。

200W以上発電できる日が年間1/3あり、1日5時間程度あると仮定。そうすると年間発電量は、
200W x 5h x 365/3 = 121kWh
これを通常の電力料金に置き換えると、約3千円。

投資回収できる年数は 80,000 ÷ 3,000 = 26年
やっぱり今でも太陽光発電はスパンが長すぎて使えない。
26年後も今と同じようにAI計算をしているとは思えないし。(その頃に私はこの世界から足を洗ってる?)

太陽光発電はほかにも使えるのでAI計算に限定しなくても良いが、パネルの設置、保守費用(自分は電気系なので自前でできるが)などを考えると実際の投資回収ができるのは30年以上だろう。ほとんど回収できるかどうかわからないレベル。それくらい太陽光発電は長い目で見ないといけない。やはり化石燃料発電には到底及ばない。

ちなみに風力発電も見積もったことがあるけど、これも化石燃料発電には到底及ばない。

ということで、AI計算で一番効率が良いのは冬にやること。

2020.8.1

Yolov4 for WindowsをVisual Studio 2015でbuildするためのメモ

https://github.com/AlexeyAB/darknet#requirements
こちらによれば、VS2015で build.ps1 を実行すればできるよ!と書いてあるがそんなことはない。(OSSあるある)

まずbuild.ps1を書き換える。

22行目付近、getLatestVisualStudioWithDesktopWorkloadPath() の戻り値を
  return "C:\Program Files(x86)\Microsoft\VisualStudio14"
に変更
51行目付近、getLatestVisualStudioWithDesktopWorkloadVersion() の戻り値を
  return "14"
に変更

PowerShellを起動したら、

PowerShell -ExecutionPolicy RemoteSigned .\build.ps1

で実行。(実行権限を与えてある場合は、.\build.ps1だけでいい)

ちなみにOpenCVは次のようにやった。

https://sourceforge.net/projects/opencvlibrary/files/opencv-win/
opencv-4.4.0-vc14_vc15.exe をdownload、展開 (ex. C:\opencv)
set OpenCV_DIR=C:\opencv\build

※CUDA, cuDNNが必要と書いてあるが、なくてもbuildは通った。このPCにはGPUが入っていないので。

前回「どうしてバイナリを公開しないんだ!」と書いた手前、こちらに置いておきます。

ソースコード:https://github.com/AlexeyAB/darknet

※CUDA, cuDNNなしでbuildしたのでGPUは使わないかもしれません

展開方法:

↑のソースコードを展開 or git cloneする。
展開したところへ unzip yolo-v4-win64.zip で展開

2020.8.2

Yoloを使って間取り図認識、やってみたところ、

全画像966枚中、30枚偽陽性(3%)、5枚見逃し(0.5%)

間取り図認識の場合偽陽性は問題ない。見逃し率が0.5%、200枚のうち1枚見逃す程度なのでそこそこというところでしょうか。
ただし、この中に学習用に使った画像も含まれているので実際は悪くなるはず。

現在画像を自動ダウンロード中、学習に使っていない画像でどういう結果が出るのか。
不動産屋が提供する画像はある程度クラス化されるので、恐らくそれほど悪くならないような気がします。

ただ、全画像の見逃し率が0.5%と言っても、1つの物件当たり平均十数枚の画像がある印象ので、物件当たりの見逃し率になると5%程度までになり、20件のうち1件の物件を見逃すことになります。自分が探したい物件は100件のうち1件くらいの感じなので、ちょっとよろしくないかもしれません。
もしその仮定だとすると、感覚的に見逃し率は0.05%程度まで抑える必要がある感じです。(あくまで感覚)

見逃し率が少し気になるものの、scrapy+yoloのおかげで物件を探す労力が大幅に削減されます。
Suumoがそういう機能を用意してくれたら嬉しいけど、まぁたぶんやらないでしょう。
不動産屋的には、間取り図だけでOK/NGを判断されるというのは避けたいところでしょうから。
でも私みたいにはっきりしている人がいるんですよ!!

そういう人は非常にレアだとは思いますが、見逃し率が許容できるレベルになったら学習データなどを公開しようかと思います。

2020.8.3

間取り図認識の本格運用に入ってみた。

某不動産サイトから、小田急線、相鉄線、京急線を条件に検索。
ダウンロードした画像は8千以上、そこから間取り図と認識した画像は約1,000。

思った以上に誤認識(偽陽性)が多い感じで間取り図以外の画像も4割くらい紛れ込んでいる(適合率が非常に悪い)が、大した問題ではない。(むしろ物件の付帯情報なので悪くはない)
それよりは同じ物件を複数の不動産屋が掲載するのでスキップしなければならない画像が多い。

このAIシステムで何よりも良いのは、間取り図基準で探す人間にとっては非常に楽だと言うこと。
上記の3つの路線から自分が希望する間取り図を、ブラウザの操作だけで探すのは死ぬほど辛い。
趣味の欄に「不動産探し」と書いてもいいくらいだ。

ちなみに偽陽性になる原因の多くは、「トイレ」を誤認識してしまうこと。
トイレの模式図はどの間取り図にも必ず入るので汎用性が高い反面、自然画的な写真では誤認識しやすい。
(本当に実物のトイレを認識しているかもしれませんが(笑)

ということで、重複問題はあるものの、これならかなりの物件を容易に探せそう。
路線を増やせる余裕はまだある。
これをルーチンワーク的に、一週間に一回くらい回せばいいかな、という感じです。

2020.8.22

最近は猛暑続きなのでAI計算はやっていません。200Wの熱源はこの時期かなり強烈です。
それなら、AI計算用のPCをベランダに置いてみようか?
っていうくらい。
電源延長ケーブルを使えば可能ですが。。

最近夜は涼しくなってきたので再開してみましたが、やっぱり暑いわ〜

Suumoからの間取り図抽出AIはそこそこ使えるようになってきたので、学習データ諸々を公開しても良いのですが、そういう人は希だと思うので、たぶんしないかなぁ

2020.8.26

暑いのを我慢してAI計算を再開。やっぱり暑い〜

現在やっているのは、動画ファイルから対象物を見つけるAIの構築中。
以前やっていた建てもの探訪からCMとnon-CMを区別する・・・とは異なりますが、Yoloを使って対象動画フレームなのかどうかを識別するAI。

Yoloで認識させる対象物は独自に学習させたAI。
汎用的に認識できるAIを構築したいと思ったが、やはりなかなか難しい。
汎用的なAIにするにはそれなりに学習データが必要。

しかし、その動画ファイルのみに限定した対象物であれば、汎用的な努力をするより、限られた物体だけを学習させればいいはず。学習データは10枚程度あれば十分なはずだが、Yoloの規定通りの学習させようとするとかなり時間がかかる。(ここが以前からネックになっていた)
そこで、ある程度誤差が下がったところで学習を打ち切ってみたらどうなのか?
っていうのを探っている最中。
これなら5時間もかからないはず。
Yoloは誤差曲線を見ながら適当なところで中断できるのが良い。
(文言だけでは何を言っているかわからないだろうけど)

こういうのは寒い冬にやりたかった。。

【新ネタ】
ソフトエンジニアなら必ずと言っていいほどやるログ解析。
ログを解析すれば大抵の場合は問題の範囲を特定できる。
しかし、ある程度問題を解決していくと再現できない問題に直面するときがある。
例えば、非常に長時間ヘビーなことをやっていると突然発生する問題。
こういうケースに悩まされているエンジニアもいることだろう。

単純に似たような再現テストをやってもなかなか再現しない。こういうのはエンジニアもユーザーもどちらも辛い。
そこでログをAIに学習させて、問題が発生する確率をAIが算出する、と言うAIは作れないだろうか?

現在私が取り組んでいる対象のデバイスのモデルは単純で、ユーザーの入力コマンドに対して結果が出るというもの。通常ならばそれと同様のコマンドを同じタイミングで入力すれば再現するはずだが、数ミリ秒、または数十ミリ秒単位の違いで再現できないのではないかと思っている。つまり、似たような再現テストをしても確率的な問題でなかなか再現できないのでは無いかと。

ログデータは大量に蓄積されているので、学習データは十分にあると思う。
問題はAIのモデル。ログデータは時系列なのでRNN系のモデルが良いのか?

単純にログデータをAIに突っ込ませてもAIには理解できないはずなので、入力コマンドとそれに対する結果というものをRNN系のAIに学習させればエラーが発生する確率を出すことができるだろうか?

エラーが発生する入力パターンを導き出せるAIを作れるのが理想だが、恐らくそれは(現代の技術では)恐らく不可能なので(解析解を出すようなもの)、最低でも今やっているテストのコマンドパターンでエラーが発生する確率は何%、みたいものが出せるとかなり嬉しい。

とりあえず「ログ解析 AI」でヒットしたサイトを調べてみるか・・・

2020.9.4

「ログ解析 AI」ではあまり参考になるようなものは見つからず。アクセスログから攻撃パターンを見つける、みたいなのは少し参考になったけど。

お手本になるものがないのでとりあえずお試しで作ってみた。

入力コマンドは関係のあるものだけを抽出、それらを数値化。
結果については、warning, errorのうち関係ありそうなものだけを抽出し、数値化。
モデルは一般的なLSTMを使って学習。

問題は、時刻情報をどのように盛り込むのか?とりあえず秒単位でイベントを載せることでやってみた。ほとんどイベントなしの情報になるので、ダメっぽいが・・・
(正弦波とか株式相場なら常に変動するのでいいのだが)

【結果】
1秒ごとのイベントを学習させたところ、予想したとおりゼロに張りっぱなしの予測結果。まったく意味が無い。(誤差は0.01と低いが、1000秒に数個程度しかイベントが発生しないのでAIも楽な方向へ動く - ここは人間と変わらない?)
ちなみに学習データは220万個程度(=1日86400秒x数日x4)。なので学習時間はLSTMにしてはそこそこかかる(1〜2時間程度?)。

次に時刻情報は破棄して、順番だけを維持して学習させた場合。

これも案の定というか、うまい具合に平滑された結果となっている。(誤差は1.1とかなり大きい)

そもそも予測結果のラベルは離散値であり、各ラベルの値の大小には全く意味が無い。なのでこんな連続値で出されても何の意味も無い。
出力の活性化関数がリニアになっているので、それがいけない。(流用コードなので)

2020.9.5

活性化関数をsoftmaxに変えたほか、データの前処理にも決定的な間違いがあったのですべてやり直し。学習に使ったデータで予測を行うとそこそこ良い結果(誤差は0.001未満)なので、明日は学習に使っていない実際のログデータで予測を行ってみる。

2020.9.6

実際のログデータでやってみました。

最大値が3.0となっていますが、10以上がエラー発生の基準なので、このログによる予測からはエラーが発生しないと言う判断になる。実際エラーは発生していないログなのでAIの判断は正しい。

ちなみに学習に使用したデータで予測させると、

最後のところに10以上の値があり、実際このあたりでエラーが発生している。
うまくいっているように見える。

今回の問題はどういう入力を与えたら発生するのかというところ。
やりたいことは「このログはエラーが発生するのか」ではなく、「どういう入力を与えたらエラーが発生するのか」というところ。(アクセスログから攻撃パターンを見つける、というのとはちょっと違う)
ここが悩ましい。。

「学習データに使用した入力をそのままそっくり与えれば発生するでしょう?」
のはずですが、実際は発生しない。
となれば、AI云々以前の話で、それ以外の条件があると言うことになるかもしれない。
可能性としては微妙なタイミングの問題もあるかもしれないので、ミリ秒単位の精度が必要なのかもしれない。
さすがにこのレベルになるとLSTMですら難しいだろう。どんなにニューロンの数を増やしても無理なはず。

どのようなパターンで発生するのかAIが理解できたとしても、本質的にはパターンでは無くタイミングの問題だとすると現代のAIではそこまで洞察することは無理。

2020.9.7

ほぼ諦め気分のログ解析ですが、「それじゃ、どのログがエラーを起こすのか?」という視点でログを少しずつ削りながらAI予測をやってみた。
近傍の前後のログでエラーが出る。
学習に使用したデータ長に寄ると思うので、当然と言えば当然だが。。
再現テストに必要なパターンを絞り込むためのアプローチとしては有効だとは思う - これ重要

なんだかんだといってもやはり、学習に使用したデータ数が圧倒的に少ないのではないかと思う。
滅多に起きないエラーなので、学習データを集めることができない。

これは現代のAIにおいては致命的なので、AIによるアプローチは諦めざるを得ない。
様々な経験的背景を考慮することができるAIを作ることができればまだ可能性はあるのだが。。。
そういうモデルを人間が考えなければいけない。モデル構築など今のAIには無理。

ただ良かったのは、今回の件を通してKerasを使えばLSTMも容易に使えることがわかったところだろうか。

2020.9.17

ログ解析をAIでやる際にもう一つ良かったこと。
データの前処理を行う際に、想定していないデータを検知できる。

データの前処理はAIの学習データを正確に作らなければいけないため、少しでも間違いがあってはいけない。
そのため想定外のデータが来た場合はPython scriptで例外を投げるように作ってある。
このおかげでこれまで目視で漏れていたエラーを把握できるようになった。

さて、本来のログ解析。学習データが少ないのがネックだが、GANをやってみようかと思う。
事象がレアな場合はAutoEncoderという手もあるけど、LSTMでAutoEncoderは難しいよね?
やりたいこと・知りたいことはエラーの検知では無くて、エラーを発生する入力パターンなので、GANを使ってgeneratorがどんなパターンを生成したときにdiscriminatorが正解を出してくれるのか。

恐らくだが、学習データが少ないためありえないパターンで正解が出てくると思う。
でもそれはそれで、そのパターンで実機で動作させ、エラーは起きないよ、っていうのをAIに学習させれば良いと思うが、これの繰り返しが恐らく数回〜数十回は必要だろう。大変だけど、事象がレアな問題は可能性がある限りやってみるしかない。

PythonとPerl話

Pythonを真面目に使い始めて1年以上経過した。まだ初級レベルで時々グーグル先生にお世話にならないといけないが、ようやく自分が作りたいものを自由に作れるようになってきた感じ。

私の中でPythonがscript系ではすっかりメイン言語になったが、最近のPerl(といっても3年前)が、大幅な仕様変更があり驚いた。

require 'web.cgi'

なんていう書き方は普通だが、このweb.cgiが同じディレクトリにある場合、デフォルトでは認識できない、ということをググりまくってようやくわかった。
セキュリティ上の理由から@INCからカレントディレクトリを外してしまった!!
そんなのありうる?

Pythonもいずれ、
import mylib in current directory
みたいな記述をしなくてはいけないのだろうか?

バカすぎる仕様変更。
セキュリティ意識の低い人のために無駄な仕様変更は止めて欲しい。

2020.9.24

AIを動かす良い季節になった!

久しぶりに間取り図認識の改善をやってみた。
これまで30%程度の誤認識があったので、CNNを使って誤認識された非間取り図を取り除くプログラムを作ってみたけど、どうしても誤差が小さくならなかった。(7.25時点)

しかしよ〜く見たら単純なミス。誤差関数をbinary_crossentropyにしたのにoptimizerがrmspropのままだったのが原因。これをsgdに変更したらうまくいった!

全体的に誤認識率は1%以下程度になったので、十分実用的。
(間取り図を閲覧していて百枚に1枚程度の関係ない画像は全く問題にならない)

Yolo + simple CNNの二段構えだけど、少ない学習(数百枚程度の画像)で非常に高い認識率が得られました。
素晴らしい〜

まだ多少問題はあるのの、認識率は十分実用レベルなので公開しても良いレベルかな。
けど、間取り情報だけ見たい人はいないだろうなぁ。。

こういう機能はそもそも不動産サイトが提供すれば良いんだけど。
需要が無いから機能が無いわけで、だったら公開する必要はやっぱり無いね。
そもそものそもそもだけど、そういうデータを公開したところで、それを扱える人は私と同じようなことをやっている人だし、そういう人は自らシステムを作っているはず。
もし公開するのなら、誰でも使えるようなシステムにすべきだろう。

ログ解析

この問題が自分の中で最重要課題。
大抵のバグは1日くらいテストすれば再現するけど、今抱えているいくつかの問題は一週間、あるいはそれ以上のテストをしないと再現しない。

これをAIを使って解決したいと思っていますが、今のところどういうモデルを使ったら解決できるのかまったく見えていない。

困っているのは私では無くてユーザーなので、なんとか解決したい。

ハードウェアの問題かもしれないが、そうだと言える証拠が無いとハード屋は動かない。

2020.9.29

ログ解析はLSTMなどのRNNを使っただけでは何の解決にもならない。
(事象の頻度が少ない異常検知であり、異常かどうかを知りたいのでは無く、どういうパターンなら異常になるのか知りたい - 特殊すぎる?)
となればGANを使うしか無いはず。(ここまでは間違ってないはず)
GANの中で有望なのがSeqGANではないかと思うが実装例が少ない。(画像系は非常に多いけど)
とりあえずSeqGANを徹底的に調べてみるか?
どういうアプローチが良いのか全く見えていない。

こういうことに詳しいことに教えを請いたいところだけど、その前に自分自身で追い込んでみないと。

2020.9.30

ログ解析は諦める。あれはやはりハード側の問題なので、AIレベルでは解けない問題。

ただ、GANの分野は色々と面白そうなので、ログ解析からどういうパターンが問題なのか、っていう方法は今後も調べてみたいと思う。ググっても出てこないからやりがいがある。

今は昔と違ってプログラマー人口が圧倒的に多いから、誰かがやってそうだけど。(公開していないだけ?)

2020.10.16

某不動産サイトから間取り図だけを取得するAIはかなりできがいいと思っているけど、問題はどれだけの時間がかかっているのか。これを数分で、とかいうのなら素晴らしい。しかし、実際はscrapeとAIによる判断が必要なのでかなりの時間がかかっている。(複数の路線の物件を見ているのもあるけど数時間?)

例えば100時間かかる作業がAIのおかげで10時間になった、ではインパクトが少ない。この辺は技術と言うより見せ方の問題だろうか。

個人的にはその10時間がすべて自動的にやってくれるので長いとは思わないのだけど・・・
それよりは間取り図から自分のお気に入りの間取りを探す方が大変。
ほとんどが対象外なので、、、これもAIに学習させたいところだけど、たぶん難しいだろうな。。

2020.10.24

間取り図だけを抽出してくれるので、効率は非常に良くなったのだが、なぜか自分にとって魅力的な間取り図の物件がほとんど出てこなくなった気がする。

効率を求めると失う物がある典型例だろうか?

検索対象を広げたせいもあるが、間取り図だけで千件近い。これをすべて目を通すだけでもかなり大変。
(実はこの中には重複画像がかなりあるのでそれを除去すれば200件程度になる?)

まずは重複画像の除去をなんとかしなければ。

2020.11.7

AIとは直接関係ないけど、Pythonで直接AMV codecのframeを読み出しができれば、かなりの作業が楽になるのだが。。
一旦mp4に変換してからでないとPythonで扱えない。
AviUtlは扱えるのに、ffmpegは扱えない。
たぶんAviUtlはDirectShow filterを使っているからだろう。

2020.11.27

Suumoから間取り図だけを抽出するAI。これはほぼ完璧にできたけど、コロナのせいか、自分が希望するような物件はほぼ出てこなくなった。
そうなると、やっぱり「自分好みの間取り」を探してくれるAIを作らないといけないか。。
今のAIレベルだとたぶん難しいだろうなぁ。。
自分の場合は「卓球台が置ける部屋があること」が第一条件になるけど、これは画像認識というより、厳密な物理的情報になると思うのだが。。これってAIでできるんだろうか?
例えば、同じ8畳でも真四角な部屋より、縦長な8畳なら卓球台は置ける。
こういう情報は今のAIで学習できるんだろうか?

2020.12.5

Yoloで、動画ファイル上の任意のフレームを認識処理させることができないか、と色々と調べていたが、ようやくできた。(ただし、Windowsのみ)
もちろん、OpenCV+Pythonを使って、mp4 file open -> 任意フレーム抽出 -> darknet.exe呼び出し -> 任意フレーム抽出 -> darknet.exe呼び出し ...
とすれば可能ですが、学習済モデルをその都度読み込むため非常に時間がかかる。

参考にしたのはこちら。https://midoriit.com/2020/06/darknet-yolo%E3%82%92python%E3%81%A7%E4%BD%BF%E3%81%86.html

これでやってみたところ、pythonを終了しない限り、学習済モデルの再ロードはされません。素晴らしい!

残念なのは、Linux版では動かなかったこと。
ValueError: NULL pointer access
と出たり、uselibを実行すると、
uselib: error while loading shared libraries: libdark.so: cannot open shared object file: No such file or directory
が出たりする。(誰か教えて。もちろん LIBSO=1 してますし、libdarknet*.soはあります)

2020.12.10

cloudによるGPUを一時的に使用するにはreasonableだけど、継続的に利用するなら購入した方が良い、だったけど勤務先の会社が社内向けに提供を開始するという話があり、何とか理由をつけて利用できるようになれば自前GPUより遙かに強力なAI計算が(自腹を切らずに)できるようになる!素晴らしい〜
(A100をMAX 128だって!)

2020.12.11

Suumoから間取り図を取得するシステムはほぼ完璧なんだけど、問題は似たような間取り図が多い。
そこで類似画像を取り除くプログラムを検討していたところ、一番良いのは次の通り。
・average hash
・最大矩形による比較
この二つ。
これでほぼ完璧に類似画像を除去できる。
average hashはどこでも取り上げてあるので説明は不要だけど、それに最大矩形を組み合わせる、っていう記事は見つけられていないけど、これはとても有効でした。(1,000個あった間取り図が500個に減ります!)

Average Hashに関してはこちらを参考:
https://water2litter.net/rum/post/python_imagehash_diff/
hashは4つ使用して、最悪値を除外し、残りのハッシュ値が規定値以下なら類似画像と認識。

外接矩形に関してはこちらを参考:
https://water2litter.net/rum/post/python_cv2_outerrectangle/index.html

2020.12.22

pipをversion upしたら、proxy経由でpip installできなくなってしまった。(pip version=20.3.3)

WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:777)'),)': /simple/requests/

ググると色んな方法が書いてあるけど、いずれもダメ。
pipのSSL仕様が変更になったのだろうと推測し、次のようにpipをバージョンダウンしたらOK。
get-pip.py install pip==20.1
※get-pip.pyは別途ダウンロードが必要
別のPC(Win7)では、HTTP_PROXY, HTTPS_PROXYを削除したら動いた、というのもあり。

→HTTPS_PROXYを正しく設定したら動くようになったorz

2021.1.6

今日は寒かった。暖房をつける代わりにAI等の計算にGPUリソースを無料で貸し出します!
詳細は下記メールまで。
GTX1080, memory=12GB, CPU=i5-4460@3.2GHz(4core)、SSD数百GB空き、Ubuntu18.04

2021.2.15

リソースの無料貸し出しは暖かくなってきたので終了します。
誰もこの日記を読んでいないから申し込みは無かったですけど。


連絡先: