トップページ | 2006年11月 »

10月31日の日記

OFFMODE R25

朝、何気に OFFMODE R25 Get!

いやぁ、何だろうねぇ~。

変な所で運を使い果たしても困るんだけどなぁ。
中を開くと、L25 の創刊予告が。

信号の電球交換


そんな朝、通勤途中の交差点で信号機の電球を交換しているオッサンに出くわしました。

オッサンと言っては失礼ですね。業者の方です。

小さいハシゴ車(東京電力が電線の検査に使ってるアレです)のゴンドラに乗ったオッサンが信号機の電球の前でゴソゴソやってるんです。

「何やってんだろ?」と思ったらそのハシゴ車の後部に『信号機の電球交換中です』とプレートが貼り付けられてる。

信号機って青、黄、赤が別々にパカッと開くんですね。

ワゴン車の後部扉がカパッと開くように信号機がパカッと開くんです。
そうかぁ。そうやって開くのかぁ。

そしたら、そのオッサン、青信号点灯中(黄と赤は消灯中)に黄色の電球を取り替えているんですね。

青信号なんてそんなに何秒も点いているもんじゃございません。
つまりは、青信号が黄信号に変わるまでに電球の交換を終えなければいけないわけです。
「いやぁ、まったく大変なお仕事だな。」

・・・と思って見ていたら、
赤信号の電球交換中に信号が黄色から赤に変わりました。

なんだ。。。結局タイミングなんて関係無いのねん。

辛っ~!

これが、辛いんですね。
煎餅一面に七味がまぶしてあるんですが、
3枚も食べると汗が、、、滝汗です。

2時間経ってもちょっと運動すると汗噴出すもの。
3枚だぞ、3枚。

金吾堂製菓
(2006/11/1 追記)
汗の量は人や体調によると思います。
“辛い”と言っても激辛ではなく、唐辛子と七味の別の成分が相互作用して発汗につながっているようです。

夜景

会社がちょっとした高層ビルなんですが、

昼間にビルから外を見ると、東京ってスモッグだらけなんですね。

ほんの少し遠くなるとガスってて見えやしない。

しかも地表から2,30メートルの低い空気が格段に汚れているように見えるんです。

「こんなところで生活してちゃいけない。」
「人が生活する場所じゃない。」
って、そう思います。
ところがそのスモッグの下(中か?)では何百万って人が生活してるんですよね。
「いやぁ、不健康極まりない。」

ところが、これが夜になると綺麗な夜景に変わるから不思議です。

薄汚れた空気は暗くなると目立たなくなるようです。

ビルのあかり。街灯の灯り。

夜になって汚いものが見えなくなるのは、いいんだか、わるいんだか。

| | コメント (2) | トラックバック (2)

DCTについて

DCT( Discrete Cosine Transform )


下記の図はDCTの基底64個を示しています。
それぞれが8x8ピクセルです。


離散コサイン変換 ( = DCT( Discrete Cosine Transform ) ) というのは、
画像データである8x8ピクセルを上記64パターンに分解する事なのです。

    7 7      
(画像データ)  =   Σ   Σ   ax,y   ×   cos(x,y) 
    x=0 y=0      
  cos(x,y) は上記64パターン
  ax,y がDCT係数 ( DCT coefficient )


普通の画像データでは DCT係数 ax,y 64個のうち、の数個だけが突出し、残りの係数がゼロに近い値となります。

JPEG や MPEG では、この性質を利用して圧縮を行っています。

| | コメント (2) | トラックバック (0)

さっき帰ってきました。

さあ録画しておいたMステ観るぞ!

・・・

機械の不調で、(録画予約時間に起動しようとした形跡はあるものの)
見事、録画失敗してました。

がっかりです。
まったく。

| | コメント (0) | トラックバック (0)

R25 の女性向け『L25』11/1 創刊

されるらしいです。
Recruit のニュースリリース
ちなみに、 http://L25.jp が既にできてたり。

| | コメント (0) | トラックバック (0)

昨日の日記

日本語間違っちゃってますね。
蝸牛(かぎゅう)” と書くべきところを
“牛汁”(ちがっ)
“牛耳”と書いちゃってます。

バカ丸出し!

これは、コッソリ直しておかないといけません。

| | コメント (0) | トラックバック (0)

ロックとポップス

昨日「ロックな君こそ」な R25 を見たせいもあるのだろうけど、
「自分は音楽が好きなのか?」ふと考えてみた。

正直、 “ロック”“ポップス” の区別すらよくわからない。。。

   “ポップス”“Pops” は違うのか?

     “ロック”“Rock” の違いはなんだ?

          Queen はたぶん “Rock” だ。

      木村カエラ“ロック” なのか? それとも “ポップス”

ヨクワカラナイ...

たぶん、僕にとっては “スキ”“キョウミナイ” の2択しかない。

“ロック”だろうがポップス”だろうが、どうでもいい。

スキだから聴いている。 ただそれだけなのだろう。


いや待て! “キライ”な音があった。 シャカシャカ音
シャカシャカ音が音楽じゃない、という話もあるが。

なぜシャカシャカ音キライなのだろう?
「高音部分のみ。。。」なんて科学的な説明もある。。。

自分なりに答えが出たので、ここで『新説』発表~♪
新説:『シャカシャカ音は受動喫煙と同じ!』

受動喫煙(すなわち人の吸ったタバコの煙を吸う)は
「なんでコイツの肺を通った煙を吸わなければならないんだ カチッ 」 っとなるから不快なわけですよ。

それと同じで
「なんでコイツの耳の穴を通った音を聞かされなければならないんだ カチッ
そういうわけです。
だからシャカシャカは不快なんですっ。



う~ん。説得力ない。

まあ、それはそれ。 そんな僕は最近、木村カエラをヘビーローテーション。
通勤時間を含めて1日2時間は聴いてます。

ロックかポップスかもわからないままに。。。


そうそう、今日はサディスティックミカバンドの CD 発売日です。

昨日の夜中3時につけっぱなしのTVから「今週のミュージックステーションはサディスティックミカバンド・・・」 というCMが聞こえてきたんです。

以前、ビールのCMでサディスティックミカバンド(with 木村カエラ)をやってた時は、 「なんでCD出さないんだろう。出してくれないかな。」と思ってたんですが。
それ以来、忘れてました。

そんな時に「Mステでミカバンドです。」

「もしかして?」と思って調べたら今日じゃないですか。
買いそびれるところでした。

| | コメント (0) | トラックバック (1)

MUSIC R25(2006/10/24) get!


R25 の別冊『音楽 R25』をゲットしました。

いつもなら木曜日に配布されているフリーペーパー R25 が
駅の R25 置き場にありました。

なんでだろう、と思ったら
今日は携帯の『番号ポータビリティサービス』なんですね。
今回の R25 は au とのタイアップでした。

なるほど、それで music...
Music携帯ですから・・・

今日は仕事がキツくて早々に退社したのですが、
たまには早く帰ってみるもんです。

ちなみに R25 はここ1年ぐらい愛読してます。

| | コメント (0) | トラックバック (0)

(連載)第5回:PNG(ぴんぐ)

敢えて言おう、カスであると。

PNG は Unisys が GIF の圧縮技術である LZW について権利を主張し、 GIF の公共性がグラついた事を期に仕様化された。

PNG は GIF を 凌駕(りょうが) 駆逐(くちく) する事が唯一の目的だった。


実際、当時にさかのぼって、Unisys が権利主張し始めた頃は、多くの人が (いきどお)りを感じたものです。

「なんで皆が使っているものに課金する!」
「Unisys 許せない!!」
キィーッ!!

そんな頭に来た人達によって PNG は作られたのです。

本来“ものづくり”というのは、その“もの”を使う人の利益を考えて作らなくてはなりません。
そうしないと決して良いものはできないのです。

ところが、PNG を作る動機は
「GIF ぶっ潰してやる」
「GIF の市場、奪い取ったる」
キィーッ!!
なのですから、全くユーザーの方は見ていないわけです。
動機が不純なのですから、良いものができるはずがありません。
キィーッ!! という感情に任せて作ったものなどダメなのです。



では、PNG がどれほど素晴らしいのかを見ていきましょう。
まずは、圧縮率からです。

一部の人達によって「PNG の圧縮率はたいていの場合、GIF を凌駕する」と言われています。
本当でしょうか?

まずは 256 色の画像について検証してみましょう。
Lena という有名な画像です。
ちなみに、"ZIP" と書いているのは、BMP ファイルをそのまま ZIP 圧縮したものです。
lena (512x512x256)
BMP 263,222 byte
(100.0%)
GIF 191,793 byte
(72.9%)
PNG 194,418 byte
(73.9%)
ZIP 168,255 byte
(63.9%)

GIF の勝ち(辛勝)


1画像だけで判断するのは危険です。
別ファイルでもやってみましょう。
GoldHill という、これも有名な画像です。
gold (720x576x256)
BMP 415,798 byte
(100.0%)
GIF 268,146 byte
(64.5%)
PNG 270,566 byte
(65.1%)
ZIP 240,112 byte
(57.7%)

またも、GIF の勝ち(辛勝)

256 色というのは、PNG にとって不利なのかもしれません。
もう少し色数を落として、規則的なパターンで試してみましょう。
※ 16bits になっていますが、実質 2bits です。
市松模様 (128x128x16)
BMP 8,310 byte
(100.0%)
GIF 1,198 byte
(14.4%)
PNG 1,556 byte
(18.7%)
ZIP 235 byte
(2.8%)

GIF の勝ち
このパターンは PNG よりも GIF に有利だった様です。

PNG にくらべ、ZIP がはるかに圧縮できているのは何故でしょう?

PNG は ZIP と同じ inflate/deflate を用いています。
なぜ ZIP と同じ圧縮エンジンを用いているのでしょうか?
おそらく、キィーッ!!っとなった時に たいした考察もなく
「圧縮エンジンは有名所の ZIP と同じにしておけば良いだろう」
ぐらいの考えだったのでしょう。

それなのに、ZIP に遠く及ばない。。。

ZIP はファイル単位で圧縮を行います。
PNG は画像のライン単位で圧縮を行います。
この差です。

なぜこんな処理にしちゃったのでしょう?

たぶん、インターレースの処理が頭から離れなかったのでしょう。
頭に血が上っているのですから、仕方ないと言えば仕方ない。

ちなみに“可逆”(圧縮して展開すると完全に元に戻る)の場合、
「エントロピーをいかに最大にするか」
が圧縮率の唯一のファクターです。
この分野では ZIP や LZH が凌ぎを削っています。
可逆の画像フォーマットが圧縮率で ZIP を追い抜くという事はかなり難しい事になります。
画像専用の圧縮フォーマットであれば、 画像の持つ特徴に合ったエントロピー圧縮を行えば ZIP を追い抜く可能性が出てきます。

もし PNG が ZIP の圧縮率に近い値を出すことができていれば
  「おまえ、よく頑張った。」
と褒めようという気にもなりますが、、、
同じ圧縮エンジンを用いている割には離され過ぎです。
「桁違いじゃないの。」

結論から言うと、PNG が極端に良い圧縮率を叩き出せるのは、画像データがPNG のフィルタにマッチした著しく特殊なケースだけ、 すなわち PNG にとって都合の良い一部の画像だけなのです。

安易に ZIP の inflate/deflate に手を出した事にも問題があります。
ZIP は今まで何度もセキュリティホールが見つかって修正した過去があります。
ZIP のセキュリティホールを突いたウィルスが画像データの形で撒き散らされたら、と思うと、そら恐ろしい事です。
画像データの圧縮フォーマットを作ろうという人達は、独自の力で圧縮エンジンを作り上げるだけのスキルが必要なのです。
「他の人が作った便利なモノを使えばいいや。」という考え方では安直過ぎるのです。


次に、PNG のもう一つの特徴である「 GIF は 256 色までしか扱えないけど、PNG はフルカラー扱えるもんネー!」について検証してみましょう。
JFIF テスト画像 (227x149x24bit)
BMP 101,970 byte
(100.0%)
GIF -
(24bit 圧縮はできない)
PNG 85,539 byte
(83.9%)
ZIP 77,897 byte
(76.4%)
JPEG 5,446 byte
(5.3%)

“可逆”を捨てきれない PNG は “不可逆”と割り切った JPEG には全く太刀打ちできません。
完敗です。
もし“可逆”が必要な画像データだったら (情報量を落とさずに圧縮したいなら)、 ZIP 圧縮すればよいのです。
「レントゲン写真を JPEG 圧縮して肺にノイズが写ったら困るじゃないかーー!」という PNG 信者による子供地味た反論を聞いた事があります。
「そんな重要なデータは圧縮するな」と言いたいです。



PNG 開発の唯一の、そして最大の目的が“GIF の駆逐”だった訳ですから、 プロパガンダのために宣伝文句が幾つも必要だったはずです。

しかも、圧縮率が悪い、処理時間が遅い、バッファが沢山必要、と実力を伴わないフォーマットなので、極めて不利な戦いだったのです。

キィーッ!!っとなった人達(しかも大して技術を持たない人達)が不利な状況をひっくり返すには “大衆を見方に付ける”というやり方しかなかったのかもしれません。

そうなると、
「Indexed color だけではなく full color が扱えます」と言わなければならないし、(JPEGには負けるけどネ)
「透明色が1色ではなく、Alpha channel が扱えます」と言わなければならない。(対応しているブラウザあんまり無いけどネ)
「圧縮率で GIF を圧倒する」とデータを改ざんするような真似までして虚栄をはるような事までしなければならない。(ウソはいけないヨネ)
モニタの色温度を考慮するようなブラウザが無いのを知っていて「γ補正が・・・」(意味ないヨ)
必要も無いのに「48ビットが・・・」(これも意味ない)

聞いていて虚しいばかり。。。

プロパガンダのためのスローガンだけが先行する形になってしまう。

たいした中身が無いのに、必要の無い機能まで山ほど詰め込んでウダウダの仕様(バランスを欠いた仕様)になってしまう。


たとえば、あなたが車を買いにディーラーへ出向いたとしましょう。

店員はあなたにこう言います。
「この車、いいでしょう。今ならカーナビお付けしますよ。」
「ETCも付けましょう。」
「5.1chのDVDシアターシステムも付けましょう。」
このぐらいだったらサービスの範囲内かもしれません。
店員はさらにこう言います。
「誰かに“ライフル”で射撃されても大丈夫なように防弾ガラスと装甲車並のボディを付けましょう。」
「だって必要でしょう。無いよりあった方が良いでしょう。」、と。
店員は調子に乗ってさらにこう言います。
撒き菱(まきびし)によってタイヤがパンクさせられるかもしれません。
 今ならキャタピラをお付けしますよ。」

さすがに、この辺で「おかしい!」と気付かなければなりません。

気が付かないと、燃費がひどく悪く、サスペンションも効いていない車に乗るハメになってしまいます。
しかし“目的地にたどり着く”という車の最低限の特徴を備えているために、ディーラーを訴えることもできないのです。

PNG は不要な機能が山ほど付いているという意味で、こんな感じの画像フォーマットなのです。

良いところがほとんど無い。
その上、“GIFを駆逐する”という唯一の目的を成し遂げられなかった。
Unisys の特許失効という燃料切れによって、一気にトーンダウンした。

それが PNG なのです。

もう一度言おう、カスであると。

また、PNG 騒動に踊らされた人にも言いたい。
「ちゃんと検証したのか」と。
「あるいは、ちゃんと考えて、自分なりに納得してそのような結論を出したのか」と。

(おわり)
言いたい事を言ったのでスッキリしました。


市松模様に関する補足(2007/1/23)

“名無しさん”から「bmp2png で圧縮したら 191 バイトだぞ、ゴラァ(゜Д゜#)」というご指摘を受けたので試してみました。

実際にやってみると、181 バイトでした。おー、ふごい。


では、どこに違いがあったのか見てみましょう。

まず GIF から。

青色の部分が LZW による圧縮データ(画像データをエントロピー圧縮した部分)です。
0000000 47 49 46 38 39 61 80 00 80 00 b3 00 00 00 00 00 GIF89a....3.....
0000010 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 21 f9 04 .............!y.
0000040 00 00 00 00 00 2c 00 00 00 00 80 00 80 00 00 04 .....,..........
0000050 fe 10 04 49 a7 ad f8 ea cc b7 ef e0 27 86 e4 e8 ~..I'-xjL7o`'.dh
0000060 99 65 8a ae 6a cb be a0 2b c3 f4 6c d7 e7 ad e3 .e..jK> +CtlWg-c
0000070 7b cf 4f be e0 4f 48 d4 0c 8f c5 24 12 b8 54 3a {OO>`OHT..E$.8T:
0000080 9b 2f e8 73 2a fd 50 af 55 65 76 8b 75 76 b9 60 ./hs*}P/Uev.uv9`
0000090 61 78 fc d5 95 c9 68 57 7a 7d 26 b5 d9 f0 4c 7c ax|U.IhWz}&5YpL|
00000A0 fe 06 d4 e9 70 fc bd bc d7 a3 fd 7d 57 81 80 60 ~.Tip|=<W#}}W..`
00000B0 84 83 5e 86 89 62 87 8a 4d 8c 8f 50 8d 90 3d 93 ..^..b..M..P..=.
00000C0 92 3f 96 95 36 99 98 34 9c 9b 2d 9f 9e 2b a2 a1 .?..6..4..-..+"!
00000D0 6e a4 a7 72 a5 a8 1b aa ad 39 ab ae 76 b0 ab b3 n$'r%(.*-9+.v0+3
00000E0 b1 b1 b3 b5 a8 b7 b7 b9 ad bb b4 bf be bd a2 c3 1135(779-;4?>="C
00000F0 a5 c1 a7 c5 9e c7 aa c9 9f cb c4 cf ce cd 96 d3 %A'E.G*I.KDONM.S
0000100 99 d1 9c d5 92 d7 9b d9 93 db d4 df de dd 89 e3 .Q.U.W.Y.[T_^].c
0000110 8f e1 8d e5 86 e7 90 e9 87 eb e4 ef ee ed 7e f3 .a.e.g.i.kdonm~s
0000120 81 f1 84 f5 7a f7 83 f9 7b fb f4 ff fc f5 9b 33 .q.uzw.y{{t.|u.3
0000130 b0 4e 40 3c 05 e3 1c bc 93 b0 cd 42 82 0f 1d 36 0N@<.c.<.0MB...6
0000140 5c 33 91 4f c5 3f 11 d9 64 3c 73 b1 cb 46 8a 55 \3.OE?.Yd<s1KF.U
0000150 1f 3d 76 1c 33 52 50 c9 42 21 c9 a4 c4 72 72 ca .=v.3RPIB!I$DrrJ
0000160 4a 92 2f 5d b6 dc 32 13 51 4c 9a 37 6d d6 8c 94 J./]6\2.QL.7mV..
0000170 33 4b 4f 2d 3f a5 04 2d b2 33 c9 50 9e 45 1d 25 3KO-?%.-23IP.E.%
0000180 5d b4 14 c9 51 a6 4f 87 44 f5 d1 34 c8 d4 23 55 ]4.IQ&O.DuQ4HT#U
0000190 9d 66 dd b1 55 6a d7 1b 5f 79 5c e5 3a 56 6c d8 .f]1UjW._y\e:VlX
00001A0 19 67 6b 44 00 00 3b                            .gkD..;
次に PNG です。
同じく青色の部分が(LZW ではなく)zlib による圧縮データです。
見事に小さいですね。
0000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 .PNG........IHDR
0000010 00 00 00 80 00 00 00 80 04 03 00 00 00 31 10 7c .............1.|
0000020 f8 00 00 00 30 50 4c 54 45 00 00 00 80 00 00 00 x...0PLTE.......
0000030 80 00 80 80 00 00 00 80 80 00 80 00 80 80 80 80 ................
0000040 80 c0 c0 c0 ff 00 00 00 ff 00 ff ff 00 00 00 ff .@@@............
0000050 ff 00 ff 00 ff ff ff ff ff 7b 1f b1 c4 00 00 00 .........{.1D...
0000060 40 49 44 41 54 68 81 ed ce 31 0d 00 00 08 03 b0 @IDATh.mN1.....0
0000070 39 c0 bf 4b 24 20 62 17 49 ab a0 99 52 b6 14 03 9@?K$ b.I+ .R6..
0000080 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 ................
0000090 03 03 03 03 03 03 03 03 03 03 03 03 03 83 e7 83 ..............g.
00000A0 03 2b 5e f0 e2 dd 71 f1 12 00 00 00 00 49 45 4e .+^pb]qq.....IEN
00000B0 44 ae 42 60 82                                  D.B`.
もう少し詳しく見てみましょう。

IHDRの12バイト目、赤色の
00
の部分は Filter method を示す。
Filter method = 0 は「フィルター無し」を意味すし、
続く、緑色の
00
の部分は、Interlace method を示す。
Interlace method = 0 は「インタレース無し」を意味する。

つまり libpng の部分はデータそのものには加工を加えていない。
圧縮率には全く寄与していない事になります。
高い圧縮率は zlib によってもたらされたものです。
「エンジン性能が良いから高い圧縮率が得られた。」
それだけの事です。

私の主張はこうです。
「だったらわざわざ PNG のヘッダなんて付けずに、ZIP 圧縮しろよ。」

PNG の存在意義を私は認めません。

ちなみに、10月24日にアップした上記の記事ですが、
IrfanView 3.98 とその plug-in
PNGOUT.DLL (Dec 26 2005) Optimized PNG Format - PNGOUT by Ken Silverman
を用いています。
PNG と GIF とを同条件で圧縮した結果です。

| | コメント (33) | トラックバック (1)

(連載)第4回:GIF(じふ)

GIF はパレット色画像の圧縮として最適のフォーマットだった。
        Unisys が現れるまでは。


GIFの仕様はこちら

Graphics Interchange Format

GIF は CompuServe での画像配信を目的として開発されたフォーマット。
著作権は CompuServe Incorporated 社が保有する。
LZW に関する特許は Unisys 社が保有する。

特徴 【長所】
・普及率が高い
・処理が極めて軽い
・中間バッファがほとんど要らない
・透明色、アニメーションGIF
【短所】
・非パレット色(256色を超える色数)が扱えない
・透明色は1色のみ(アルファ・チャンネルが扱えない)

■普及率が高い
Unisys が特許問題を持ち出すまでは、パレット色(256色以下)の画像フォーマットとしては標準的なものだった。

Unisys 問題により、一時期 GIF を PNG に置き換えるなどの動きがあったが、
2003 年に米国で、2004 年には日本で特許期限が切れたため、
今でも標準的な画像フォーマットとして扱われる。

■処理が極めて軽い
LZW を用いた極めてシンプルな圧縮法。
デコード時はパレット色の Index を計算するのに数ステップしか掛からない。
これは、デコードが極めて速い事を意味する。
デコードが極めて速い事が、後のアニメーション実装を容易にする事にもつながった。

■中間バッファがほとんど要らない
LZWのスライド辞書 ( 4 Kbyte ) とパレット保存用バッファ ( 1 Kbyte 以下 ) ぐらいしか中間バッファを必要としない。
これは画像フォーマットとしては極めて少ない部類に入る。

■透明色、アニメーションGIF
透明色は GIF89a から
アニメーションGIF は Netscape 2.0 によって、アプリケーション拡張の機能を使って実装された。
複数のフレームを用意し、その間に待ち時間( msec 単位 )を挟み込むことでアニメーションを実現している。

■非パレット色(256色を超える色数)が扱えない
Indexed color(パレット色)以外は扱えない。
実用面では、フルカラー色は JPEG で、などの住み分けが出来ているため、 GIF がフルカラーを扱えない事自体はそれほど不都合ではないようだ。

■透明色は1色のみ(アルファ・チャンネルが扱えない)
GIF では透明色を“最大1色”としている。
割り切った仕様、とも言えるが、この割り切りによって多くのアプリケーションのサポートを容易にした、とも言える。
アルファ・チャンネルが扱えないため、次世代マルチメディア ( MHEG など ) への応用が難しくなっている。
パレット ( = color table ) を拡張するだけで実現できるのだが。

サブマリン特許 特許登録をした後、成立するまで公開しなくてもよい制度(アメリカの旧制度)を悪用し、
公開まではその技術が普及するのを待ち、 場合によっては普及促進活動を行い、 時を見計らって特許料金の回収を行う事を言う。
一般ユーザーにとっては“寝耳に水”で慌てる事になる。

潜伏することから、潜水艦(サブマリン)と呼ばれる。

特許は、特許権利者の権利を守るのが目的であるが、 同時にそれが世間一般の不利益につながる事があってはならない。

サブマリン特許が生まれた背景にはアメリカの特許政策がある。

サブマリン特許の存在は、一部の権利者が権利を盾に一般市民から利益を吸い上げる道具としてしか使われておらず、 その存在を許す法律は悪法と言わざるを得ない。

この Unisys 問題が公になった数年間は GIF フォーマットにとっては空白期間となった。
たとえば日本のデジタル放送の規格である ARIB 規格では、GIF の採用は見送られ、 データ放送の画像フォーマットは JPEG と PNG とされている。

あなたがデジタルテレビ( BS 放送、CS 放送、地上波デジタル )のデータ放送で見ている チャンネルロゴや天気図は GIF では無く PNG なのだ。

(つづく)

| | コメント (9) | トラックバック (0)

(連載)第3回:JPEG2000 (じぇいぺぐ・にせん、J2K)

まず結論を言おう。

JPEG2000のフォーマットは表舞台に立つ事無く消える

特徴 【長所】
・ブロックノイズなどノイズに強い。
・圧縮率が高い
【短所】
・処理が重い
・中間バッファのメモリ量が多い

■ブロックノイズなどノイズに強い。

音声データの圧縮や解析ではフーリエ変換が行われる事が多い。
1次元のデータを波の重ね合わせに分解するのである。

画像データの場合は横1ピクセルラインずつ切って1次元で処理しても良いのだが、
その場合には縦のピクセル間の相関関係を全く無視する事になってしまう。

画像は2次元として処理をした方が効率が良い。

そこで、JPEG や MPEG では縦横8ピクセルx8ピクセルの格子に区切って DCT変換 ( Discrete Cosine Transform ) を適用しています。

ところが、8x8に区切った事で、格子状の境界が見えてしまう場合があるのです。

JPEG 2000 ではウェーブレット変換 ( Discrete Wavelet Transform ) を用いることで ブロックノイズを抑止しています。

■圧縮率が高い

JPEG に比べ、圧縮率が高い。
JPEG は10分の1程度が妥当とされているが、
JPEG2000 は20分の1程度まで圧縮可能と言われている。

■処理が重い

DCT 変換にくらべ、ウェーブレット変換の処理はずいぶんと重いようだ。

普及が進めば、高速化への努力が行われるのであろうが、今のように普及の兆しすら無いような状態ではそれも望めない。

■中間バッファのメモリ量が多い

JPEG の DCT では8x8とサイズが小さいため、DCT 係数を計算するための中間バッファは、それなりに小さくできる。
小さいと、何が有利かと言うと、、、
CPU を用いたシステムでは「ストレージ(HDD や FlashROM)」⇒「メモリ」⇒(「2次キャッシュ」)⇒「キャッシュ」⇒「レジスタ」と 複数の記憶装置を用い、中央(アキュムレータ)に近いほどアクセス速度が高い。
サイズが小さいと、レジスタに乗りやすく、8x8程度ならまず間違いなくキャッシュに乗る。

キャッシュに乗る(すなわち MPU で閉じている)か、それとも SDRAM メモリのアクセスが必要になるかでシステムとしての処理性能が大きく変わる。

圧縮前

BMP (240x320x24bit)

圧縮後
JPEGJPEG2000

9.8%
(Irfanview:JPEG option[q=95])


4.8%
(Irfanview:JPEG option[q=80])


3.3%
(Irfanview:JPEG option[q=60])


2.6%
(Irfanview:JPEG option[q=40])


2.2%
(Irfanview:JPEG option[q=30])


1.7%
(Irfanview:JPEG option[q=20])

9.9%
(Irfanview:JPEG2000 option[q=100])


4.7%
(Irfanview:JPEG2000 option[q=40])


3.2%
(Irfanview:JPEG2000 option[q=20])


2.4%
(Irfanview:JPEG2000 option[q=10])


2.1%
(Irfanview:JPEG2000 option[q=5])


1.8%
(Irfanview:JPEG2000 option[q=1])

画像を(JPEG2000の特徴がわかりやすいものに)差し替えました(2006/10/23)
※ ブラウザに「画像を滑らかにする」オプションがある場合は OFF にして画像を確認してください。


JPEG が普及し始めた頃、フルカラー画像を扱える適当な画像フォーマットは存在していなかった。
当時のパソコンの CPU は今よりもはるかに貧弱で、ハードディスクなどの記憶装置のバイト単価が高かった。
インターネット接続にしても、モデムという極めて低速なものしかなかった。
そんな時に「10分の1に圧縮できる」というのは、人々が飛びつくには“動機付け”として十分だった。
画像フォーマットが普及するには、 エンコーダーとデコーダーがどれだけ急速に普及し始めるかによる。
パソコンを所有している一般のユーザーがエンコード・ソフトやデコード・ソフトをインストールしようと思わせるだけのものがないといけない。
画像フォーマットそのものに魅力があるか、という問題である。

JPEG の場合には、フリー・ソースコード ( JFIF コード ) が世の中に出てくると、画像修正ソフトが競うように JPEG をサポートし始めた。
ブラウザの対応も早かった。

人々から支持された画像フォーマットは、支持された時点で普及までのレールが一気に引かれたと言って良い。

それに比べ、JPEG2000 は画像フォーマットとしての魅力に欠ける。
JPEG で圧縮率が10分の1だったものが、JPEG2000 でたった20分の1になるだけである。
この程度の改善だと、普通の人は「たった半分か」と思う場合が多い。
もしこれが“100分の1”だったら普及率は変わっていたかもしれない。

話が変わって Audio についていうと、
Audio コーデックでは MP3 が10分の1程度の圧縮率だが、MP3 が普及し切った頃に TwinVQ というコーデックが登場した。
TwinVQ は MP3 の約半分まで圧縮できる優れたコーデックだったが、“半分程度”ではポータブルプレイヤー市場をくつがえす事はできなかった。
倍程度ではダメなのである。

JPEG2000 は時代の波にも乗り遅れた。
インフラが整備されると“圧縮”そのものの価値が下がる。

(つづく)

| | コメント (5) | トラックバック (0)

(連載)第2.5回:JPEG progressive モード

特徴 ・「ジワァ~」と出る
【短所】
・展開にメモリを食う

Adobe Photoshop(Progressive Level3)
Spectral Selection

Adobe Photoshop(Progressive Level4)
Successive Approximation

Adobe Photoshop(Progressive Level5)
Successive Approximation

■「ジワァ~」と出る
JPEGのプログレッシブモードというのは、ネットワークが遅かった頃、 「画像の概形を少しでも早く表示する」という目的で作られたものです。

まず、ぼんやりとした画像を見せる。
その後、徐々にハッキリしていけばよい。

今ではネットワークが整備されたので、またパソコンのスペックも上がったため、
「ジワァ~」と出す目論見が、“一瞬で”表示されてしまいます。

つまり、必要性が無くなってしまったのです。
技術が時代に負けてしまったんですね。
「時が経てば、どんなに優れた技術も無価値になる」という良い例かもしれません。

■展開にメモリを食う
プログレッシブモードには“スペクトラル・セレクション”と“サクセッシブ・アプロキシメーション”という2種類があります。

まずは、“スペクトラル・セレクション”
上記の Adobe PhotoShop の例では、Level3 のものがそうです。
64個のDCT係数を複数個に分けて順に圧縮していくのです。
Adobe の例だと、係数No.0 (すなわちDC成分)、係数No.1~No.5、係数No.6~No.63の3ブロックに分け、 それぞれを別のスキャン( SOS: 0xFF 0xDA )で圧縮します。

第1スキャンでは DC 成分だけが圧縮されていますが、
第2スキャンには DC 成分が入っていません。第1スキャンの DC 成分をメモリに取っておかなければならないのです。
1画面分の DC 成分を、です。
プログレッシブでは画像サイズ分の DC 係数を保存するためのメモリが必要になるのです。

“サクセッシブ・アプロキシメーション”というのは“スペクトラル・セレクション”の発展形です。
DCT 係数の上位ビットだけを先に圧縮し、下位ビットは後で別スキャンで送る、というものです。
当然ながら、上位ビットの情報が残っていないと、下位ビットのスキャンは展開できません。


(つづく)

| | コメント (4) | トラックバック (1)

(連載)第2回:JPEG(じぇいぺぐ)

規格書は ISO/IEC 10918-1 ISO/IEC 10918
ISO (International Organization for Standardization)で規格書の PDF を販売しています。
こちらで "10918-1" を検索してください。
2006年10月現在、10918-1 は無料になったようです。(10819-2,3,4は有料)

CCITT(ITU) T.81 は ISO/IEC 10918-1 と同内容です。
こちらは www.w3.org から自由にダウンロードできます。→ itu-t81.pdf

特徴 ・非可逆圧縮(圧縮前と完全に一致する訳ではない)
・自然画の圧縮に向いている。(逆にエッジの多いアニメには向いていない)
・圧縮時間と展開時間に大きな差がない
【長所】
・圧縮率が高い(圧縮率を高くしても絵として成立する)
・圧縮/伸長の処理が割りと軽い
・自然画に関してはデファクト標準
・特許問題が無い(と思われている)
【短所】
・(実は)一度圧縮してみないとファイルサイズ(圧縮率)がわからない
・オーサリングに向いていない
・仕様にグレーゾーンが多い
関連規格 JFIF(じぇいふぃふ)
ISO/IEC 10918 規格ではsampling方法、DCT演算、量子化、エントロピー圧縮についてはガッチリ決められていたものの、 実用で使うには曖昧な部分がある。
例えば『色空間』
「モノクロは“色成分=1個”という運用をする。」
「カラーは“色成分=3個、順に Y(輝度),Cb(色差),Cr(色差)”という運用をする。」
こう決めたのは JFIF である。
“4:4:4 や 4:1:1 を基本的な使い方とする”と決めたのも JFIF である。

規格として、JFIF は ISO/IEC 10918 を機能制限したサブセットとなっているが、
運用面を明確化した事により、世間一般では「JPEG = JFIF」の図式が成り立っている。
すなわち、業界標準(デファクト・スタンダード)となっている。
Exif(えぐじふ)
JFIF とは独自に日本のカメラ団体が策定した規格。
ISO/IEC 10918 のサブセットであるが、JFIF のサブセットでは無い為、JFIF との互換性は保証され無い。
※ Exif ファイルは JFIF ではほぼ間違いなく展開できるため、問題にはなっていない。
関連団体 Independent JPEG Group
「自分たちはJPEG規格とは直接関係ないんだ」という有志によって、JPEG 運用面の規格 JFIF が策定された。
彼らは同時に JFIF ソースコードを無償提供し始めた。
関連規格のJFIF参照
Windows の画像ツール、画像Viewer のほとんどは JFIF ソースを組み込んでいる。
※ Adobe PhotoShop は JFIF をカスタマイズして使用。Internet Explorer や Mozilla も JFIF を使用。
こうして、世間一般で「JPEG と言えば JFIF のこと」という構図が作られた。

JFIF ソースコードの配布は 1998 年頃まで盛んに行われた。
・1996/02/07 に Version 6a が配布された(baseline が完成)
・1998/03/27 に Version 6b が配布(progressive が追加された。また Unisys 問題により、GIF ファイルの read/write 部が削除された)
この Version 6b を最後に開発が完了している。
■非可逆圧縮(圧縮前と完全に一致する訳ではない)
JPEG は『サンプリング(色空間の変換を含む)』⇒『DCT変換』⇒『量子化』⇒『ハフマン符合化(ジグザグスキャンを含む)』という4工程で作成される。
逆に JPEG ファイルを人が見て分かる画像データにするには『ハフマン復号化』⇒『逆量子化』⇒『逆DCT変換』⇒『逆サンプリング』と圧縮時とは逆の工程で行われる。
実は、可逆圧縮(圧縮してもデータが損なわれない)が保証されているのは4工程のうち『ハフマン符合化/復号化』だけである。

サンプリングは4:1:1の場合、Cb, Cr のデータ量を4分の1にする処理が行われる。
サンプリングでデータ量を落とさない場合は4:4:4である。
色空間をRGBからYCbCrに変換する場合に計算誤差(整数に丸める)が発生することがある。
DCT変換/逆DCT変換は、理論上は可逆であるが、FastDCT アルゴリズム (Arai, Agui, and Nakajima's algorithm for scaled DCT) を用いる場合などでは、±1程度(色深度0~255の内の±1程度)は許容範囲としているようだ。
実際の JPEG の使われ方では量子化でゴッソリ情報量を落とす。
だとすれば DCT での±1程度の誤差は許容されるのかもしれない。
色空間の変換計算誤差あり
サンプリングモノクロとカラーの4:4:4は可逆
それ以外は色差成分のデータ量が削減される
DCT変換計算誤差あり
量子化量子化テーブルの要素をすべて1にすれば可逆
普通は量子化でデータ量をごっそり削る
ジグザグスキャン可逆
ハフマン符合化可逆


色空間はカラー画像をYCbCrに変換して用いる。
4:1:1のサンプリングではCb,Crの2x2ピクセルを1ピクセルに間引く処理が行われる。
 4:4:44:1:1
Y
Cb
Cr


■自然画の圧縮に向いている。(逆にエッジの多いアニメには向いていない)
JPEG では8x8ピクセルの格子状の単位で2次元の周波数分解を行い、高周波数成分を除去する事で高圧縮率を実現している。
自然画においてはたいていの場合、大きな変化(低周波数成分)が重要で、細かい変化(高周波数成分)は重要度が低い。

下記の2つの四角、色合いの違いを除いて、何が違うか見分けがつくだろうか?

実は、左側の四角は1ピクセル単位で黒と白を交互に並べている。 右側は灰色で全面を塗りつぶしただけである。
左は高周波数成分が極めて高い画像、右は高周波数成分が全く無い画像である。
自然画においては、このような細かい凸凹は見えなくても良い場合が多い。
人の顔のシワなんて見えなくったって大した問題はないのである。

■本当にアニメには向いていないのか?
アニメは自然画と違ってエッジの部分(すなわち高周波数成分)が重要な意味を持つ(らしい)

『サンプリング』『DCT変換』『量子化』『ハフマン符合化』のうち情報量をゴッソリ削るのは『量子化』工程のみです。
量子化テーブルの64要素をすべて1にすれば、量子化でのデータ欠損は無くなります。
そうすれば、モスキートノイズやブロックノイズはもちろん発生しません。

量子化テーブルの要素をすべて1にする事は可能なのでしょうか?
JFIF 配布のソースでは可能です。(quality=100 にすれば良いだけ)
一般のエンコードソフトでは、量子化テーブルがオール1にはならない様に制限を掛けているようです。
圧縮前

圧縮後
低画質←の拡大図高画質

■圧縮時間と展開時間に大きな差がない
『DCT変換』と『逆DCT変換』はおおよそ同じ時間で処理できます。
『ハフマン符号化』と『ハフマン復号化』の時間もほぼ同じです。
1枚のJPEGを作る時の『DCT変換』の時間は画像サイズに比例します。
『ハフマン符号化』は出来上がった JPEG ファイルのサイズに比例します。
圧縮レートによって『ハフマン符号化』の時間は前後するわけです。

MPEG ではエンコード時の動き補償の計算に処理時間が掛かります。
綺麗な画を作ろうとすればするほどパターンマッチングの処理量が増加するためです。
MPEG ではエンコード処理とデコード処理には大きな差があります。

それに比べ JPEG はほぼ同じ。
サンプリングと逆サンプリングほぼ同じ
メモリのreadとwriteの時間が大きく異なるシステムでは差が出る
DCT変換と逆DCT変換ほぼ同じ
DCT変換処理を何らかの手段で工夫している場合
(AC成分がすべてゼロの場合の最適化など)差が出る場合もある
量子化と逆量子化量子化を除算命令で実現している場合は差が出る
(普通CPUでは積算より除算が遅い)
逆数を掛ける実装になっていればほぼ同じ
ジグザグスキャンと逆ジグザグスキャンほぼ同じ
ハフマン符合化と復号化ほぼ同じ
アルゴリズムを工夫している場合は差が出る


■圧縮率が高い(圧縮率を高くしても絵として成立する)
JPEG は圧縮率を変えられる(データ量を加減できる)のが大きな特徴の1つだ。

このバラの写真は JFIF ソースの中にサンプル画像として含まれるもの。
テスト用画像(圧縮前)
テスト画像 BMP フォーマット
227x149ピクセル(24bit)

データ部は101,469byte

PhotoShopというツールでは JPEG 圧縮オプションでレベル12(最高画質)~レベル0(最低画質)を選択できる。
(次の絵は、上ほど綺麗で下ほど圧縮率が高い)

あなたならどのレベルで妥協できるだろうか?
(圧縮後)圧縮レベルを変えて圧縮
Adobe PhotoShop
画像品質Level=12
PhotoShop画像品質Level=12 21,345byte
(圧縮率21% (≒ 1/5 ) )
Adobe PhotoShop
画像品質Level=11
PhotoShop画像品質Level=11 15,065byte
(圧縮率15%)
Adobe PhotoShop
画像品質Level=10
PhotoShop画像品質Level=10 11,346byte
(圧縮率11%)
Adobe PhotoShop
画像品質Level=9
PhotoShop画像品質Level=9 9,304byte
(圧縮率9.2%)
Adobe PhotoShop
画像品質Level=8
(最高品質 (低圧縮率) )
PhotoShop画像品質Level=8(最高品質 (低圧縮率) ) 7,901byte
(圧縮率7.8% (≒ 1/13 ) )
Adobe PhotoShop
画像品質Level=7
PhotoShop画像品質Level=7 6,568byte
(圧縮率6.5%)
Adobe PhotoShop
画像品質Level=6
(高画質)
PhotoShop画像品質Level=6(高画質) 6,046byte
(圧縮率6.0% (≒ 1/17 ) )
Adobe PhotoShop
画像品質Level=5
PhotoShop画像品質Level=5 5,438byte
(圧縮率5.4%)
Adobe PhotoShop
画像品質Level=4
PhotoShop画像品質Level=4 4,859byte
(圧縮率4.8%)
Adobe PhotoShop
画像品質Level=3
(標準)
PhotoShop画像品質Level=3(標準) 4,107byte
(圧縮率4.0% (≒ 1/25 ) )
Adobe PhotoShop
画像品質Level=2
PhotoShop画像品質Level=2 3,055byte
(圧縮率3.0%)
Adobe PhotoShop
画像品質Level=1
(低画質 (高圧縮率) )
PhotoShop画像品質Level=1(低画質 (高圧縮率) ) 2,331byte
(圧縮率2.3% (≒ 1/44 ) )
Adobe PhotoShop
画像品質Level=0
PhotoShop画像品質Level=0 2,137byte
(圧縮率2.1% (≒ 1/47 ) )

人によっては「最高画質でも妥協できない」だろうし、他の人では「標準以下でも耐えられる」だろう。

どの圧縮率が良いか?は『用途による』のである。

(注)上記の画像はJFIFのサンプルに含まれるものなので、圧縮に有利な画像(圧縮率を上げても絵として見えやすい画像)と思われます。
一般に、JPEG の圧縮率は『10分の1程度が妥当』とされています。

■圧縮/伸長の処理が割りと軽い
JPEGは今ではWebでの標準画像フォーマットのように使われる。
パソコンのブラウザはもちろん、携帯でもJPEGは展開され表示されている。
パソコンの処理能力に比べ、携帯のLSI処理能力が著しく劣っていることをご存知だろうか?
PCでは電源供給も十分行われ、CPUに馬鹿でかいヒートシンクを付ける事によってCPUをぶん回す事が当たり前になっている。
今ではCPU周波数がギガは当たり前。
それに比べ、携帯はバッテリーで動作する。もちろん手で持てないほど熱くなってはダメ。
おのずと動作周波数が抑えられる。
携帯で Web を見ようと思うと、このような制限された環境で動作するスペックでなければならない。

もし仮に、Web で標準となっている画像フォーマットがとてつもない処理量を要求するものだったとしたら・・・
「PCでは見ることができても、携帯では見ることができない。」
そのような状況を一般消費者は受け入れられるのだろうか?
それとも携帯に専用LSIを組み込み「携帯利用料金が月500円アップし、携帯端末の重量が3グラム増え、バッテリーの持ちが悪くなったら」 それを消費者が受け入れるのだろうか?

『画像フォーマットが普及するかどうか』は『一般消費者がそれを受け入れるかどうか』という判断が左右する。

今の携帯にJPEGデコード専用のLSIなんか入っていない。
ソフトデコードで十分なのだ。
JPEGのデコード処理は携帯のCPUで処理できるほど軽い。

■自然画に関してはデファクト標準
デジカメでは JPEG が標準的に使われる。
例外は一部のハイエンド機(HDD内蔵タイプが多い)で非圧縮データを用いるぐらいである。

JPEGでは伸長(=展開)の処理量と圧縮の処理量はほぼ同じ。
処理量は画像サイズに比例すると考えて良い。
しかし Web で使われる画素数とは桁違いの画素数がデジカメには求められる。
デジカメでは、今やメガピクセルは当たり前。 その内、ギガピクセルになるかもしれない。
(CCDの集積化やメモリの速度がファクターになる)

ギガピクセルの後はテラピクセルまで行くだろうか?
そこまでの情報は必要なのだろうか?

(話がそれてしまったが)
デジカメでは専用のJPEGエンコードLSIを内蔵している。
画素数が増えてしまうと、さすがにソフト処理という訳にはいかない。
一度、標準的なハードが確立してしまうと、容易にはくつがえらない。

■特許問題が無い(と思われている)
世間一般のほとんどの人は「JPEGに特許問題がある」なんて思っちゃいない。
一部のコアな人は「特許問題があった」事を知っている。
ネット検索で“JPEG”と“特許”をキーワードにすれば、有名なJPEG特許問題1件が出てきます。

しかし実情は「1件どころではない」。

JPEGに関するサブマリン特許は何件もあり、セットメーカー(デジカメやプリンタ)が標的にされている。
彼らのやり口はこうだ。
まず特許を登録しておく。
しばらくは黙って標的を絞る。
標的が決まると個別にセットメーカーを訪問し「あんたのところの製品、うちの特許に抵触してるんですが、特許料払ってくれません?」と言い寄るのである。
単なる“言いがかり”の場合もあるし、“後々、特許無効”と判断される場合もある。
しかし「金で解決するなら・・・」と特許内容を吟味せずに示談に応じるメーカーも多い。
このようにして示談に応じたメーカーから数億(時には百億以上)の金が流れることになる。
このような特許料はデジカメやプリンタの代金に上乗せされて一般消費者がかぶっているのだ。(もちろん、企業努力によって企業がかぶっている場合もある)

報道にすっぱ抜かれて、無効判決を受けた JPEG 特許の例や、一般消費者をターゲットにしてしまった GIF の Unisys の例は、 “当たり屋”としては素人なのです。
裏道には玄人が行脚しているのです。

(ちょっと生なましい話になってしまいましたね。技術的な論点に戻しましょう。)

■(実は)一度圧縮してみないとファイルサイズ(圧縮率)がわからない
JPEG では量子化テーブルを決めた後に圧縮を開始し、1枚の画像圧縮が終わるまで同じ量子化テーブルが使われる。
途中で量子化テーブルを変える事はできない。

圧縮対象の画像データによって圧縮率は変化する。
たとえば高周波数成分を全く含まない真っ白な画面は極めて圧縮率が高くなる。

そのため、圧縮 JPEG ファイルのサイズを一定サイズにする事は難しい。

もしやろうとすると、
『一度圧縮しサイズを見る』⇒『量子化テーブルを変えて再圧縮』
なんて処理を2,3回繰り返して理想サイズに近づけるぐらいしか手がない。

■オーサリングに向いていない
最近はダイレクトプリンタなんていうデジタルカメラのメモリカードを直接(PC無しで)印刷できるものが出てきている。
これらのプリンタにはLSIが内蔵され、デコードしながら印刷をしているのである。
ソフト処理をしている場合もあるし、専用のハードを載せている場合もある。

ところで、JPEG ファイルは MCU という単位で左から右へとデータが収められている。
4:4:4 の場合には8ライン単位で、4:1:1 の場合は16ライン単位でデータが格納されているのだ。

プリンタで画像ファイルを印刷する場合、この並び通りに印刷できれば良いのだが、 縦方向の印刷並びが必要になる場合もある。
画像を90°回転させて印刷する場合があるのである。
プリンタの機種によってはクリッピングといって、画像の一部だけを切り取って印刷する事も可能だ。

印刷する JPEG 画像ファイルをいったんメモリにデコードしてしまえば印刷並びの問題など関係無いのだが、 300万画素の場合はデコードすると9メガバイト近くになってしまう。
普通、プリンタにはそんなに多くのメモリは載せない。(パソコンとはメモリ量の単位が違う)
プリンタでは、印刷ヘッドが動く時間よりも早くデコードが出来ていればよく、 そうなると「少ないメモリで頑張れ!」という理屈が通ってしまう。
少しでも原価を抑えることが企業努力とされる。

JPEG ファイル中で印刷しようとするMCUの位置は JPEG ファイルの先頭からシーケンシャルになぞっていくしかない。
JPEG ファイルにはリスターとマーカー ( RSTn ) が用いられる場合もあるが、サーチ処理がほんの少し楽になる程度である。
JPEG ファイル内をサーチする、すなわちオーサリングには向いていないのである。

■仕様にグレーゾーンが多い
エンドユーザー(一般消費者)にとってはほとんど関係無い事なのだが、開発者にとっては仕様の曖昧さ(グレーゾーン)は大きな問題だ。

JPEG は 1991 年という古い時代に研究者たちが集まって成立した規格であるため、 仕様がフレキシブルである反面、仕様が曖昧だ、という部分がある。
たとえば色空間が定義されていない、なんてのは最たるものである。
色空間については JFIF が「YCbCr を使う」と決めてそれがデファクトとなったが、 本来なら仕様で決めるべき内容である。
JFIF が手をつけなかった曖昧な部分に『マーカーが重複した場合どうするか』『必要なマーカーが含まれていない場合の処理はどうするか』 などがある。
componet_id なんてのは固定で決めてしまっても実用面でなんら不自由は無いし、マーカーの出現順番だって固定してしまっても大きな問題は無い。

開発者を悩ませる問題の1つに『マーカーの直前の0xFF』がある。
JPEG 規格ではマーカーの手前に複数個の 0xFF を置くことを許可している。
この 0xFF は単なるゴミ・バイトである。(データとしての意味は持たない)
マーカーセグメントとマーカーセグメントの間の不要な 0xFF であれば、無視するだけで済むのだが、 マーカーには RSTn (リスタート・マーカー) や EOI (エンド・オブ・イメージ)もある。
圧縮データ中の 0xFF は 0xFF 0x00 で置き換える事が仕様で決まっているため、ゴミの 0xFF は厄介な問題だ。
JPEG の仕様で「JPEG ファイル中に不要なゴミデータは認めない」と決めてしまえばスッキリするのであるが、 曖昧な仕様がそのまま残ってしまうと、開発者を悩ませる事になってしまう。

JFIF が作り出したグレーゾーンもある。
JPEG 規格では JPEG ファイルの最後に EOI の 0xFF 0xD9 が存在しないといけない事になっている。
JFIF では EOI が無い JPEG ファイルも許可している。
通信が発達していなかった昔は JPEG ファイルが途中で切れる場合もあった。
JPEG ファイルが途中で切れている場合、エラーとして全く表示しないのが良いのか、データがある分だけ表示した方が良いのか。
JFIF は「途中まででも表示した方が良い」と考えたのかもしれない。
このようにデファクトによって作られたグレーゾーンも存在する。

ちなみに ISO の規格は MPEG1 ⇒ MPEG2 ⇒・・・と時代を経るにしたがってグレーゾーンを減らす努力が行われているようだ。

(つづく)

| | コメント (0) | トラックバック (0)

(連載)第1回:色空間について

下記は“緑”“赤”“青”のグラデーションを階調を変えて並べたものである。
あなたはどの階調から境目が見えるだろうか?
Green
256階調
128階調
64階調
32階調
16階調
8階調
4階調
Red
256階調
128階調
64階調
32階調
16階調
8階調
4階調
Blue
256階調
128階調
64階調
32階調
16階調
8階調
4階調

おそらく、“緑”と“赤”は8階調で境目が判るだろう。
16階調でも境目が見えるのではないだろうか。
32階調で境目が気になるほど見える人は少ないのでは?(ちなみに私は見えない)
“青”に関しては、人間はもっと鈍感で、8階調でも気にならない程ではないだろうか。

3原色のうち“赤”や“緑”は人にとって重要な色であるに違いない。

これは私の推測だが
人がまだサルだった頃
サルは森の中で、ずっと緑の中のエサを見つめていたのだ。
あるいは緑の陰で待ち伏せする敵を警戒し続けていたのだ。
きっと必死こいて緑を見続けていたのだろう。
だから“緑”は感知しやすい色なのだ。

“赤”はどうだろう?
人の顔色を見るのには微妙な赤の違いは重要だ。
あるいは食料としての肉が新鮮か腐っているかを見分けるために赤が重要だったのかもしれない。
敵に襲われた時に傷口を見て怪我の程度を知るために赤が重要だったのかもしれない。

それに比べ“青”は人にとってそれほど重要な色ではないのだろう。


この画像をRGBに分解すると次のようになる。
R
G
B

「自然界においては、赤よりも緑の濃淡が輪郭に密接に関係している」 ということが、なんとなく判っていただけるのではないだろうか。

RGBの3原色に分解する事を『色空間』という。
『色空間』にはRGB以外にもCMYKやLab、YUVなどがある。
ここでは(JPEGにつなげる都合上)YCbCrを紹介する。
Y
Cb
Cr

“Y”は輝度(Luminance)であり、明暗そのものである。
カラー画像をモノクロにしたもの、と思ってもらって良い。
“Cb”“Cr”は色差(Chrominance)であり、それぞれ“緑⇒青”成分、“緑⇒赤”成分である。

RGBと同様にYCbCrのグラデーションを作ってみた。
Luminance
256階調
128階調
64階調
32階調
16階調
8階調
4階調
Chrominance (Green-Blue)
256階調
128階調
64階調
32階調
16階調
8階調
4階調
Chrominance (Green-Red)
256階調
128階調
64階調
32階調
16階調
8階調
4階調

輝度(明暗)は人にとって重要なようだ。
輝度の32階調は境目が見える人もいるのではないだろうか。
(RGBのグラデーションよりはハッキリわかるはずだ。)

輝度に比べ、色差はその重要度が劣る。
それも「かなり」

「重要度が低いならデータ量を端折(はしょ)ったっていいじゃないか」
これが JPEG や MPEG での画像圧縮の考え方につながる。

(つづく)

| | コメント (0) | トラックバック (0)

(連載予告)画像フォーマットについて


実は So-net で自ホームページを放置している間も、
書き足したいコンテンツはあったのです。
この際ですから、少しずつ書いていきたいと思います。

(連載予告)
第1回:色空間について
第2回:JPEG について
第3回:JPEG2000 について
第4回:GIF について
第5回:PNG について

| | コメント (2) | トラックバック (0)

10月17日の日記

会社を早めに上がって東急ハンズを目指しました。
(とは言っても、帰宅途中で寄り道するだけですが)
東急ハンズ(新宿タイムズスクエア)(ブレてる)

着いたのは8時過ぎ。

この時間ならやってるはず。。。
(後で調べましたが、営業時間は8時30分まででした。)

普段から買い物に時間を掛けるのは苦手なので、閉店まで15分もあれば十分。

東急ハンズ(新宿タイムズスクエア) 店の近くまで来ると、、、

変です。
人通りが少ない。。。
平日のこの時間はこんなものなのでしょうか?

近づくと、警備員が入り口の前で、赤く光る棒を振ってます。

さらに近づくと、入り口のシャッターが下りているようです。


(帰宅後、web で調べると、今日から3日間、改装工事でお休みでした。orz)
東急ハンズ新宿店
営業時間 10:00~20:30
10月17日(火)・18日(水)・19日(木)は
改装工事のため休業させていただきます。
10月20日(金)リニューアルオープン!

写真が斜めになっているのは、立ち直れなかったからです。 (ウソです。)

NTT docomo代々木ビル(8:30pm)
さて、8時半。

「ついでだから紀伊国屋(本屋さん)寄ってくか。」

紀伊国屋書店 新宿南店
営業時間
平日、日曜日/10:00~20:00
土曜日/10:00~20:30

シャッターが下りてました。
ガラス越しの店内で、店員が一日最後の作業(店内整理)をするのをこの目で確認し、 大人しく帰ってきましたとさ。


帰宅後
「今日は早く帰ったからココログUPしとくかな」

ココログフリーメンテナンス実施のお知らせ:
2006年10月17日(火)16:00-2006年10月19日(木)16:00

ログインする事すら許されませんでした。

| | コメント (0) | トラックバック (0)

夕日

荒川の夕日 近所の川原に行ってきました。

日が暮れるのが早くなっちゃって、まぁ。
(秋の日は釣瓶落とし)

| | コメント (0) | トラックバック (0)

So-netから来ました。

So-net にホームページを持っていたのですが、
「U-Page Proサービス終了のお知らせ」 という連絡があり、
この際なので、ホームページを終了し、ブログを始める事にしました。

よろしく。


So-net に残してきた「サイト閉鎖のお知らせ」
閉鎖に至る思いなど

8月末にSo-netから「U-Page Proサービス終了のお知らせ」が DM(ダイレクトメール) で来ました。
その時は「終了してもいっかなぁ」と思いつつ、たまたま8月9月は忙しく、 後回しにしていて、気が付いたら1ヶ月半が経っていました。

今日になって、旧ページのファイル・タイムスタンプを見てましたら、
ホームページを開設したのが1998年で、それから2年ぐらいはせっせと更新していたみたいです。(←まるで他人)

ホームページ立ち上げ当時は「HTMLでこんな事ができるのか」と新しい知識を得るのが楽しく、 ホームページに貼るgifファイルを自分で作るわ、cgi を作るわ、さらには JavaApplet にまで手を出す始末。

その後「どうやったら人が見に来るのか」という事に興味が移り、いろんなコンテンツを作っては発表してました。
“アクセスが一時的に集中してアクセスカウンタが吹っ飛んだ”なんていう過去は、今となっては楽しい思い出です。

“HTMLの書き方”については
CSS(Cascading Style Sheet) が出てきて、その書き方がなんとなく分かったところで

飽きちゃったんですね。

その後、出てきた flush や xhtml なんかには興味を示す事無く、飽きちゃったんですね。

“アクセスアップ”については
「こういうコンテンツに人は興味を持つんだ」という自分なりの結論が出たところで

飽きちゃったんですね。


こうしてホームページの立ち上げから飽きるまで、たったの2年!

我ながら飽きるのが早い!


その後は仕事が忙しくなった事(という口実も)あり、 ずっと放置していました。


そして時は流れ、、、
途中 So-net から「U-page サービスを終了し U-page+ を開始します」(← U-Page Pro じゃ無い方ね) とアナウンスがあった時も、放置したまま。
それまでは U-page Pro と U-page に2箇所ホームページを持っていたのですが、
U-page サービス終了と共に、U-page 側のコンテンツは消えちゃいました。
そうそう、PNG という画像フォーマット仕様の日本語訳が消えたのは、この時でしたね。
いや、もう遠い過去の事ですが。。。


そうこうしている間に「U-Page Pro サービス終了のお知らせ」です。

自分としては
「終了する丁度良いタイミングじゃないの」
という思いに至ったわけです。

そんな訳で、旧ページのコンテンツは 2006/11/30 のサービス終了と共に消えます。


機会があれば、別の場所でお会いいたしましょう。

では。

[管理人]

| | コメント (1) | トラックバック (3)

DHTML てすと2

<script type="text/javascript">
<!--
function show(idstr) {
obj = document.getElementById( idstr );
obj.style.display = "";
obj.style.visibility = "visible";
}
function hide(idstr) {
obj = document.getElementById( idstr );
obj.style.display = "none";
obj.style.visibility = "hidden";
}
//-->
</script>
<span ID="id001" style="visibility:visible;">
<button style="color:black;text-decoration:none;"
onclick="show('id002');hide('id001');">click!(open)
</button>
</span>
<span ID="id002" style="visibility:hidden;display:none;">
<button style="color:black;text-decoration:none;"
onclick="hide('id002');show('id001');">click!(close)
</button><br>
a<br>
b<br>
c<br>
d
</pre>
</span><br>

| | コメント (0) | トラックバック (0)

DHTMLのテスト

<span onmouseover="this.style.cursor='hand'" title="onmouseover カーソルテスト">DHTMLのテストです。</span>
DHTMLのテストです。

| | コメント (0) | トラックバック (0)

CSS テスト


<span style="font: italic bold arial; color: navy; background-color: silver">ABCD</span>
ABCD

<br>
<span style="border: 5pt double maroon; padding: 1 5 10 20">Border</span>
<br>

Border


<span style="margin-left: 20px">Margin</span>
Margin

<span style="width:100%; filter: dropshadow( color=silver, offx=2, offy=2, positive=true )">DropShadow</span>
DropShadow

<span style="width:100%; filter: glow( color=silver, strength=3 )">Glow</span>
Glow

<span style="width:100%; filter: blur( strength=5, direction=45 )">Blur</span>
Blur

<span style="width:100%; filter: alpha( opacity=100, finishopacity=30, style=2 )">Alpha</span>
Alpha

<span style="width:100%; filter: wave( freq=2, strength=2 )">Wave</span>
Wave

<span style="width:100%; filter: flipv() fliph()">FlipV FlipH</span>
FlipV FlipH

<span style="width:100%; filter: flipv()">FlipV</span>
FlipV

<span style="width:100%; filter: fliph()">FlipH</span>
FlipH

| | コメント (0) | トラックバック (0)

HTML Tag テスト2


<table border=1>
<tr><th>A</th><th>B</th></tr>
<tr><td>あ</td><td> </td></tr>
<tr><td colspan="2">い</td></tr>
</table>
AB
 


<s>strike</s>
<u>underline</u>
strike
underline

<font color="red">赤</font>


<sup>sup</sup><sub>sub</sub>
supsub

<ruby><rb>るび</rb><rp>(</rp><rt>ruby</rt><rp>)</rp></ruby>
るび(ruby)

<a href="http://www.htb.co.jp/suidou" alt="水曜どうでしょう">リンク</a>
リンク
<form>
<fieldset>
<legend>aaa</legend>

<fieldset>
<legend>bbb</legend>
<ul>
<li>c
<li>d
<li>e
</ul>
</fieldset>

<fieldset>
<legend>ccc</legend>
<ul>
<li>f
<li>g
</ul>
</fieldset>

</fieldset>
</form>
aaa
bbb
  • c
  • d
  • e
ccc
  • f
  • g

| | コメント (0) | トラックバック (0)

HTML Tag テスト1


<hr>



<h1>h1<h1>

h1



<h2>h2<h2>

h2



<h3>h3<h3>

h3



→<!-- This is comment -->←


| | コメント (1) | トラックバック (0)

トップページ | 2006年11月 »