2009年10月31日土曜日
茄子 スーツケースの渡り鳥
局:BShi
放送日:2009/10/31
評価:HV1280
こちらはOVA。
大きいというほどではないけれど、円に近い分布。
分布通り輪郭くっきりという質感ではないけれど、線も暗くコントラストも高く、分布の割りには十分鮮明に見える。
縦はほぼ正確に720のジャギが確認できるHV1280。
茄子 アンダルシアの夏
今日からマ王! 第3シリーズ 30話
局:NHK-E
放送日:2009/10/31
評価:HV1280-i
今回は28話に比べるとボケも軽減して劣化も少なく安定していたので、より正確な特徴が確認できた。
フィールドのジャギのピッチから誤差1以下で縦713。確認した範囲では同じ状態で処理は安定しているようだ。28話で見たところも強いぼけと乱れで特徴を読み取ることができなかっただけで、処理としては同じだった模様。
今のところ720に近い縦サイズからフィールド拡大で縞が出ているアニメで720以外の確認例はこれのみ。繰り返しになるけれど、単純に713→1080とした状態だけとは思えない縦方向のボケ、あるいはにじみと言った方が近い乱れもあるので、最後の段階での拡大は720→1080だったけれど、その前に別の処理があったために変わった特徴の映像になった可能性もありそう。
処理過程はともかく、713からのフィールド単位の拡大と考えても差し支えない特徴の映像なので、Destripe(357, 3, 2, 3, 2)の縦712.7程度の近似値で縮小すると縞の乱れのない絵に戻すこともできる。
さらに、Destripe(357, 3, 3, 2, 2, 50)誤修正程度の設定を使えば、にじみを軽減してより鮮明な映像になるけれど、この設定だとオリジナルより鮮明?という感じになってしまうので画質評価視点から逸脱気味の設定。
今後も同じ状態が続くかどうか分からないけど、映像データとして一回くらい見ておいてもいいくらい縞縞アニメの素材としてはかなりの珍種で面白いサンプルかも。
番外 再び縞解消法バージョンアップ
Destripeプラグイン併用の速度改善版はこちら。
今回は元に戻すという視点にとらわれず、より鮮明な(あるいはバランスのよい)質感に調整できるように拡張しています。特にHV1280-iでは縦方向にボケているものが多いので、より元の絵に近づけることができるようになるかも。
不適切な値を受け付けないようにした他、一部処理を変更していますが、新しい設定を使わない限り以前と同じ結果になります。
function Destripe(
\ clip clip, int "hh", int "rt", int "sft1", int "sft2",
\ int "addb", int "mode") {
addb = default(addb, 0)
mode = default(mode, 1)
Assert(hh>=1 && hh<=2048,"hhは1~2048") Assert(rt>=1 && rt<=64,"rtは1~64") Assert(sft1>=(-rt*4) && sft1<=(rt*4),"sft1範囲エラー") Assert(sft2>=(-rt*4) && sft2<=(rt*4),"sft2範囲エラー") Assert(addb>=0 && addb<=256 && (addb%2)==0, \ "addbは0~256の偶数") Assert(mode>=-158 && mode<=100, "modeは-158~100")
w = clip.width()
th = hh * rt
c = ((addb == 0) ? clip :
\ clip.AddBorders(0, 0, 0, addb)).Separatefields()
c = (mode == 0) ? c.BicubicResize(w, th) : (
\ (mode == 1) ? c.Spline36Resize(w, th) : (
\ c.blur(0, -(float(mode)/100.0)).
\ Spline36Resize(w, th)))
ve = c.SelectEven().
\ PointResize(w, hh, 0, rt - sft1, w, th)
vo = c.SelectOdd().
\ PointResize(w, hh, 0, rt - sft2, w, th)
return Interleave(ve, vo).Weave()
}
modeの拡張
mode=0 ResizeIntre互換
mode=1 標準
はそのままで
mode=それ以外(指定可能範囲は-158~100)を指定することで質感の調整が可能
プラスの大きな数字ほど鮮明になり、マイナス値ではぼけが強くなります。この設定は縦方向のみに影響します。ただし、絵でみると横方向にも変化が出ているように見えることがあります。
オリジナルを尊重という視点でいうと、似ような描き方の縦線と横線の黒さが近くなるように調整するとよさそう。推奨というほどでもないけれど、SDでは指定なし(mode=1で)で十分、HDでは15~30程度の範囲がバランスがよいものが多い。劣化が酷い場合は、さらに大きな数字の方がよく見えるものも少なからずあります。好きな質感を選んで使えばよい話だけれど、より鮮明な画質に調整する場合はこの段階ではバランスを重視し、別の処理でさらに調整した方がよい結果になることも多いだろう。
modeより前にaddbがありますので、例えばHV1280-i(GONZO)の設定
Destripe(360, 6, 4, 3)
をmode=25で少しシャープな絵にする場合は
Destripe(360, 6, 4, 3, 0, 25)
とするか、
Destripe(360, 6, 4, 3, mode=25)
とmodeを明示して指定します。
現状のアプローチでの汎用の縞解消法としてはほぼ完成形で、何か変えるとすれば処理の高速化ぐらいですが、特定の拡大処理に依存すたリサイズで縮小するとより自然な絵になるものもいくつかあり、あと2回くらいは変身を残しているかも。
TestDestripeなどは前回の修正のものをそのまま使って下さい。
追記
縞解消の処理の意図を把握した上で 処理を見ると、一旦大きく拡大した後にPointResizeで縮小するとい う2段階のリサイズを行なっているのが冗長で、直接フィールドの位置を調整して縮小すれば効率的と思えてくるかもしれないけれど、この面倒な処理にはもちろん理由があり、むしろこの2段階処理がDestripe(去年のResizeIntrも)の一番重要な部分だったりする。
絵で見た方が早い、ということで実験してみよう。
このイメージは、SD-iアプコンした映像とその縞を解消するために縮小する処理過程で、フィールドの一部を拡大したものだと思ってください。細かいと分かりにくいので縦16倍しています。
左の「初期状態」 は、アプコン前のSDの映像に相当する画像。横方向に4つのブロックに分かれているけれど、一番左の縞状態の部分が1ピクセル幅の線になります。順に2, 3, 4ピクセル幅の横線の縞のある状態。この縞とアプコンで出る縞はまったく関係なく、最初から縞のある画像です。
中央の「縦に拡大」は486→1080と同等の比率で縦方向だけにbilinearで拡大した状態。輪郭がボケているけれど、縞の周期など全体の特徴はある程度維持できている。
右上の「直接縮小」 のイメージは、中央の画像を、Spline36Resizeで直接縦486に縮小した状態。全体の特徴は「初期状態」に十分近いけれど、拡大で出たボケも 含めて再現しているため、少しボケ(この映像ではにじみという表現の方が近い?)が出てしまっている。特に左端の元が1ピクセル幅しかなかった縞の部分で は、輝度の変化が大きい。
右下の「拡大+間引き縮小」 がDestripe相当の処理の結果で、縦に拡大した後、PointResizeで情報を間引いて縮小した結果。元通りというほど理想的な結果ではないけ れど、右上に比べるとにじみが軽減され、特に1ピクセル幅の縞の部分でもある程度初期状態に近い画像を得ることができる。この例では拡大時のリサイズを bilinearにしていますが、輪郭をはっきり残すリサイズであれば、さらにDestripeの効果が強くなります。
簡単にいうと、大半のリサイズアルゴリズムは元の画像(この実験でいうと真ん中の画像)の特徴をいかに保持しつつサイズだけ変更するかを工夫した処理なので、右上の結果は 中央の拡大後のイメージの特徴を残しているという点で、理想に近い結果になっているけれど、元の状態に近づけるという特異な処理に価値がある縞解消においては、Destripeの方がよい結果を得られることが多いという話。直接リサイズ時に高精度に縦位置調整を行なったとしても、右下のようなイメージになり ません。縮小時のアルゴリズムを変えても似た傾向。
ここまでは理屈の上での話。
では、実際の縞アニメ映像をDesripeで戻すと必ず優秀な映像になるかというと、簡単に都合よい話にはならない。
ほとんどの場合、アプコン処理で発生するリンギング的なノイズや圧縮での劣化によるノイズが、元映像の解像度とは関係しない場所に存在しているので、より鮮明な映像にしてしまうDestripeではノイズがボケることなく残ってしまい汚い絵になりやすい副作用がある。Destripeでノイズが増えるという話ではなく、右上のように少しボケることがノイズ軽減効果になるための差。
さ らに右上と右下を比較すると、左端の1ピクセル幅の線こそ差は大きいけれど、少し太い線ではそれほど劇的な差になるわけでもない。実際のアニメ映像は元か ら少しボケていることもあって、面倒な処理の割りには見てわかりやすい効果が弱い映像も珍しくなく、右上の映像を少しシャープ系フィルタで補正する 程度でも、ほとんど判別できないくらいの映像も多い。理論的考察も大切だけど人が見る映像の処理の話である以上、理屈より実際の映像を見た印象が重要なのはいうまでもないところ。
縮小後、正しいフレームを得て再アプコン処理を行って静止画で比較すれば細かい部分で(わかりやすいところでいえばSD解像度で入っているOPEDの文字など)の違いがわかる程度なので、そこまでこだわる意味があるかは微妙かも。HVに関しては直接のリサイズでは再現できないすっきりした線になり激重分の効果が得られる例はそれなりにあるだろう。
という感じで、現時点ではコストに見合う効果が実際にあるのかというとソースや環境、あるいは見る人次第だろう。
今回は元に戻すという視点にとらわれず、より鮮明な(あるいはバランスのよい)質感に調整できるように拡張しています。特にHV1280-iでは縦方向にボケているものが多いので、より元の絵に近づけることができるようになるかも。
不適切な値を受け付けないようにした他、一部処理を変更していますが、新しい設定を使わない限り以前と同じ結果になります。
function Destripe(
\ clip clip, int "hh", int "rt", int "sft1", int "sft2",
\ int "addb", int "mode") {
addb = default(addb, 0)
mode = default(mode, 1)
Assert(hh>=1 && hh<=2048,"hhは1~2048") Assert(rt>=1 && rt<=64,"rtは1~64") Assert(sft1>=(-rt*4) && sft1<=(rt*4),"sft1範囲エラー") Assert(sft2>=(-rt*4) && sft2<=(rt*4),"sft2範囲エラー") Assert(addb>=0 && addb<=256 && (addb%2)==0, \ "addbは0~256の偶数") Assert(mode>=-158 && mode<=100, "modeは-158~100")
w = clip.width()
th = hh * rt
c = ((addb == 0) ? clip :
\ clip.AddBorders(0, 0, 0, addb)).Separatefields()
c = (mode == 0) ? c.BicubicResize(w, th) : (
\ (mode == 1) ? c.Spline36Resize(w, th) : (
\ c.blur(0, -(float(mode)/100.0)).
\ Spline36Resize(w, th)))
ve = c.SelectEven().
\ PointResize(w, hh, 0, rt - sft1, w, th)
vo = c.SelectOdd().
\ PointResize(w, hh, 0, rt - sft2, w, th)
return Interleave(ve, vo).Weave()
}
modeの拡張
mode=0 ResizeIntre互換
mode=1 標準
はそのままで
mode=それ以外(指定可能範囲は-158~100)を指定することで質感の調整が可能
プラスの大きな数字ほど鮮明になり、マイナス値ではぼけが強くなります。この設定は縦方向のみに影響します。ただし、絵でみると横方向にも変化が出ているように見えることがあります。
オリジナルを尊重という視点でいうと、似ような描き方の縦線と横線の黒さが近くなるように調整するとよさそう。推奨というほどでもないけれど、SDでは指定なし(mode=1で)で十分、HDでは15~30程度の範囲がバランスがよいものが多い。劣化が酷い場合は、さらに大きな数字の方がよく見えるものも少なからずあります。好きな質感を選んで使えばよい話だけれど、より鮮明な画質に調整する場合はこの段階ではバランスを重視し、別の処理でさらに調整した方がよい結果になることも多いだろう。
modeより前にaddbがありますので、例えばHV1280-i(GONZO)の設定
Destripe(360, 6, 4, 3)
をmode=25で少しシャープな絵にする場合は
Destripe(360, 6, 4, 3, 0, 25)
とするか、
Destripe(360, 6, 4, 3, mode=25)
とmodeを明示して指定します。
現状のアプローチでの汎用の縞解消法としてはほぼ完成形で、何か変えるとすれば処理の高速化ぐらいですが、特定の拡大処理に依存すたリサイズで縮小するとより自然な絵になるものもいくつかあり、あと2回くらいは変身を残しているかも。
TestDestripeなどは前回の修正のものをそのまま使って下さい。
追記
縞解消の処理の意図を把握した上で 処理を見ると、一旦大きく拡大した後にPointResizeで縮小するとい う2段階のリサイズを行なっているのが冗長で、直接フィールドの位置を調整して縮小すれば効率的と思えてくるかもしれないけれど、この面倒な処理にはもちろん理由があり、むしろこの2段階処理がDestripe(去年のResizeIntrも)の一番重要な部分だったりする。
絵で見た方が早い、ということで実験してみよう。
このイメージは、SD-iアプコンした映像とその縞を解消するために縮小する処理過程で、フィールドの一部を拡大したものだと思ってください。細かいと分かりにくいので縦16倍しています。
左の「初期状態」 は、アプコン前のSDの映像に相当する画像。横方向に4つのブロックに分かれているけれど、一番左の縞状態の部分が1ピクセル幅の線になります。順に2, 3, 4ピクセル幅の横線の縞のある状態。この縞とアプコンで出る縞はまったく関係なく、最初から縞のある画像です。
中央の「縦に拡大」は486→1080と同等の比率で縦方向だけにbilinearで拡大した状態。輪郭がボケているけれど、縞の周期など全体の特徴はある程度維持できている。
右上の「直接縮小」 のイメージは、中央の画像を、Spline36Resizeで直接縦486に縮小した状態。全体の特徴は「初期状態」に十分近いけれど、拡大で出たボケも 含めて再現しているため、少しボケ(この映像ではにじみという表現の方が近い?)が出てしまっている。特に左端の元が1ピクセル幅しかなかった縞の部分で は、輝度の変化が大きい。
右下の「拡大+間引き縮小」 がDestripe相当の処理の結果で、縦に拡大した後、PointResizeで情報を間引いて縮小した結果。元通りというほど理想的な結果ではないけ れど、右上に比べるとにじみが軽減され、特に1ピクセル幅の縞の部分でもある程度初期状態に近い画像を得ることができる。この例では拡大時のリサイズを bilinearにしていますが、輪郭をはっきり残すリサイズであれば、さらにDestripeの効果が強くなります。
簡単にいうと、大半のリサイズアルゴリズムは元の画像(この実験でいうと真ん中の画像)の特徴をいかに保持しつつサイズだけ変更するかを工夫した処理なので、右上の結果は 中央の拡大後のイメージの特徴を残しているという点で、理想に近い結果になっているけれど、元の状態に近づけるという特異な処理に価値がある縞解消においては、Destripeの方がよい結果を得られることが多いという話。直接リサイズ時に高精度に縦位置調整を行なったとしても、右下のようなイメージになり ません。縮小時のアルゴリズムを変えても似た傾向。
ここまでは理屈の上での話。
では、実際の縞アニメ映像をDesripeで戻すと必ず優秀な映像になるかというと、簡単に都合よい話にはならない。
ほとんどの場合、アプコン処理で発生するリンギング的なノイズや圧縮での劣化によるノイズが、元映像の解像度とは関係しない場所に存在しているので、より鮮明な映像にしてしまうDestripeではノイズがボケることなく残ってしまい汚い絵になりやすい副作用がある。Destripeでノイズが増えるという話ではなく、右上のように少しボケることがノイズ軽減効果になるための差。
さ らに右上と右下を比較すると、左端の1ピクセル幅の線こそ差は大きいけれど、少し太い線ではそれほど劇的な差になるわけでもない。実際のアニメ映像は元か ら少しボケていることもあって、面倒な処理の割りには見てわかりやすい効果が弱い映像も珍しくなく、右上の映像を少しシャープ系フィルタで補正する 程度でも、ほとんど判別できないくらいの映像も多い。理論的考察も大切だけど人が見る映像の処理の話である以上、理屈より実際の映像を見た印象が重要なのはいうまでもないところ。
縮小後、正しいフレームを得て再アプコン処理を行って静止画で比較すれば細かい部分で(わかりやすいところでいえばSD解像度で入っているOPEDの文字など)の違いがわかる程度なので、そこまでこだわる意味があるかは微妙かも。HVに関しては直接のリサイズでは再現できないすっきりした線になり激重分の効果が得られる例はそれなりにあるだろう。
という感じで、現時点ではコストに見合う効果が実際にあるのかというとソースや環境、あるいは見る人次第だろう。
登録:
投稿 (Atom)