概要

• 画像処理における 整数と浮動小数点変換 の2つの手法を比較
• 255除算（標準） と 256除算（代替） の違いと利点・欠点を解説
• 極値の扱い・量子化誤差・実用上の影響について説明
• どちらの手法を選ぶべきかの 結論と推奨 を提示
• 量子化理論 や他の参考意見も簡潔に紹介

画像処理プログラムにおける整数-浮動小数点変換の2方式

• 画像を 浮動小数点（float） に変換し、処理後に 8ビット整数 へ戻す処理が一般的

• 主な変換方式は以下の2つ：

  • 標準方式（255除算）
    • 変換式：pixels = img / 255.0
    • 保存時：output = np.trunc(result * 255 + 0.5)
    • 特徴：0→0.0、255→1.0に正確にマッピング
  • 代替方式（256除算）
    • 変換式：pixels = (img + 0.5) / 256.0
    • 保存時：output = np.trunc(result * 256)
    • 特徴：0→0.00195…、255→0.998…にマッピングされ、両端値がピッタリ0や1にならない

• どちらも最終的に clamp（0～255に丸め） して8ビット化

標準方式（255除算）の特徴と批判

• 0と255が0.0と1.0 に正確に対応し、GPUや多くの標準実装で採用
• 変換後の値は[0,1]範囲を 少しはみ出す
  • 例：0→0.0、255→1.0だが、実際のbin幅は両端が半分
• 極値（0,255）が出現しづらい
  • 一様乱数でヒストグラムを取ると、0と255の出現頻度が他より半分
• しかし、 元画像の再量子化（uint8→float→uint8） は損失なし
• 極端値のbin幅が狭い問題は、 実用上あまり影響しない ケースが多い

代替方式（256除算）の特徴と利点・欠点

• 各float値が整数のちょうど中間 に配置される
• 例：128/256=0.5で、値の間隔が均等
• dithering（ディザリング） やノイズ加算時に端値の特別扱いが不要
• ただし、 0や255がfloatの0.0や1.0に一致しない ため、黒判定などが煩雑
• 元画像が標準方式で保存されている場合、 精度を取り戻せない

量子化方式としての2手法の整理

• mid-riser（標準：255除算）
  • 量子化式：k = trunc(x L)、復元：y_k = (k+0.5)/L
  • L=255の場合
• mid-tread（代替：256除算）
  • 量子化式：k = trunc(x L + 0.5)、復元：y_k = k/L
  • L=256の場合
• mid-riser は0→0.0、 mid-tread は0→0.00195…と、 0の扱い が異なる

量子化誤差と実用上の意味

• 255除算は理論上、量子化誤差がわずかに大きい
  • 平均絶対誤差：1/1020（255除算）、1/1024（256除算）
• しかし、 実際の画像がどう保存されたか に依存し、理論値ほどの差は出ない
• 他人が作成した画像 を処理する場合、標準方式（255除算）が安全
• 自分で保存・読込を完結 させる場合のみ、256除算のメリットを活かせる可能性

結論と推奨

• 他人から提供された画像や標準的なワークフローでは255除算を推奨
• 浮動小数点値の正確さや量子化誤差を極限まで気にする場合のみ256除算を検討
• ただし、 保存・読込の両方を自分で管理できる場合 に限定
• 方式を混在させると誤差やバグの原因 になるため、統一が重要

参考意見・関連資料

• Jonathan Blowの2002年記事：mid-riser/mid-tread量子化の図解
• Andrew Keslerの2015年記事：256除算のディザリング利点を主張
• Wikipedia「Quantization（量子化）」：mid-riser/mid-treadの定義と数式
• StackOverflowの議論：量子化誤差の理論値比較

まとめ

• 画像処理で整数⇔float変換時は255除算が基本
• 理論的には256除算も一考の価値あり
• 現場の標準や互換性を最優先 に選択するのが無難