堕天使の煉獄

うーん。
でもやっぱいまさらjavascriptとかやりたくないなぁ。ってことで、ブラウザで動くミニゲーム的なのの開発環境再考。
webGL重いんだよなぁ……といいつつもc#の使えるunityがやはり楽なのかなぁ。

なによりjavascriptだとゲームのフレームワーク的なのはいくつかライブラリあるものの割と個人ベースなのと、ドキュメントが少ないてのもあって。
まずオブジェクトとかデータ構造しっかり作りたい派なので、その辺言語的にも環境的にもやりにくそうなんですよね。javascript@html5は。

でもunityもユーザー定義のデータ構造でがっつりってのはあんまし向いてないっぽい？　印象。
良くも悪くもＧＵＩの開発環境で便利な分、融通というか作り方をある程度固定されてる感じでちょっと息苦しさもあったりして。

でもちょっと久しぶりに調べてみたのだけども。
以前ちょっと触ってたときはver4.5でいまはver5.4。
気がついたら随分上がってるぅ。んでもって次の5.5が３月リリースで、その後は2017という年度名がついたバージョンになるそうな。
調べてると5.5に入る新機能で便利そうなのがいくつか目についたりして、微妙に
5.4いれたばっかりだけど5.5になるまで待とうかなて気になったりして、こっちも３月のリリースまでおあずけ状態なのかなと。
これまたタイミングが悪い。

タイミング悪いで思い出したけど、先日、そろそろＨＤＤが稼働時間２万時間に達しそうなのと、最近ちょっと音も大きくなった気がするし、読み込み速度も落ちてきてる気がする……。ってことで死ぬ前に換装するかなと重い腰をあげたのだけども。
うちの近所ってパーツショップ全然ないんですよね。一番近くて車で３０分弱のところ。ＨＤＤは通販で買うの怖いので直接買いたいし。
てことでパーツショップにＧＯ。
シーゲートは以前酷い目に遭ったのでヤダー。やはりＨＤＤは日立→東芝製だなということで東芝の3ＴＢのＨＤＤを買うことに。
お店到着。ＨＤＤ売り場みてみると東芝の4ＴＢは売り切れてる。3ＴＢは売り切れの札ついてないけど……鍵付きケースの中の該当品番の所はなにも置いてない……まあレジカウンタの中にあるんだろうな。この時点ですでにやな予感びしばしきてましたが。案の定、「済みません売り切れてます」の声……。
なんかおいらこういう目にあうことすごく多い気がするんだよな。
売り切れてないとぬか喜びしてからのがっかりパターン……。
再入荷の連絡待ちですごすごと帰宅……。ああついてない。


話はもどって、unity。
5になってからかなり変更点があるようで。シーン管理まわりがかなり変わってるんですね。以前はわりとこの辺、シーン切り替えでシーン内のオブジェクト全破棄とかの仕様で結構シンプルなミニゲームでは問題無いけどちょっと凝ったの作ろうと思うと逆に面倒で、シーンは結局一つで、シーン内で自前でオブジェクトの生成破棄の管理して、シーン内シーン管理的な事をするみたいな方法論もあったりして微妙な感じでしたが。

シーン内シーンどころかシーン自体を合成して結合したりとか、シーンの使い方がかなり変わったっぽいですね。

2Dまわりもかなり強化された感じぽ。
以前は有料じゃないと使えなかったものや、サードパーティ製？の拡張機能が標準機能として取り込まれていったものとかで、随分と至れり尽くせりな環境になってる印象ぽ。
でもその分、調べ物の量も増えそうだけど。

ああ、そういえばそういう感じだったか。あーここはかわったんだーと、徐々に思い出してきてるものの、古いプロジェクトのコードのこってたのでエディタで見てみるとCreateScriptableObjectPrefubとかコメント読んでも何やる物だったか思い出せないｗ　
ScriptableObjectてなんだっけ。とググってみたものの、なんかいまいちよくわからない。でも以前はなんかちゃんと使ってたっぽいんですが。
ろくにゲーム作らないでフレームワークばっか作ってた記憶しかないのですが、見たとこver5に上がって結局使い物にならない物ばかりな印象ｗ
オーディオ関係管理とか、シーンまたぎのシーン遷移エフェクト付きのシーン管理とか、わりとがらりと変わってしまった部分のコードが多いんですよね……。
この辺、いろいろと用意されてる開発環境って、過去ｖｅｒからの破壊的変更が大規模で発生すると、過去の資産がゴミになるってところが泣き所ですよね……。

うーん。


話は変わって麻雀関係調べてたときに出てきたの。



糞ワロタｗ

多牌少牌とか関係ねー。足りなきゃ山でも河でもどっからでも拾ってきて追加とか無法地帯ｗｗｗｗｗ
みーんな左手卓の上だしｗｗｗｗ



プロ参戦シリーズ
Part1ラストで牙をむき始めpart2から完全にカオスｗ
確認ワロスｗ
サマ無しで打つんとちごたんかいプロｗ

何でもありの露骨なイカサマアリ＆みんな気づかないフリ麻雀がこんな笑えるとはおもわなんだｗ

VisualStudio2017、３月７日リリースっぽいですね。ＲＣ版は急いで入れる必要もないかなとおもってスルーしてたのですが、最近ちょっとまたＶＳ触りたい案件が。

なにげにインタラクティブなコンテンツを増やしたいなーというのがあって。昔はブロック崩しとかあったけど、あれは人様が作ったツールの上に絵をのっけるだけって感じなので、もうちょっとお手製感ある感じの～ってことで。

flashは斜陽だといいながらも、いまだにブラウザゲームはflashのが多かったりするし、html5は重いし音が出なくなったりとかトラブルも多い＆ブラウザ毎の環境依存がまだまだ多い感じで、いまいち気楽にちょろっとミニゲーム作れる環境てのが思い当たらない感じで。

unityでwebGLだと、unityしばらく触ってないので大分忘れちゃってる＆まずフレーム回りから作らないとだし。最初の環境整備で時間食いそう。

flashだけどparaflaとか昔あったなー。あれで脱出ゲームとか簡単なの作るのもいいかなーといおもったのだけど、サイト閉鎖してる？
あとあれアクションスクリプトのｖｅｒがかなり低い所までしか使えなかったよなとか。
それにいまからflashってのも時代に逆行かなという気もする。

個人的にはあんまり好きじゃないｈｔｍｌ５は、それでも開発環境が特別な物がいらない、なんならテキストエディタだけで済む。ってあたりは手軽でいいんですけども。

ソースコード丸見えだったり、ちょっと規模大きめなの作ろうと思うと、コード補完のある環境とか欲しいよなーとか。

その辺でなにか進展あったのかなとググってみたらば。

javascriptの解説サイト見てたら頭痛くなってきた。
やっぱ静的な型付けない言語はどうにも微妙だなぁ……。
解説サイトのコードがかなり酷い（変数とかの命名規約とかが特に）てのもあって、こんなで型付けがないなんて、混迷の極みになりそうじゃん……と。
あとjavascriptでクラスとかオブジェクト指向って出来るみたいなこと書いてあったのでどれどれと見てみたら、連想配列をクラスと見なして～とか、その書き方とかperlのオブジェクト指向とほぼ同じような書き方するのね。
それっていわば無理くりの見なしオブジェクトって感じで、似非オブジェクト指向なかんじの奴じゃないですか。やだー。
また書き方もひちめんどくさい書き方で、javascript無理～って気分になってきたりで。

したらTypeScriptなるものがあるのを発見。開発元がＭＳってのでうーんとおもったのだけども。javascriptのスーパーセットで、静的な型付けとｃ++のクラスの書き方に近い形での（というよりＣ＃のが近いみたいだけど。TypeScriptの開発者にＣ＃の開発者がいるとかで）クラスも使用出来るとかで。
まんまｃ言語に対するｃ++みたいな関係性（ｃ++のなかでｃの文法は全部使えるのでｃ++でｃのみで書く事も出来る）なかんじで。
TypeScriptのクラスや静的型付けの機能を使わなくても素のjavascriptのコードもそのまま書けるため、外部のｊｓライブラリもそのまま使用出来ると。
で、最終的にはjavascriptのコードとして出力されると。
んでもってＩＤＥはVisualStudioで対応してて、インテリセンスもデバッグも出来る。

ふむう。
これなら結構書きやすそう＆作りやすそうかなとか思ったり。
素のjavascriptは言語的に気持ち悪くて無理……。

で、VS2017が３月７日リリース予定というタイミングですよ。
いまからＲＣいれるのもなんだし、2015でもｗｅｂなんとかを追加すればすぐに環境出来るっぽいのですが……どうせなら2017来てからのがよさげだし（ES6対応あたりなんか2017でもいろいろ追加されてるみたいぽ）
て感じで、すぐにやってみようとおもってたところでおあずけなタイミングでむぐぅ。

まああとはcanvasのパフォーマンスとかその辺の技術情報あたりはちょっと下調べいるかなーぐらいですかね。

そんな感じでVS2017来たらTypeScriptでhtml5ななにかミニゲームっぽいもの作ってみようかなーと。


それ以外では、とりあえず麻雀ＰＧの続きやる。
お絵かきも再開する。

てかなにげに一寸前。
某氏とコミケの申し込み関係でちょっと打ち合わせした時に、なんかちょっとサイト用の更新ネタやろうぜってことになってそのときが２月の11日だったか12日だったかで。
ちょうどバレンタイン直前だったので、バレンタインネタでなんか某氏にＳＳかいてもらってそこに挿絵いれる感じで、リハビリ企画的なのやろうやろうって話になったんですが。

某氏はちゃんとＳＳあげてきてくれたもののこっちは全く描けず……事前にリハビリ無しで残り二日の時事物に間に合わせるのは無理だった＿｜￣｜○
気分は半年以上寝たきりで急に起き上がって1500ｍダッシュみたいな感じぽ（ぉ
って感じで一旦落しちゃった感じで。
時事物はタイミング逃すとどうしょうもないものなぁ。

気がついたらまた改造ロマサガ3やりだしてましたよ。現実逃避にｗ

なにげに改造ロマサガ。なんだかんだで最後までプレイしたことなくて。いっつもアビスゲート二つ目ぐらいでもうお供レベルｍａｘ、技も全部覚えてる感じで、あとは消化試合だよなーって状態になっちゃっててそこでもういいやって止めるパターンだったので。
んで今回は道場使わないで、とにかくさらりとその時点で出来るイベント全部つぶしながら進めていったらアビスゲート全閉時の段階でまだお供レベルｍａｘまで行かないままで進められたので（といってもギリ二段階前ぐらい）これならまだ楽しめる余地あるなと。まだ最後の最終技のみ未習得いくつかあるぐらい残ってるし。
で、今回初めて真・破壊する物、真・猿、サイヴァ全部撃破までやって、ＥＤまで出したり。ＥＤもちゃんと改変されてるのね。通常プレイじゃなかなか使う機会のない技とか術のお披露目も再現されてて憎い演出だ……。といいつつコマンダー陣形技以外は全部出してるけど（ぉ
と、ようやくしゃぶり尽くしての初ＥＤまで。
はふーやりきった感満載。イベント大杉。

その後にちょっぴり風邪ぎみ？　ってのとＰＣのＨＤＤが最近音でかくなってきた気がするーと診断ツールみてみたら稼働時間二万時間になりそうでそろそろ寿命怖くなってきたかんじぽ。
そろそろＨＤＤ自体も買い換え考えた方が良いタイミングだなぁ……。
んでとりあえず診断結果自体はグリーンだったので（グリーンでも突然死はいつでもやってくるからアテにはならない指標だけど）1.2ＴＢぐらいのデータ保存用のパーテーションが残り５０ＧＢとかなってるし断片化もかなり進んでるので、久々にバックアップせこせこ取ったりして無駄なの消して２００ＧＢぐらい空けたあとデフラグ～。


で待ち時間半日とかになってたので、のど飴なめながら溜まってる図書館の本読み読み。
リチャード・ドーキンス著「神は妄想である」ようやく読了。文字がみっちり詰まってるので読むの時間掛かった～。
ネタ的には科学的な宗教批判と大好きなネタです。
そんでようやく次の御手洗潔シリーズの「暗闇坂の人食いの木」に取りかかれる～。リンカーン・ライムシリーズも積んでるし、まだまだ読みたい本いぱーい。でもこの季節、暖かいお布団の中で読んでるとすぐ寝ちゃうんだよなぁ。


そんなかんじで我に返ったのがつい最近。
そんでこれからどうしようと予定を考え始めたりの今日。

書庫編集ツール。
とりあえず一段落ーとおもっていたのですがQTemporaryDirなるものを見つけてしまったりで。
システムの一時フォルダを簡単に作れる感じの。QTemporaryFileってのがあるのは知ってたんですが、これのディレクトリ版があるとは。わりと最近追加された物っぽいですけど。

結構この一時ファイル、ＯＳとかシステム変わると場所ちがったりとかで、そんでもってＱＴからはあんましWinAPIを直で触りたくない（＝windous.hをインクルードしたくない）てのもあって。

そんでこんなんあるんだったら、一旦やめにした、zip以外の書庫→zip書庫のコンバート機能も追加したいなと。

まあそもそも、アーカイバの解凍機能にメモリ上に解凍があればもっと楽なんですけどね……なぜか軒並みこの機能だけ関数はリファレンスに載ってはいる物の、「未実装です」の文字がついてるですよね。

その所為でどっかに一時フォルダつくってそこに解凍して使い終わったら削除～まわりのそこそこ煩雑な処理書くハメになるので……。
あと一旦ディスクに書き込むので遅いしね。

あとは愚痴としては、なんで各アーカイバの解凍コマンドきっちり統一されてないのかと……。
大抵は-xで解凍でこれは統一されてるのかとおもったら7-zip32だと-なしのxだけとか、意外にバラバラ。
結局コマンド毎に各アーカイバ別に個別にコマンドを生成するような感じにしないと単一のインターフェースで扱えなかったりでうっとおしい。

そんな感じでunrar32、7-zip32、ついでにunzip32(自前の解凍ルーチンで非対応書庫の場合の予備で)で解凍→zip書庫作成できるように。


一寸困ったのが、ファイルはそのままファイル自体に情報ついてるのでいいのだけど、ディレクトリの更新日時がおかしくなってしまったりで。
……なんにも考えずにディレクトリパスからlastmodefy取得するルーチンにしてたらディレクトリの日付が2073年とかになっててワラタ。

そいやなんかunifyzipのvectorのとこのコメントでそれに関連しそうなの見た覚えあるな……と見に行ったらば「フォルダの更新日時が変わってしまうところが不満」みたいなのが。

でもこれって、一時ファイルに解凍したときにディレクトリってそこで作られるんだよなぁ。
んで、zip書庫内ではディレクトリって「これはディレクトリだよ」っていうデータ上のヘッダデータがあるだけで、ディレクトリというもの自体が保存されてるわけでない（そもそもそんなんできるものではない）で、解凍とか展開時にディレクトリを示すヘッダがあったらディレクトリを作成するっていう目印ていどのものなのですよね。

そんなかんじなのでアーカイバのコマンドラインから一括解凍してる場合はディレクトリの更新日時て簡単に取得できないんですよね。
出来ない事はないかもですが、一括解凍じゃなくて個別に解凍しながらチェックするとか、ディレクトリヘッダだけ検索してリストアップするとか……そもこれはzip書庫のフォーマットの話で他の書庫だとディレクトリの扱いどうなってるのかしらないのでアレですけど……。

一旦ディスクに書き出してから再圧縮の流れだと、一時フォルダのなかに展開するときに作成したディレクトリの日付になっちゃうのはまあ、それでいいかーとかおもっちゃったり。
ファイルの日付ならともかく、ディレクトリの日付とかあんま気にしなきゃいけないケースで無いような気もするし。
とかく統合アーカイバ系で細かい操作とかめんどくさいので一括解凍以外やりたくないというのが本音（ぉ

自前処理のzip→zipの場合はこのディレクトリアイテムもヘッダごとコピーなので更新日時は変更しなくても済むぽ。書庫内のデータをバイナリで右から左に移してるだけなので。

アーカイバもメモリ上に展開が出来ればこの辺クリアできそうなんですけど。実際にディスクに一旦書くからややこしいことに……。


とりあえずこれでついにunifyzip使わなくてもすむ形になったかな。zip以外→zip書庫の際におこなう冗長ディレクトリ除去とかフィルタリングとかも付けたし。

あとはちょっと悩んだのが件のQTemporaryDir

{
QTemporaryDir dir;　// ここで一時ディレクトリ作成
if (dir.isValid()) {
// dir.path() returns the unique directory path
// なんかする
}
}// ここで一時ディレクトリの中身全部クリアされる

使い方的にはたったこれだけなんでとっても簡単。スコープ抜けたら削除というのはわかりやすくて良いですね。
実際にはシステムディレクトリのappなんとかのユーザー名/アプリ名のなかにさらにユニークな名前の一時フォルダがつくられるのですが、このユニークな名前ってのがどうやって取得しているのかと。

この手のは大抵は現在時刻を種にしたユニークな文字列を付加するのですがシステムのディレクトリでなく、一時フォルダの場所を自分で指定するようなものも欲しいなというところで（うちは違うのでアレだけどＳＳＤとか使ってる場合は場所指定出来た方が良いだろうなーとおもたので）自分で似たようなのつくろうとおもうと、このユニークな文字のジェネレータだけどこかにない物かと思ったりで。

ttp://doc.qt.io/qt-5/qtemporarydir.html
でもQTemporaryDirのドキュメントみてみると

QTemporaryDir(const QString &templatePath)

これってまんま、ここにパスいれたらその直下にユニークな名前のディレクトリ作ってくれるコンストラクタなんじゃねーのと思うのですが、なにやら説明みるとちがうっぽい。英語なのでよくわからん。

実際に試してみると、引数のtemplatePathにユニークな文字が付加された文字列がdir.path()で返ってくるように。

templatePathという名前からして、どうもこれがユニークな文字のジェネレータっぽいんですが……。

static QString QTemporaryDir::templatePath(const QString &templatePath);

じゃあかんかったんかコレ……

コンストラクタで別の機能なかんじなので、ちょと時間おいて利用コード後から見たら、うん？　ここで一時フォルダ作ってるっぽいけどすぐ閉じてて意味ないじゃん。スコープ抜けたら一時フォルダ消えちゃうんだし。
うっかりこんなコード書いたのかな。とりあえずunique_ptrに放り込んだコードに書き直すか……と半分ぐらい書いたところで、これユニークな文字のジェネレータだったわ……と気づいたりしたしｗ

そんな感じで結局今日もがっつりＰＧやってしまった……

でも今度こそ一段落ぽ……。

レベル補正を書庫編集ツールに組み込み～
前のは別プロジェクトで作ってたテスト用のだったので。


既存のリサイズとかトリミングとかグレースケール化とかの処理は、設定したあと設定保存ボタン押したところでプレビュー画面が設定適応後に更新。という感じだったのだけど、レベル補正はスライダ弄ったら即座に反映してくれないと使いづらいなと。

その辺で画像の管理方をちょっと変更したりと、なんだかんだでいろんな所に手をいれる必要が出てきてしまったりで。

んでスライダいじると即座にプレビュー反映出来た物の……デバッグビルドなので遅いってのもあるんだろうけど、一辺2000ピクセル越えたあたりからスライダがドラッグしてもかなりもっさり動作に。クリックで飛び飛びに変更する分にはラグとか気になるレベルではないんですけど。
リリースビルドでもかなりマシになるけどやっぱ2000ピクセル越えあたりからちょっと引っかかる感じに。まあこの辺はいろんな処理との兼ね合いもあって画像編集専用のソフトとかみたいに扱いやすい形にピクセルデータをがっつり管理するような作りにはなっていないのでまあしょうがないかなと。

それからレベル補正の設定は個別に保存とか出来たほうが便利な気がして、全体の設定とは別にプリセットとして別個保存出来る形にしてみたり。
どうせやるなら全体の設定もプリセットで切り替えられるほうが良いかなと。これまではメニューからファイルにインポートエクスポートみたいな感じだったのを、こちらもプリセット方式に。


あと気づいたのは……写真屋のとだいたい同じ動作にしようとして、いろいろと普段触らないところまで触ったところでレベル補正て、だいたいアナログ線画スキャン後の調整がメインだったので気づかなかったけど、これってチャンネル別に設定個別保存になってるのね。そんでレベル補正でカラーバランス的な使い方もできたのかーとか。いままでＲＧＢの一括でしかつかったこと無かったよ……。
印刷データなんかは気持ち赤弱めたりとか、最終的にカラーバランスとかもちょっと弄ったりとかするんですけど、レベル補正のチャンネル別補正のがいろいろ細かく出来そうでよさげだなといまさらにｗ
そんでもって、処理的にはチャンネル別とＲＧＢ（輝度）はブレンドする感じでいいっぽいのかな。Ｒ+輝度*0.5　Ｇ+輝度*0.5　Ｂ+輝度*0.5と言う感じで。写真屋のと結果的に比較してみても多分そうなってるぽい。
レベル補正+カラーバランスな感じで、これはこんど色塗りのときに使ってみよう。しかし意外なところからの発見だったなぁ。てかこんなん常識で、あんた知らんかったのかって話だとしょんぼりですけどｗ



んでもって、この辺の情報ぐぐってるときに散見した、レベル補正でのノイズの問題ての。
んでもこれはまた違う話かな。

補正掛けるのが圧縮率高めのｊｐｇだとブロックノイズみたいなのがでるのですが、レベル補正をなんども重ねがけするとそのノイズがものすごく際だってくる現象が。上のは三回目ぐらいでこんな感じのノイズがぼこぼこでちゃってるぅ。

これはｊｐｇの特有の圧縮時のノイズが鮮鋭化されちゃう的な物でまた違う話かな。
レベル補正でのノイズは平坦化とかの時にばらつきの極端な部分をうまく処理しないと～みたいな話っぽい。
まあ平坦化とかはやってないので関係なかんべ。

んでも微妙にこの辺関係するところでは、ヒストグラムを作るときに、階調別のピクセルの個数をカウントするのですが、数ピクセルだけほかと二桁ぐらい違うのが数個でてくるんですよね。画像によっては。
でも考えて見れば背景真っ白でちょろっと絵があるてのだと、当然白が殆どを占めることになるわな……。

で、ヒストグラムを描画するときに縦軸の幅を最大値を基準にすると（横が階調0～255として縦が階調別のピクセルの個数になる）一部のピクセルに偏ってる場合、他の部分が小さくなりすぎてしまう。とりあえず平均値をとって、平均の3～4倍ぐらいを最大値にして、それを越えるのは裁ち切り。みたいな処理にしてるのだけど、なんかいろいろと界隈の情報サイトみてると、結構そこから分布状況を考慮していろいろと補正したりとかした方がいいよーみたいな空気が。

でもまあ、その辺は別にいいかなーとか。
一枚の画像をつきつめて補正するツールでなく、書庫内の画像を一括で処理する目的なので、そんなこだわってもしょうがないんじゃないかなと言う感じだし。

とりあえずここで一旦、切りにしようかな。
書庫にファイルの個別追加はべつに他のツールでもできるし、何かのツール入れたからなのか、デフォの機能なのか知らないけど、普通にエクスプローラ上で書庫ファイルにドロップしただけで追加出来るしなぁ。（でもこれ誤爆で単に移動したかっただけなのに書庫に追加結合される処理になることたまにあるのでうっとおしい）

てな感じでとりあえず書庫編集ツールは一段落ぽ。

はふ～

先日の続き～



とりあえずでけたー。
上が写真屋で同じパラメータでレベル補正かけてるの。
下半分が自前の。

いやあ、苦労した。
何が一番苦労したっていうと、対数ってなんだ、食い物ですか？　って感じでレベル補正のパラメータ指定の▲三つのうち、真ん中のやつ。これが対数スケールで9.99～0.10の値をとるのですが、0～255の値をこれと相互にやりとりする方法がさぱーり。

学生時代、とっとと専門学校いくべーと決めたので、わざわざ面倒なことするひつようもなかんべと、選択は文系のほうに行ったので、高校時代に代数幾何とかやってないんですよね。

対数スケールとかその辺ググってみると、塩分濃度がどうだとか、いかにも大学受験向けっぽい数学のサイトがぽこぽこ。

log10とかlog2とか見聞きしたことはあっても、実際になにかといえばまったく存じ上げませんっていう感じのところからのスタートラインなので、なにをどうすりゃいいのか判らなすぎｗ

知識としてはmath.hのなかのpow, sqrt, exp, log, log10とか関数あるの知ってるけど、実際には使ったことなんて数えるほど。sin,cos,tanあたりに比べると、あんまし使用する機会がないぽ。

いろいろと脳みそねじ切れそうになりながらようやく

double gamma = glib::divD(std::log(relativeCenter), std::log(0.5));

relativeCenterは真ん中の▲の位置の割合で
relativeCenter = (center - min) / (max - min)な感じ

どうも最後のstd::log(0.5)てのが、真ん中の127を1.0と基準値にするための定数っぽい？？
いまいちこの式がなにをやってるのかわからんち。logってなんなのかいまだにちよくわかってないｗ

とりあえずこれで、スライダを動かして、スライダの位置0～255から9.99～0.10の対数表示に変換は出来る用になったんですけど。

今度はその逆、スピンボックスに直接9.99～0.10の値を入力したときに、スライダ上の位置0～255に直す方法がさぱーり。
いろいろあーでもないこーでもないとやってるうちに、なぜか1.0以下の時はなんかちゃんと動いてるんだけど1.0以上になるとスライダの▲が遠くに吹っ飛んでいってしまふ＿｜￣｜○
さらにはよーく値をみてみると、ちゃんと動いているようで0.01あたりになるとスライダの位置と値が微妙に少しづつずれていってる……。
これは実数つかってるので、計算上の誤差がでてるのかな？？　対数スケールなのでちょっとの誤差があとあとおおきくなっちゃったりするんだろうか？　とか。

で、結局ようやく出来たのが

int pos = (max - min)) / std::pow(2, gamma) + min;

posはスライダのcenterの位置0～255の値。

うーん。
対数で使う冪上の上の数字。これがなんか掛けるときは足す、割るときは引くとかこの辺なんか基本っぽいんですが。
std::pow(2, v)てのが、9.99～0.10の対数スケールがlog10（常用対数）とかいうやつで、そこからもとの数字に戻すのに冪上でなんか掛けなきゃいけないというのはわかったものの、ここでなんで2という数字が出てくるのかさぱーり。

そんなこんなで、とりあえずちゃんと動いてるんだけど、いまいちよくわかってないｗ

まあ、動けば良いんだ動けば（ぉ

とりあえず、右端が0.10以下にならないのは、対数軸で0は存在しない（そんな気小さくなっても近似だけで0にはならない）ので0.10で切り捨ててるのかーてのと、中心の1.0も実際は小数部で1.01とか9.98とかに普通になるのだけど、1.0＝そのまま変更無し（補正無し）の意味なので、ある程度の範囲ないは1.0と見なす（いまのとことりあえず0.98～1.02の場合は1.0扱いにしてみたところ、写真屋のレベル補正のガンマ補正値のとこもそんな感じになってるっぽい）とか、いろいろ普段使ってても気づかなかったし、気にもとめなかった数字の意味とかが見えてきたのはちょっと面白かったけど。

しかしまあ、大学受験とかやってるひとはこんなんやってんだなぁとおもうと大変だなぁとか。コピペできない画像で置いてある類の複雑な数式とかみるだけで気分が悪くなっちゃいますｗ
そんな感じで数学という魔物に苦労した……。
それ以外は特にそれほど悩むところもなく。


あとは実際に画像補正かけたときの速度はどうなるかなーとおもっていたのだけども。

……結構重いな。

600*600pixぐらいの画像でテスト。
dstTable は事前に輝度0～255に対してにガンマ補正値で補正掛けた値のテーブル。

time= 214ms　debug
time= 48ms release
for (int y=0; y<height; ++y) {
　for (int x=0; x<width; ++x) {
　　QColor cr = img.pixelColor(x, y);
　　cr.setRed(dstTable[cr.red()]);
　　cr.setGreen(dstTable[cr.green()]);
　　cr.setBlue(dstTable[cr.blue()]);
　　img.setPixelColor(x, y, cr);
　}
}
QImageのピクセル操作関係はこんな感じにやるらしいのだけども。
このQColorがなんか糞重そう。
毎回各色毎にセットしてそれをさらにsetPixelColorでセット。なんか生成＆コピー回数多そう。
もうちょっとピクセル直接扱える感じの手段ないのかとドキュメントを読む。

time= 45　debug
time= 13 release
for (int y=0; y<height; ++y) {
　for (int x=0; x<width; ++x) {
　　QRgb cr = img.pixel(x, y);
　　img.setPixel(x, y, qRgb(dstTable[qRed(cr)], dstTable[qGreen(cr)], dstTable[qBlue(cr)]));
　}
}

QRgbてのは0xRRGGBBで入ってるuint型の数値らしい。
qRed,qGreenとかのはまあ調べるまでもなくシフトして取り出すマクロなんだろうなと。
qRgb(r,g,b)てのもシフトで結合するマクロかな。
と、こんなわかりやすいものちゃんとあるんじゃないかということで試してみるとこれで４倍ぐらい速くなる。
やっぱシフト演算はやい。

リリースビルドだと画像一枚の補正に13ms。まあ十分じゃないかと。

なにげにstd::array使ってるのでdebugとreleaseの差もなかり変わってきてるんじゃないかと。std::arrayはdebugだと数１０倍遅くなるらしいので。releaseだと生配列とほぼ同等なんだとか。


んでもって……出力レベル（入力レベルの下についてる奴）って要るのかな？　といまさらにｗ

てかこれ、いままで写真屋でもレベル補正は数多く使ってきた物の、出力レベルは触る機会まったくなかったところで。いままできっとハイパス、ローパスなんだろうとおもってたんですけど、違う物だったんやね。といまごろ気づいたり。
これ用途としては特定の印刷時にこのレベル以上の黒は使いたくないとかこのレベル以上の白は使わないとか、そういう限られた局面に使う感じで、普通はあんまし使わないものらしいですね。

てことは要らなかったかな、コレ……。

しかしこのての画像処理、今時なら普通はOpenCVとか使うんだろうけども。
でもアレも結局ＵＩは自前で作らなきゃいけないし、ver2とver3系がいまはどっちつかうべきなのかーとか情報の量とか、あれがないこれがないとかverの差異で結構面倒そうなのと、ＱＴだと結構導入もめんどくさそうってのもあったりして。
そんでもって、一気にいろいろと出来る事増えるんだろうけど、逆に出来る事増えすぎて混乱しそうってのもあるかな。
なのでちょっと機能足す分には自前でガリガリ書いたほうがシンプルに済むからいいかなとか。


これで後は、書庫内編集ツールでＴＯＤＯとして残ってるのは……
書庫内に個別ファイルを追加する機能……
zip以外の書庫→zip書庫化を自前でやってUnifyZip使わなくても済む用に。

の二点なんだけども。

二つ目のほうは、ちょろっと最初期の頃に組んだやつ流用して、とりあえず7-zip32.dllとunrar32.dll使って解凍まではまたやってみたんだけども。
そしてやっぱ統合アーカイバ系ＤＬＬは使いにくい……。痒いところに全く手が届かないし処理も遅いし。
やっぱファイルにしか解凍出来ないってのがキツイなこれ。
テンポラリのフォルダつくってーとか、自分しか使わないツールならまあいいんだけど、公開しようとか考えると、フォルダを作る位置とかで不味い場所に作っちゃった場合とか、いろいろ考慮する点も出てきたりしていろいろとめんどくさい。
さらには展開後フィルタリングとかそういうのも付けてったりとかいろいろと処理が多い。
もうUnifyZipにおまかせでええやん……という気になる。

一つ目のファイル追加は、やっぱ欲しい気もするのだけど。
リスト追加後、追加ファイルも一括リネームとかの対象に入ることになるのだけど、あとから外部ファイルが変更されたらとか、結構これも考慮する点が多いぽ。そして書庫内リストのデータクラスの派生で外部ファイル用のを作るべきか……フラグ追加するだけで管理しちゃうか。
そしてその辺組んだとしたら、空の書庫ファイルからローカルのファイル詰め込んで新しい書庫を作成するってのも普通にできるわけだけど、そうなると上のzip以外の書庫→zip書庫化の処理もやっぱやっちゃおうかなという気もでてくる。
今のところrarとか解凍まで出来てるのだから、あとは解凍されたファイル群をまとめてzip書庫化の流れまでファイル追加機能付けたらそこまで見通しが立ってしまうんだよなぁ。

むーん。

他にやるべき事はあるのに、何でかそっちじゃないっていう横道にそれる癖があるんだよな……。

そんな感じで脱線中な日々。

書庫ファイル内編集ツールで、画像関係の編集がリサイズ、トリミングの他にはグレースケール化ぐらいしかなかったりで。
そのうちレベル補正ぐらいはつけたいなと思っていたけど、今やることなのかなーと思いなからもガリガリＰＧ。



左が写真屋のレベル補正のヒストグラム表示。
右が自前の表示。

……あるぇー？
なんかヒストグラムの形が全然ちがう。



でもＲＧＢ（と書いてあるけど実際は輝度）では違うけど、赤とかほかの色別チャンネルに変えると、同じ形になるぽ。（表示上の比率が違うだけで）

なんでだー？　といろいろとググってみると

画像編集系サイトでは良く出てくる女性の画像（使用フリーのやつですよね？）のヒストグラムの例があったので
ttp://www.mis.med.akita-u.ac.jp/~kata/image/lenna/lenna-hs.html

lenna.jpgを読み込んでヒストグラム表示してみたのがこれ



やっぱ写真屋（左）と合わない。
が上のＵＲＬの先の一番下の輝度のヒストグラムと自前のやつ（右）は一致したり。

てことはやっぱり写真屋のＲＧＢのヒストグラムはなにやら計算式が違う別物なのか……。
なんか値の密集度によって比率をなにやら操作してる的な記述も見つかったのですが、べつに写真屋の型を再現しなきゃいけない理由は無いのでどうでもいいかｗ
とりあえず今の輝度のヒストグラムはちゃんと出来てるぽいので一安心。


うーん。次は実際に値指定して、画像に補正かける処理書くだけなんですが。
そのまえに、写真屋の入力レベルの下の▲マーク。
右と左はシャドウとハイライト（ハイパスとローパスのがなじみのある表現ぽ）てのはいいとして、真ん中がよくわかってない。

初期値は1.0で、下限（左端）が9.99、上限（右端）が0.10となるのだけど、この数字って何？？

まあ、ヒストグラム拡張するときの式なんかはネットに転がってるので、実際の計算はできるんだけど、この値がなにでどういう物なのか判らないままやるのはなんだか落ち着かないぽ。


最初はトーンカーブ作ろうとしてたんですけど、結局レベル補正だけでいいやーというかんじに。
トーンカーブはスプライン曲線の制御点動かして書くグラフがつくるのめんどくさい……というのと、主に利用局面としては、白黒漫画系の画像でハイパス、ローパス（グレーを真っ黒or真っ白）にしたいぐらいの用途で、カラーの色補正とか各画像毎に細かく調整したくなるような類の操作は一括処理ではあんま使わないかなーとか。

あとは今回こういう画面作ってみて気づいたんだけど。
このヒストグラムのグラフ。
写真屋の方も256*100ピクセルのサイズになってるんですね。

0～255階調の分布調べてそれを表示するわけだから、横サイズ256pixで1pxの幅の線をループで横並びに256回描いたらいっちゃん楽やんけ。
縦幅は100を基準に正規化したらわかりやすいやんけよっしゃ縦は最大100pxで。
と実装してみたら、写真屋の方も全く同じ感じで描画してるっぽいですねｗ

特に意識しないで作ってみたらば、同じ見た目すぎてちょとワラタ。

まあ普通に考えたら中途半端な横端じゃ線がぼけるし、等倍(512pix)じゃでかすぎるし。となるともはや必然のサイズなので、余地なしの事案なのでだからなんじゃい話ですけど（ぉ

ヒストグラムの下の出力レベルの黒→白のグラデーションも横幅256pxなんですよね。取り得る値も0～255なのでそのまま1pxに対応してるのですが、普通に写真屋つかってても、そこが256pxだったとはいままでまったく意識もしたこと無かったのに、いまごろそれに気づいた感じでなんかへんな気分。

見た目同じついでに他も同じにしておくかという感じで、ヒストグラムの方にはまだつけてないですけど、出力レベルの方のグラデの下の▲つかった値指定部分。
独自widgetでちまちまつくって見た目同じ操作感おんなじなの作ってみたりｗ
毒をくらわば皿までの心意気で（ぉ

そんなかんじで、麻雀ＰＧ再開したいけど相変わらず脱線中。

頭が痛～い。
熱はあんまなさげだけど、頭がずーんと重い感じで痛い～。ちょっぴり暖い日のあと、また冷え込む日が来た所為でちょっと油断して体冷やした所為か軽く風邪ひきさん。
でも一日寝たら治ったので一安心。ここ数年、只の風邪でも数日寝込んだりすること増えたので。一番酷いときは抵抗力も下がった所為か蓄膿までなって一月ぐらい寝込んでた事もあったからなぁ……。
でも最近は外出後は手洗いとうがい徹底したりとかしてる所為もあるのか、ひいても軽い風邪で済んでるっぽい。

そんな感じで相変わらずＰＧちょろちょろ。

気がついたらQT5.8リリースしてたり。5.7は結構なんども延期とかしてかなり遅れたので、今回ははやかったなーという印象。てか別ラインで進めてるかんじらしいので、5.7が遅れた分5.8とのリリースの間隔が狭まっただけということなのかもですけどね。

んでQT5.8。
表面的にはそれほど変化無しな印象。でも内部的にはかなりリライトして整理されたとかで。
ttp://blog.qt.io/blog/2017/01/23/qt-5-8-released/

QT5.7からだったか、妙にvcビルドでデバッグ実行した時、ファイルダイアログとか別窓（別プロセス？）開くときにしばらく待たされる（5～10秒ぐらい。なんか毎回何かdllをロードしてるっぽい？）終了時の確認ダイアログでもそうなったりするので、デバッグ作業に無駄に時間掛かってうっとうしい。それを回避するためだけにMinGW版もいれて、最終的に完成版のときだけvcビルド使うみたいな運用とかもやってたりしたりで（結局はそれも面倒で待ち時間にイライラしながらもｖｃビルドばっかやってたけど……）
それがQT5.8では改善されてたのがまずうれしかったですね。てことでQT5.7は消して、5.8はMinGW版は入れずにもうｖｃビルドのみを使う事に。



細々としたところもうちょっとちゃんと作らないとなというかんじで随分前からボタンだけ用意してあったけど機能はつけてなかった正規表現の特殊文字の簡易入力とか、入力文字列の履歴機能とかそこらへんを追加とかしたり。

あとはツールバーの機能リンクは、今はとりあえず文字で置いてるけど、アイコンとか作った方が良いかなーとか。

んでとりあえずキリの良いところでソースのバックアップとかとったりするついでに診断ツールに放り込んでみたら……9000ステップぐらいあるぽ。

うーん。zip書庫開いてあれやこれやするだけの軽い感じで作り始めたツールだったのに、なんだかんだで1万ステップ近くなっちゃってるんだなぁ……。