カラー化

　いろいろ違和感あるけど、まぁそれっぽい感じにはなってきたんじゃないかなぁ。

　左下のアイコンだと、Aは緑、Xは青、Yは黄、が正しい色のはず。
　右上のNETFLIXは赤が正しいはず。
　「おすすめのタイトル」の左端はGears of War 3っぽいけど、このシリーズはナンバリングは赤だけど、緑に見えてる。立ち絵の背景は夕焼けっぽい黄色だけど、これもまた緑になってる。
　ギアウォの右のソードオフダブルバレルのおじさんは、Red Dead Redemptionっぽいけど、これの背景は赤色らしい。
　一番右側はCall of Duty Black Opsっぽいけど、これに関しては色彩が殆どない絵なのであまり参考にならない。とはいえ、手の部分は肌色が緑色になってる。
　中段のGOLDの文字は、ちゃんと金色っぽい色になってるのが謎い。

　色相のズレっぽいので、バーストサイクルの位相に補正値を加算してやればある程度マシになるのかもしれない。
　変換マトリクスはWikipediaにあったやつを使ってるけど、RGB→YIQ→RGBで、だいたい誤差の範囲で復元できるので、YIQ→RGB処理はそんなに間違ってないと思う。YIQ値もだいたいグラフで想定される範囲だし。
　YC→YIQの処理がテキトーに書いたやつなので、ここも問題ありそう。

　そもそも、バーストサイクルの色が上下で変わるのが問題ありそう。コイツが色相の基準になるんだから、コイツはどの場所でも同じ色にならなきゃいけないのに。

　やっぱりサンプリングレートが足りない&中途半端なのが問題なのかなぁ。

　最初に1回だけバーストサイクルを読み込んで、残りは約180度ずつ回して、バーストサイクルの色を固定して、バーストサイクルの位相を固定値ズラして、みたいなことやっても、ある程度の変化はあるけど、なんかコレジャナイ感。そもそも根本的に間違ってるんだろうな。
　適当なカラーパターン出せる機材を準備するべきかもしれない。。。


/* 全く関係ない話だが、僕が属していた小学校のとある教師は、「肌色」が差別用語だとして、使用を禁止していた。でも代替策は聞いた記憶がないなぁ。「日本人の色」とか「アメリカ人の色」とか「アフリカの方の人の色」とか言えばいいの? (念のために書いておきますが、後半部分は当該教師への当てこすりの皮肉です) */

***
追記
　デコードしたIQ面を回転させたらいい感じになった。



　思ったよりちゃんとデコードできちゃったぞ……ッ!?
　もっと「あーあ、やっぱ安いマイコンじゃダメなんだね」みたいな結論になるような道筋を考えてたのに……

***
追記

　バーストサイクルの位相を計算するatan2のyを反転して与えたら良さそうな感じになった。



　実測の位相と、手動でパラメータを決め打ちした位相を比較したら、傾きが同じ程度で上下逆、という状態だったので気がついた。
　手当り次第で作ってるから、符号の正負とか、位相の90度違いとか、そういうミスが多い。逆に言えば、そういうことろに当たりをつけて切った張ったしていけば良さそうな雰囲気。とか下手にヤマ張ると全く違うところだったりするんだけど。
　ゲームのアイコンは良さそうな色合いだけど、NETFLIXがちょっとオレンジっぽい。huluは青すぎる気がする。左下のボタンの色は結構近い。

　うーん、いよいよちゃんとデコードできるようになってきちゃったぞ……
　そろそろ画像の処理は中断して、データ圧縮&1フレーム丸々キャプチャできるようにしなきゃいけないかな。

　左下のアイコン、時計のマークとか、左右に影が出てるけど、LPFのリンギングだと思う。実際の風景とかを写した映像なら気にならないんじゃないかなぁと楽観してる。デジタルのアイコンは輝度変化が大きいので高周波成分までしっかり通す必要がありそう。

***
追記
　たぶん、大雑把な部分ではこれでいいはず。



　IQのゲインとかは未調整だけど、色合いは不自然な感じはない。
　位相に関しては、微調整は別として、明示的に角度をずらしたりはする必要はないらしい。YCからRGBを直接出すなら、それに応じて位相をずらす必要があるらしいけど、YIQを経由してマトリクスでRGBに変換するなら、0度/90度で良い。

　試しにC#で簡単なハフマン木を作ってみてる。とりあえず動いてるんじゃないかなぁ。
　ただ、若干特殊な挙動を実装する予定なので、その部分がネックになりそう。あと実行速度と。どんなに頑張っても速度は足りない気がする。なんせ16サイクル未満しか使えないので。

　試しに、↑の画像の生データを圧縮してみたけど、76.2KiB→49.6KiBで、圧縮率0.65くらい。もうちょっと圧縮率が高ければ1フレーム分をRAMに記録できそうだけど、たぶん足りない。うーん、出だしから絶望的な感じだ……
　例えば下位1bitを捨てたら41KiBとか、2bitを捨てたら34KiBとか、多少は改善するけど、さすがに2bit捨てると目に見えて画質が悪化する。まぁ、そもそも画質が悪いので、縮小してみればそれほど気にはならないけど。
　3bitも捨てると縮小してても明らかに画質が悪化してるのが見えるけど、圧縮率は0.34くらいになる。

　マイコンで垂直同期のトリガができれば、フレームの中央部に近いラインだけ読み取る、みたいなこともできるはずだし、メモリが足りなければ最悪1フレーム全体のキャプチャは諦める、という方向性で、もう少し進めてみよう。。