[osask 6708] FORM: Re: Jenny2.

このメールは、OSASK-ML投稿フォームから書き込まれた内容です。


お名前: I.Tak.

[osask 6706]に返信です。

>  次に、itak8を見てみます。itak8では、与えられた4階調が、00、55
>、aa、ffであるというところから発想がスタートです。まず、

 それは誤解です (むしろドキュメントを読んでない)。
 入力が最大値255、出力が最大値3、どちらも同じ範囲をカバー
しているので、
    r * 3 / 255
を計算しようという仕組みです。後は四捨五入です。まじめにやる
と遅くなるので近似計算をしているだけです。高速な近似がそれぞ
れの場合に応じて特殊化するのは仕方がありません (16bpp用はう
まい近似が思いつかないので手付かずです)。

>  僕はこのアルゴリズムは数学的に美しいと思いますが、嫌いです。と
>いうのは、4階調が00、55、aa、ffに割り当てられているということに
>強く依存しているからです。もし僕が、00、40、80、c0に割り振ったら
>どうだったでしょうか?3f、7f、bf、ffに割り振ったらどうだったでし
>ょうか?

 上記のようなわけで、川合さんの言うほどそのパレットに強く
依存しているわけではないのです。発想は。
 質問に対する回答です。前者を例にしますと、0xc0以下と以上で
分けて、"以上"の範囲を潰してしまうしかありません。"以下"の
範囲は従来どおりに処理します (0x00のパレットが最小で0xc0の
パレットが最大であるとき、0xffをタイリングで表現することは
不可能です)。
 そもそも、パレットから0x00, 0xffをはずすわけにはいかない
と思います。タイリングは一次補間みたいなものですから。

>  k4では00とffしか使えないものとして8色のみを使って減色していま
>すが、itak4では、緑や黄色や赤に限れば、84という階調が利用できる
>という所に目を付けて、階調を増やしています。この努力を僕は大変高
>く買っていますが、しかし好きにはなれません。こういう特殊な事情を
>前提にしたものはよろしくないと思うのです。

 ところがどっこい、それほど特殊なわけではありません。
 まず、RGB空間を、
    (r,g,b)=(0,0,0), (0x80,0,0), (0,0x80,0), (0,0,0x80),
            (0x80,0x80,0), (0x80,0,0x80), (0,0x80,0x80),
            (0x80,0x80,0x80)
に囲まれた内側空間と、
    (r,g,b)=(0,0,0), (0xff,0,0), (0,0xff,0), (0,0,0xff),
            (0xff,0xff,0), (0x80,0,0xff), (0,0xff,0xff),
            (0xff,0xff,0xff)
に囲まれた外側空間に分けます。するとそれぞれの空間に対称性が
あり、処理が単純になります。その処理はn4相当のもので十分でし
ょう。特殊なのは外側と内側に分けるところだけです (とは言え、
色合いがずれるのはタイリング処理の都合で内側と外側の分離が不
完全だったからです、多分。変えてみるか……)

>しかし、n8では「00のみ」や「ffのみ」が出てくるチャンスがitak8よ
>りも多い(約2倍)あるのです。つまり、黒はより黒く、白はより白く
>ということになるでしょう。僕はそういうほうがメリハリがあって好き
>です(n8にメリハリがあるというよりも、n8は普通で、itak8がメリハ
>リを損なっている、と考えていますが)。

 RGBを空間と捉えると約8倍の容積……というのはともかく。
 i*は入力に対して忠実だが、n*はコントラストが強くなってい
る、というのが私の見解です。入力をx軸、出力をy軸にしてプロッ
トすると分かると思いますが、i*の方が全体的に誤差が小さくなり
ます。
 どっちが普通か? という問題については、汎用の減色ツールに
パレットを与えて減色してみれば分かることですので。やってみま
すか。

>  次に、k4、itak4、n4の比較です。まず、k4は暗いです。そしてn4は
>元の絵よりも明るくなってしまったように見えます。そしてitak4はさ
>らに明るくなった上に、空の色のカラーバランスが何か変です(比較の
>ためにn8も併せてみるともっと分かりやすいと思います)。

 カラーバランスは、前述のように、外側と内側の分離が不完全
だからですね。
 で、"さらに明るくな"るのは、たまたま苦手な色だったからだろ
う、としか言いようがありません(--; どっちのパターンを出力す
るか微妙な色だが、明るい方に近いから明るくした、ということで
す。こういうことはどんな減色ルーチンでもあることです。n4にも
そういう弱点色はあります (誤差が最大になる色は0x33とか0xccと
かです) 。もしかしたら、裾野の緑色がそうなのかもしれません。

 裾野を見るか空を見るかという好みの問題は好みの分かれるとこ
ろですので (?)、コメントは控えます。


 私は、実装がどうであれ精度の良い出力が高速に出れば良いと
考えています。プログラムに美しさを求めるのはかなりいいこと
ですが、そのためにハードなり環境なりの特性を活かしきらない(パレットを8個しか使わないとか) のは、「そりゃエゴだよ!」と思うのです。




ML番号でジャンプ
ML単語検索