博士

ロボ子、今回のITニュースは、Apple IIでQuicktakeカメラのデジタル写真を扱うプログラム開発の話じゃぞ！

ロボ子

Apple IIですか！ずいぶんと懐かしい響きですね。Quicktakeカメラのデジタル写真を扱うとは、具体的にどのような内容なのでしょうか？

博士

最初はQuicktake 100の写真デコードから始まったみたいじゃが、Quicktake 150/200のサポートへと拡張されたらしいぞ。

ロボ子

なるほど。Quicktake 150の画像フォーマットは独自仕様でドキュメントが公開されていなかったとのことですが、どのように対応したのでしょうか？

博士

dcrawプロジェクトを参考にして、Apple IIデコーダーを作成したらしいのじゃ。すごいじゃろ？

ロボ子

dcrawプロジェクトを参考にしたのですね。初期のデコーダーは1枚の画像をデコードするのに70分もかかっていたとのことですが、どのようにして高速化したのでしょうか？

博士

アルゴリズムの改善で、デコード時間が1分未満に短縮されたらしいぞ！最適化はC言語で行われ、最終的な実装は6502アセンブリ言語で記述されたみたいじゃ。

ロボ子

70分が1分未満ですか！驚異的な改善ですね。具体的にはどのような最適化を行ったのでしょうか？

博士

色の情報を削除したり、不要なバッファを削除してメモリの使用量を最適化したりしたみたいじゃな。あと、除算の最適化も重要だったみたいで、153600回の除算を2000回未満に削減するために、2行ごとに除算テーブルを事前計算したらしいぞ。

ロボ子

除算の最適化は効果がありそうですね。他にどのような工夫があったのでしょうか？

博士

出力バッファへのアクセス方法を改善したり、ハフマン符号のデコード方法を改良してビットシフトの回数を減らしたりしたみたいじゃ。6502アセンブリ言語での実装では、アドホックな最適化が多数適用されたらしいぞ。例えば、行の初期化時に乗算をシフト演算に置き換えたり、ビットシフト処理にルックアップテーブルを使用したり、不要なハフマン符号の読み込みを省略したり、バッファアクセスに自己書き換えコードを使用したり…色々あるのじゃ！

ロボ子

自己書き換えコードですか！ずいぶんと大胆な最適化ですね。そこまでやることで、ようやく実用的な速度になったということでしょうか。

博士

そういうことじゃな！最終的な6502実装はGitHubリポジトリで公開されているみたいじゃから、ロボ子も見てみると良いぞ。初期実装と現在の実装の比較動画も公開されているらしい。

ロボ子

GitHubリポジトリと比較動画、確認してみます。それにしても、昔のハードウェアでここまで最適化するのは、パズルを解くような面白さがありそうですね。

博士

まさにそうじゃな！昔のエンジニアはすごいのお。そういえば、ロボ子。Quicktakeで撮影した写真を見てたら、ロボ子の昔の設計図が出てきたぞ。…モノクロだったけどな！

ロボ子

えっ、私の設計図がモノクロ…ですか？それはちょっと解像度が低いですね！