Libre10のリリースの用意をしていて、debianだと大体の依存ソフトが
パッケージ化されているんだけど、solrpyだけがどうしてもPyPIに頼らざるを得ないということで、パッケージ化されているpysolrに乗り換えてみました。
ぶっちゃけそれほどの違いはなさそうだし、移行も簡単だったんですが、
multiValuedのelementを挿入する際にpysolrだとelementはstringである必要がありますといったエラーが出てうまくいかない
solrcon=pysolr.Solr(http://~~~:8983)
solrcon.add([{
'single' : 'single-text'
'multiValued' : ['multi-text1','multi-text2']
}])
こういう風に設定するはずなんだがうまくいかない。
結論から言うと、pysolrが内部で使っているlxmlのバージョンが古いとこのエラーが出るらしい。
ということでlxmlのバージョンを3.2.1にアップグレードすると、この問題は起こらなくなりました。
jQMを使ってLibre10向けのmobile頁を作っていて、
どうもviewport タグを設定するとスマホ/タブレットでズームが出来なくなるのが気になって調べてみた。
<!DOCTYPE html> <html> <head> <title>My Page</title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" href="http://code.jquery.com/mobile/1.2.1/jquery.mobile-1.2.1.min.css" /> <script src="http://code.jquery.com/jquery-1.8.3.min.js"></script> <script src="http://code.jquery.com/mobile/1.2.1/jquery.mobile-1.2.1.min.js"></script> </head> <body>
こちらは公式http://jquerymobile.com/demos/1.2.1/docs/about/getting-started.htmlからの引用このままだとuser-scalable=noになって、ズームできないから変えてみようと言うことで
<meta name="viewport" content="width=device-width, initial-scale=1">を <meta name="viewport" content="width=device-width, user-scalable=yes, maximum-scale=5">へと変えてみたわけです。
しかし、何も起こらない。
chromeの開発者ツールで見てみると
該当部elementが
<meta name="viewport" content="width=device-width, user-scalable=yes, maximum-scale=5, user-scalable=no, initial-scale=1 "> になってるんです。
どうやらjQuery mobile内で書き換えられてるらしい。
mobileinitで書き換えてみたりしたけれどもうまくいかず、
最終的にviewportの設定をjQuery mobileを読み込んだ後に変更して、うまくいくようになりました。
<!DOCTYPE html> <html> <head> <title>My Page</title> <link rel="stylesheet" href="http://code.jquery.com/mobile/1.2.1/jquery.mobile-1.2.1.min.css" /> <script src="http://code.jquery.com/jquery-1.8.3.min.js"></script> <script src="http://code.jquery.com/mobile/1.2.1/jquery.mobile-1.2.1.min.js"></script> 追加→<meta name="viewport" content="width=device-width, initial-scale=1"> ←追加 </head> <body>
さて、最近Libre10の開発中にsolr dbのindexを変更したくなったため、調べてみたところ
Solrではindexのupdateには対応してない!とのことで
reindexingが必要と言うことでした。
仕方ないのでlibre10用のSQLiteのDBにchanged=1としてupdateが必要であるというフラグを立てておいて
indexerの監視時にreindexするようにしました。
これでfqを使ったより高度な検索ができるようになるはず!
Libre10の開発をしていて、pdfからjpegを切り出すcgiの速度調査をしたいと思い、
プロファイルについて調べてみました。
調べた結果がこれ
http://search.cpan.org/~timb/Devel-NYTProf-5.02/lib/Devel/NYTProf.pm
プロファイル結果をソースコード付きでHTMLにしてくれるのが非常に便利です!
とはいえ、CGIの引数を与えたときの動きを見たかったので、Apacheの該当フォルダのconfに
SetEnv NYTPROF "file=/tmp/nytprof.out" SetEnv PERL5OPT "-d:NYTProf"
を追加、nytprofhtmlで解析して調べるようにしました。
画像縮小処理がscaleよりresizeのほうが早いとか、jpegtranは結構時間かかってるから軽量化せずに
表示させた方が結果的に早いとか、色々わかってとても便利でした。
[参考] : http://perl-hunting.blogspot.jp/2010/01/use-develnytprof-with-cgi-and-apache.html
[注意]
フォルダ内にあるCGIにアクセスする毎に/tmp/nytprof.outが上書きされるので、
テスト環境で実行した方が良いかと思われます。
先日からLibre10の開発を進めているわけですが、
Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成
こちらのサイトを参考にImlib2を実装してみたはいいものの、画質が綺麗という噂に惑わされ
ImageMagickを使うことにしました。
とはいえ、先ほどのブログでも言われていたことですが、ImageMagickは処理が遅いと一般に信じられています。
ということで巷にありふれている情報ではありますが、jpegの中に持った縮小済みデータを使って、
ImageMagickのresize高速化をしてみます
convert -resize [Width]x[Height] src.jpg dst.jpg から convert -resize [Width]x[Height] -define jpeg:size=[Width]x[Height] src.jpg dst.jpg
参考はこちら 本当は速いImageMagick: サムネイル画像生成を10倍速くする方法
これでサイズにもよりますが、結構な高速化が期待できます。
ちなみにresize関連のコマンドでscaleやthumbnailがありますが、測ってみたところ最も高速なのはresizeでした。
thumbnailならファイルサイズは下がるはずなので、そことのバランスになりますね。
前回のrec10に引き続き、誰得系プロジェクト第二弾!
Libre10を開発開始しました。
大学に入って資料やテストプリントなどをスキャン&OCRしてたのですが、
せっかくのこのデータ、生かさなきゃもったいない!
文書データを活かす→全文検索っしょということで、最初はデスクトップサーチを使ってたわけです
デスクトップサーチ最強でしょ、spotlight使いやすすぎワロタとか言ってたら、
スマホで使えなかったわけです。
スマホで使えなくて何がWeb2.0(死語)だ!ということで、時代はクラウド、そう、雲の時代なわけです。
蜘蛛の糸から雲へ。
なんとなく日本語的に収まりがよかったりしますが、そんなことどうでもいいです。
自分の持ってるデータ、クラウドで使えなくて何が情強(自称)だよ!ってことです。
御託はこれぐらいにして、
Libre10とは
検索エンジンにApache solrを用いて、検索結果のpdfを1ページごとに切り出して表示する、
pdf統合管理プラットフォームです。(大袈裟
http://sourceforge.jp/projects/libre10/
こちらから最新のソースなどは見られます。一応手元ではひと通り動いています。
久しぶりの投稿です。
手持ちの自炊後電子教科書を何とかスマホやタブレットで全文検索、観閲できるようにならないかと思い、
pdfから透過テキストを取り出して、眺めていたのですがどうにもミスが多く、手で修正する必要がありました。
もちろんそんなの面倒でやっていられないため、怪しい記号の羅列のまま使っていたわけですが、
新たに電子教科書全文検索エンジンLibre10を開発するに当たり、新たなOCRソフトに切り替えてみました。
これまでは読んde!!ココ Ver.13
を使っていたのですが、今回新たに
読取革命Ver.15 製品版
へと切り替えてみました。
気になる結果ですが、日英混在時の英語の文章が読んでココでは全くといって良いほど認識できていなかったのが
読取革命ではほぼ正しく、全体の合致率もおおよそ80%程度から90%程度まで上がっているという印象を受けました。
発売時期を見てみると2007年と2012年と5年もの間が開いており、さもありなんと言ったところでしょうか
思っていたよりもOCRエンジンの精度は上がっているようで、良い買い物をしました。
Windows8が発売したということで、早速WinVista/Win7からアップグレードしてみました。
元の構成は
CPU:AMD PhenomII X4 905e 2.5GHz(4コア)
Mem DDR2 8GB
HDD Hitachi HDT721010SLA360
GPU:Radeon HD5770
です。
いざ入れてみたところ、Winメニューがないなど違和感はあるが、案外使いやすい!
・・・ということもなく、そもそもWindowsストアやIE10など、メトロUI(タッチパネル用の新しいUI)向けのソフトを起動しようとすると10分近くかかります。
Webページ見るのに10分
Winストアの初期画面にいくまでに数分
これでは作業どころではありません。
原因を探るべく調べてみたところ、常にHDDアクセスが100%になっているのが気になったため、
今はやりのSSDを導入してみました。
Intel SSD 330 Series Maple Crest 240GB MLC 2.5inch 9.5mm Reseller Box SSDSC2CT240A3K5
これまでのHDDのベンチマークがこれです(Hitachi HDT721010SLA360 1TB)
Win8に併せて、CrystalDiskMarkも限定版にしてみましたw
SSDの結果がこれです
速度が大幅に上がって、Windows8自体も別次元の早さで動くようになりました。
Windows Experience Indexも5.4から7.1に上昇。これで律速がCPUになりました。
はっきり言えるのは、Windows8+HDDはまともに使えませんが、Windows8をきっかけにSSDを導入してみてはいかがでしょうか。