こんばんは、川合です。
I.Tak. さんは 2003/12/15 20:19:55 の「[osask 6783] Re: Jenny2」
で書きました：
>(減色結果を元に戻す話)
>> i8モデルの場合は、多分下位ビットに0を追加するだけです。だって
>> 最近値への丸めは、もう済んでいるはずですから。ここで変に0x58なん
>> てしようものなら、これを16階調に戻したときに6になりかねません。
>
> それは誤解です。それでは傾きが保存されません。
> y = x * 3 / 255 というのが変換の式で, 逆変換は x = y * 255 / 3
>です。すなわち85倍にします。なんで64倍にするんですか?
すみません、そのとおりです。僕は四捨五入と切り捨ての違いだけし
か考えていませんでした。ただ、この例の場合、
x = y * 255 / 15 = 17 * y
だと思います。だから、5は0x55になるわけですね。変なことを書いてすみ
ませんでした。
>> それはタイルを色の混合のための手段と見ているときは正しいのです
>> 。でも僕のように、混合の手段ではなく、混合された色域をフルに使っ
>> て色を割り振り直すという観点に立てば変わるわけです。
>
> でも高速モードと高品質モードを混ぜたら (画像の一部を高速モード、
>一部を高品質モードで出力したら) 矛盾が生じるわけですよ? それって
>「高速」以上の大きな違いじゃありませんか。
いや、そう思う気持ちは分からないでもないですが、僕の目にはさっ
ぱりその「矛盾」が実感できません（つまり、僕はtest043のaとbを並
べてみても、あれ矛盾だよ、とはどうも感じないわけです）。僕にも見
て分かるようなうまい例を作れませんかねえ。i8だとこうなのに、n8だ
とこんなに変だ！みたいなやつを。
> 減色結果から飽和を示さないと納得できないということでしたら,
>図示しないと難しいので↓のページを見てください。
>http://user.ecc.u-tokyo.ac.jp/~g240845/osask/n8.html
なるほど、そういうことでありましたか。これならなんであれを飽和
といいたかったのかがよく分かります。そういう観点では確かに飽和し
ています。でも、僕の「等間隔に区分する」という観点では飽和しては
いません。
しかしこういう考え方の違いは面白いです。この図を見ると、I.Tak.
さんが等高線を無視する傾向があるのが実によく分かります。混ざると
仮定すれば、等高線なんて関係ないですからね。
僕は、正方形の半分を白で半分を黒で塗り分けると、いつも境界付近
がより白く、より黒くみえるように錯覚してしまいます（実際はそんな
ことはないのに）。僕の場合混ざるのが実感できるのは、小さな周期で
交互にドットが来る場合であって（これがまさにディスプレイのRGB状
態だと思います）、タイリングなしグラデーションなどでは混じりを感
じられませんでした。
・・・と、ようするに僕が言いたいのは、混じりを感じるかどうかは
個人差があって、容易に共通の見解が得られるわけではないだろう、と
いうことです。混じりを感じないという前提に立てば、n系も一つの考
え方でしょう。
つまり、どっちが客観的に見てよりよいと言えるということにはなら
ない、と思います。
むしろ、高速モードは多少色が狂っても（僕はn系が狂っているとは
思っていませんが）、簡単なアルゴリズムであるべきです。イメージの
忠実さよりも、まずは高速に描画することを求められているからです。
基本的にビットシフトだけで済むようなn系のアルゴリズムは、3/255や
31/255という複雑な定数を乗じなければいけないものよりも、一般的に
見て有利だと思われます。
しかし、タイリングモードでは、高速性はそれほど関係ないので、
i系を使うべきだというのも、一理あるとは思います。
> それは誤解です。深読みしすぎですよ。
> あえてオリジナルと減色結果と言うなら、0 1 2 3 がオリジナルで、
>0 0 3 3 が減色結果です (でも区別する必要はありません)。「a と b が
>あって、c に近いのは a である」と言いたいのではなく、「a と b は近い」
>と言いたいのです。そういう文ですよね?
> 等高線の間隔ではなく, 傾きこそ本質であるとずっと言っていたのです。
なんと、オリジナルは0123なのか・・・。
いや、僕は「a と b は近い」と言われても、分からないので質問し
たのです。aとbは、cとdよりも近い、というのは分かります。単にaとb
は近いと言われても、それは主観的な判断でしかないので、僕には賛成
も反対もできません。僕でも分かるように、何と比べて近いと言ってい
るのかを教えてもらえないでしょうか。
> リニアにこだわったのは、「正しい減色は線型」という共通の理解が
>あると思ったからです。しかしそうではなかったんですね。
>
> なお極めて私見ですが、あの文から「"リニア"≠線型」という意図を
>汲み取るのは困難です。エスパーかニュータイプでなければ無理でしょう。
そうか・・・。いや、他の人が何といおうと、あれはI.Tak.さんに伝
えるために僕が書いた文章なので、そのI.Tak.さんが誤解したのなら、
それは僕のせいです。すみません。
というかI.Tak.さんは僕の意図を誤解することがままあるので（古く
はSJISとEUCを比べてSJISが好きなんじゃないかとか、最近ではcmd004
の挙動とか）、どんどんと思い込んで先に進まないで、確認しつつ前進
してください。しつこく聞いていいです。僕はめんどくさがらずに、答
えますから。
>> >「減色は選択した色群(パレット)を使用して各ピクセルの元の値からの誤差
>> >を小さくする変換である」という定義について、川合さんは納得して
>> >いただけますか?
>>
>> この定義は、僕の理解とはあいません。本当にこんな定義なのでしょ
>> うか。
>
> 川合さんの定義をぜひとも教えていただきたく思います。
使用する色数さえ減れば、どんな画像に対するエフェクトでも「減色
」というんだと思っていました（非リニアだったりしても、です）。こ
れは定義というほどのものじゃないですよ。他の人が、違う意味合いで
使っていたら、ああ本当はそういう意味だったのかと、思い直してもい
いと思うくらいです。
だから、これは減色じゃない、だからこの文脈では減色という言葉を
使うべきではないのだ、と言われれば、素直にそうします。
でも、定義だと言われると、それは本当なのか？！と聞いてみたくな
ります。
>> もちろんこのような減色もありますが、たとえば自由なパレットを30
>> 個与えて、そのパレットのRGB値を決めつつ、処理をする場合もあるよ
>> うに思います。そのような処理は、この定義の外になってしまいます。
>
> それは誤解でしょう。
> この定義は、*誰が*選択した色群かを明示していません。人間が決めた
>色群もプログラムが勝手に決めた色群も含むんじゃないんですか。
> 私が今まで見た減色ツールはパレットを決めてから上記のようなアルゴ
>リズム (まさかそのまま実装してはいないと思いますが) で減色している
>ようでした。
つまり、I.Tak.さんの解釈によると、（プログラムが）色群を選択す
る行為は、減色とはまた別の行為であって、別の処理の名前が付いてい
る事言うことですね。なるほど。そうなのか。・・・そう言われるとそ
うかもしれないです。
そういうことなら、ある人が、「僕の減色アルゴリズムはすごいよ、
最初のパレット選択アルゴリズムが頭いいんだ」みたいな会話は、厳密
な意味ではおかしいということですね。・・・本当？まだ僕は不安なの
で、この辺を断言してください。お願いします。
>> また元の絵からの誤差を小さくする変換とした場合、何をもって誤差
>> とするのでしょうか。RGB値ですか？それとも明度や色相？それともま
>> た別の指標？
>
> 誤差は 入力値→出力値ベクトル として表すのが一般的でしょう
>(今のOSASKに入れてある誤差拡散ルーチンはそのようになっています)。
>なおRGB空間とYCbCr空間やYUV空間は行列計算と定数の加減算によって
>変換可能です。誤差がどれかの空間で小さくなればほかの空間でも小さく
>なるはずです。
理屈の上ではそうですが、そうすると、16btカラーからの減色で、グ
レイスケールが色ずれを起こすほうが、正しいということになります。
もちろん、それが正しいのかもしれません。しかし、僕はそんなルーチ
ンはほしくないのです。だから、他の人がそういう誤差の観点から正確
なルーチンを改造OSASKに積んで使うのはもちろん結構ですが、僕は自
分の推奨する本家OSASKには入れたくはありません。
>> 僕は僕なりに元の絵に近づけようとしています。それを減色でないと
>> 言い切るには、もうちょっと説明がほしいです。
>
> 川合さんがどんな基準でもって「元の絵に近くなった」と判断するのか
>私には分かりませんので、教えてください。「元の絵に近い印象を与える」
>と言われますが、それはどのように数値化されるのでしょうか。例えば
>ある写真のオリジナルと減色後Aと減色後Bを比較して、AとBとどちらが
>どの程度良いかをどう評価しますか。
> まさか「人間が見て判断する (私がルールブックだ!)」とは言いません
>よね。
そのまさかですよ。主観でしか決められないというのが僕の見解です
ので、とりあえずOSASKにどれを使うかは僕の主観こそすべてでありま
す。いくつか絵を変換してみて（というかたいていはグラデーションパ
ターンでありますが）、どちらが好ましいのかを判断しています。
僕は最初から、「見比べた」と書いてきたのに・・・。
もちろん僕だって、可能なら数値的に判断したいですよ。しかし、そ
れだと僕にとっては不満の残る結果になるようだったのです。だから、
数値的な指標を作るのをあきらめて、実際に変換結果を作り、見比べて
うなるわけです。
僕が理論的な話を嫌がって、まっさきにBMPファイルを作ってこれを
見てください、と言ったのはそういうことです。だって、僕はそれを見
て決めているんですから。だから、i系を採用させるためには、僕のア
ルゴリズムでは僕の感性から見ても汚くなるような変換例を発見すれば
いいのです。もしくは、僕でも納得するような、客観的と言える指標を
見つけて、その点でi系のよさを訴えてもいいです。
これは何も減色（色の再配置？）ルーチンだけではありませんよ。全
部のOSASKのコードに言えることです。僕は僕のためにOSASKを作ってい
ます。だから僕が納得しなければ、大多数が賛成でも、僕は採用しませ
ん。その代わりに、亜種をいくら作ってもよい、としているのです。
>> 僕は「減色」という言葉は、アルゴリズムを規定しないと思っていま
>> した。例えば、グレイスケールにするのも減色の一種だと思っていまし
>> た。グレイスケールではRGB値的に一番近い色を選ぶのではなく、明度
>> が近い色を選んでいます。
>
> 私も、アルゴリズムが規定されるとは思いません。そもそも上の"定義"
>にアルゴリズムが規定されているようには思えません。定義されているの
>は減色ルーチンの評価基準であるように思います。
そうなのかなあ。僕はアルゴリズムを間接的に規定していると思いま
す。仮に評価基準だとしても、それでこれはよい、これは悪いと言える
わけですよね。そうだとすると、明度だけで選ぶグレイスケール化は、
作者にとっては非常に満足するものであっても、本当は違うやつが「よ
い」のかも知れません（だとしたら、グレイスケール化は減色とは別の
ことなのかな）。もしかしたら、明度が一番近い色を選ぶこととRGB値
的に一番近い色を選ぶことは、常に結果が一致しているのかもしれませ
んが（その場合、この例は例としてはよろしくないことになる）。
> 少ない言葉で楽に正確に表現するために, 専門用語が定義されています。
そのとおりですが、じゃあ、僕は語彙が少ないので、僕の話す専門用
語はあいまいに使っていることのほうが多いと想定してください。もし
くは、僕は全ての専門用語に、〜のようなもの、という記述を加えまし
ょうか？
つまり、僕が何度も言い換えをするのは効果がなくて、僕が最初に一
度言った言葉の意味にこだわり続け、その後の訂正は基本的に無視する
ということなのですね。とても残念です。
減色、といわずに、色を減らす画像変換、と書けばいいのでしょう。
それとも画像変換のようなもの？
ただ僕は、全部に「ようなもの」を付けたかどうか確認しなければい
けないので、発言量は現在の数割に落ちます。というか、この問題がそ
れほど重大ならレスするのをやめるべきなのかもしれません。コミュニ
ケーションコストが大きすぎます。
僕は相手を誤解することはあまりないですが（しつこく確認するのを
嫌がられることはありますが）、僕を誤解する人は多いようです。僕は
聞きますが、答えを期待しないほうがいいかもしれません。
>> > 私と、I.Takさんは「減色」のアルゴリズムについて話していたのですが、
>> >川合さんは n式色調変換アルゴリズムについて話しているので話が
>> >かみ合わないわけです。
>>
>> そうなんですか？＞I.Tak.さん
>
> 何をもって「良い」減色とみなすかが完全に食い違っているように
>思います (もしかしたら川合さんは減色しようとさえしていないのかも
>知れませんが)。だから川合さんの基準をぜひ教えてください。
僕の基準についてはもう書いたのでいいと思います。
僕が聞きたいのは、僕がn系の減色（色を減らす画像変換のようなも
の）だけを話していて、i系や減色一般の話をしていなかったという認
識が、I.Tak.さんの見解なのかどうかです。そしてI.Tak.さんは小柳さ
んが定義するところの「減色」について論じていたのでしょうか。僕に
は、僕が提唱した「誤差は重要じゃない、パレット値にこだわるな」と
いう話に理解を示して、その話をしてくれているんだと思っていました
。
> 「リニア性が高いほうが高品質」まったくその通りでしょう。「ビデオ
>カードのA/Dコンバータは線形に反応している」と仮定すると、線形な減色
>こそ自然です。基本的な物理には線型がたくさん出てきますし、類推して
>線型を仮定するのは一般的なことです。
もちろん、基本式がリニアであることは、・・・っていうかリニアと
かいう専門用語は避けよう、丸め前の基本式が「f(x) = a * x」である
ところまでは全く同感です。しかし、ここでいう「線形に反応している
」の線形は、それ以上の意味を含む小柳さんの言う線形量子化を指して
いるのでしょう。その点については賛成できません。
仮にI.Tak.さんの想定している通りだったとしても、i系の減色結果
は僕にはきれいにみえないことに代わりはないので、また、高速モード
では速度的に不利になりやすいという傾向にも違いはないので、僕が採
用しないという点では変わりないと思われます。ただ、I.Tak.さんの論
理的な妥当性は裏付けられる、というだけです。
しかしそれが品質といえるのかどうかは、というか、n系とi系の差違
を主観を超えて比較しうると考えるところについては、やはり同意しま
せんが（客観的比較のためには基準が必要だが、その基準のどれを選ぶ
かが相変わらず主観的、という意味）。
それとも、「品質」も画像処理における専門用語で、僕の知らない定
義があるのかなあ？
僕は論理のために自分の感性を捨てることはしません。自分の感性と
常に一致する理論があれば、その理論を感性の代わりにすることはあり
ますが。だから、理論的におかしくても、それはなんら問題ではありま
せん。「僕にとっては」おかしいのは僕ではなく、理論なのですから。
「goto文を使うことは構造化プログラミングの害だから、使うべきで
はない」という理論を守るあまり、ソースやバイナリがでかくなるのに
甘んじているケースが良くありますが、僕がこの理論を「コンパクトで
高速なバイナリを得ること」という目的のために無視するｋとがあるの
と同じ事です。
つまり過剰なまでにリニア性にこだわるのは、「僕にとっては」理論
のために、自分の気に入らない変換結果に甘んじなければいけない、と
いうことなのです。
>> それで確認ですが、整数論でリニアという語があるんでしょうか。つ
>> まりi8は整数から整数への変換であって、しかも丸めを伴っています。
>> そういうときにリニアという言葉を普通に使っていて、それは線形量子
>> 化を意味するのでしょうか。後学のために、教えてください。
>
> 私は知りません。i8がn8より線型であることを定義から導けるはずだと
>考えて苦労しました。ところが川合さんは整数関数の線型性を重視して
>いないのでしたとさ。あちゃー。
お手数をおかけして、すみませんでした。このような不幸を防ぐため
にも、確認をおねがいします。僕も専門用語は使わないようにします。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/