堕天使の煉獄

先日の続き～



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

いやあ、苦労した。
何が一番苦労したっていうと、対数ってなんだ、食い物ですか？　って感じでレベル補正のパラメータ指定の▲三つのうち、真ん中のやつ。これが対数スケールで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書庫化の流れまでファイル追加機能付けたらそこまで見通しが立ってしまうんだよなぁ。

むーん。