検索条件
全1件
(1/1ページ)
2023/09/30(土)値のビット幅を拡縮するとき
2023/09/30 18:44 16bitデータを8bitに落としたり、8bitデータを計算のために32bit表現にしたりすることある思考整理メモ。
unsinged
画像データとかはこっちだな。落とすときはそのまま右shiftする。
落とすときはそのまま右shiftする。まぁ。普通？拡張するときは2択？
1つは単純に左シフトする方法。
つまり、u8をu16にするとき、8bit左シフトする＝256を乗ずる。この方法は最大値は最大値にならない。
u8をu16にするとき、255*256は65535にならず、65280になる。
u8をu24にするとき、255*65536は16777215にならず、16711680になる。
これは、unsigned型は 0 から 1-(1/2**bit数)までを表現でき 1.0を表現できないとする立場(立場？)とも言える。
65535 は 1.0 ではなく 1.0-1/65536 = 0.9999847412109375 である世界の計算。
色の処理をするときはあんまよくない。
たとえば、255の赤が65535の赤にならないので色がくすむ。
もう1つは、元のビット幅の1を繰り返したものを乗ずる方法。
元のビット幅分左シフトしては元の値を足すことを繰り返す方法とも言う。これは、当該unsigned型の表現可能な最大値(255とか65535とか) が 1.0 である世界。
最大値が最大値として復元される努力をする感じ。
つまり、u8をu16にするとき、 8bitの1 = 0x01 を、上から16bit分繰り返した 0x0101 = 257を乗ずる。(=8左シフトしてから元の値を足す)
u8をu16にするとき、255*257は65535になる。
u8をu24にするとき、255*0x010101(65537)は16777215になる。
こっちは、255の赤を65535の赤にできる。
ビット数が整数倍じゃないとき丸まってしまう。
たとえば、7bitの値を23bitにするとき
7bitの1 0b0000001 を 23bitになるまで繰り返した 0b00000010000001000000100=66052を乗ずると、
127*66052=8388604 で、23bit unsigned の最大値は 8388607にはならない。
こういうケースで最大値がほしいときは、普通に 8388607/127 (= 約66052.0236220) を掛けないといけない。
割り算を嫌うなら、7bit左シフトしてから元の値を足すを4回繰り返して一旦28bit表現にしてから右5bit落として23bit表現にする、をしてもできる。
7bitの1である 0b0000001を4回繰り返した 0b0000001000000100000010000001=2113665を掛けてから、32で割る(5ビット右シフトする)感じ。
signed
音声波形データとかはこっちで表現されよう。正負で表現可能な段階数が違うので面倒。
落とすとき
正のs16をs8に落とすとき、32767/127 = 約258.00787で割る負のs16をs8に落とすとき、32768/128 = 約256.00000で割る
正負によって除数が変わる。
はぁ？
そもそもsigned型では 0から+1の距離と 0から-1の距離が異なるのですか？
0から+1と0から-1の距離は一致するが、負の方にだけ表現できる幅が少し広いと考えるべきでは？
なら、より幅の広い負に配慮して、どっちも256で割りましょうか。。
ただし、s16の絶対値を256で割ってs8にしてはダメ。
負について256で割ったあとfloorしないといけない。
0方向丸めしてしまうと、0付近 s16の[-15,+15]の31要素がs8の0になってしまい歪む。
floorすれば、s16の[0,+15]の16要素がs8の0、[-16,-1]の16要素がs8の-1になる。
s16の世界にあった65536種類の値を256個ずつグループにまとめて、256種類の値に射影したいと考えると、
結果的には、unsignedと同じで、落としたいビット数分だけ右シフトするんでよさそう。
拡張するときは？
拡張するときは？正負によって表現できる幅が違うので、単純に最大値を最大値にマップすることはできない。
とりあえず、素直に拡張したいビット数分左シフトする方法が1つ。
s8をs16にするとき、+1は+256に、+127は+32512になる。
-1は-256に、-127は-32512に、-128は-32768になる。
最大値に配慮する方法も考えてみてはおく。
「+127が最大」か「-128が最小」か？「+127が最大」だよ派
ビット拡張先の正の最大値をビット拡張前の最大値で割ったものを係数にする。s8をs16にするとき、 32767/127≒258.0078740 なので、試しに 258.008 を掛けてみると、
+127が +32767.016 くらいになる
-127が -32767.016 くらいになる
-128は -33025.024 くらいになって、オーバーフローしちゃう(それはそう)。
うーん、元データの性格にもよるけど、-128 なんてなかった(-127と同値として扱う)と割り切るのは、1つのやり方としてはなくはないか？
変換を何度も行った場合の値の保存性は？
「-128が最小」だよ派
拡張先の負の最小値を拡張前の負の最小値で割ったものを係数にする。これは、 1<<(拡張したいビット数) になるので、先に書いた単純左シフトと同じになる。
「+127が最大」かつ「-128が最小」だよ派
「正のとき 258.0078740 を掛け、負のとき 256.0を掛ける」条件分岐をする。[0,+2]の距離と [-1,+1]の距離が変わっちゃう。
これは最初に割る話をしたときと同じであんまり筋がよくないと思う。考えない。
あとは、floatと行き来するとき……
signedは負方向に広い。 「-1.0を-32768とする」か「-1.0を-32767とする」かの2択。上で書いたけど s16の+32767を+1.0、-32768を-1.0など定義してしまうと0を境界に「1の幅」が変わって歪む。
「-1.0を-32768とする」
とき、変換時 32768 を係数に乗算・除算することになる。デメリットがあって、s16では、-1.0を-32768として表現できるが+1.0を表現できなくなる。
s16で表現できる範囲は、 1/32768 = 0.000030517578125 を用いて、-1.0 から +0.999969482421875 = (1-1/32768) となる。
「-1.0を-32767とする」
とき、変換時 32767で乗算・除算することになる。こっちは、+32767で1.0を表現できるので一見よさそうだけど、
その一方で-32768は 1+1/32767 (=約-1.000030518509476) になるので、
係数とかに使うときはちょっと気にしといた方がいいのかしら。
また整数型に戻すときはsaturationするだろうし、まぁそんなに気にしなくてもいい気もする。
「-1.0を-32768とする」よりは「-1.0を-32767とする」こっちの方が素直かしらという感覚になるのが不思議。
signed整数型では +1.0 を表現できないんじゃなかったの？
signed整数型を [-1.0, +1.0-ε] の範囲じゃなくて [-1.0-ε, +1.0] として扱おうとしてるってことね。
unsinged のときは、255とか65535とかで掛けたり割ったりすると思うのでそれと一緒ね。
というか、まず、その整数型の最小値と最大値が [-1.0, +1.0-ε] を表すのか、[-1.0-ε, +1.0] を表すのかを考える方がよさそ。
unsignedでも 最小値と最大値が[0, +1.0-ε]なのか[0, +1.0]なのかを考えるのがよさそ。まぁ、unsignedは普通は後者だけど。
😌