〜2013年11月中旬〜
なんか2台目がなりやすいなと思ったら、
それ/lib/udev/rules/51-android.rulesに登録してないよ。
追加したらsudoしなくてもいけるようになった。
なんと、それが原因だったんかい。
ということは/lib/udev/rulesに何も書かなくても、
sudo adb start-serverすればいけるんだな。
% adb kill-server % sudo mv /lib/udev/rules.d/51-android.rules
% sudo adb start-server * daemon not running. starting it now on port 5037 * * daemon started successfully * % adb devices List of devices attached 015d256851181c0e device m:~/1311 % adb shell date Mon Nov 11 21:25:31 JST 2013
deleteとかgsubを使わない方法。
% echo "私は'zarigani'です。" | ruby -pe '$_=$F*""' -aF\' 私はzariganiです。
1.8ならjoinしなくても$_=$Fでいい。
これは困る。スキャンした画像はほとんどがグレーなので。
どうして?
% advpng -z -4 001.png 391388 391388 100% 001.png (Unsupported bit depth/color type, 8/0) 391388 391388 100%
というわけで、zopflipngを使うわけなんだけどこっちはこっちですごく遅い。
スキャンした原画像を残すためにも少しでも小さくしたいわけだけど、
数が多いしねえ。
カラーでスキャンしたUbuntu Magazineをやってみた結果。
% du -sh * 158M C120-UM-NO07 154M C120-UM-NO07-advdef 146M C120-UM-NO07-advpng 146M C120-UM-NO07-zopflipng
C120-UM-NO07が元画像。pngで134枚。
advpngは20分ぐらいでzopfilipngは90分。この差はでかい。
advdefはpng画像だけでなく、.gzもzopfliと同じ方法で再圧縮してくれるすぐれもの。
あとadvzipってのもある。そのうちrubyのソースで試してみよう。
Rubyのソースでやってみた。
% cp ruby-2.1.0-preview1.tar.gz ruby-2.1.0-preview1.tar.advdef4.gz % time advdef -z -4 ruby-2.1.0-preview1.tar.advdef4.gz 14449544 12933217 89% ruby-2.1.0-preview1.tar.advdef4.gz 14449544 12933217 89% advdef -z -4 ruby-2.1.0-preview1.tar.advdef4.gz 416.71s user 3.49s system 99% cpu 7:01.89 total
7分とか結構時間がかかるが、1割ぐらいは小さくなる。
1度だけだし普通のgzipで伸長可能なので転送量を減らすためにもやっといたほうがいいかもしれない。
zipはadvzipで。
% cp ruby-2.1.0-preview1.zip ruby-2.1.0-preview1.advzip4.zip % time advzip -z -4 ruby-2.1.0-preview1.advzip4.zip 16124069 14290333 88% ruby-2.1.0-preview1.advzip4.zip 16124069 14290333 88% advzip -z -4 ruby-2.1.0-preview1.advzip4.zip 554.12s user 7.10s system 99% cpu 9:23.66 total
こちらもおなじような感じ。時間は余計にかかっているがunzipで展開可能。
-3でも試してみる。
% cp ruby-2.1.0-preview1.tar.gz ruby-2.1.0-preview1.tar.advdef3.gz % time advdef -z -3 ruby-2.1.0-preview1.tar.advdef3.gz 14449544 12927303 89% ruby-2.1.0-preview1.tar.advdef3.gz 14449544 12927303 89% advdef -z -3 ruby-2.1.0-preview1.tar.advdef3.gz 124.88s user 0.07s system 99% cpu 2:05.46 total
あれ、意外にも勝ってしまった。時間もかからないし。7zも優秀だったのか。
だったらzipも最初から7zで作るほういいか。
% unzip -q ruby-2.1.0-preview1.zip % time 7z a -tzip -mx=9 ruby-2.1.0-preview1.7z.zip ruby-2.1.0-preview1 >/dev/null 7z a -tzip -mx=9 ruby-2.1.0-preview1.7z.zip ruby-2.1.0-preview1 > /dev/null 92.19s user 0.39s system 359% cpu 25.752 total % ls -o ruby-2.1.0-preview1.7z.zip -rw-r--r-- 1 eban 14349935 2013-11-14 02:11:22 ruby-2.1.0-preview1.7z.zip
すばらしい。zopfliを使わなくても7zで十分だったか。
全部並べてみる。
% ls -oS ruby-2.1.0-preview1*.gz -rw-r--r-- 1 eban 14449544 2013-09-23 00:29:26 ruby-2.1.0-preview1.tar.gz -rw-r--r-- 1 eban 12933217 2013-11-14 01:48:59 ruby-2.1.0-preview1.tar.advdef4.gz -rw-r--r-- 1 eban 12927303 2013-11-14 02:06:54 ruby-2.1.0-preview1.tar.advdef3.gz % ls -oS ruby-2.1.0-preview1*.zip -rw-r--r-- 1 eban 16124069 2013-09-23 00:29:26 ruby-2.1.0-preview1.zip -rw-r--r-- 1 eban 14349935 2013-11-14 02:11:22 ruby-2.1.0-preview1.7z.zip -rw-r--r-- 1 eban 14290333 2013-11-14 02:01:43 ruby-2.1.0-preview1.advzip.zip
まとめるとgzipしてからadvdef -z -3がサイズ的時間的にもお得。
zipよりは7zのzip互換モードを使うほうがお得。
Google Chromeを先日新しいの入れたんだけど、妙に軽かったりと不思議に思い、
ふとfileで見てみたら32ビット版だった。
% file /opt/google/chrome/chrome /opt/google/chrome/chrome: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd3fff1d61e19a0c0c1b89af18c4741111dbc787b, stripped
まあいいか。ひょっとしてOnTabも32ビットにしたからいけたとか?
なんか最近文字列の選択がしづらい。
なぜか途中でキャンセルされて何度もやりなおさないといけない。
あとhototのリンクをクリックするとブラウザに2個3個と同じ内容のタブがでてきて、
ああそうか、だからキャンセル扱いなんだなと納得した。
どうしたもんかと基本の電源OFFしてONしたらなおった。
こんなことがないとOFFにしないしなあ。って裏にそんなスイッチがあるなんて気づかなかったよ。
OFFにする必要ないもんなあ。
調子に乗って400個ぐらいあるディレクトリで
% ls *.png | xargs -rP0 -n1 advdef -z -4
したら何も受けつけなくなった。強制的にリセットしたら全ファイル一度にやろうとしていた。
可能な限りってのはコアの数とか何も考えずにってことらしい。
というわけで/proc/cpuinfoとか見ることにした。と思ったらnprocなんてコマンドが。
% nproc 4
やっぱそういうコマンドも必要だよな。
卜部さんに教えてもらったので、parallelを使ってみる。
今回はconvertで。convertだとファイル名は途中に書かないといけないので-iオプション必須。
{}がファイル名に置き換わる。実際に実行すると
% parallel -i convert '{}' -resize x754 -type grayscale -depth 4 -verbose ../outdir/'{}' -- *.png 004.png=>../outdir/004.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 5c 0.450u 0:01.030 002.png=>../outdir/002.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 3c 0.450u 0:01.019 001.png=>../outdir/001.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 4.1KB 0.450u 0:01.039 003.png=>../outdir/003.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 8.19KB 0.460u 0:01.199 006.png=>../outdir/006.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 4c 0.440u 0:00.959 005.png=>../outdir/005.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 0.440u 0:01.099 007.png=>../outdir/007.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 0.440u 0:01.049 008.png=>../outdir/008.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 6c 0.450u 0:00.920 009.png=>../outdir/009.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 41KB 0.500u 0:00.440
という感じになる。parallelはコアの数をちゃんと考慮に入れてくれるので、
この場合は最大4プロセスで処理される。
xargsの-0相当がないのでfindとの組み合わせは注意。
convert '*.png'はメモリをやたらと喰うのでforで回していたが、やっぱ並列で処理したほうが速いよな。
convertでノンブルをcropしてtrimして目的の大きさへリサイズするなんてよくやるが、
そのときに縮小率を揃えるために何個かサンプル取るよね。
そこでどのくらいの大きさになったのか知りたくなる。
今までは
% identify 100.png 100.png PNG 1090x1600 1090x1600+0+0 8-bit PseudoClass 16c 136KB 0.000u 0:00.000 % convert -crop +0+100 -fuzz 80% -trim 100.png x.png % identify x.png x.png PNG 880x1349 1090x1600+105+125 8-bit PseudoClass 16c 109KB 0.000u 0:00.000
てなことをしていたが、info:で得られるようだ。
% convert -crop +0+100 -fuzz 80% -trim 100.png info: 100.png PNG 880x1349 1090x1600+105+125 8-bit PseudoClass 16c 0.020u 0:00.080
というか不思議なことにpngって元画像の情報も残ってるんだな。
高さとそのオフセットが知りたければformatで指定できる。
% convert -crop +0+100 -fuzz 80% -trim 100.png -format "%h %Y" info: 1349 +125
丁度半年だが、今回はなぜこんなに早いのか。
ひょっとしてちょっと前に
変な挙動してたが、
あれって結構電力消費してたりして?
まあ、半年も保てば全然問題ないんだけどね。