[osask 6778] Re: Jenny2

  こんにちは、川合です。


KOYANAGI, Masaaki さんは 2003/12/14 15:50:59 の「[osask 6777] Re
: Jenny2」で書きました:

(入力が)
>なぜ [0, 256) なのですか?

  ええと、それは僕がアナログ入力を[0, 1)と考えているからです。僕
の理解(というか想定)では、256階調というのは、このアナログ入力
を2進数で表わして、その上位8bitを持ってきたものです。たとえば、
0.8456なら、0.11011000011...ですから、11011000(0xd8)というわけ
です。

  これは結局、256倍して切り捨てているだけ、ともいえます。

>255 *より上* の輝度は物理的に出せません。出せる輝度の上限はデジタル値
>255 です。つまり [0, 255] です。

  もちろん、255より明るい色は出ません。しかし、それをいうなら
250.2という色も出せません。実数で連続的な数値を有限個数の整数値
に変換するとしたら、出せない色を近い色で代用するというのは、当然
であろうと僕は考えています。だから、たとえば255.1を255という整数
値に置き換えるのはさしあたり問題がないと僕は考えます。

  たとえばここに、256通りの光の強さを識別できるようなリニアなセ
ンサーがあったとします。そして最大値の255を返す輝度を1825.564[cd
]としましょう(ここでカンデラという単位で適当なのかどうかは、僕
には分かりませんが・・・すみません)。

  このとき、小柳さんやI.Tak.さんなら、

    このセンサーは入力[0, 1825.564]に対して出力[0, 255]だ。

とするでしょう。

  僕はその表記でも構いませんが、プログラミングを考える場合には、

    1825.564 / 255 * 256 = 1832.723  という計算をして、

    このセンサーは入力[0, 1832.723)に対して、出力[0, 256)だ。

とします。

  小柳さんやI.Tak.さんにはこれを気持ち悪いと思うんじゃないでしょ
うか。1830なんていう入力をしたら飽和してしまうのに、そんなのを入
力値に含めてもいいのか、と思うような気がします。

  僕はいいと思います。この僕のモデルでは、[0, 1832.723)の範囲の任
意の強度の光をランダムに選択して入れるとすると、0〜255の数字が出る
確率は、いずれも等しくなります。そして僕はこれをあえて、[0, 256)と
表記します。だって、1832.723に対応する数字は、256ですからね。

  (ただしこの装置が、1832という入力で飽和するだけでは済まず、壊れ
てしまうというならまた話は別です。しかし一般的に言って、変換可能最
大値よりも0.4%程度の入力で壊れるような装置はまずありません。)

  僕がこのモデルが好きなのは、こういう仮定をしても、何も損なわない
からです(同じ装置で装置側の設定を全くいじっていないことに注意)。
純粋に解釈の問題です。また、4階調でも16階調でも256階調でも、結局違
いは、[0, 1)の区間を2進数で表わして、上位何ビットを持ってきたのか
、の違いでしかない、と考えられるのは、ソフトウェア的には有利になり
ます。階調を落とすときに、四捨五入しないでいいからです(もちろん、
i8のように四捨五入のための下駄加算と他の用途のための加算を統合して
、事実上全くの追加コスト無しに計算することが可能な場合もありますが
)。

  ソフトが楽か面倒かということのほかにも、「変域全体のランダムな数
値に対して、0〜255のどの数値も当確率で分布する」という性質を、僕が
非常に好ましく感じているという面もあります。

>(1) 
>>入力を[0, 256)
>という川合さんの上限値が開いているという前提が間違っていることについて
>異論はありますか?

  異論があります(上記の通りです)。

>(2) 「コンピュータは[0,1]という閉区間の連続値(輝度)を表すために
> 0 から 255 までの 256個の整数値を使用します。その変換(A/D変換)に
>線形量子化(I系アルゴリズム)が使われている」という点に異論はありますか?

  異論があります。実際のA/D変換回路が、そのようなことをやってい
るとは僕は思っていません。数学のモデルとしては、小柳さんの説明で
いいでしょう。・・・いやもしかしたら、実際のA/D変換回路も、0に変
換される確率が、1〜254に変換される確率の半分になっているのかもし
れません。僕はそういう風に設計している回路を見たら、愚かなことだ
と思うでしょう。僕が回路設計するとしたら、そんなことはしませんね
。

  四捨五入するという考えは、もともと誤差をどう扱うか、という考え
に由来しています。1.23という値は、1という整数値と、0.23の誤差だ
と考えて、それで最近値1を選ぼう、という話になっているわけです。
僕のセンサーに対する考えは違います。

    [0, 1)という範囲に、ゾーンナンバー0
    [1, 2)という範囲に、ゾーンナンバー1
    [2, 3)という範囲に、ゾーンナンバー2

という風に考えるのです。だから、1.23という実数は、整数値と誤差に
分離するのではなく、どの範囲に属しているかということを考えます。
そしてつねに、ゾーンナンバーであることを忘れません。僕は、A/D変
換の本質は、実数の小数部分を「誤差として」丸めることではなく、ど
のゾーンに属しているかの番号に変換する行為だと思っているのです。
だから、どのゾーンへ変換される確率も同じになるべきだと考えている
のです。

  例えば、16階調カラーを256階調カラーに変換するとします(減色の
反対)。例えば、16階調における5というゾーンナンバーは、5/16とい
う数値ではなく[5/16, 6/16)を表わしているわけですから、256階調に
直す場合、もし誤差を最小にしようと思うなら、変換値は0x50ではなく
0x57か0x58にするでしょう(実際の実装では手抜きというか、高速化の
ために0x50のままにすることもありえますが)。

  i8モデルの場合は、多分下位ビットに0を追加するだけです。だって
最近値への丸めは、もう済んでいるはずですから。ここで変に0x58なん
てしようものなら、これを16階調に戻したときに6になりかねません。

  このどちらを好ましいと思うかですね。これも好みの問題だろうと思
いますが。

>(3) [0,1] までの一様乱数を発生させて (2)の変換を行うと、0 と 255 の整数
>値に置き換わる確率は 1から254までの整数値に置き換わる確率の 1/2 になる
>という点に異論はありますか?

  これは異論なしです。そのアルゴリズムで実装すれば、1/2になるは
ずです。だから僕は、I.Tak.さんの実装がミスだとか、そんな風に思
ったことはありません。

>(4)*川合さんが*[0,1]という閉区間の連続値を 0 から 3 までの 4個の
>整数値に変換するとします。川合さんが使うのは n系 アルゴリズムですか?
>それとも i系アルゴリズムですか?

  もし、その1という数値が、輝度のように物理的に上限がないもので
あれば、そしてその0が、やはり輝度のように物理的に負にならないこ
とが保証されているなら、上記のように[0, 1.3333)に範囲拡張した後
で、n系アルゴリズムをつかうでしょう(刻みは0.333になります)。

  もし1より大きい入力に対して機械が壊れてしまうなら、光学的に輝
度を75%にするフィルターを掛けて、[0, 1)としてn系アルゴリズムを
利用します。・・・もしくは、1.0000という値が来る確率は事実上0%
であるとみなし(つまりこれを飽和値として扱っても問題はないとし
て)、[0, 1)と解釈し、刻み0.25で扱います。どちらにしても、n系で
あることには変わりありません。

  電流値や速度のように、負にもなりうる値を扱うときは、僕でもi系
を選ぶことがあると思います。

>(5)[0,1]という閉区間の連続値 を  0から 255までの256個の整数値に
>A/D変換したデータがあります。これを*川合さんが* 0から3までの4個の
>整数値で変換するとします。川合さんが使うのは n系 アルゴリズムですか?
>それとも i系アルゴリズムですか?

  このA/D変換は、文意からすると、小柳さんアルゴリズムでの変換と
いうことでしょう。

   いろいろ考えましたが、これも輝度のような負になり得ない値が対象
なら、減色の場合にはn系を使うのが、僕としては妥当のように思いま
した。

  (考えたことのメモ)

・刻み1/256にすべきところが刻み1/255になっている。これを変換しつ
  つ、[0, 4)に変換する。しかも四捨五入のために0.5を加えてから切
  り捨てている。だから、

    f(x) = (int) ((x - 0.5) * 256 / 255 / 64);
         = (int) ((x * 4 - 2) / 255);

---

  念を押しておきますが、もしこれが数値計算の誤差やノイズによる誤
差のような話題であれば、話は全く変わってきます。この手の誤差は、
ゾーンナンバーという考えがほとんど役に立ちません。この時は最近値
への丸めが最も有効であろうと思われます。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/

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