「そろそろ区切りにしよう」と思っていた矢先に面白い結果を出す方法が見つかるのは難儀なものだ、しかもどちらかが完全に優れているとは言えず、先に開発したものと一長一短でありながら、先のものの問題をある程度解決する、ましてや殆どの画像では大して違いが見極められないのも難しい所、ただ結構肝になる部分でもあるので少々延長決定.

、、、やはり鬼門であるなぁ:-<

「色数」という決められた数の箱がある以上何処かを詰めれば何処かが必ず足りなくなる、至極当たり前の話ではあるのだが:-<

減色処理再開、とは言っても情報落ちが発生した個所を直したり細かい微調整メインでエンジンとしてはこの路線で行くつもり、日記を読み返すともう1ヶ月近くいじっているワケで、単機能としてはここまで時間をかける事になるのは珍しい事、やはり鬼門であったなというカンジ. まぁ取り合えずエンジン自体は最後の調整を行って今月いっぱいで終了を予定.

少々減色のパラメータの判断に迷ったので、気分転換でActionScript用にsprintfを作ったら半日かかった、今までprintfは何回か作っているが基本的な変換部分はCランタイムやその言語ライブラリにあるフォーマッタを使ってたのだが、JavaScriptまで想定に入れると全て自前で書く必要があった為、整数は何の問題も無いが、浮動小数の指定 %f, %g, %e辺りの処理が細かい所までCのランタイムと一致させようとすると繰り上がりの処理の例外など結構ややこしい、まだ浮動小数表現の誤差領域まで含むと一致しないのだが、表現可能な領域についてはCのランタイムと一致した模様、取り敢えず幾つかのパターンについてランダムデータを与えて数時間回した所では出力文字列の不一致は発生していないカンジ. まぁ小物なれど真面目に取り組むと結構ややこしい部分なので、ここは一回作って持ち札としておいて損はあるまい.

JavaScript/ActionScriptでのprintf実装はweb上に幾つかあるにはあるのだが、機能が限定されていたり定番と呼べる程テストされたものが無い割には浮動小数の誤差近傍などかなりデリケートな部分も含む為、下手に依存ライブラリを増やしてメンテナンスコストを増加させる事を考えると、正直自分で作った方が安心できるだろうという所. アルゴリズム微妙な部分の判断に迷った時は別の事をやった後に見直すと良い具合に割り切りができるもので、printfの実装を一応終えてから (落とし穴が発生しがちな部分なので更にチェックは必要だが) 減色処理で悩んでた個所を見直した所こちらも良い具合に方針確定、それ程ロスタイムにはならなかったので結構悪くないカンジ. という事で後少しだけこのまま続きます;-)

息抜きがてらここ2日程 Flex SDKをいじってみる、ざっくり一通りなめて大体は掴めたので、3D表示でもやってみるかなと作り始めたが、、、なんか小回りが効かない、コンストラクタの可変長引数での多態が効かないとか、演算子のオーバーロードができないとか、手を抜いて型宣言してないとwarningが大量に出て (-warnings=falseとすれば抑制できるけど、言語標準としてそう定義されている以上余り望ましくない) 何の為の型推論かと問うてみたくなったり、JavaやC#よりタイプ量増やしてどーすんだと思ったり、演算子のオーバーロードが無いのでベクトル演算や行列の計算部分がやたら読みにくくなったり、何かいい加減書いててストレスになってきたので止めorz

どーにも気軽にってカンジでも無くて残念 :-<

まぁ何も無いのもちと悔しいので適当にワイヤーフレームだけ回してお茶を濁しときます (マウスドラッグで回転) 一応以前仕事でやったグラフィックライブラリの検証プログラムやZバッファレンダラのプロトタイプから引張ってきているので、マトリクスやスクリーン変換等OpenGLと同じトランスレーションがかかっているのだけど、どーでも良い事、正直Zバッファレンダラまで作るモチベーション出ない & ワイヤーフレームの何が面白いんだなんて言わない事、やってる本人もつまんないんだから(ヲイ

# 余談だが3Dやるなら標準コンポーネントに型を限定した高速なArrayバッファが欲しい所、Zバッファの実装とか頻繁に発生するベクトル・行列演算とかJavaScript規定のArray実装のオーバヘッドを考えると色々きついし、全て独立した変数に閉じ込めるのもいかにもナンセンスな気がする:-< まぁ素直に標準機能で最低限のZバッファ付きBitmapDataがあってGLやDirectXのサブセット程度の描画メソッドなど一通り押さえていればそれが一番良いが.

# 通常スクリプトをOFFにしている状態で<object>タグを使って埋め込むとスクリプトは使ってないにも関わらずswfを再クリックした再にIEがスクリプト確認出してくれて実に嫌なカンジ、ついでにそのmsgの 「スクリプトは通常安全です」 の文句に思いっきりツッコミたくなって (ローカルPCに対する攻撃の起点の殆どはスクリプトなんですが) 更に嫌なカンジ :-<

ふむ

「7倍速ければ何ができるだろうか？」

マジに書くとIEエンジンの10倍程度ではまだ「全然」かなぁ、、、インタプリタとの比較は常にフェアでは無いがNativeのリプレースなら最低限で100倍(※1)程度は欲しい所、ましてや真面目な「グラフィックアプリケーション」(※2)に言及するならなおさら、ね;-)

まぁ普及の問題はこれとは別にどれだけが「乗る」もしくは「乗せられる」か、その上で実際にユーザーに対して効果的なコンテンツを提供できるかという所なので未知数だけどね:-P

※1) 結構法外な要求に見えるかもしれないけど、実際コンポーネントでの律速吸収が絡まない部分で速度比を計測してみると真面目に数百倍のオーダーで開きがあるので、100倍程度は実におとなしい話、元々が世界が違うから成立しているもので、同じ土俵に上げるとそうなってしまう、無論UIインターフェイスのみが律速になっているものに関しては可能性が増えるのは良い事ではある ;-)

※2) 今の時代に信じられないかもしれないけど、今のPCスペックですら関数呼び出しはもちろん、整数<->浮動小数のキャスト変換や通常の除算すらはばかられる世界もあるって事ね (で、実際速度的に数倍のオーダーで目に見えてレスポンスに影響する) 無論それが全てでは無いし、ブチ当たらない人はとことん目にしない話、ただ画像関連や非定型的な3次元処理などでは割とそういう話って馬鹿にできないのだなーなどと痛感、実際例の減色でも覿面に効いてるし. その上で別に使っている技術要素は知った事では無くoutputとして出てくる所はユーザーにとっては「単なるソフト」なワケで、その辺を上手く見極めないと辛いだろーなとかそんなカンジ.

# ちょっと辛辣になっているのは、確かに効果は否定しないけど、いささかプレス内容が扇情的な気がしたので、という所で (まー穿った見方をするとコンテンツを握っていない側が「勝利」する為には乗ってくれる人間がいないと話にならず、またそれは技術系の「そういう」サイトも然りなので、そうなりがちな理由も分からなくもないのだけどね) :-P

相変わらず減色処理、延々減色画像を眺めてたら何が綺麗なのか何が駄目なのか、段々脳が麻痺してきて判断のつかない状況に、、、真面目な話これは数日脳と眼を休めないとまともな判断ができなさそうなカンジ、という事で暫く休息を入れる事に.

ちなみに今の時点ではこんな具合 t6mが誤差拡散強度「中」としての採用を予定しているもので、t6hの方が「強」として予定しているもの、それぞれフルカラーのbmpをexeにドロップすれば減色画像が表示されます.

殆ど特異点も出難く他のソフトの結果とも並べられる所まで来たんじゃないかと思うのだけど、半分麻痺しているのでマジに正直自分でもワケ分からんorz

ちなみに先日書いたL*a*bでの色判別も試したが、決して悪くないもののそれ程良くもないというカンジ. 特に青と紫がかなり近い色として認識されてしまうが、単色として見れば妥当なのかもしれないが、画像の構成要素としては少々難がある気もする. ちなみに色の感覚というのは育った環境などに影響されるもので、例えば一時期ハマっていたアメリカの輸入もののお菓子などはやたらどぎつい色で、これもまた風土かなぁなどと思いながら口内を着色料まみれにして食べていたのを思い出す. 映像の見た目や日用品の色合いなどもヨーロッパを初め結構国ごとや地域ごとに独特である事を考えると、均等色空間という考え方もどこまで信じれば良いのかなどと思ってしまう. また人間の場合加齢に伴い水晶体の濁りが強くなる為、若い人に比べて年をとった人が見ている世界はより赤色が強いかったりもする. うーん :-<

# ちなみにoptpixやPadie/xPadie,Yukariなどの専門ソフトを除けばPhotoShopの減色は以外と (言われている程) 悪くない印象、ノイズやモアレに無頓着でその意味では常に元画像のイメージを壊す部分はあるが、満遍なく色を拾うという特性を持ち様々なタイプ傾向の画像に対し安定はしている、またそこらに溢れる画像処理をうたうソフトに入っている減色よりはそれでも性能は良い、それ以外色々ソフトを調べた所ではViX(モード2)とgmaskの減色エンジンはかなり良い品質、それ以外は大抵PhotoShopに及ばないという所な気がした.

# ま、つーてもこの時代ゲームなどを除けば減色は色を再現するってよりも、webサイト広告の画像を縮めるのがメインだったりするんですよね、無論品質が高い方が良いのは事実なのだけど、そういうサイトに乗っかってるとことんビットを切り詰めて圧縮効率を上げる為に誤差拡散も外しているモアレだらけの画像とか見ると正直モチベーション的に萎えるものがあるのも事実、まぁ知的好奇心の探求としての側面があるのでそれでやめるとかは無いが. 結局内容的には256色という制限がある非可逆圧縮の設計みたいなものだし、そうして考えるとDCTの方がはるかに縮むなどとは決して言ってはいけない(笑)

# 大体実際はガンマや白色点真っ当に設定されたPCの方が少ないし、店頭売りのPCの殆どは見栄えや発光を良く見せる為にやたら青色や彩度が強調された設定になっててデタラメもいーとこだし、普及品のLCDは中間点以外のガンマ追従性はまだCRTに及びもつかないし、そう考えるとここまで真面目に考える事に意味なんか有んのかぁ (口から泡吹きながら逆ギレ状態で) みたいなそんなカンジで(えー

相変わらず減色処理を色々と、色の類似比較がどうにも揺らぎを含みがちなので安定した比較方法を考慮する必要がある、但しある程度の揺らぎを許容できないと減色結果にモアレを多分に含むし、閾値的なアプローチはjpegなどのアーティファクトを顕在化してしまうケースがある:-<

YCrCbなどでも限界に来ているので、取り敢えずL*a*bを検討する段階かも. それと絡んで減色に限らずディスプレイのガンマ特性って結構大きなものなんだなーと改めて実感.

以下RGB3成分のカラーキューブプロット (本当はflashとかJavaとかの利便性が上がればこれをHP上でクルクル回す見せ方も有りなんだけどね、現状ではちといずれも大掛かりなのは難点:-<)

【gamma:=1.0, 通常の殆どのプログラムでの扱い】

【gamma:=2.2】

注) 縮小画像で分かり難いけどXYZ軸がそのままRGBで描画されているのでその部分は無視して下さいm(__)m

ディスプレイのガンマを考慮する方が感覚として直感に近づけられるが、数値情報と考えるとペイントソフトのカラーピッカーの位置表現をこれにしてしまうと、絵を描くには良いが、既存の情報などをチェックする場合に問題なのはちと難点 (+ちと暗い色が拾い難い) グラディエントツールなどでは検討しても良いかもね;-)

【おまけ、L*a*bテスト】

若干スライスが見辛いが、やはり3Dプロッタは便利 (と言っても画像になると一方向からしか見えないので伝わり難いかもしれないが(^^;) 難点は3次元までは問題無いが4次元以上の把握はやはり難しい所 (当たり前と言えば当たり前なのだけど、アルゴリズムを検討する時にイメージで把握できると出来ないとでは楽さ加減が全然違うのですな:-<)

不毛だと言いつつGIFのエンコーダ/デコーダを書く、アニメーションGIFについてはまだライブラリ上のデータ構造が定まらないが、取り敢えずは完成と言って良い所まで来たカンジ、2〜8の任意bit画像で既存ファイルの読み込みも生成したGIFを他のソフトで読む事にも成功. 本当は2〜3日で完成するだろうと安易に思ってたのだが、LZWの細かい仕様合わせなどでハマり結局1週間近くかかってしまった.

しかし、開発で情報を探すうちにこんな記事(※1)が、、、どーしたものか :-<

※1) 新たに"米UnisysはLZWの技術に関連する2件の特許を出願中"のくだり、ね.

あまりの暑さに意識が朦朧としてコーディング効率悪化、クーラーガンガンにかけている筈なのだが、それでも限界.

余興のつもりだったが、つい面白くなって減色処理色々、先日書いたメディアンカットはどうしても平均色に引きずられる為低ビット、とりわけ64色以下の減色では元の画像の雰囲気を損ねるケースが多い模様、大体128〜256色辺りが比較的安定しているようだ、それ以外にはパレット適用時の色の類似判定を工夫してみたりで256色に限定すればPhotoshopや汎用的なペイント・レタッチソフトについているものの殆どよりは結構良い結果を出せる所までは来たと思う.とは言ってもそれ用の専門のソフトには敵わずという具合.

64色などではK平均法などでクラスタリングする方が良いのかもしれない、ただどのように初期値を得るべきか、、、メディアンカットもRGBの分割をある程度規則的にすれば再現性は上がるのだが、今度は画像の見た目を大きく損なう事になるのが問題か、まだRGB以外の色空間は試してないので結論を出すのは次期早々ではあるが.

しかし、デスクを窓際に置いているのだが壁に熱が篭っているせいか、日中はもはやコーディングできる環境では無く最早ダメダメorz

---------------

余談だけど256色よりは65536色環境の方が最近は重要な気がするんだけど、どーなんだろーね. ただIEなんかはそのまま表示しているけど、画像Viewerなんかはディザリングして表示するものもあるみたいなので、本来は表示側の仕事かもしれない、jpegなんかは内部的にはRGBじゃないし、結局圧縮効率は悪化する & jpegでは品質も上げないとNGって事もあって保存オプションに65536色環境で正常に表示する為にディザリングするオプションを付けるべきか否か.

更に余談だが、webセーフカラーって上の65536色環境だとそれ程(実カラーと)重複しないんだよね、そういう意味ではなんか嘘臭い気がするんだが、実際の所どーなんだろ? アレってなんか意味あるの、みたいなそんな具合で.

加えて余談だけどGDIそのままでビットマップ表示すると65536色環境ではマッハバンドが出るのだけど、幾つか.NETで作った画像関連の自分用アプリでは表示がディザリングされて表示されている、GDI+にそういう機能があるのかな、などとも思ったのだが、暑さの為まだ未確認X-<

汎用の印刷ライブラリを組んでいたのだが、少々煮詰まったので気分転換も兼ねて減色アルゴリズムのテストなど書いてみる、こんな具合.

先日の実験画像を256色に減色、自分で試す場合はここにあるcrecude_test.exeにbmpをドロップすれば256色設定で算出されたパレットをコンソールにダンプして減色結果を誤差拡散で表示します. 一応ロジック的には任意パレット数に減色可能ではあるが、今の所サンプルは256色固定 ;-)

アルゴリズム的には非常に基本的なメディアンカットと呼ばれる方法で、RGB3次元のヒストグラム空間で空間をある基準(一般には占有量、今回は平均色と変動値)でRGBいずれかのチャンネルを選択し再帰的に2分割してその空間に属するピクセルの平均色をパレットとして割り当て、規定のパレット数に到達した時点で打ち切り、その後その生成されたパレットによる減色結果を誤差拡散を適用して表示するという具合.

結果は見ての通り、良くも無く、悪くも無く、とまぁ極めてごく普通という具合. まぁ世間的には申し訳程度で付いてる安易な実装よりはマシで、普通のソフトに付いているごく普通の機能と同程度、専門ソフトには案の定かなわないというカンジ.

分割基準や孤立気味のピクセル集合を特殊扱いする、あるいは視覚モデルを用いた重み付けやLab空間などでの分割、局所的な重みの動的変更など色々思いつくが、詰めだすときりが無い分野でもあるし、まぁ2値減色以外組んだ事無かったので勉強がてらという程度の事 ;-) 作っては見たものの減色処理が最終段のみのワークフローである事を考えると多少面倒でも専門のソフトを使うのが望ましい.

まして減色画像など今の時代となってはWinのアマチュアゲームならいざ知らず、ゲーム機でも携帯機を除けばほぼ意味無いし、せいぜい後はパチンコとかのごく限定された開発で生き残っている程度. 無論PCで言えば256色環境などもはや考慮する必要は無く、せいぜいGIFを作る場合位にしか役に立たない、微妙な圧縮率の違いも回線が太くなっているので昔程気にする事でも無く、GIF自体もWeb素材としての納品とかの都合を除けばアニメーションGIFを作る以外にフォーマットとしてのアドバンテージなぞ無い事を考えると、まぁほんの余興.

実際自前のペイントソフトもGIFはサポートするつもりは毛頭無いので、今の所このルーチンの使い道は皆無(笑) まぁフォーカスする分野で作った事の無いものを消化しておこうという自己満足とせいぜい話題のネタ作り程度 ;-)

# まぁ他にもその限定的な用途で効果的な機能として作るならパレットの細かい割り当てや共通パレットの作成機能など細やかな作業をする為の専用のインターフェイスが必要になるし、そこまで面倒な事をして実装しても見返りは少ないというカンジ、気が向いたらほんのお遊び程度に乗っけるかもしれないけど、正直意義を全く感じない(苦笑)