Ch's barn
日々の出来事を書き殴る
2020年2月16日日曜日
環境構築
PC環境を替えると、いろいろ入れなおすのがめんどくさいわけですが、それでも10年前に比べるとずいぶんとましになりました。
Windows10のインストールはSSDの高速化・低価格化の恩恵も伴って非常に速くなり、インストール後の更新もあらかじめ最新ビルドをUSBメモリで用意しておけばすぐに終わります。
WindowsXPのころはnLiteなんてツールを使ってインストールディスクをカスタマイズしたりしていたものですが、いまではそんなことを憶えている人も少なくなったのではないでしょうか。
さて、今回のPC新調後に入れたものは以下の通り。
追加で入れるものもずいぶん少なくなりました。
・Chrome
開発者ツールの使い勝手の都合上、普段使いのブラウザはChrome一択です。
Webページ制作ではChrome用に書いた後にIE11で確認し、まずいとこを見つけたら修正又は不具合回避を入れる感じです。
本当はIE11なんか対応したくないんですが、私がいる業界ではそれはまだまだ許されません。
なおFirefoxとEdgeでの確認は、「IE11で大丈夫なら問題ないやろ」という理由でよくオミットされます。(一応クライアントからなにか言われた時のためにインストールだけはしますが…)
というのが、先月までの私だったのですが、この度のChromium Edgeの正式リリースにより、Chromeはお払い箱になりました。
出力が基本的に同じで、利用している拡張機能も問題なく動いたので、それなら「Microsoft Edgeを使いましょう」を見なくて済む分、Edgeのほうがましということになります。
Windowsを使う以上はある程度の個人情報をMSにもっていかれるのは仕方がありませんが、Googleにまで差し出すのはどうにも気に入りませんしね。
・AdobeCC
お仕事の都合上PhotoshopとIllustratorは必須なので選択の余地はありません。
他には納品後のメンテナンスは別の人がやることが決まってる場合とかにDreamweaverを使ったりもします。
正直、経費的にはつらいものがあるのですが、Adobe Fontsが無制限で利用できるので、フォントだけで年5万円ぼったくるモリサワに比べればはるかにましではあります。
世のWebデザイナーさんには、モリサワパスポート以外では利用できないフォントは使用しないで欲しいと常々願っております。
・Office365 solo
WordやExcelはほとんど使いませんが、たまにPowerPointで作った資料や指示書が回ってくることもあるので一応入れます。
まあ、メインの目的はOneDriveの追加1TBなんですけどね。
現在、データは基本的にNASに置いてネットワークドライブとしてマウントし、処々の作業はそこで行っております。
IFは1GbEなので遅いといえば遅いんですが、扱うデータはせいぜい1GB程度のPSDやAIなので、さほどストレスはありません。
で、バックアップが必要なデータのみNASとOneDriveで同期させて冗長化を図っております。
・VisualStudio Code
コーディング用。
HTML/CSS/JavaScript/PHP/Python/Bashはこれで書きます。
拡張機能が豊富で非常に優秀です。
SublimeTextとか、ずいぶんお客さんは減ったのではないでしょうか。
これといいEdgeといい、MSは将来Chromiumを乗っ取ってしまうのではないかと時々思います。
・Notepad++
プレーンテキスト用。
昔はコーディングもこれでしたが、VSCodeに持ってかれました。
メモ帳もデフォルトがUTF-8(BOMなし)になったりと地味に改善はしてたりしますが、やはり機能不足です。
・Git for Windows
Gitは便利ですが、GitBashの利用頻度が高いです。
なにかちょっとコマンド打ちたいときにはGit Bash Here で、気づけばbashが5個くらい起動してたりします。
・WSL(Ubuntu18.04)
MSYS->Cygwin->MSYS2とWIndows上でUNIXライクな環境を使ってきましたが、もうGitBashとWSLの併用でいいんじゃないかな。
WSL2が正式リリースされたらもっと便利になるんでしょうかね。
・VisualStudio2019 Comunity
一応入れましたが、まだ一度も使ってないな。
・Python3.8
スクレイピングとか、コマンド1つではちょっと終わらない面倒な作業の時用。
VapourSynthは3.8にはまだ対応してないようなので入れてません。
・PHP7.3
HTMLテンプレートエンジンとか。
WordPressのおかげでやっすい共用レンサバでもPHP7はまず動くので、Dreamweaver使わないなら選択肢はこれのみではないでしょうか。
PUGとかも悪くはないけど、Node.jsとか動かせる共用レンサバってないしねぇ。
・AviSynthPlus
AviSynthはとりあえず無条件で入れる。
そろそろ何かまた書こうかなぁ。
ちなみに今回、インストーラ使って入れようとしたら日本語が文字化けしてました。
報告したら半日で直ったようですが、配布は次のリリースまで待たないといけないみたいです。
まあ、言語選択で英語選べば、何も問題はないんだけどね。
・AvsPmod
AviSynthのお共に。
もう64bitのみでいいですね。
・VirtualDub2
これもAviSynthのお供ですな。
・mpv
動画プレーヤー。
レンダリングも軽いし、avsも再生できるし、ほとんどこれで充分。
DirectShow系は正直飽きたかな。
・QuickViewer
画像ビューワー。
開発には私もちょっとだけ絡んでる縁で入れました。
表示も高速だし、zipやrarもそのまま開けるし、なかなかいいのではないでしょうか。
ショートカットをsendtoにおいて、コンテキストメニューからファイルやフォルダを開いてます。
欲を言えば、PSDもプレビューできるといいかも。
・TEXTCALC
電卓機能付きメモ帳で、とても便利。
もう10年以上愛用してます。
これを知ってしまうとWindows標準の電卓は不便すぎて使えない。
・萬屋
便利ツールの詰め合わせ。
作者は上記のTEXTCALCと同じでDV(メディアプレーヤー)の作者でもあるPRINCE KOGA氏。
とにかく多機能で、PC使ってて「あー、こんなツールがあれば便利かも」と思いついたときにこれをみると、たいていの機能はすでに持ってたりする変態ツール。
ファイルのリネームやカラーピッカー、簡易画像処理から、DirectShowフィルターのメリット値変更、ローカルHTTP/FTPサーバー、OutputDebugStringの表示、QRコード生成、各種ハッシュ値、Base64エンコード/デコードetc...
もうこれをWindows標準でつけてくれないかなぁ、MSさん。
というわけで、今回は「TEXTCALCと萬屋、とても便利だからみんな使うといいよ!」というお話でした。
2020年2月9日日曜日
PCデスクを新調した
これまで使っていたのは、リサイクルショップで買ったオフィス用スチールデスクだったのですが、どうも合ってなかったのですね。
私の身長は、高校卒業のころでギリギリ170cmでしたので、現在はおそらく169cm弱まで縮んでいます。
この身長で、踵がしっかり地に着く高さの椅子に座り、高さ720mmのオフィスデスクに腕を乗せると、肘を結構上げた状態になります。
これはペンを握って書き物をするなら丁度良い高さなのですが、キーボードを打つにはいささか高すぎです。
そこで椅子の高さを上げるわけですが、そうすると今度は踵が浮いてしまい太ももが圧迫され足がしびれます。で、足元にフットレストを置いていました。
でも、フットレストではやはり不安定なんですよね。
自分の体格でPC作業に最適な机の高さを調べると、だいたい65cm程度のようです。
そこで、知り合いの家具職人さんに「幅1500x奥行600x高さ650、ある程度頑丈であれば材質はお任せで納期緩めの催促なし2万円」でお願いしたところ、3週間ほどで出来上がりました。
正直かなりおまけしてもらえたと思います。知り合いに職人さんがいてよかった。
実際さがしてみると、高さ700mm未満のオフィスデスクって、少ないというか、ほぼゼロですよね。
コクヨもイトーキもオカムラもどれも高さ700mmばかりですが、キーボード作業でこれが丁度いい身長は178cmくらいだそうですよ。
女性とかかなり不便な思いをしている方も多いと思うんですが、どうなんでしょうかね?
11年半ぶりの自作PC
タイトルの通り、先月ひさびさに自作PCを組みました。
前回組んだ時はCPUがQ9450(Core2Quad)だったので、おそらく2008年だったと思います。
MBは一部で大人気?だったASUS P5Q、メモリはDDR2-800の2GBx4枚、GPUはたしかRADEON HD3850だったかな。
5年ほど前にDELLで安売りしていたi7 4790のミドルタワーに買い替えるまで、結構長く使っておりました。
で、今回自作した理由は、メーカー品やBTOだと、値段と性能が折り合わなかったから。
現在の情勢でデスクトップPCを新調するとすれば、CPUは最低でもRyzen5 3600でメモリ32GB程度は欲しいわけですが、BTOだと15万コースです。
10年くらい前は一式そろえるなら自作よりもBTOのほうが安上がりになっていた覚えがあるのですが、ここ数年でまた自作のほうが安くなってきてるようですね。
で、ちょうど正月セールで天神のツクモが安売りしてるようなので見に行って、その場でパーツ一式そろえました。
OS: WIndows10 pro DSP
CPU: Ryzen7 3700X(中古)
MB: ASUS TUF B450M-PRO GAMING
MEM: G.Skill DDR4-3200 16GBx2(中古)
GPU: GXT-1060
SSD: Lexar NM610 (M.2 NVMe 500GB)
電源: 750W (80plus gold)
ケース: MicroATX
中古と安物SSDで合計11万5千円程度で揃えましたが、現状では特に問題はないようです。
それにしても、最近の福岡の自作事情はほんとによくなりましたね。
10年前は自作パーツなんてアプライドと博多駅近くのドスパラくらいしかなかったんですが、今では博多駅前にヨドバシ、天神にビックカメラとツクモがあって、選択肢がずいぶんと増えました。
これ以上増えるのは厳しいと思いますが、これからもこれらのお店が維持できていけばいいなと思います。
2016年11月30日水曜日
まいとま1
いや、なんか動画関連のコードをいじるモチベーションが特に理由もなく急速に衰えたので、別のことをやろうかと思いまして。
そういえば以前にも似たような感じで数年ほどネットから消えてたことがあったような…まあ、しばらくしたらまた何かしらフィルタ書いたりする気になるのではないかと思います。
さて、Might and Magicなんですが、1はX1版、2はPC98版をやったことがあるんですが、もう一度やりたくなったのですね。
スタークラフトは既に倒産して久しいうえに洋ゲーの移植なせいかProject Eggでも復活は無理そうだしどうしたものかと思ったのですが、探してみたらDOS版なら今でも買えることが分かったので(しかも1~6のセットで10USドル…安い)、もう英語でもいいやとすぐに購入しました。
で、今回は1のお話。
Might and Magic Book One - Secret of The Inner Sanctum(以下MM1)は1986年のクリスマスセールの頃に発売された栄光のシリーズ第1作。
作者のJon Van Caneghem(ジョン・ヴァン・キャネガン)はUCLAの学生だった20歳のときにNew World Computing,inc.を立ち上げ、それから3年かけてほぼ一人でこのゲームを作り上げました。
なんでも「やっとできたぜさあ売るぞ」と思ったが引受先が見つからなかったので、Activision社が手を上げるまでの数か月はパブリッシャーも自分でやる羽目になり、NWCのオフィス(兼ヴァン・キャネガンの自宅のアパート)にかかってきた800本余りの電話(注文やユーザーサポート)の応対をしたとか。
最初はApple][版しかなかったこのゲームはその後徐々に売れ出してコモドール64やIBM-PC/AT互換機(MS-DOS)等にも移植されます。
はたまた、まだそんなに売れてない頃にいきなり日本から押しかけてきたスタークラフトの社長と契約したので、1987年末には日本製PC版(以下スタクラ版)も発売されるなんてことも起こりました。
こうしてMM1は世界中に広まり、ヴァン・キャネガンはゲームクリエイターとしての確固たる地位を築いたわけです……が……2016年現在にやってみると、ほんとつらいわこのゲーム。
つらい理由その1:グラフィック
モンスターの絵なんかはヴァン・キャネガンが自分で書いたにしては結構雰囲気出てるなぁとは思うんですが、色数も少なく、なにより画面が暗すぎる。
あと戦闘中はテキストしか表示されないので非常に寂しい。
自分はスタクラ版の見た目が結構好きだったので、余計にそう感じるのかもしれません。
つらい理由その2:経験値稼ぎ
DOS版MM1はスタクラ版に比べると、実はちょっと優しくなっています。
たとえばスタクラ版では最初はどのキャラも棍棒1本持ってるだけの無一文で、ある程度の装備を揃えるまでが非常にきつい(慣れれば実はそれほどでもないんだけど)のですが、DOS版はデフォルトキャラのCRAG THE HACKが200GOLD所持しています。
この違いが生まれた理由は、スタークラフトが移植に当たって参考にしたのは初期のApple//版であるのに対し、DOS版は発売後しばらくしてからヴァン・キャネガンが手を加えたバージョンを移植したものだからでしょう。
"M&M is also one of the most difficult games in which to get started, particularly if you have one of the earlier versions. In those, your party starts out with no money, no armor, and only clubs for weapons. This does not make for a very effective fighting force, especially when monsters show up in large groups. Characters die with appalling frequency under those circumstances.
Fortunately, by the time you read this, the newer version of the game should be out. In that one, the pre-created party that comes on disk will have some money with them, and you can mug 'em to equip your own characters a bit more decently. That, of course, is no guarantee they will survive, but at least their chances will have improved slightly."
(Computer Gaming World 1987年4月号より)
多分、発売後に押し寄せた800件の電話のうちの結構な割合が「ゲーム開始後すぐに全滅する」とかの苦情で、ヴァン・キャネガンもさすがに自分がやり過ぎたことに気づいた(もしくは電話をこれ以上受けるのが嫌になった)のではないかと思われます。
これ以外にもDOS版は若干優しくなっているところがいくつかあります。
例えばコーラック(ソーピガル地下)->アガール(エルキューン)->テルゴラン(ダスク)のスクロール運搬は、スタクラ版(&Apple//初期版)では1セットあたり500GOLD+経験値1人1500ptだったのが、DOS版では1500GOLD+経験値1人3500ptに増えています(ちなみにこれがDOS版におけるもっとも効率の良い稼ぎ)。
まあ、スタクラ版はスタクラ版でバグ(PIRATES MAPが一度にたくさんもらえるとか、木登りクエストはどれか1本登るだけでOKとか)がある分、Apple//初期版よりはラクなんですが。
でもやはりきついのですね。
ハードは80186のTandy2000とかではなくi7上のDOSBoxなので1セット2分程度しかかからないのですが、それでも何百回も繰り返すとなるとさすがに御免被りたい。
でも繰り返さないとなかなかゲームは進まない……だってこのゲーム、DOS版でもモンスターとエンカウントしちゃうと逃げるのはまず無理なんだもの……orz
そしてチートに走る
昔は自分もこの程度では音を上げたりせず嬉々としてやりこんだものですが、さすがに年なのか気力がさっぱりわきません(つーか昔の俺は色々頭がおかしかったのでは)。
MM1といえば有名なセーブデータを2つ用意する所持金&アイテム増殖チートもありますが、あれは昔やったしねぇ……。
で、どーしたもんかと思いつつ試しにセーブデータ(ROSTER.DTA)をバイナリエディタで弄ってみたところ、どうやらこのゲーム、データ改変チェック等は一切行っていないようなので(まあ、スタンドアローンのゲームでそんな手間かけても意味ないとも思いますが)、こんなツールを作りました。
mm1cheat
データ解析しながらあれこれやってたら結局一日潰れましたが、(主にコード書くのが)楽しかったので、これはこれで元は十分に取れた(10USドルの6分の1だから190円くらい?)と思います。
あ、まだ一度もやったことのない人はこんなの使ったらダメですよ。
ファミコン版はバランス調整も結構いい感じになってるらしいので、未経験の方はそちらをやることをお勧めいたします。
2016年9月1日木曜日
MPEG2DecPlus その3
修正:
- RFFフラグアリのソースでupConv > 0のとき出力が壊れてたのを修正。
- 不要になったバッファの確保を削除。
JEEBサーバにある最新版バイナリへのリンクを右側に追加しましたので、ほしい方はそちらからDLしてください。
なお、今回のバグは0.0.0からすでにあったようなので、旧バイナリはすべて削除されました。
2016年8月31日水曜日
画像端処理
例えば縦方向のみで半径2の平均化フィルタを書くとします。
このとき各サンプルの配置は下図のようになりますが、
ここで問題になるのは画像の上端及び下端をどうするかです。
参照する値が五つ揃わなければ(sa+sb+sc+sd+se)/5は出来ないので、足りない分をどうにかして補う必要があります。
ここで考えられるのは以下のようなものとなります。
パターン1:画像端は処理しない。
面倒なことは避けるという極めて常識的な方法です。
上のような場合は画像の上下各2ラインはそのまま入力値をコピーし、3行目から下端-2行目までの計算を行います。
この方法は半径が小さい場合は特に悪くはないのですが、半径が大きくなるとフィルタがかからない部分も大きくなりますし、重ね掛けをすると未処理のままの画像端の値の影響が大きくなっていく欠点があります。
パターン2:足りないところは0として計算する。
「ないものはないんだから0でいいだろう」という身も蓋もない方法です。
たしかにないものはないのだから、ある意味正しいのかもしれませんが、これはパターン1以上に問題があります。
特に重ね掛けをすると画像端の劣化は激しく、RGBなら真っ黒、YUVなら緑色に染まっていくことになります。
なんでもOpenCVのガウシアンブラーには、まさにこれが起こるのがある(あった?)みたいですね。
パターン3:画像端の色でパディング
存在しないからと言って0として扱うのは問題があり過ぎなため、画像端も処理したい場合にはよくとられる方法です。
存在しないところは境界の色がそのまま続いていると考えるわけですね。
これならばとりあえず全体を処理することが可能ですし、真っ黒になったりもしません。
ただし、半径が大きくなればその分だけ画像端部が参照されることも多くなるため、そこら辺の考慮は必要になります。
パターン4:ミラーリング
パディングの欠点を補うため、存在しない部分は上下(または左右)が逆になった画像がくっついているものとして処理する方法です。
これであれば画像端も処理できますし、上端だけが何度も参照されるということもそこそこ避けることができます。
今回来た質問は
> const uint8_t* sc = srcp; > const uint8_t* sb = sc + spitch; > const uint8_t* sa = sb + spitch; > const uint8_t* sd = sc + spitch; > const uint8_t* se = sd + spitch; この部分で、sbとsdは同じものになってしまうのではないでしょうか。というものでしたが、これも一種のミラーリングを行っているのですね。
CombMaskはインタレ映像のコーミングを見つけるわけですが、画像上端では次のような状態になりますので、saとsbはそれぞれseとsdと同一の点を参照するようにしているのです。
と、ざっと画像端処理について書いてみました。
画像端処理の問題は、多くの空間軸処理において起こります。面倒ではありますがなにかしら対策しないわけにもいかないので、どれにするのかよく考えて行いましょう。
2016年8月30日火曜日
MPEG2DecPlus その2
変更内容
・idct=5(IEEE1180 reference)を倍精度浮動小数点処理に戻した(より遅くなった)。
・idct=4として単精度浮動小数点処理のLLMアルゴリズムを実装(SSE2またはAVX2使用)
0.0.0においてはとりあえず64bit化を目標にしていたため、iDCT関連は3のみをintrinsicで書き換え、5は単精度浮動小数点処理として新規で書き直し、他は全部削除という少々寂しい感じでしたが、これで少しはましになったように感じます。
今回追加した単精度LLMは従来のidct=4(64bit floating point)の替わりになるものとして追加したつもりです(コード自体はDCTFilterで書いたものとほぼ同じ)。
品質は単精度のためほんのわずかに落ちますが、それでもほぼ最高品質と言っても問題はないですし、速度は向上しています。
そしてIEEE1180 referenceは単精度にしていたのをやめて倍精度に戻しましたので、出力も従来のものと完全に一致するようになりました。(ただし、一応SIMD化はしていますが、従来のIEEE1180 referenceよりも遅いです)。
ところでDGDecodeのidctはたくさんありますが、どれを使うべきなのかをちゃんとわかっている人って、現在だとどのくらいいるのでしょうか?
かつて、idct=5に丸め込みバグがあったころは「普通は6を除いた中で一番速いもの、とことん品質重視なら4」というのが答えでしたが、5のバグが直ってからは、よくわからないという人が増えてしまったのではないかと思ったのでついでに解説しておきたいと思います。
まず1、2、3の三つは使っているCPUの命令セット以外は同じなので、スピード以外はなにも変わりません。
7(simple MMX)は1、2、3よりも少しだけ質が良いですが、スピードを落としてまで選ぶほどのものかどうかは疑問があります。
6(skal)はスピードは3に並ぶほど速いですがIEEE1180 compliantではない(実用上はともかく、規格的にはダメな実装である)ため、3が使えるCPUでは選ぶ意義はまったくありません。
4と5は品質的にほぼ等価なので、もし品質をとことん重視したいならばより速い4を選ぶべきでしょう。
以上によりSSE2がまともになったmerom(core2duo)以降のCPUであれば、3か4のどちらか好きな方ということになります。
で、品質の違いを確認する方法なんですが、ググってみた限りではなぜか「これだ」と思えるようなわかりやすいものがみあたらなかったのでこれも解説します。
src = "xxxxxxxxx.d2v" #d2vであればなんでもよい ref = MPEG2Source(src, idct=5) #とりあえず最高品質とされる5 target = MPEG2Source(src, idct=4) #5と比較したいもの d0 = mt_lutxy(ref, target, "x y - abs 0 > 255 0 ?", chroma="process").SUbtitle("diff>0") d1 = mt_lutxy(ref, target, "x y - abs 1 > 255 0 ?", chroma="process").SUbtitle("diff>1") w = BlankClip(d0, width=4, color_yuv=$FFFFFF) StackVertical(StackHorizontal(ref, w, target), StackHorizontal(d0, w, d1))これでこんな感じの画像が得られるはずです。今回はffmpegでエンコードした640x480のmpeg2を使いました。
下半分の左側はidct=5と比較して出力が一致するサンプルは0、1でも違う場合は255に変換したもの、右側は出力が2以上違う場合のみ255で他は0に変換したものです。
自分的には出力の違いが1を超えない(右側は全て単色)で、かつ違いの出るピクセルの数が0.01%未満であれば最高品質と言っていいのではないかと思います。
出力1の違いを肉眼で判別できる人間はいませんし(もし出来るという人がいれば、それは実は人間ではないか、頭がおかしいか、ただの嘘つきのどれかです)、なにかしら軽くフィルタを一つかけるか非可逆圧縮でもしようものならば簡単に吹き飛んでしまいますので、違いなんてでようがないのです。
品質とコストの兼ね合いをどうするかは人類普遍のテーマです。
安易に遅い方が質が良いとか考えないよう注意してください。