問題タブ [quantization]

私は画像処理で少し遊んでいて、色の量子化がどのように機能するかを読むことにしました。少し読んだ後、Modified Median Cut Quantizationアルゴリズムを見つけました。

私はLeptonica ライブラリの C 実装のコードを読んでいて、少し奇妙だと思うものに出会いました。

ここで強調したいのは、私はこの分野の専門家ではなく、数学の専門家ではないということです。したがって、これはすべて、アルゴリズムの実装が間違っているということではなく、すべてを理解していないことが原因であると予測しています。まったく。

アルゴリズムは、vboxが最大軸に沿って分割され、次のロジックを使用して分割されるべきであると述べています。

最大の軸は、(母集団による) 中央値のピクセルでビンを見つけ、長い方の辺を選択し、その辺の中央で分割することによって分割されます。単純に中央値ピクセルのビンを短辺に配置することもできますが、細分割の初期段階では、高密度クラスターの一部として同じ vbox に低密度クラスター (細分割では考慮されない) を配置する傾向があります。将来の中央値ベースのサブディビジョンであっても、中央値の vbox 色でそれを打ち負かすクラスター。ここで使用されるアルゴリズムは、初期のサブディビジョンで特に重要であり、可視であるが人口が少ないカラー クラスターに独自の vbox を与えるのに役立ちます。これは高密度クラスターの細分化にはほとんど影響せず、最終的には vbox 内の人口がほぼ等しくなります。

議論のために、分割の過程にある vbox があり、赤い軸が最大であると仮定しましょう。レプトニカ アルゴリズムの 01297 行で、コードは次のように表示されます。

• 赤の可能なすべての緑と青のバリエーションを反復します
• 反復ごとに、赤軸に沿って見つかったピクセル (人口)の総数に追加されます
• 赤ごとに、現在の赤と前の赤の母集団を合計し、赤ごとに累積値を保存します。

注：「赤」と言うとき、反復によってカバーされる軸に沿った各点を意味します。実際の色は赤ではなく、ある程度の赤が含まれている場合があります

説明のために、赤い軸に沿って 9 つの「ビン」があり、それらの人口が次のとおりであると仮定します。

4 8 20 16 1 9 12 8 8

すべての赤いビンの反復後、partialsum配列には、上記のビンの次のカウントが含まれます。

4 12 32 48 49 58 70 78 86

合計の値は 86 になります。

それが完了したら、実際の中央値カットを実行します。赤い軸の場合、これは行 01346 で実行されます。

ビンを反復処理し、累積合計を確認します。そして、これがアルゴリズムの説明から私を突き飛ばす部分です。total/2より大きい値を持つ最初のビンを探します。

total/2は、中央値ではなく平均値より大きい値を持つビンを探していることを意味しませんか? 上記のビンの中央値は49になります

43または49を使用すると、ボックスの分割方法に大きな影響を与える可能性がありますが、アルゴリズムは一致した値があった場所の大きい側の中心に移動します。

私を少し困惑させるもう1つのことは、紙が中央値を持つビンを特定する必要があることを指定しているが、偶数のビンがある場合の処理​​方法について言及していないことです..中央値は(a +の結果になりますb)/2であり、ビンのいずれかにその人口数が含まれているとは限りません。したがって、選択したビンの大きい側の中心で分割が実際にどのように行われるかにより、無視できるいくつかの近似が行われていることがわかります。

少し長くなってしまったら申し訳ありませんが、数日間私を夢中にさせているので、できる限り徹底したかったのです;）

Photoshopの名前を付けて保存機能を使用し、jpegファイル形式を選択すると、次のウィンドウが表示されます。

ご覧のとおり、ベースライン（「標準」）形式と最高の画質を選択しています。この画像を16進エディターで開くと、いくつかのFF DBマーカー（量子化テーブルの開始）が表示されます。まだ問題ありませんが、次の画像を見てみましょう。

上のフォーム画像を見るとわかるように、アドレス行BDAでFFDBマーカーが始まります。最初の2バイトは0084であり、これはこのマーカーが132バイトのデータを保持することを意味します。いくつかの計算を行うと、2つの量子化テーブルがこのマーカーによって定義されていると結論付けることができます。最初のテーブルの値は次のとおりです：0C 08 080809など...

同じファイルに、次の図に示すように、2885アドレス行から始まる別のFFDBマーカーがあります。

この場合も、最初の2バイトの値は00 84であり、これは132バイトのデータを意味します。ただし、今回は、最初の量子化テーブルの値は次のとおりです。010101など...

どのFFDBマーカーを使用する必要があるのか​​、またファイルに複数のFFDBマーカーがあるのはなぜですか？

生の画像を jpeg 画像にエンコードする際に、8x8 データ ユニットがレベル シフトされ、2-D DCT を使用して変換され、量子化され、ハフマン エンコードされます。

最初に行 DCT を実行し、次に列 DCT を実行し、結果を最も近い整数に丸めました。このブロックを量子化モジュールに送りました。量子化中に、次の Q テーブルを使用しました。これらの表は、品質係数 99 に対して IJG によって推奨されています。

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1
1 1
1 1 2 2 1
1 1 1 1 2 2 2
1 1 1 2 2 2 2
1 1 2 2 2 2 2 2
1 2 2 2 2 2 2 2

1 1 1 1 2 2 2 2
1 1 1 1 2 2 2 2
1 1 2 2 2 2
1 1 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2
2 2
2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2

「2」で割っている間の量子化中に、結果をゼロから四捨五入しました。例: 11/2 = 6. したがって、デコード中の逆量子化中にすべての奇数に +1 のエラーが追加されます。

別のセットアップでは、丸め手法を変更しました。ここでは、結果をゼロに丸めています。例: 11/2 = 5. したがって、復号化中の逆量子化中にすべての奇数に -1 のエラーが追加されます。

2 番目のケースでは、ファイル サイズが非常に小さくなり (768x512 画像の場合、ほぼ 100 kb 小さくなります)、PSNR が大きくなります。2 で量子化すると「1」であるすべての AC 係数が 1 ではなく 0 になるということで、ファイル サイズが小さいことを説明できました。したがって、RLE はファイル サイズを小さくします。しかし、エンコードの画質が向上している理由を説明することはできません。2 ～ 3 dB 増加しており、テストしたすべての画像で発生しています。

私の主張は、DCT は基本的に A * DCTmatrix のどちらの側でも等しいエラーであるため、等しい損失が生じるはずです。しかし、ここではそうではありません。

過去数日間、PNGを少しいじってみましたが、その結果に腹を立てています。私の結果の大部分は圧縮を扱っていると結論付けています。それで、今週末、私は高度な圧縮記事に飛び込むつもりです。これまでの調査結果を共有したいと思いました。誰かが私の目標を達成するためのアドバイスを持っているかどうかを確認し、おそらく私を正しい方向に向けること。

私は現在、15秒未満のウィンドウ内で可能な限り最小のファイルサイズを取得する必要があるプロジェクトに取り組んでいます。

私が使用している画像の大部分は、フル256カラーパレットを備えたPNG-8bppです。これらの画像のほとんどは、5bpp（32色）で正確に表現できました。

ただし、インデックス付きのPNGは、1、2、4、および8bppのみをサポートします。したがって、私のアイデアは、PNG形式を必要最小限の情報に変換し、3、5、6、または7bppのIDATセクションをサポートするエンコーダー/デコーダーを作成することでした。

画像を表すのに6色しか必要ないので、3bppを使用してIDATをエンコードし、最大8色のパレットを作成することにしました。まず、IDATを解凍しました。これにより、新しいファイルサイズは368KBになります。IDATに3bppを適用した後、新しい非圧縮ファイルサイズは274KBです。良いスタートを切ったようです...次に、新しいIDATセクションにdeflateを適用しました。結果...59KB。

4bppを使用するよりも10KB大きくなります。

24色は32色で5bppで表すことができます。上記と同じ手法を使用すると、非圧縮よりもはるかに優れた結果を得ることができましたが、圧縮時に失われました。最終サイズは圧縮されています...84KB。次に、6,7bppで試してみました...同じ結果で、8bppよりも圧縮率が低くなりました。

念のため、すべての非圧縮画像を保存し、他のいくつかの圧縮アルゴリズムを試しました... LZMA、BZIP2、PAQ8 ...同じ結果、8bppの圧縮サイズは5、6、または7bppよりも小さく、4bppのサイズは3bppよりも小さくなっています。

なぜこれが起こっているのですか？圧縮アルゴリズムを微調整/変更して、8bpp圧縮を行う5、6、または7bpp形式を使用するPNGのような形式をターゲットにすることはできますか？それは時間の価値がありますか...そしてはい、さらに10KBを節約することはそれだけの価値があります。

テキスト画像を読み取り、グレースケール画像に変換し、ソーベル演算子を適用しました。ここで、「画像を量子化」したいと思います。

Android 4.0 または 4.0.3 を実行しているエミュレーターで、色のバンディングが見られますが、これを取り除くことはできません。私がテストした他のすべての Android バージョンでは、グラデーションは滑らかに見えます。

RGBX_8888 として構成された SurfaceView があり、レンダリングされたキャンバスにバンディングが表示されません。レンダリングの最後にノイズ パターンをオーバーレイして画像を手動でディザ処理すると、グラデーションを再び滑らかにすることができますが、パフォーマンスが犠牲になることは避けたいと思います。

そのため、バンディングは後で導入されています。4.0 以降では、SurfaceView が描画されてから表示されるまでの間のある時点でより低いビット深度に量子化されているとしか思えません。各チャネル、555 (565 ではなく) への量子化を提案します。

Activity onCreate 関数に以下を追加しましたが、違いはありませんでした。

代わりに onAttachedToWindow() に上記を入れてみましたが、それでも変化はありませんでした。

(私は RGBA_8888 が 2.2 以降のデフォルトのウィンドウ フォーマットであると信じているので、そのフォーマットを明示的に設定しても 4.0 以降には影響しないことは驚くに値しません。)

ソースが 8888 でデスティネーションが 8888 の場合、何が量子化/バンディングを導入していて、なぜそれが 4.0+ でしか表示されないのでしょうか?

非常に不可解です。誰かが光を当てることができるのだろうか？

そこで、画像に適用するための「単純な」減色について検討し始めています。私は最終日、これがどのように機能するかを調査し、ここで実験するのに適切なアルゴリズムと思われるものを見つけることができました：メディアンカットアルゴリズム

ここでの出力は、n色のパレットです。このアルゴリズムが実際に機能することをまだ確認していませんが、機能すると思います。私がやりたいのは、その出力を取得して、パレットが生成された画像に適用することです。

色圧縮形式と画像に関する深い知識に精通しているとは言えませんが、インデックス付きパレットが付属する画像形式から始めなくても、パレットを適用するにはどうすればよいのでしょうか。 （つまりGIF）。

ピクセルごとに、現在のピクセルの色とパレット内の各色の差を計算し、そのピクセルを最も差の少ないパレットの色に置き換えることを考えています。これはアプローチするための実行可能な方法でしょうか？

注-私はさまざまなライブラリ（ImageMagick）を調べましたが、これらは少しやり過ぎのようです。私が画像操作で行うことのほとんどは、カラーパレットを減らすことです。これほど複雑なことはありません。そのため、このアルゴリズムを実装することが私のニーズにとって最も簡単なアプローチになると考えています。

JPEG 圧縮では、量子化中および DCT 変換中に損失が発生します。

JPEG 画像圧縮での DCT 変換後の量子化後に多くの 0 が得られるのはなぜですか。

I hav a greyscale image. I did 8x8 blocks and computed each of their DCTs. I want to quantize the DCT coefficients and then replace their LSBs with my secret message bits. How exactly do I quantize the coefficients? Should I use the quantization matrix used by JPEG? How to determine the values of such a quantization matrix?

指定したカラーマップを使用して、他の画像の .gif 変換を保存したいと考えています。Image Magick の「-remap cmap.gif」オプション

例: convert -remap cmap.gif input.png output.gif

cmap.gif から指定された色を使用して input.png を処理しますが、出力カラーマップの順序が変わります。Image Magick にまったく同じカラーマップを使用させる方法はありますか?

.gif ファイル入力を受け入れるが、個々の画像のカラーマップを変更する機能のない固定カラーマップを使用する古い表示プログラムに新しい画像を追加しようとしています。