サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
koujinz.cocolog-nifty.com
リンク ・画像の変換(目次ページ) 『拡大・縮小』関連 ・画像の縮小 ・画像の拡大「Nearest Neighbor法」 ・画像の拡大「Bilinear法」 ・画像の拡大「Bicubic法」 ・画像の拡大「Lanczos法」 ・画像の拡大-距離計算に関する考察 ・超解像 ここまで、Bilinear法、Bicubic法、Lanczos法、すべて 「X方向の距離とY方向の距離を求め、それぞれのウェイト計算をし、 X方向のウェイトとY方向のウェイトを掛ける。」 という手法をとってきました。 しかし、距離と言えば、X方向やY方向ではなく直線距離のはず。 つまり、デジカメであれば、カメラを傾ける事でX軸Y軸は傾くし、 スキャナーだって対象の角度を変えれば傾く。 X軸やY軸の方向は、人間が処理の都合で後から付けたもの。 画像の拡大にとって、 「そのような後付けの軸方向に左右されるべきものなのだろうか。
リンク ・画像の変換(目次ページ) 『拡大・縮小』関連 ・画像の縮小 ・画像の拡大「Nearest Neighbor法」 ・画像の拡大「Bilinear法」 ・画像の拡大「Bicubic法」 ・画像の拡大「Lanczos法」 ・画像の拡大-距離計算に関する考察 ・超解像 【線形補間法、バイリニア法 (Bilinear 法)】 下の図で、縦軸はピクセルの画素値です。 たとえば、24bit RGB の場合、R,G,B それぞれ 0~255 の値をとりますが、 その 0~255 が縦軸だと思ってください。 横軸は隣り合うピクセルです。 この図は、たまたま拡大率が3倍の場合を示しています。 この場合には、 s1 → d2 s2 → d5 s3 → d6 のように、3ピクセルおきに、そのままの値を持ってくれば良いです。 その間にある、d3, d4 は s1 と s2 の間の値(中間値)を持ってくれば
この式で、 n = 2 が Lanczos2, n = 3 が Lanczos3 です。 Lanczos2 は距離が2以内の画素、つまり4x4画素を参照して 拡大後の各ピクセル値を求めます。 Lanczos3 は距離が3以内、つまり6x6画素を参照します。 単純に考えると、4x4 = 16, 6x6=36 ですから、 Lanczos3 は Lanczos2 の2倍以上の計算量が必要な事になります。 (処理時間が倍、という事と思ってよいでしょう。) では、4x4 の代わりに 6x6 を用いるメリットは何でしょうか? 「4x4 の外側の画素の影響を受ける」という事ですね。 下記に Lanczos2 と Lanczos3 で拡大した画像を作ってみました。 違いが分かりますか? (160x120 → 384x256)と拡大 《元画像データ》 まっすぐな線(縦、横、斜め、どれでも)というのは、 4x
ディザリング(dithering) リンク ・画像の変換(目次ページ) ディザ関連 ・パターン・ディザ ・誤差拡散法 ・24bit→8bit減色 ディザリング(ディザ法)というのは、デジタル Audio の量子化や デジタル静止画の減色方法の事です。 静止画に関しては、元々は、印刷機やプリンターで 「いかに本物らしく表現できるか」 という事から発達した技術です。 古くは、印刷機は白と黒の2色(2階調)しかありませんでした。 カラードットプリンタではインクの色数が増えていますが、 それでも数色です。 最近のモニター(PCではグラフィックカード)ではフルカラー(true color) に対応しているのは当たり前ですが、 windows 出だしの頃は 256 色しか対応していないものが多くありました。 ディザ法が発達した背景にはこのような歴史があります。 ここでは静止画の減色方法の内、有名な2つ
リンク ・画像の変換(目次ページ) ディザ関連 ・パターン・ディザ ・誤差拡散法 ・24bit→8bit減色 24bit の画像を 8bit (256 color) にする方法について、です。 《元データ (24bit RGB)》 この絵の色分布(ヒストグラム)を調べると下記のようになります。 白っぽい背景の面積が大きいので、その部分にピークが出ます。 色の分布を3次元表示すると下記のようになります。 (横:Green,縦:Red,奥行:Blue) 分布がある領域に固まっている事がわかります。 別の画像のヒストグラムを調べると下記のようになります。 《元データ (24bit RGB)》 このように、通常の絵のヒストグラムは、ある領域に分布が集まったもの、 あるいは、幾つかの分布領域が組み合わさったものになります。 さて、24bit の画像を 8bit (256色) に減色する事について考え
リンク ・画像の変換(目次ページ) 『拡大・縮小』関連 ・画像の縮小 ・画像の拡大「Nearest Neighbor法」 ・画像の拡大「Bilinear法」 ・画像の拡大「Bicubic法」 ・画像の拡大「Lanczos法」 ・画像の拡大-距離計算に関する考察 ・超解像 【バイキュービック法 (Bicubic 法)】 バイリニア法は隣接する4点から線形的に中間値を求めているだけなので、 エッジが立っている場所でのガタガタ感が否めません。 バイキュービック法は もう少し滑らかに中間値を求めてやればいいんじゃね? という発想からきているのだと思います。 そのためには隣接する点だけではなく、その先の点をも考慮する必要があります。 つまり、d6, d7 の値を決めるために バイリニア法 では s2, s3 の値を参照しました。 それよりも滑らかにしようと思うと、 s2, s3 に加え、s1, s4
リンク ・画像の変換(目次ページ) 『拡大・縮小』関連 ・画像の縮小 ・画像の拡大「Nearest Neighbor法」 ・画像の拡大「Bilinear法」 ・画像の拡大「Bicubic法」 ・画像の拡大「Lanczos法」 ・画像の拡大-距離計算に関する考察 ・超解像 東芝のホームページに REGZA に搭載している『超解像技術』 (レゾリューションプラスなど)の解説記事がありました。 ここや ここ。 「実に、おもしろい。」 「私もやってみよう!」 ある画像①を拡大し、拡大した画像②をもう一度縮小③すると、 オリジナルとの差分④が得られます。 『差分が出てしまうということは、 拡大時に落としてしまった情報成分があるのではないか?』 どうやら、そんな発想から来ているようです。 こういった考え方は MPEG Video エンコードのループバックに似ています。 『オリジナル画像①を拡大した②に
「画像フォーマット」カテゴリの記事 超解像(2009.05.30) アンチエイリアシングとClear Type(2009.05.17) アウトラインフォント(2009.05.16) エッジ検出・エッジ強調・ぼかし(2009.05.09) 画像の拡大-距離計算に関する考察(2009.05.06)
リンク ・画像の変換(目次ページ) ディザ関連 ・パターン・ディザ ・誤差拡散法 ・24bit→8bit減色 【誤差拡散法 (Error Diffusion Method)】 誤差拡散法について理解する前に、 それよりも単純な『繰り越し法 (Carry Over Method)』について理解しましょう。 注)『繰り越し法』, "Carry Over Method" といのは、 私が勝手に名付けたので、世の中で通用するかどうかは知りません。 繰り越し法は次のようなアイデアです。 ・累積が 255 になったらプロットする。 ・プロットできなかったら次のピクセルに持ち越す。 実際には、プロットする条件を “128 以上”とした方が原画に近くなります。 すなわち、 ・累積値(A)が 128 以上になったらプロットする。 ・A<128 の場合は、次のピクセルに貯金(A)を繰り越す。 ・A≧128 の
リンク ・画像の変換(目次ページ) YCbCr関連 ・Video 信号の「RGB⇔YCbCr変換」 今度は画像フォーマットにおける YCbCr の方を JPEG JPEG の規格書(ISO/IEC 10918)には規定が無かったような気がします。 「気がします。」と書いたのは、私にとっては遠く昔の事なので、 10918がどこかに行っちゃいましたし、記憶の範囲で語る事しかできないから。 JPEGに関しては IJG (Independent JPEG Group)という団体がフリーのソースコードを書いてばらまき、 今ではソフト、ハードのほとんどがそれを元にしていると考えてよいでしょう。 この JIG のソースコードによって JPEG の RGB⇔YCbCr 変換が 世の中の JPEG の事実上の標準(デファクト)になったのだと思います。 JPEG (by IJG)
リンク ・画像の変換(目次ページ) YCbCr関連 ・画像フォーマットの「RGB⇔YCbCr変換」 久しぶりに画像ネタを 世の中には RGB だとか、YCbCr だとかという色空間があって、 その相互変換について。 変換式については ITU-T BT.601 や BT.709 という規格書で定義されています。 (色空間については、これ以外にも規格があります。) 正確には、画像フォーマットの YCbCr ではなく、ビデオ信号の YCbCr の話です。 D端子ケーブルとか、Composite(NTSC)ケーブルとかを流れるデータ信号の事です。 その Bt.601には次のように書かれています。 ITU-R BT.609
“可逆”を捨てきれない PNG は “不可逆”と割り切った JPEG には全く太刀打ちできません。 完敗です。 もし“可逆”が必要な画像データだったら (情報量を落とさずに圧縮したいなら)、 ZIP 圧縮すればよいのです。 「レントゲン写真を JPEG 圧縮して肺にノイズが写ったら困るじゃないかーー!」という PNG 信者による子供地味た反論を聞いた事があります。 「そんな重要なデータは圧縮するな」と言いたいです。 PNG 開発の唯一の、そして最大の目的が“GIF の駆逐”だった訳ですから、 プロパガンダのために宣伝文句が幾つも必要だったはずです。 しかも、圧縮率が悪い、処理時間が遅い、バッファが沢山必要、と実力を伴わないフォーマットなので、極めて不利な戦いだったのです。 キィーッ!!っとなった人達(しかも大して技術を持たない人達)が不利な状況をひっくり返すには “大衆を見方に付ける”とい
このページを最初にブックマークしてみませんか?
『koujinz.cocolog-nifty.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く