2002/03/15(金) [n年前の日記]
#1 ftp鯖にloginできず
日本のアニメ映像に特化した映像codecって
_(以下略)
親父さんのPC(giants)から自鯖(kerochan)のftpサーバにログインできず。
自分のメインPC(tomoyo)からなら、ログインできることを確認済みなのだけど。
同じアカウント名、同じパスワードのはずなのに。
サーバの設定ミスか、クライアントの設定ミスか…
サーバの/var/log/messageを見ると、PAMがどうこうと…
PAMって何?
親父さんのPC(giants)から自鯖(kerochan)のftpサーバにログインできず。
自分のメインPC(tomoyo)からなら、ログインできることを確認済みなのだけど。
同じアカウント名、同じパスワードのはずなのに。
サーバの設定ミスか、クライアントの設定ミスか…
サーバの/var/log/messageを見ると、PAMがどうこうと…
PAMって何?
[ ツッコむ ]
#2 [capture] アニメ専用codec
おねティのエンコ中映像を眺めながら、ぼんやりと思ったんですが。
日本のアニメ、それもTVアニメに特化したcodecって作れませんかね。
以下、妄想。
実写映像に比べると、日本のTVアニメって、特殊な映像ですよね。
例えば、以下のような特徴が。
・ セルとBGで構成。
・ 口パク、目パチのカット多数。
・ FIX、PANのカット多数。
・ 通常3コマ撮り。
・ 数枚でループするアニメを多用。
これらについて強く意識すれば…高圧縮・高画質化の圧縮codecを作れそう。
エンコード処理の流れとしては…
1.シーンチェンジを検出。今後はシーン単位で処理。
2.各シーンの性質(FIX、PAN、etc)を分析。
3.何コマで動いてるか、ループしてるか、どの範囲がセル・BGなのかを分析。
みたいな感じかな…
昔のアニメでは撮影時のガタつきとかがありますが。
FIXか否かが推測できれば、フレームのガタつきに対する補正処理ができそう。
これができれば、安定した画面が得られるでしょうね。
もっとも、意図的に画面を揺らしてる場合、その情報を消去する危険性もありますが。
3コマ撮り、ループアニメ…これらも容量圧縮に繋がる。
「このフレームは、何フレーム前(前フレームとは限らない)をそのままコピーすればOK」
となれば、容量は少なくなる。(再生時のバッファは、より多く必要になるかも)
また、変換前のソースから、それら同じフレーム画像だけ集め、時間軸ノイズ除去もできそう。
何度も使われる「高画質な一枚」を作れますね。
セル部分とBG部分に分解できれば、効果ありますね。
このへんはセルで、このへんはBGではないか、という目処さえ立てば…
そのシーンの全フレーム画像から「BG」部位を抜き出し、時間軸ノイズ除去…
これも、「高画質の静止画像=一枚のBG画像」を得られる。
BG画像さえ、一度得てしまえば…
FIXカットは、静止画上で、セル部分だけ順次置き換わるもの…
PANカットは、静止画をスクロールさせるだけ…
容量削減も果たした上で、安定した画面も得られる。
セルは基本的に、輪郭線と均一な塗りから構成されてるはずの画像…
故に、セル上でチラチラする些末な色の変化成分は単なるノイズとみなせて除去できる。
また、フレームによってそれほど色が変化するはずもないので、時間軸上で一貫した色情報を得る事もできる。
より均一な塗りであれば、可逆圧縮の利用も現実味を帯びてくる。
(PC98やX68Kの頃は、その手の可逆圧縮、盛り上がってましたね…)
もしくは、「輪郭」「塗り」をベクターデータに変換できれば、容量削減につながる可能性が。
(そういや、こういう処理…
オブジェクトとBGに分解して処理するcodecの記事を、以前どこかで見かけたような。
たしか日本の会社だったような…)
つか、あちこちMPEGの仕組みと変わらん気も(爆)
ただ、MPEGは、
「全く同じフレーム画像(部位)はそうそう出てこない。どこかしら微妙に違うのが当たり前」
が前提だと思うのです。
日本のTVアニメに特化すれば、
「全く同じフレーム画像(部位)が、うんざりするほど出てくるのが当たり前」
という前提で処理ができるから、より圧縮が効くんじゃないかな。
で、もちろん、これらの方法で高圧縮・高画質が得られないシーンも出るはずで…
その場合は、実写映像に適した圧縮方法を使ってそのシーンを処理すればいい。
あくまで、効果が期待できそうなシーンにのみ、アニメに特化した処理を使う、と。
…と、別にこういうのはcodecでなくてもいいのか(爆)
ガタつかない、チラチラしない…
そういった、綺麗でクリアなソースさえあれば、今現在のcodecでも低容量・高画質化は得られるし。
フィルタ処理で上記のような処理をして、クリアなソースを吐き出せば、それだけで充分効果があるでしょうね。
しかし…上記のような処理が出来たら…
それってそのままFLASHデータにも変換できそうだな…
…なんてことを妄想してしまうぐらい、自分のキャプチャしたおねティ映像はチラチラグラグラ(爆)
本来、FIXカットだからピクリともしないはずの部分が…チラチラチラチラ…
参っちゃうよなぁ…
日本のアニメ、それもTVアニメに特化したcodecって作れませんかね。
以下、妄想。
実写映像に比べると、日本のTVアニメって、特殊な映像ですよね。
例えば、以下のような特徴が。
・ セルとBGで構成。
・ 口パク、目パチのカット多数。
・ FIX、PANのカット多数。
・ 通常3コマ撮り。
・ 数枚でループするアニメを多用。
これらについて強く意識すれば…高圧縮・高画質化の圧縮codecを作れそう。
エンコード処理の流れとしては…
1.シーンチェンジを検出。今後はシーン単位で処理。
2.各シーンの性質(FIX、PAN、etc)を分析。
3.何コマで動いてるか、ループしてるか、どの範囲がセル・BGなのかを分析。
みたいな感じかな…
昔のアニメでは撮影時のガタつきとかがありますが。
FIXか否かが推測できれば、フレームのガタつきに対する補正処理ができそう。
これができれば、安定した画面が得られるでしょうね。
もっとも、意図的に画面を揺らしてる場合、その情報を消去する危険性もありますが。
3コマ撮り、ループアニメ…これらも容量圧縮に繋がる。
「このフレームは、何フレーム前(前フレームとは限らない)をそのままコピーすればOK」
となれば、容量は少なくなる。(再生時のバッファは、より多く必要になるかも)
また、変換前のソースから、それら同じフレーム画像だけ集め、時間軸ノイズ除去もできそう。
何度も使われる「高画質な一枚」を作れますね。
セル部分とBG部分に分解できれば、効果ありますね。
このへんはセルで、このへんはBGではないか、という目処さえ立てば…
そのシーンの全フレーム画像から「BG」部位を抜き出し、時間軸ノイズ除去…
これも、「高画質の静止画像=一枚のBG画像」を得られる。
BG画像さえ、一度得てしまえば…
FIXカットは、静止画上で、セル部分だけ順次置き換わるもの…
PANカットは、静止画をスクロールさせるだけ…
容量削減も果たした上で、安定した画面も得られる。
セルは基本的に、輪郭線と均一な塗りから構成されてるはずの画像…
故に、セル上でチラチラする些末な色の変化成分は単なるノイズとみなせて除去できる。
また、フレームによってそれほど色が変化するはずもないので、時間軸上で一貫した色情報を得る事もできる。
より均一な塗りであれば、可逆圧縮の利用も現実味を帯びてくる。
(PC98やX68Kの頃は、その手の可逆圧縮、盛り上がってましたね…)
もしくは、「輪郭」「塗り」をベクターデータに変換できれば、容量削減につながる可能性が。
(そういや、こういう処理…
オブジェクトとBGに分解して処理するcodecの記事を、以前どこかで見かけたような。
たしか日本の会社だったような…)
つか、あちこちMPEGの仕組みと変わらん気も(爆)
ただ、MPEGは、
「全く同じフレーム画像(部位)はそうそう出てこない。どこかしら微妙に違うのが当たり前」
が前提だと思うのです。
日本のTVアニメに特化すれば、
「全く同じフレーム画像(部位)が、うんざりするほど出てくるのが当たり前」
という前提で処理ができるから、より圧縮が効くんじゃないかな。
で、もちろん、これらの方法で高圧縮・高画質が得られないシーンも出るはずで…
その場合は、実写映像に適した圧縮方法を使ってそのシーンを処理すればいい。
あくまで、効果が期待できそうなシーンにのみ、アニメに特化した処理を使う、と。
…と、別にこういうのはcodecでなくてもいいのか(爆)
ガタつかない、チラチラしない…
そういった、綺麗でクリアなソースさえあれば、今現在のcodecでも低容量・高画質化は得られるし。
フィルタ処理で上記のような処理をして、クリアなソースを吐き出せば、それだけで充分効果があるでしょうね。
しかし…上記のような処理が出来たら…
それってそのままFLASHデータにも変換できそうだな…
…なんてことを妄想してしまうぐらい、自分のキャプチャしたおねティ映像はチラチラグラグラ(爆)
本来、FIXカットだからピクリともしないはずの部分が…チラチラチラチラ…
参っちゃうよなぁ…
[ ツッコむ ]
以上、1 日分です。