MS 謹製の画像形式。
nikqさんがいじってたので僕もちょっと見てみた。

記録方式としては、可逆圧縮から非可逆高圧縮、色深度は整数から浮動小数、
色空間はRGBからYUV420、果てはBayerまで網羅的に対応している点が凄い。
RAWからJPEG,PNGまで駆逐してやろうという野望を垣間見させる内容だ。

パラダイム的にはJPEGとJPEG2000の中間だが、その分JPEG2000ほど重くはない。
基本はブロック構造で、独自の非線形変換を使う(みた感じ軽そう)。
エントロピー圧縮も特に凝った事はしていないようで、
回路もJPEG2000と比べれば、かなり軽いものになりそうで、
カメラ等での実用が期待できる。

じゃあ肝心の圧縮は？(JPEG比)
分かりやすい高圧縮時で調べてみた。
(圧縮後ファイルサイズは極力同じにした)

原画1(bmp) JPEG HD Photo
原画2(bmp) JPEG HD Photo

見た目は、まず輪郭に強い。
JPEGで崩れる線もわりとまともに残る。
色差の崩れが酷いのがJPEGの特徴だけど、HD Photoではしっかり残る。

しかし、その代償としてブロックノイズが酷い。
JPEGも酷かったが、HD Photoではさらに酷い印象を受ける。
ただ、pre/post-filterである程度は低減しているので、
そこまでくっきりはでない。
ブロックが分からなくなるまで、filteringしても良いと思うのだが、
これは処理量の問題かもしれない。

私的には、
原画1はHD Photoの辛勝(どっちも汚すぎたが、色はHD Photoの圧勝),
原画2はHD Photoの勝ち。

ちなみに、PSNRでは両方HD Photoの方がJPEGより大体2ずつ高い。

奥が深いと思うと同時に，高級アセンブラの延長であるC/C++の限界も露呈していると感じる．
実装の問題かもしれないけど，例外は吐かれるコードを見るとやっぱり使いづらいよねえ．
(詳しくないので適当ですが)例外は当然OSのサポートの上に成り立つわけで，普通に実装すればりユーザタスクとカーネルを行き来する事になるはず．だから，オーバーヘッドは相当でかい．
てなわけで，安易に例外に頼るのではなく，できるだけ値返しでエラーを検出できるような構造が美しいと思う．といってもやっぱり例外は要るよねえ．だいたいオーバーヘッドなんて普通気にならないし．

C++: 水面下の仕組み
microsoft.com
VCのコンパイラ設計者によるC++実装の説明．
VCはもちろん他のC++コンパイラを使う上でもこれは理解しておきたい．

仮想継承
www.uri.sakura.ne.jp/~cosmic/yuno/lab/cpp_virtualbase.html
多重継承して仮想継承して…そんなプログラム書きたくないですね．
というかバグったら原因追求にかなり手間取りそう．

iTunesってサブネットの中で勝手にファイルを共有する機能があるみたい．
当たり前なのかもしれないけど，今頃知って超驚きました．
簡単便利気持ちいい，て感じでうまいこと(グローバルで)やればWinMXとか(最近は何か知らないけど)なんて目じゃないぜ！
みたいな．
けど，さすがに他人のところのファイルはストリーミングしかできなくてダウンは無理らしい．
(ていうか，この共有だけでも訴訟されかねない機能なんじゃ？？僕もこういう機能を夢想していたけどやったらきっと逮捕なんだろうな，って思ってた)

しかしやっぱり外人は凄いですね．
この共有プロトコルはDAAPって奴なんですが，もう勝手に実装されまくり．

myTunes Redux
minimalverbosity.com/
サーバ．

itshell - Net::DAAP::Client
blog.bulknews.net/mt/archives/001241.html
日本語での解説

Rendezvous サービスタイプ
developer.apple.com/ja/qa/qa2001/qa1312.html
apple.comでの情報．

Get It Together
sourceforge.net/projects/getittogether/
sourceforgeで探したら腐るほどフリーの実装があって，↑はダウンロードもできちゃう．
そりゃそうだよね．

単に鍵を期日まで預けておけるサーバがあればそれでいいような．
けどタイムカプセルは面白いかも．
未来の自分へメッセージを残せるサービスがあったら流行らないかな？

直接関係はないんだけど，karl(nooon)の(ACE BBSの広告に使われた)40バイトサインテーブルジェネレータを思い出した．ってもう6年前に取り上げたネタですけど！

; the cos table has 1024 values & ranges from -2^24 to 2^24
build_table:            lea    DI,cos_table

                        mov    CX,1022

                        mov    EBX,cos_table[4]

                        mov    EAX,EBX

@@calc:                 imul   EBX

                        shrd   EAX,EDX,23

                        sub    EAX,[DI-8]

                        stosd

                        loop   @@caslc



cos_table               dd     16777216     ; 2^24

                        dd     16776900     ; 2 ^24*cos(2a/1024)

                        dd     1022 dup (?)

ただ取り上げるだけじゃあれなんでこれをCに落とすと，

int cos_table[1024] = {1<<24,16776900};

void build_table() {

    __int64 a;

    int b;

    a = b = cos_table[1];



    for( int i=2;i<1024;i++ )

        cos_table[i] = b = ((a*b)>>23) - cos_table[i-2];

}

て感じです．imulとshrdはどうしてもうまく表現できないのでint64使ってしまったところが情けないですが，いいアイディアが思い浮かばなかったので．windowsならMulDivとか使えばいいんですけどね．
ちなみに誤差は絶対で30000くらい出ます．相対誤差は浮動小数点じゃないので比べるのが難しいですが(0付近になるとどうしても大きくなる)，だいたい0.2%以下です．

VC7はVC6と比べてだいぶキャストが厳しくなってるみたい．
warningで済んでたところが軒並みerrorになってしまう．
てことでこれからはちゃんとC++なキャストを使おうと思った．

ネタもないのでまたhook．
といってもこれはSetWindowsHookEx()を使うだけの基本技です．

参考 : thebbs::キーロガーはどこにある？ 487-490にURLのまとめがある

研究しようと学校に泊まったらなぜかWin32 APIのフックに調べることになってしまった．
どうやら本気でフックしようとするとドライバから書くなくてはならないみたいだ．
ただ，このサンプルはそのフレームワークを提供してくれるので，ユーザは非常に簡単に特定のプロセスの特定のAPIをフックすることができる．
これを使えばいちいちラッパー等書かなくても，あらゆるアプリを思いのまま改良及び悪用できる．

ちなみにサンプルではTextOutを乗っ取って，「Hello from TestApp!」と本来表示されるところを勝手に「Do you recon this is the original text ?」と変更して表示してくれる．
メッセージフックやウィンドウプロシージャフックならよくサンプルも見かけるけど，こういうのって珍しくない？
ただ，このサンプルちょっと不安定なのが玉に瑕．

Task State Segment(TSS)というものをご存知だろうか．
これはIntelがマルチタスクをハードウェアでサポートするために286以降に搭載している機構である．
コンテキストの保存と回復はマルチタスクでは必須であり，それをハード化しようとするのは自然(ありがち)な発想である．
しかし実際のOSでは，このTSSはまともに活用されていないようである．
というのもこのTSSという機構はかなり限定された場合にしか都合よく使えないらしく(例えば1タスク=1スレッド)，
結局コンテキストスイッチをソフトウェアで書く羽目になるからだ．
(単にソフトで書いたほうが自由度が高くて処理が目に見えて，気分的に安心するという事も影響してるんだろうけど)
参考 : Multitasking
参考 : コンテクスト管理 について

ただ，組込みのような環境だとOSにあわせてハードをカスタマイズすることもできる．
(できるといっても普通はOS機能をハードでやるなんてことは労力の割りに効果が無いのでやらないだろうけど)
例えばSilicon TRONなんてものがあったりする．
ITRONの基本的な機能をハードで実装したものだ．
ハードウェアの利点は並列化であり，順序的な要素が強そうなOSの機能はハード化する必然性はないともいえる．ただRTOSの基本的な機能程度ならばハードで実装してもそれほどコスト(面積)はかからないので，悪くは無いのかもしれない．

このシリコンTRONでは，完全にCPUとは独立したモジュールになっているが，仮にコンテキストスイッチ等を実現する場合，CPUのアーキテクチャを変更する必要がある(レジスタやCPUの状態を変更する必要があるため)．
これが問題のような気がする．というのも現在のRISC系アーキでは，原則的にパイプラインをストールさせない事を目標に設計されている．コンテキストスイッチとかそういった類の重い命令の追加は根本的なアーキに手を加えることになり，不用意な複雑化を招く(CISCの二の舞)．
そういったロジックを載せる位なら，その面積をキャッシュにでも充てた方がシンプルで良いというのが普通の人の考えるところである．

やるとしたら先日紹介したRMT Processorのように，超高速にスイッチングできるようにタスクコンテキストブロック(TCB)を全てCPUに埋め込む方法が考えられる．
しかしそこまでやる価値があるだろうか．RMTの場合はコンテキストスイッチが多発するマルチスレッドCPUなので理に適っているが，シングルスレッドCPUの場合そこまでコストをかける必要性が見当たらない．(いくらハードリアルタイムだといっても，スクラッチパッドメモリを載せてそこにカーネルやTCB群，クリティカルなタスクを載せてしまえば普通は問題はないはず．それで問題があるならそもそもワイヤードロジッックでやるべきだろうし)

ということはRISC系プロセッサでは下手にハードでOS的機能は支援しない方が良いのだろうか？
うーん，誰もやってないってことはしない方が良いって事なのかなあ．

SSEを使って常微分を解いたり．
まだルンゲクッタで解くのは研究中のようですが，楽しみです．
個人的に数学とアセンブラの組み合わせは古き良き時代のデモシーンに繋がるものがあって好感です．

「いま話題」とか言いながら3年前の記事なわけですけど，CMMってよく知らなかったので．
行き当たりばったりの僕には無縁の概念かもしれない．

BBCのR&Dがwaveletなcodecをオープンソースで出したようです．
waveletベースなcodecはOn2 TechnologiesのVP5あたりが有名らしい．全然知りませんでした．ちなみにH.264(MPEG4 AVC)といった次世代DVD(東芝NEC陣営)で使われる事になっている最先端の規格は未だにDCTベースです．ただこの辺は圧縮率とハードウェアコストの兼ね合いみたいなのがあるので，単純にどれがいいかは分かんないような気もします． Blu-LayなんかMPEG2で行くみたいだしね．これはビットレートに糸目をつけず高画質を求めるとMPEG2が最適みたいな話っぽいし，よく分からん．演算量が少なくても圧縮率が高くてビットレートと画質の線形性も保たれる万能codecを誰か考えて！
(from #osdev-j)

アルゴリズム体操を見て，アルゴリズムってなんだー！？って思った人．
ここで講義を受けてみよう．
なぜか動画が置いてあるんだけど，正直音声だけでも情報量的には問題なさそうです．

計算例があついです．計算自体は簡単そうだし，実装してみると面白いかも.

Beeさんがflipcode入り．
氏のページのRaytracingテスト画像がまた燃える．
鬼すぎます．
何者ですか，彼は．