画像縮小品質2008/01/31 00:00:00

縮小結果のコレクション

【追記 : 3/20】このエントリの内容は、あくまで見た目の主観に基づいたものです。技術的な面は二の次ですので、その辺りを考慮してお読み頂けると幸いです。


写真だと分り辛いので、エッジの強い部分を多分に含む、自分のイラストを使いました

元画像は無駄に大きく、1600×1600pix.

320×320pix. への縮小なので、20% と比較的切りの良い縮小なので、少々計算に問題が有っても、酷く崩れる事は無いでしょう

クリックすると、大きな画像が見れますが、圧縮率が高いので、細かい事は分り辛いと思います


  • Dibas32
    基本的に単純平均化による縮小っぽい結果
    問題は周り 1 dot の処理が妙な部分
  • Paintgraphic2
    単純平均化による縮小らしいけれど、計算精度が低いのか粗くなる事がある
  • FView2000
    単純平均化による縮小にしてはエッジが甘い
  • PhotoCrew 2
    基本に忠実な単純平均化による縮小
  • JTrim 1.53c
    高品質と言われている Lanczos3 による縮小
    しかし、エッジに強調処理が見られるので、高品質とは言い難い…
    また、Dibas32 にも見られた現象だが、周り 1 dot の処理が変
  • Yukari FLAX 10.992
    Lanczos アルゴリズムの独自改良版による縮小
    JTrim に近い結果が得られる (周り 1 dot の不自然さは無い)
    エッジの強調処理による不自然さは改善されているが、やはり変
  • KazArt.hpi
    私の独自実装
    基本的には、単純平均化による縮小だけれど、計算速度を考慮して 256倍積算処理という妙な事を行っている為、少し精度は低い筈
    ただ、拡大と縮小のアルゴリズムがはっきりと分離されているため、完全に縮小専門のコードという辺りが他とは異なるかも… (単に、内部に切替えて処理するコードが無いだけだが…)
    “少しとは言え精度が低いから結果は芳しくないだろうなぁ…” と思っていたけれど、基本に忠実な PhotoCrew 2 の結果に非常に近い
    意外と真っ当な結果に、コードを書いた本人がびっくりした (^^; ← ォィ
  • Paint Shop Pro PHOTO X2
    “スマート縮小” と言う自動的に最適のアルゴリズムを選択する物を使ったため、内部処理は不明
    すっきりとした結果が得られているが、Lanczos アルゴリズムに似たエッジの不自然さが少し出ている 【追記】三次補間なのだそうです
  • openCanvas 4.5.09 plus
    基本に忠実な単純平均化による縮小
  • Photo Shop Elements 3.0
    単純平均化に近い結果だけど、エッジの強調が見られる
    最新版のアルゴリズムでも大きく変るとは考えがたい
  • Painter X
    基本に忠実な単純平均化による縮小
  • SILKYPIX Developer Studio 3.0
    そもそもこのツールで縮小だけをやろうとしている時点でかなり妙なのだけれど、他とは全く異なる程に美しい縮小が行われているのが興味深い
    RAW 現像の技術を応用した周波数解析や、縮小時に画質に悪影響を及す周波数成分の除去なども行っているらしい (内部処理は 48bit RGB を基本に、計算はそれ以上の精度で行われている)
  • IrfanView 4.10
    この中には載っていないが、Lanczos アルゴリズムを選択して縮小してみると、単純平均化による縮小より少し高画質に縮小出来た
    エッジの不自然さもないので、一括処理も可能な事を考えると、最も利便性が高く、程々に美しい縮小が望めそう 【追記】縮小に関しては、どのアルゴリズムを選択しても結果に変化はないそうです。

……と言う事で、結果からすると、“SILKYPIX Developer Studio 3.0” が理想だけれど、処理に時間は掛るし、扱える画像形式の制限もあるしで、“IrfanView 4.10” が最も扱易く、程々に高画質という結果に

拡大だとまた結果が異なってくると思うけれど、縮小だとこんな感じみたいです

 

【追記 : 3/20】コメントは有難いのですが、きちんと自分の言葉でのコメントにてお願い致します (掲示板でのやりとりをそのままペーストした匿名投稿だった為、公開は控えます)。このエントリでの内容は、あくまで手元のツールでの結果で、主観に基づいているのは事実です (アルゴリズムを追求している訳ではなく結果を優先している為、結果の見た目での主観的な判断になっております)。また、このエントリで単純平均と書いているのは平均画素法のことです。妙な用語を使った為に、誤解を招いたことをお詫び致します。

【追記2 : 3/20】Lanczos アルゴリズムと、三次補間 では、エッジは出るべきして出ているのだとか , それが特性らしいので、アニメ調や、ぺったりとした画像には向いてない様です

【追記3 : 3/20】C-yan さんの「藤 -Resizer-」 と言う素晴しい拡大・縮小ツールがあります。性能に関して問題は無いのですが、結果を基画像サイズの % で指定する為、ドット単位で結果を得たい場合には少々不向きなのが難点です。「四分の一に縮小したい…」と言うような一般的に多そうな用途では、かなり便利かつ強力なツールです。【修正 : 3/20】設定の変更でドット指定も可能です。

コメント

_ nanana ― 2008/03/20 20:49:53

技術的な考察はよくわからないですが、最終的なアウトプットとしてjpegで保存されるのはいかがなものかと。
比較画像を不可逆圧縮形式で保存されたのでは、ここを見ているだけで途中の状態を知らない人間には
縮小エンジンによる劣化なのか、jpeg圧縮による劣化なのかの区別がつけられないと思います。

_ nullpo ― 2008/03/20 21:46:15

>【追記3 : 3/20】C-yan さんの「藤 -Resizer-」 と言う
>素晴しい拡大・縮小ツールがあります。
>性能に関して問題は無いのですが、結果を基画像サイズの % で
>指定する為、ドット単位で結果を得たい場合には少々不向きなのが
>難点です。

藤 -Resizer- のウィンドウの右上にある「大きさの指定」で
「絶対指定」を選択するとピクセル単位で大きさを指定できます。

_ 和哉%管理人 ― 2008/03/20 22:04:02

> nullpo さん

ご指摘有難う御座います。修正致します。

申訳御座いませんが、某掲示板風のお名前での書込はできれば御遠慮下さい。

_ 和哉%管理人 ― 2008/03/20 22:30:33

> nanana さん

確かに仰るとおりです。公開当時、深く考えずに、画質を落してしまっておりました。

ただ、png Image では容量をオーバーしてしましますので、このエントリでの主観的な判断基準になっている、エッジ周りが判別できるよう、制限容量ぎりぎりまで画質を上げた JPEG Image に差替えました。

できれば、捨てハンドル名と判断されかねないお名前ではなく、普段使われているハンドル名でのコメントポストをお願い致します。

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

※投稿には管理者が設定した質問に答える必要があります。

名前:
メールアドレス:
URL:
次の質問に答えてください:
√7 の計算結果を漢数字表記で6桁分(以下切捨)/ドットは ANK 使用/最後に ^q$ を付加

コメント:

トラックバック

このエントリのトラックバックURL: http://asg.asablo.jp/blog/2008/01/31/2590715/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。