駄日記 (未完結間欠日記)

> このところせっせと段ボール工作に精を出していたところ、 むかーし百均で買った木工用ボンド (正確には「セメダイン木工用」、まあ成分一緒だけど) が残りわずかになってしまったので、 この際、紙にも紙以外にも使えてできれば耐水性のある接着剤をひとつ買おうかな、 と思ってざっくり検索かけていろいろ調べてみた結果、 似たようなタイプの接着剤を 5種類も買ってしまった。 そんなに使わないのに…。 このちっちぇえ木工用ボンド (50mL しか入ってない) も、7年も前に買ったやつなのに…。 っていう。
そしてついでに先日はさみがひとつダメになったので、 代わりのやつを買おうかな、とこれもざっくり検索かけていろいろ調べていった結果、 さらに 3つもはさみを買い足してしまうという。 よくよく考えれば以前に必要数以上買ってるんだから既にある分で足りてるのに、っていう。 使い分けどうすんだよ。
これらはいずれもいつもの「試してみたい病」の症状なんだが、 接着剤とか全部試し終える前に寿命尽きるんじゃねーのワシ。 なお接着剤は 5種類のうち 4種類がセメダイン社の変成シリコン系、 1種がコニシの (独自開発っぽい) シリル化ウレタン樹脂の製品。 はさみは 1つがレイメイのスウィングカットっていうやつ、残り 2つは PLUS 製で、 片方は洗えることを謳った台所用の製品で、片刃がぎざぎざになっていて紙なんかは却って切りにくい。 試しに紙を切ってみたらジャリジャリジャリっという感触で違和感があった。 でも野菜だの肉だの、厚みのある食材なんかを刻むのにはいいかも…まだ試してないけど。 もう片方はごくスタンダードな (といっても PLUS のフィットカットカーブシリーズの) 事務用はさみだが、 以前買ったものは刃同士が接する内側の面が (一般的なはさみ同様) 平面だったものが今回買ったのは緩い凹面になっていて、 粘着テープを切った時などに糊がつきにくくなってるらしい。 以前買ったコクヨやナカバヤシのはさみは緩い凹面ではなく、刃のついている部分だけが段差状に飛び出ていて、 やはり糊のつきにくさを謳っているが、 まあ原理的にはほぼ同じか。
しかしこれでウチからコクヨのはさみがなくなっちゃったなあ…。 先日ダメになったやつも切れ味は特に落ちてなかったし、ハンドルの樹脂がちぎれなければまだ当分使えたんだろうけど。 今回コクヨを買わなかったのは…同じ“刃の迎え角が (ほぼ) 一定”を謳った製品でも、 PLUS の“フィットカットカーブ”の方が、コクヨの“ハイブリッドアーチ刃”よりも、 刃の先っちょ部分の使いやすさが若干上に感じるので…。 ひょっとするとなにか特許的なからみでプラスと同じ刃のカーブにできなかった (しなかった) のかもしれんけど。 まあ、用途によっては刃がカーブしているはさみよりも刃がまっつぐなフツーのはさみの方が使いやすいこともままあったりするんで (特に刃の先っちょを使って細かい刻みを入れたい時とか)、 フツーのはさみもあった方がいいんだよな…。ホントは。 いや、もう買い足さないけど。

> メモ。算術平均値を逐次的に計算する方法 (オーバーフロー避け)。

say average(1 .. 10);  # 5.5

sub average {
    my @data = @_;
    my $av = shift @data;
    my $n = 1;
    $av += ($_ - $av) / ++$n for @data;
    return $av;
}

> ヨドバシドットコムで買った、手指消毒にも使えるというウオッカ (66%)、ニオイがそこはかとなく乙類焼酎だこれ。 いいニオイのようなムッとくるニオイのような…。 消エタと同等くらいに蒸留されてるかと思ったら、明らかに「酒」だったか。 ちなみに消エタはずっと以前から、消毒よりもむしろちょっとした清掃に重宝してきたが、 これでなにか清掃するとその都度なんとなく酒を飲みたい気分が喚起される…。 まあこれも飲めるんだけどね。酒だし。飲まないけど。
酒のニオイはするけど、もちろん手指消毒に使う分には支障ないんだろう。 消毒用として薬局で市販しているエタノール類にも価格を下げるために混ぜ物している製品があるくらいだし。 よく見るのは IPA (イソプロパノール) を混ぜてるやつだが、 昔買った中にユーカリ油 (揮発性) をごく微量添加しているのもあった。 微妙にいいにおいがして割と好きだったんだが、その後ワシが行く範囲の薬店では見かけなくなってしまってちょっと残念…。 たぶん探せば今でもどこかに売ってはいるだろうけど。

> 郵便受けに国勢調査の調査票が入っていた。 そうか、今年は国勢調査の年だったか。 さすがに回答はオンラインが推奨になってるな。 ちなみにオンライン回答できるようになったのは 2010年から、しかし試験的な導入で対象も東京都だけだった。 それより前の 2005年の時点ではまだ調査員へ回答手渡しが原則、郵送も可、くらいだったし、 さらに前は封筒にも入れずハダカの状態で調査員へ手渡しだったんだなあ…もう覚えてないけど。 オンライン回答の受付開始が 14日 (月曜) 以降になっていたので、 14日の早朝にさくっと回答しておいた…。 名前だのなんだの、データ集計には不要な (と思われる) 個人情報までいろいろ書かされるのが相変わらずヤな感じだわ。 しかし国勢調査かー。国勢ももはやすっかり衰えてしおしおになってきてるんだろうなー。 でもって 5年後にはさらに顕著に出るんだろうなー。

> Chromium ベースの Iridium というブラウザは、 なぜか拡張機能の管理画面から「削除」ボタンを押しても無反応で、拡張機能が削除できない。 バグか不具合と思っていたんだが、ふと検索してみたら、 ブラウザ上部の各拡張機能アイコンの右クリックメニューから「Remove from browser...」を選択すれば削除できるらしいことが判明した。 …いや、これやっぱりバグか不具合だよな。仕様と呼んじゃいけないよな。 だって“拡張機能の管理画面”に「削除」ボタンがちゃんと表示されているのに、 そいつらが“飾り”でしかないんだもんな…。 まあとりあえず、いちいち Iridium 本体を設定 (フォルダ) ごとアンインストールして再インストールする、とかしなくても、 拡張機能が削除できることが分かったのでよかった…。
なお、同じく各拡張機能で、有効無効の切り換えができない (トグルを操作しても反映されない) という症状もある。 管理画面からトグルスイッチを操作すると見た目だけは反映されたように見えるが、 ページを再読込すると元に戻っている、つまり内部状態には反映されていない。 そしてこれについては今のところ対処法はなさそう。 まあどうしても一時的に無効にしたい場合でも、諦めて一旦拡張機能を削除して、 有効にしたくなったらまたインストールし直す、とかするしかないだろうな。
Iridium は他にも、Advanced Font Settings を入れているのにフォントサイズのコントロールが利いているのかいないのかよく分からなかったりとか、 登場してけっこう日がたってる割にアヤしい振舞いがちらほらあってあんまし安心して使える感じじゃないんだよなあ…。 つーかまあ結局ぜんぜん全く使ってないんだけど。
今なら Chrome 互換で Chrome より安心して使えそうなものを選ぶなら Brave Browser あたりを選択しておけばいいんじゃなかろうか。 個人的には Chromium 系の常用ブラウザは Cent Browser にしてるけど、 Windows 環境でのフォント表示 (の汚くなさ) が Chromium 系で一番マシだからなので安心して使えるとかはあまり考えてない (ちなみに Cent Browser は Windows 用しかない)。 ウリは高性能高機能寄りなので、まあ一番使ってて便利ではあると思う。 といってもビルトインされてる機能はほとんど活用して (できて) ないけど…。

> 7月のレジ袋一律有料化以降、前よりレジ袋を買う (求める) 頻度が増えた気がする。 まあ有料化以降は毎回レジでレジ袋についてのやりとりが発生するようになったので、そういう印象になってる可能性もあるけど。 でも以前から、レジ袋を入手したい時にはなるべく無料でつけてもらえる店を選びつつも、 あまりタダでいろいろもらうのもなんだし…店員さんにレジ袋を用意してもらう手間や時間も (わずかとはいえ) かかるし、と思って、 (店によらず) なるべくバッグ持参で買い物するよう心がけてもいた。 それが今はどこで買い物してもレジ袋に関しては条件がほぼ同じな上、 どっちみちレジ袋のある程度定期的な入手は必要なので (主にゴミ袋として使うため)、 結局、前よりもバッグ持参せずに気軽に買い物に行ってレジ袋もためらいなく購入するようになったよーな気がする。気持ち的に…。 なにしろ今はレジ袋を買う買わないに関係なく、そのためのやりとりがレジで必ず発生するんで、 レジ袋をつけてもらうかもらわないかと、レジでの手間や時間がかかるかかからないか、があんまし関係なくなっちゃったからな。
ところでレジ袋一律有料義務化ってなにが大義名分になってたんだっけ。 レジ袋 (プラスチック) の消費量削減とかだったような気がするんだが…。 ワシ個人に関しては以前とぜんぜん変わってないか、むしろ増えちゃってるかもっていうね。 有料化自体は別にいいんだけど、大局観がぜんぜん感じられないし、 ちゃんと結果もモニタ (して適宜軌道修正なんかも) するのかも分かんないしなあ。 どうするつもりなんだろうなーそのへん。

> 先日、室内でアシダカグモらしい奴を発見。 アシダカさん見たのはこれがたぶん初めてだと思う。 体長は 1cm ちょっとくらいであまり大きくなかった。 子供だったのか、もしくはオスだったのかも (よく知らないけどオスの方がちょっと小さいらしい)。 1～2日室内にいたようだが、その後姿を消した。 外に出てっちゃったのかな…。 無事に出られたならいいんだけど。
実は数日前 G の成虫が天井を逆さに這ってるのを見つけて G 用殺虫剤を念入りに噴霧してブチ殺した直後に、 少し離れた壁のあたりをよろよろ下りて行くのを見たのが最初で、 その数日後、目の前の襖だの壁だのを歩き回ってるのを再度見かけたんだが、 その時にな～んとなく足取りが覚束ない印象を受けたのだった…。 もしかして残留殺虫成分を食らっちゃったのかな…と若干心配だったんだが。 しかし殺虫剤を使わずに天井を逆さに這ってる成虫 G に対処するのはワシにはちょっと難しいんだよなあ…。 室内の G を放っとくのはヤだしなあ… (特に成虫は)。悩ましい問題。 凍止ジェットも一応あるんだけど近距離から一撃で狙える状況でないと使えないし…。

> 元の画像を縦横に (同一形状の複数パーツに) 分割し、 それらパーツの位置を一定の法則に従って入れ替えた、 簡単なスクランブル加工画像がある。 どちらが加工前でどちらが加工後か、人間の目でなら (元の画像にもよるけど) パッと見てほぼ確実に判別できるが、 プログラムでこれを判別するにはどうすればいいか。 というのを先日、ちょっと考えていた。 なお、分割箇所は画像の縦横サイズを元に簡単な式により一意に決まるものとする。
そもそも人間がパッと見で加工の有無を識別できるのは、 加工後画像の、各パーツの境界の部分の“画像の途切れ (不連続性)”を脳が検知するからなので、 この途切れ (不連続性) をうまいこと数値化できればいいのではないか。
そこで、まずは画像全体を、なるべく圧縮率の低い (あまり賢くない) 圧縮アルゴリズムで圧縮をかけたら、 加工前の画像の方が (画像全体の連続性が大きい分) サイズが小さくならないだろうか…と考えてみた。 しかし実験してみたところ、なかなか必ずしも思ったような結果にならない。
既存の圧縮アルゴリズムではなく、もっと単純なランレングス法だけとかならもうちょっと違いが出るかなあ… でも自分でいい感じに圧縮ルーチン書くのも微妙にメンドくさいな…。 それにランレングス法だと横方向の連続性 (不連続性) しか引っかけられないか… いや圧縮が目的じゃないんだから縦横両方向調べればいいのか… とか考えているうちに、境界の座標は計算で予め分かる前提なんだから、 この (縦横の) 境界をまたいだ 2点間の連続性だけを集中的に抽出すりゃいいんでは、と思い至った (やっと)。 加工前と加工後の両方の画像で“境界をはさんだ座標の 2点の (明るさの) 差の絶対値の平均”を取って比較してみたら、 後者の平均値の方が大きくなるのではなかろうか。
で、とりあえず手元にある jpeg と png 画像のうち適度なサイズのものを片っ端から (プログラムの内部的に) スクランブル加工して、 加工前後で前述平均値を計算比較判定してみたところ、 35477 ファイル中、誤判定が 3件、という結果になった。 90% 台には乗るかなあ…程度に予想していたが、実に 99.99% の正答率。 他の画像セットでもいくつか検証してみた範囲では、 誤判定が起きやすいのはモノクロ 2値またはそれに近いグレイスケールで、 地の部分の面積が大きい、比較的単純な線画のパターン。 また画像サイズ自体が小さいほど正答率が下がる傾向もありそう。まあそれはそうか。 ファイル単体では 0.01% 程度の確率で誤判定が起きるとしても、 複数画像のセットが揃って同じスクランブル加工をされている (またはされていない) 場合なら、 多数決方式でほぼ 100% の正答率を得られるだろう。
という訳で、前提条件が緩めとはいえ、こんな程度の計算負荷のあまり高くない方法でも十分実用になることが分かった。 こういうのって機械学習や深層学習なんかを駆使した場合だと、計算負荷や正答率はどうなるんだろうな。 やりようにもよるんだろうけど、比較してみたら面白いかな…。 まあやらないけど。やり方も知らんしのう…機械学習とか…。

#!/usr/bin/perl

use strict;
use warnings;
use Path::Tiny;
use Imager;
use File::Copy;

# スクランブル画像自動判別テスト

my $picsdir = '/f/sample_pics';
my $failure = '/f/failure';

my @files = path($picsdir)->children(qr/\.(?:png|jpe?g)$/);
my $total = @files;
my $errcount = 0;
my $count = 1;
for (@files) {
    my $img = load_img($_);
    next unless $img;
    my $scrambled_img = scramble_img($img);
    next unless $scrambled_img;
    my $avgs = calc_avg($img);
    my $avgd = calc_avg($scrambled_img);
    print $avgs < $avgd ? 'o' : '-';
    printf "\t%6d/$total\t$_\t%5.1f\t%5.1f\n", $count++, $avgs, $avgd;
    if ($avgd < $avgs) {
        $errcount++;
        copy $_, $failure;
    }
}
print "$errcount / $total\n";

sub load_img {
    my $path = shift;
    my $img;
    eval {
        $img = Imager->new(file => $path) or die Imager->errstr;
    };
    if ($@) {
        print $@;
        return '';
    }
    return $img;
}

sub scramble_img {
    my $img = shift;
    my $w = $img->getwidth;
    my $h = $img->getheight;
    return '' if $w < 32 or $h < 32;
    my $dx = calc_dlen($w);
    my $dy = calc_dlen($h);
    my $cpy = $img->copy;
    for my $y (0 .. 3) {
        for my $x (0 .. 3) {
            next if $x == $y;
            my $c = $img->crop(left => $dx * $x, top => $dy * $y, width => $dx, height => $dy);
            $cpy->paste(left => $dx * $y, top => $dy * $x, img => $c);
        }
    }
    return $cpy;
}

sub calc_dlen {
    my $len = shift;
    return int($len / 32) * 8;
}

sub calc_avg {
    my $srcimg = shift;
    my $w = $srcimg->getwidth;
    my $h = $srcimg->getheight;
    my $dx = calc_dlen($w);
    my $dy = calc_dlen($h);
    my $img = $srcimg->to_rgb8->convert(preset => 'gray');
    my @diffs;
    for my $x (1 .. 3) {
        for my $y (0 .. $h - 1) {
            my ($c1) = $img->getpixel(x => $x * $dx - 1, y => $y)->rgba;
            my ($c2) = $img->getpixel(x => $x * $dx, y => $y)->rgba;
            push @diffs, abs($c1 - $c2);
        }
    }
    for my $y (1 .. 3) {
        for my $x (0 .. $w - 1) {
            my ($c1) = $img->getpixel(x => $x, y => $y * $dy - 1)->rgba;
            my ($c2) = $img->getpixel(x => $x, y => $y * $dy)->rgba;
            push @diffs, abs($c1 - $c2);
        }
    }
    my $avg = shift @diffs;
    my $n = 1;
    $avg += ($_ - $avg) / ++$n for @diffs;
    return $avg;
}

> 以前から出版社などの公式 Web サイトで公開されているコミックスのうち気に入った作品を、 読み返し用に個人的にローカルに保存していたりする。 無償で提供されている作品だけだけど。
で、これら公開データの中には、元の画像が難読化加工されていて、 それをブラウザ内で (JavaScript により) 動的に再構成して正常に表示させているものがある。 きちんと調べてはいないが、CSS スプライト相当の仕組みで表示しているんだろう。たぶん。 なお画像の URL は JSON データなどに埋め込まれていて、HTML から直接リンクはされていない。 運営母体の違う複数サイトでまったく同じ仕組みを使っているので、 外部の会社からサービスなりシステムなりの提供を受けているのかもしれない。 まあ運営形態はともかく、 基本的にこれらサイトの画像データはすべて同じ方式で難読化されており、 JSON に埋め込まれた URL から画像を直接 GET して、 正常な表示に復元するのは特に難しいことはない (なお難読化していない画像を難読化解除処理すると、難読化画像ができあがる。 つまり、同じ画像に加工を施す毎に状態がトグルする)。
ところがこれらのサイトのうちのひとつが、ある日を境に、 元の画像データを難読化したりしなかったりをページ読み込みの都度ランダムに変えるようになった。 もちろん、なんらかの形で、難読化済なのかそうでないのかの情報もブラウザ側に渡されているはずなんだが、 ちょっと調べてみた範囲ではどういう形でその情報が渡されているのかわからなかった…。 現時点では GET し終えた画像そのものを見てどちらの状態か判別するのが確実そうだな、 と思い、加工前後両方を目視で確認して難読化状態の方だけ削除する、という形で対処してたんだが。 さすがに毎回毎回いちいち目視で確認して手作業で削除…というのが面倒になってくる… (2画面ファイラ (あふ) があるので作業自体は 4～5キーストローク単位でさくさく進むとはいえ)。 そうなるとあとはなんとかして画像の状態の情報を探し当てるか、 もしくは画像の判別を自動化するか。 まあ自動判別の方をちょっと頑張ってみるか…。 と思って数日ほどかけていろいろと試してみた結果、なんとか自動判別できるところまでこぎつけた。
しかし、そもそも元のデータの難読化加工自体、そんなに複雑なことはやっていないんだよなあこれ…。 もしもっと複雑な加工 (+ 目眩まし) をするようになったら対処すんのメンドくさいだろうな…。 まあ最終手段 (?) としては、ブラウザで表示させといてその画面をキャプチャしちゃえばいいんだけどね。 node.js + puppeteer ならモニタの実サイズを超えた大判でキャプチャするのも簡単だし。 ただ、元画像の原寸サイズ以外のスケールでキャプチャすると、 細かい線なんかがぼやけたりして画質がちょっと落ちるのが難点だけど (一応自動的に対処する方法もないことはないが)。

> 東芝EMIの「オリジナル版 懐かしの」シリーズ、これにて全種入手完了。全部中古だけど。 特に強く全種入手を目指していた訳ではない (つもりな) んだが…どうしてもな…コレクター根性がな…。 収録曲中、未所持だった音源は「たまげ太くん」の歌 2曲のみ。どっちも今回初めて聞いた歌。 当然、番組 (作品) 自体は見たことはない。まあ持ってる音源の大半はそんなんだけどねえ。 でも主題歌やイメージソングを先に知ってから本編に興味が向くこともたまにはある。

> 以下、ためこんでいた URL メモを吐き出し。