■

　書きかけて書かなかった事など。
　多分何の事か解んないと思うが、解ってもらうつもりが無い。説明する気もないのだけど、あまりに排他的なのも後で俺が読んで「？何が何だか？」状態になるので、一応書いておくと、ﾌｧｰﾑｳｪｱのﾊﾟﾗﾒｰﾀ関係。
　
　prmA~Cの数値を見て、どうもﾁｪｯｸｻﾑか何かが有るのかなと思っていたんだけど、何か変だぞと。とりあえず数値をprm1から6の数値と、A~Cの数値で見ると、なんか普通のRGBじゃねえな。白黒のときにはA~Cをつかい、他は全部0だし。ってことはA~Cは色というよりも写り方というか、そっち方面か、と思ったが白も黒も色じゃねえかよって事で、どうも扱い方が別な方面から見て行かないと何か変な事になるんだろうな、と思ってprmA~Cを白黒の時の設定にしてからprm1~6の数値を全部揃えて（40にしてみた）見ました。そうしたら何だか極端に緑色に偏った物が出来上がって来て、それでも、色が潰れるっていうより本来光量が多い場所、白黒のときに白く写る所が緑に振れて行く感じ。数値が16進数でFFまでの設定で、40で統一したってことは出来上がるのは灰色に振れるはずなんだよな。でも緑。
　って事は。
　ああ、つまりこれらの数値は白黒で弄ってた時には見えなかったけど、これは単純に数値を反映させてなくて、数値を元に計算されてんなあ、と。つまり、数値がRGBに素直に対応してねえな、と。
　予測が立ったので、極端に一つのﾊﾟﾗﾒｰﾀだけ上げ他を低い数値（ただし他の数値は全部統一）という状態で結果を見たら、やはり緑に振られっぱなし等といった妙な事になっていて確定です。という事で、RGBを計算式で加工して、それを元に画像を作ってるんだろう、という推測が出来たら後は「その手」の計算式や仕様を検索すりゃｵｼﾏｲなので今の世の中は簡単で良いなあ。一昔前だと図書館に籠るﾊﾒだったよ。
　ということで、まあY.Cb.Crだろうよ、と。
　検索しまくったら、この数式使ってJavaでﾂｰﾙ組んでる人も居たし、まず間違いないでしょ。なんかﾘｱﾙﾀｲﾑに結果を見る事が出来る書き換えｿﾌﾄを配布してました。拡張子が.jarだけど。
　MacにはﾃﾞﾌｫでJavaが組んでありますが、jarのﾌｧｲﾙをｸﾘｯｸ一発起動って状態でもないので（つうか、そこまで持って行くのには面倒過ぎる手順が要るので何か嫌です）ｺﾚはｺﾚでﾊﾟｽだなあ、と思いました。環境整えるのに半日仕事だと、流石に及び腰だよお。っていうか前持ってたMacではXcodeが動くようにしてあったんだけど、あれは面倒だった。うん。
　要するに、RGBが分解されてprmに放り込まれてて、どうもRがAと1と4、GがBと2と5で、BがCと3と6の数値を見ていて、そんでもって、A~CをY、1〜3をCb、4〜6をCrとして見ているんだって。つまり、それぞれの色と数値が見えたってことで、こっから先はｿﾌﾄを使っても良いだろうし、数値を直接加工しても良いだろうね、って。まあ好きなようにすれば良い。
　で、思った。ここまで改造すんなら最初からﾌｫﾄｼｮ使う方が良いんじゃね？と。
　やってる事は結局は同じようなもんだし。ﾃﾞｰﾀを加工すんのか、ﾃﾞｰﾀを記録する時に加工すんのかの違いだったら、結果は同じだろうと思う訳で、所詮、こうなると近似値でしかないぞ、と。真を写すなんて事は出来ないんだよな、出てくるのは全て近似値。過去にあった出来事ですらない。歪んで、ねじ曲がって、変色した別物。電力に依存した0と1の結末なんだから、そんなに深く考える必要は皆無。すべては終わった事でしかないしぃ。
　という事なんだけど、とりあえず、何が行われているのかは大凡だけど見えたので、後は適当で良いだろうという着地点を発見しました。
　これより着地します。どーん、つって。
　

　とはいえ、ﾄﾞ赤なのとﾄﾞ緑なのを早速作ってみる辺り、俺も変態さんです。今度暇だったらﾄﾞ青を作ってみようかとも思っていますが何より面倒なのと白黒の方が面白いのでいつになるかは不明です。
　あと上の写真用に改ざんした数値のﾒﾓは俺の机の引き出しに入れてあるので、興味がある人は俺の家の俺の机の引き出しを見てみると良いよ。部屋に入る時は俺に声かけてくれよな。
　以上！