DLL​/PICTURE0 :: OSASK計画

画像ファイル一般を扱えるデコーダDLL

• ・・・をみんなで作ろうかな、というプロジェクト。

なんでDLLにするの？

• ええとOSASKの予定では、この手の機能はいずれAPIとして実装される可能性が高いのですが、それは当分先になりそうなので、それまで画像を扱うプログラムの開発を控えるわけにはいかないし、それにDLLならK^[1]が「そんなマイナーな形式はAPIには入れられません」なんていうのもお構いなしに入れられるので、いいのではないかと。

どんなDLLにするの？

• 呼び出し関数：

  void call_dll0207_48(struct DLL_STRPICENV *env, int *cmd);
  void call_dll0207_48i(struct DLL_STRPICENV *env, int cmd, ...);

• 0207じゃなくてもいいんだけどね。
  • ASKA的にいうと、オフセット0x0048をfar-call。
• 質問：
  • DLL_STRPICENVは64KBくらいにしようと思っているのですが、これより大きな作業領域が必要になりそうな画像ファイルってありますか？
  • DLL自身も64KBを要求。これでいいですよね？

終端ファンクション

• ファンクションの最後につける
  • 0x0000

初期化ファンクション

• ワークエリアの初期化
  • 0x0001, 0x0000

識別ファンクション

• 与えられたファイルの情報を取得
  • 0x0002, 0x0000, info, size, fp, hint
• infoは32バイトのワークエリアへのポインタ（intの配列）。ここに解析結果が入る。
  • info[0]：画像ファイルタイプコード
  • info[1]：カラーや各種フラグ
  • info[2]：xsize
  • info[3]：ysize
  • info[4-7]：画像ファイルによって形式が違う領域
• sizeはファイルサイズ。
• fpはファイルがマッピングされているアドレス。
• hintはアプリ側がこのファイルの形式はこれじゃないか？というコード。画像ファイルタイプコードを書く。

基本デコードファンクション

• 与えられたファイルを所定の形式に単純展開
  • 0x0004, 0x0000, f_type, size, fp, b_type, buf, skip
• これは、拡大も縮小もクリッピングもない、単純明快な展開ファンクション。画像ファイルの全体を展開する。
• f_typeはファイルの画像ファイルタイプコード。
• sizeはファイルサイズ。
• fpはファイルがマッピングされているアドレス。
• b_typeは展開先のバッファタイプ。
• bufはバッファへのポインタ。
• skipは、1ライン展開した所から次のライン先頭へポインタを修正するために、加えるべき値（バイト単位）。
• 何らかの理由で展開に失敗した場合、env->errorが0以外になり、errpがセットされ、DLLの実行は打ち切られて、returnする。

部分デコードファンクション

• • 0x0005, 0x0000, f_type, f_xsz, f_ysz, f_x0, f_y0, size, fp, b_type, buf, skip
• これは、拡大も縮小もないけどクリッピングはある、そういう展開ファンクション。画像ファイルの一部もしくは全体を展開する。
• f_typeはファイルの画像ファイルタイプコード。
• f_xszとf_yszは共に符号なし整数で、展開領域のサイズを表わす。
• f_x0とf_y0も符号なし整数で、ファイル上での展開開始座標（左上）を示す。
  • f_x0 + f_xsz <= info[2], f_y0 + f_ysz <= info[3]である。
  • f_xsz、f_ysz、f_x0、f_y0で指定された画像に対して、基本デコードファンクションを実行しているようにふるまう。
• sizeはファイルサイズ。
• fpはファイルがマッピングされているアドレス。
• b_typeは展開先のバッファタイプ。
• bufはバッファへのポインタ。
• skipは、1ライン展開した所から次のライン先頭へポインタを修正するために、加えるべき値（バイト単位）。
• 何らかの理由で展開に失敗した場合、env->errorが0以外になり、errpがセットされ、DLLの実行は打ち切られて、returnする。

そのほかの規定

• envの最初の32バイトについて。
  • error：エラーコード
  • errp：エラーコードを起こしたファンクションへのポインタ
  • 残り24バイトは未定
• 画像ファイルタイプコード：

  0x0000	unknown
  0x0001	BMP
  0x0002	JPEG
  0x0003	PNG
  0x0004	ICO

• バッファタイプコード：

  0x0101	3bitカラー (0と9～15のみを使う -- 美しさ優先)
  0x0201	4bitカラー (美しさ優先)
  0x0801	6bitカラー (シェル用 -- 美しさ優先)
  0x0002	16bitカラー (美しさ優先 -- 特に理由がなければ普通はこっちをつかう)
  0x0004	32bitカラー (美しさ優先 -- 特に理由がなければ普通はこっちをつかう)
  0x8101	3bitカラー (0と9～15のみを使う -- 展開速度優先)
  0x8201	4bitカラー (展開速度優先)
  0x8002	16bitカラー (展開速度優先)
  0x8004	32bitカラー (展開速度優先)

• エラーコード

  0	エラーなし
  1	ファンクションコードエラー
  2	ファンクションパラメータエラー

DLLの実装

• test049dの

  int *cmd_vsprintf(struct STR_DLLENV *env, int *cmd)

• みたいな関数を作ることになります。これはK^[1]がやります。それで、

  int info_BMP(struct DLL_STRPICENV *env, int *info, int size, UCHAR *fp);
  int info_JPEG(struct DLL_STRPICENV *env, int *info, int size, UCHAR *fp);

• という関数を作ってください。これは自分が解釈できる形式だったら非零を返してinfoに値を入れてくれればOKです。さらに、

  int decode0_BMP(struct DLL_STRPICENV *env, int size, UCHAR *fp, int b_type, UCHAR *buf, int skip);
  int decode0_JPEG(struct DLL_STRPICENV *env, int size, UCHAR *fp, int b_type, UCHAR *buf, int skip);

• という関数もほしいです。これは成功したら0を返します。失敗したらエラーコードを。
• それぞれ、Cで書いてもASKAで書いてもNASMで書いても構いません（NASMの場合、naskでアセンブルできる状態になっていたらありがたいかな）。
• 最初のうちは、気に入らないパラメータ指定を受け取ったら、展開できないことにして、エラーにしちゃっていいです。
• この2つについてやりたい人は、こめんと欄で名乗り出てください。
• 他の画像形式でサポートしたいのがあればそれも名乗り出てください。
• 僕は上記関数以外の全てを今から作ります。
• できればライセンスはKL-01でお願いします。

こめんと欄

• できるだけ本文をいじらないようにして、ご意見はこのこめんと欄にお願いします。
• 以前のやり取りはこちら → DLL​/PICTURE0​/oldlog^[2]

• そこそこ動くようになったらWabaで使わせてもらいます。 -- ベイサイド^[3] 2003-09-28 (日) 05:25:18
• JPEGデコードルーチンを改良して、kjpegls相当にしました。4.54KB → 3.87KBです。kjpegls.binと比べて658バイトの差です。テストルーチンとセットにしてもう少ししたらリリースします。 -- K^[1] 2003-09-28 (日) 12:04:43
• http://osask.ne.nu/test050c.lzh^[4] (17.3KB) PICTURE0.BINは3.80KB(+586B)になっています。test050.bin(1.07KB)はPICTURE0.BINをDLLとして使う例です。 -- K^[1] 2003-09-28 (日) 13:43:38
• まあ対kjpeglsで+586バイトなら許せる気がするので、kjpeglsのバンドルをやめて、PICTURE0.BINをバンドルすることにします。I.Tak.さんのBMPルーチンができたら、これも入れて、BMPVも非バンドルにします（I.Tak.さんが4bit-BMPもサポートしてくれれば、ですが）。 -- K^[1] 2003-09-28 (日) 13:54:23
• あとは、もうここは改造しないだろうと思われるところから、ASKA化していくことかな。まあ僕はまだやりませんが。 -- K^[1] 2003-09-28 (日) 14:04:05
• プチ報告。ADVにDLLがつけれました。多分。 -- ＺＡＫＫＹ^[5] 2003-09-28 (日) 23:37:28
• ver.4.2くらいで、OSASK自身も必要に応じてこのDLLを使って壁紙ロードをする、ようになりたいです。そしたらOS本体が小さくなって、起動時にすぐ壁紙を使わない限り、起動時間もちょっと短くなりそう。DLLがPNGとかに対応したらOSASK本体も恩恵を受けられることになります。 -- K^[1] 2003-09-29 (月) 02:20:22
• そのためには、DLLが4bitカラー減色とシェル専用64色カラー減色にも対応しなきゃいけないのかな。その辺のDLLの仕様作りは、既にかなりの経験を積んでいるI.Tak.さんにお任せします。OSASKへの組み込みは僕がやります。はみ出した部分をメモリに書かない、みたいな処理も必要になりますよね・・・。なんか僕でも仕様＆JPEGドライバだけなら作れそうな気がしてきた・・・。明日やるかな・・・。 -- K^[1] 2003-09-29 (月) 02:26:53
• 今のOSASK内蔵ルーチンを改造すれば行単位での誤差拡散減色 (16,64色) ができます。 -- I.Tak.^[6] 2003-09-29 (月) 12:21:06
• BMPルーチンできました (高速モードのみ)。http://user.ecc.u-tokyo.ac.jp/~g240845/osask/lzh/bmpdll.lzh^[7] 。24,8,4,1bppから32,16bppに出力できましたが、エラー処理はまだチェックしてません。エラーコードは非0か0のみです。 -- I.Tak.^[6] 2003-09-30 (火) 16:30:17
• ええと、ソースを読みました。64KB中にstaticな領域がほしいのでしたら、用意しましょうか？JPEGルーチンの最適化がほとんどできてなくてすみません。これからこちらでもPICTURE0.BINに組み込んで、試してみようと思います。うまくいったらリリースします。 -- K^[1] 2003-09-30 (火) 17:11:22
• http://osask.ne.nu/test050d.lzh^[8] (23.1KB) バグなのか仕様なのか判断に困る現象に遭遇しています。TEST128.BMPなどを見てみると、縦に黒い線が何本も入っているようにみえますが、これは仕様なのでしょうか？（32bitへの展開の場合）。 -- K^[1] 2003-09-30 (火) 17:56:23
• staticな領域はBMPでは要りませんが、JPEGのように大きなテーブルを使うときは必要そうだなあと思いました (kjpeglsdを作っているときは外部ファイルにしようかとさえ思った。メモリの節約になるし)。 -- I.Tak.^[6] 2003-10-01 (水) 17:10:22
• ディザなどはしていないので、縦線が入るのはバグです。発見しました。.bpp4:にあるand eax, byte 7 は and eax, byte 15 の間違いでした。buf16,buf32ともこのバグがあります。 -- I.Tak.^[6] 2003-10-01 (水) 17:17:14
• 教えてもらったところを直したら、なおりました。ありがとうございます。これで単体起動でもKJPEGLSを越えたと思うので、OSASK-MLでアナウンスすることにします。 -- K^[1] 2003-10-02 (木) 14:09:44
• BMP,JPGともPICTURE0に関連付けという認識でOKですか? -- I.Tak.^[6] 2003-10-02 (木) 15:43:07
• いえ、今回は間に合わなかったので、JPGだけです。＞関連付け -- K^[1] 2003-10-02 (木) 16:18:35
• I.Tak.さんへ：I.Tak.さんが各種バグフィクスをしたPICTURE0.BINのソース（差分ソースでも可）がほしいのですが、どこかにアップロードしていただけないでしょうか？直したやつをバンドルしたいのですが、やっぱり僕の責任でリリースする以上、どこが改変されているのか把握したいなあ、と。 -- K^[1] 2004-02-03 (火) 15:59:32
• 各種じゃなくて一箇所だけですので (MLで書いた一箇所だけ)…… -- I.Tak.^[6] 2004-02-04 (水) 21:51:42
• 了解です。お返事が遅くなってすみません（書いたつもりになっていたのに、書いてなかった）。 -- K^[1] 2004-02-07 (土) 17:38:23
• PICTURE0.BINって透明色の扱いを何も考えていなかったのですが、そういうのも取り入れられたらいいですよねえ。32bitカラーモードでは、上位8bitにベータ値（0xff-alpha）を置くという仕様にしようかなあ・・・。ご意見募集。 -- K^[1] 2005-01-03 (月) 00:41:13
• 安全のためには、ベータ値つき32bitカラーモード、っていうのを作るべきかもしれない。 -- K^[1] 2005-01-03 (月) 00:42:47
• いやどうせなら、GIFアニメなどを意識して、nコマ目を指定して受け取るような仕様も盛り込むべきかも。 -- K^[1] 2005-01-03 (月) 00:45:09
• パレット付きをパレット付きとして取得する機能は無いわけですし, α/βマスクが取得できれば十分では。マスクも一個の画像として取得できると, GIFアニメとか16bit出力と相性良さそう。 -- I.Tak.^[6] 2005-01-03 (月) 17:01:09
• さすがI.Tak.さん、あたまいい！・・・ってことはnコマ目指定モードで、特別なコマを指定すると、マスクが得られるとかそんな感じというわけですね。なるほど、その方向で行きましょう。 -- K^[1] 2005-01-03 (月) 17:21:25
• なんかこのページに書かないまま進んでしまいましたが, タイプ3=PNG と タイプ4=ICO になりました。と, まとめておきます。 -- I.Tak.^[6] 2005-07-17 (日) 01:25:43
• 了解です。 -- K^[1] 2005-07-17 (日) 10:03:57