日記緑ログ

2005/04/02 ~ 2005/04/25

目次

戻る

Blog

近況

[Create: 2005/04/02 19:27] [LastUpdate: 2005/04/02 19:30]

生きてます。

DIB用のライブラリでも作ってみようかと思うんですが

そんなもんごろごろ転がっているけど・・・

C++のクラスにでもするとしてクラス名をつけるのが迷う・・・

CBitmapあたりが妥当だと思うんですけれど、CDIBとかいう線もないわけでもない。

近況2

[Create: 2005/04/08 19:13] [LastUpdate: 2005/04/08 19:27]

やっぱり生きています。

なんで更新がないかというとなんにもやってないからなんですが、

なんでなにもやっていないかというとビットマップのお話が纏まらないからなんです。

最大限に汎用性を高めようとすると

1.パレット

2.色空間

3.色深度

あたりが面倒そうです。

パレットは面白い効果があるのであったほうが面白いのは確かなのですが、非パレットからするとパレット対応というのは冗長な操作ですし、データ構造も多少複雑になります。

またパレットの数というのも問題になります。ノーマルのビットマップでは2色、4色、16色、256色だったと思いますが、GIFなどでは2から256までビット刻みでありますし、場合によっては512色とか1024色のパレットがあってもいいわけです。

色空間についてなのですが、RGBだけでも特に不都合は無いのが実情だとは思いつつも、JPEGなどでは記憶ではYCbCrだったはずです。

また、CMYやらHSVだかなんだかとか色は一杯あるのでそういうものを変換無しに取り扱うにはあったほうが便利そうです。

色深度ですけれど、RGBだって24だけじゃないわけで、16ビットもあるわけです。その16ビットでも555や565もあります。32ビットでアルファチャンネルとか言う話はこの際無視しますが、TIFFなどでは48ビットにも対応しています。

次世代のWindowsでは一色に32ビット浮動小数点数を割り当てるとかいう話もあったりしますのでこれも対応させてもいい時期なんじゃないかと思います。

補足しておきますが、ここでいっているビットマップというのはWindowsのBMPのことではありません。念のため。

ビットマップ

[Create: 2005/04/13 13:18] [LastUpdate: 2005/04/13 13:33]

前回までの流れを汲んでいるようでいてぶったぎりますが

WindowsのBitmapファイル(というかDIB)は横のバイト数が4バイトの倍数でないといけないことになっています。

ファイルに保存するときなどにはこのあたりをちょっと気にしたりすることがあるかもしれません。

こういうときの計算ってどうやるんでしょうか。

Bytesが横のバイト数(データ部分のみでパディング分がないもの)としたとして

(Bytes + 3) & ~3

で表すことができるでしょう。

間違っても

Bytes+(4-Bytes % 4)

と は書かないで下さい。とおもいたい。確かに上の書き方は一般的ではありませんが(つまり例えば5の倍数などというときには使えそうに無い)そもそも4バイ トの倍数になってる時点でちょっとしたトリックだということに気付いてそのようなもののためにわざわざ低速で一般的な形で書く必要はない気がします。

それだけ。

Bitmapクラス

[Create: 2005/04/13 21:57] [LastUpdate: 2005/04/13 22:05]

長いこと引っ張っていたビットマップクラスですが一応適当に作成しました。

RGB888の各々整数値、24ビットフルカラービットマップのみ読み書きできます。

ただしビットマップには実は様々なバージョンがありますが、このクラスではBMP Ver.3のみ正式に読み込めます。といってもヘッダが変なものは読み込めません。

実際のところこんなクラスを手作りするよりWindowsのAPIを使って読み書きそろばんのほうが速度は速いし安定しているし、バージョンの違いにも気を使わないですむので楽です。まあ遊び程度に考えてもらうことにしましょう。

公開はこのあたりで。

余談ですが、前回のヒルベルト曲線適当圧縮のビットマップファイルを扱っている部分をこれにかえて、インライン展開をなくしたらまともな状態になりました。やっぱりどこか変のようです。

邪悪な遺産

[Create: 2005/04/21 20:12] [LastUpdate: 2005/04/21 20:25]

タイトルは気にしないでください。

一度汚れたら完全なクリーンアップが不可能な巨大OSばかりの昨今ですのでリカバリー用のCDを作ってました。

といっても実際使えるかは検証していませんが…

使ったソフトウェアはPartition Savingです。

適当に起動ディスクをこしらえフロッピーでもよかったのですがどうせ実験ということでブータブルCDにしてみました。

さらに実験ということで2.88フロッピーディスクエミュレートモードにしてみました。

さらにさらに実験ですからそのイメージはエミュレーターで作成しました(エミュレーターに異常に反応する人は放っておきますがVMWareやVirtualPCというものが存在します)。2.88MのFDなんぞ持っていませんのでエミュレーター上で作成したわけです。

余 談ですがこういったイメージ作成をする前にはデフラグを実行してディスク上でファイルを連続させておくべきです。これによって圧縮率の向上が望めます。ま たすべてのセクターをイメージ化する場合は領域をすべてクリア(つまり0埋め)しておいたほうが圧縮率がアップし、スピードも向上します。

適当に作りましたがイメージ作りをするというより、久しぶりにDOSモードで遊べて面白かったのが大きい気がします。

PCエミュレーター

[Create: 2005/04/25 22:33] [LastUpdate: 2005/04/25 23:04]

前回エミュレーターの話が出てきたのでついでに。

Windowsに限りませんが現在主流のOSたちは肥大化が進んでいます。

肥大化が進むと弊害として環境を破壊的に構築すると復元が困難になってきます。

なんらかのアプリケーションをインストールするとシステムのクリティカルな部分に共有ファイルをころがしたり、設定を刻み付けたりします。

Windowsの場合、レジストリはデータベース構造のために書き込んだら最後ファイルサイズを戻すことはできません。いやできますがもともとはできませんでした。いまでも普通の状態では大きくなる一方です。これは使えば使うほど増えていくわけです。

こ ういったことを嫌っている人は多く、Windows95のころから月に一度はOSを再インストールする人も存在します(Win95はレジストリが肥大化す ると不安定になったり、ごみが増えれば不安定になったり散々だった。これはOSが悪いわけではないと思う。わたしは95は好きです。)。またソフトウェア の作者も極力レジストリや、システムディレクトリを使用しないことをモットーとする人もいます。

さらにいえばランタイムの共有ファイルなどはみだりに消すと他のプログラムにも影響を与える可能性があるため、アンインストール時に手付かずな場合も多く、どんどんごみが増えていくわけです。

こ れがDOSであればautoexec.batとconfig.sysあたりを適当に生かしてあとはばっさり削除してやればクリーンUP完了でした。 Windowsの場合はそうはいきません。構造が複雑で、レジストリのこのあたりのノードをばっさり削除し、Systemディレクトリのこのあたりのファ イルを適当に削除してみたらあら不思議、OSが起動できなくなってしまうことも多々あります(とはいってもあまりに重要な部分はOSからガードされている こともあったりする)。

UNIX系も注意深く設定ファイルから削除、実行ファイルを削除を煮詰めていけばいったん食い込んだ連中を追い出 すこともできなくはないと思いますが、そもそも巨大化した設定ファイルやジャングルのようなディレクトリ構造に加え、入り乱れたファイルを適切にひとつ残 らずクリーニングなどできるものでしょうか?わたしには自信がありません(

これがフロッピー一枚に収まった状態であれば文句無く可能でしょうが)。

と いうわけででてくるのがエミュレーターです。必要に応じてOSを切り替える(というかイメージファイルをとりかえる)こともできますし、イメージをコピー しておけば環境破壊も苦になりません。もちろん実際のマシンでHDDのイメージ化ツールを使用し、リカバリーCDを作成することもできます。しかしそれよ りもエミュレーターははるかに手軽です(ただし速度を期待することはできないし特殊な周辺機器はサポートされないのでそのあたりは実機でないとだめなこと もあるはず)。

一度やると面白さに面白くなりそうですよ。気持ちがあればお試しあれ。