ZACK
2003-06-13 21:25:25 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
MTVにてキャプチャーしたMPEG2ファイルを当ソフトにてエンコードし、DVD用MPEG2を作成するとオリジナルに比べ明るく(白っぽく)なってしまいます。このファイルを更に再エンコードするともっと明るくなります。有償ソフトなのでPegasysに問い合わせたところ、”簡易色調補正で調整しろ”とのことなのですがデフォルト設定では明るさは変わってしまうものなのでしょうか?
WinXP Pro
P4 2.4G/Gigabyte GA-8PE667Pro
P2700 512M
Radeon9000
MTV2000
TMPGEnc-2.512.52.161-Plus
Ligos MPEG-2 Decoder
デコーダーは上記のものがVFAPIに記載されていますが特定できていません。ちなみにインストールされているMpeg2再生可能ソフトは
Ulead VideoStudio6
Ulead MovieWriter2
EasySystems Drag,nDropCD+DVD
Intervideo WinDVD4
ソリューションをご存知の方がおられましたらアドバイスお願いいたします。
鬼畜
2003-06-13 22:25:21 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
Ligosは普段使わないので外していたら済みません。
私の環境でLigos MPEG-2 Decoder経由で開くとYC伸張されるようです。
この場合「YUVデータをCCIR601ではなく...」の設定項目に
チェックを入れてはいけません。
この設定がどうなっているかを確認してみてください。
ZACK
2003-06-14 10:21:25 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
鬼畜さん、早速のサジェスチョンありがとうございます。チェックはされていませんでした。何かお気づきの事がありましたらまたお願いいたします。
鬼畜
2003-06-14 15:30:08 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
ちょっとテストしてみました。
OS:Win XP Pro SP1
MEM:512MB
TMPGEnc:TMPGEnc Plus 2.513
元ソース:TMPGEnc PlusでDVD用の設定でエンコードしたm2vファイル
このファイルを更にDVD用の設定で別ファイルに出力、その出力ファイルをソースに
同様の設定で再エンコードをしていく作業を10回繰り返しました。
試したパターンは以下の通りです。
1.Ligos MPEG-2 Decoder,「YUVデータをCCIR601ではなく....」にチェックしない
2.m2v.vfp(伸張),「YUVデータをCCIR601ではなく....」にチェックしない
3.m2v.vfp(ストレート),「YUVデータをCCIR601ではなく....」にチェックする
それぞれ10回(というか10段)エンコードしたものと元ソースを
m2v.vfp(ストレート)経由でAviUtlで開いてヒストグラムを比較してみました。
なおオーバーレイは切っています。
すると元ソースに一番忠実だったのが3のパターンでした。
1と2の場合はYC圧縮されてしまった(のとはちょっと違いますけど)ような
ヒストグラムになってしまいました。
自分で確認しておきながら結構ショックな結果です。
この結果から「YUVデータをCCIR601でなく....」にチェックしない場合の
RGB→YUVの変換に問題があるのではないでしょうか?
ZACKさんの言われる「明るくなる」のとは、違った結果になっている
気がしないでもないですが、可能であれば他の方の報告を待ちたいです。
ZACK
2003-06-14 18:36:15 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
鬼畜さん、色々とありがとうございます。私も「YUVデータをCCIR601ではなく....」のオン、オフにて確認しました。ただし目視ですが。
オリジナルソースに比べオフでは記載の通り明るく(白っぽく)なるのですが、オンではコントラストが強くなったような画像になり、白い部分はハレーションがおきてしまいます。全体的にはオリジナルに比べやはり明るいです。
とりあえずご報告まで
鬼畜
2003-06-14 19:15:06 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
> オンではコントラストが強くなったような画像になり、
> 白い部分はハレーションがおきてしまいます。
最初にレスしたようにLigos MPEG-2 Decoderの場合は伸張されますので、
この動作自体は妥当なものと思います。
白っぽくなるとおっしゃっているのは、ひょっとして暗い部分ではないでしょうか?
今回の問題点は伸張されたデータをMPEGエンコードする際には、
「YUVデータをCCIR601ではなく....」の項目にチェックを入れないのですが、
この場合のRGB→YUV変換の方法に誤りがある可能性があると言うことです。
本来ならば私の2番目のレスにあるテストでは、誤差はあっても1〜3の全てで
同じようなヒストグラムにならないとおかしいと思います。
ということで引き続き情報お待ちしております。
どら
2003-06-15 03:16:50 ( ID:varimftn/9f )
[ 削除 / 引用して返信 ]
エンコード後の明るさについての話題なので、便乗で質問させていただければと思います
民生機のDVDレコーダからソースを持ってきて
DVD2AVIを仲介して、DVD用のmpeg2の作成をしたいと思っています。
最終的には民生機での再生を考えているわけですが
DVD2AVIでの設定は、色空間はYUV422、YUV→RGB変換はTV色調
TMPGENC側での設定は「YUVデータをCCIR601ではなく...」のチェックはON
にしています
オリジナルソースに近付けるというか、忠実なのはこちらで正解なのでしょうか?
ネット上で色々と調べてもなかなかこれだ!という情報に巡りあえませんで…
皆さんはどのようにしているのか、教えて頂けると幸いです。
余談ですが、当方AVIUTLも使っていたりして、TMPGENCのプロジェクトファイル経由で
AVIUTLで読み込ませたりすると大分変わるようで…
TV→PCスケール補正とかわけがわからなくなってます(笑)
流れ者
2003-06-15 12:59:48 ( ID:sys8jafxvjg )
[ 削除 / 引用して返信 ]
>>鬼畜氏
その実験ではRGB>YUV変換ミスとはいえません
1.2.ともにYUV>RGB変換時に伸張している段階で
Y値で15以下、236以上のデータは削除されていることになります(サチュレート)
サチュレートされている以上元ソースのデータは復元できません
鬼畜
2003-06-15 16:05:57 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
流れ者さん、レスありがとうございます。
>1.2.ともにYUV>RGB変換時に伸張している段階で
>Y値で15以下、236以上のデータは削除されていることになります(サチュレート)
>サチュレートされている以上元ソースのデータは復元できません
これは理解した上でのテストですので、比較用のソースには
Ligos MPEG-2 Decoderで伸張されたものを,「YUVデータをCCIR601ではなく....」に
チェックしないで保存したものを使用しております。
従って比較元ソース時点で既にご指摘の範囲のデータは削除されていますので、
今回の問題とは無関係と思います。
同様のテストをしていただけるとわかると思うのですが、
1と2のヒストグラムは元ソースに比べて、TMPGEncのカスタム色調補正の
「コントラスト(0原点)」をマイナス側にしたような物になります。
ご確認をお願いいたします。
ZACK
2003-06-15 16:35:31 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
下記URLに静止画をアップしましたのでご覧ください。"Original"がキャプチャーした原画で "Original_TM"が当該ソフトにてエンコード後の画像です。
http://photos.yahoo.co.jp/zack03jp
流れ者
2003-06-15 22:08:18 ( ID:sys8jafxvjg )
[ 削除 / 引用して返信 ]
>>鬼畜さん
先ほどは検証もロクにせず、しったかぶりなレスをしてしまいたいへん失礼しました。
当方の環境でも確認してみました。
DVソースのため、AviutlでYUY2展開・圧縮せずにYC伸張フィルタで伸張したのちHuffyuv(RGB)にしたものをソースとしました。
使用したアプリ類
・TMPGEnc 2.510(ちょっと古いですが)
・VirutualMod1.4.1.3.2v2
・Avisynth2.5
・CCE Basic2.67
・m2v.vfp0.6.36
1. ソース
2. ソースを16から235指定でCCEでエンコード
3. ソースをYUVデータを・・」にチェックなしでTMPGEncにてエンコード
4. 3をm2v.vfp(伸張)経由で「YUVデータを・・」にチェックなしでTMPGEncにてエンコード
5. 4をm2v.vfp(伸張)経由で「YUVデータを・・」にチェックなしでTMPGEncにてエンコード
6. 3をm2v.vfp(ストレート)経由で「YUVデータを・・」にチェックいれてTMPGEncにてエンコード
7. 6をm2v.vfp(ストレート)経由で「YUVデータを・・」にチェックいれてTMPGEncにてエンコード
以上のファイルをAviSynthのLoadAviutlInputPlugin(m2v.vfp)で読み込みColorYUV(analyze=true)にて表示。
その表示結果からYUVのminimum,maximumを抜粋しました。
1. min 006:085:082 max 255:218:147
2. min 021:097:089 max 245:208:145
3. min 021:099:090 max 247:208:143
4. min 019:101:092 max 252:209:142
5. min 018:102:092 max 240:208:142
6. min 005:096:086 max 255:219:143
7. min 000:092:082 max 255:225:144
うーん、なんともいえませんが、単純にRGB>YUV変換式には必ず誤差があるとしかいいようが、、、。
元々RGBとYUVでは有効範囲も範囲内のデータ分布も違いますし、、、、。
CCEでも変化してますし、伸張・チェックなしでもストレート・チェックありでも誤差の範囲は似たり寄ったりのような、、、どうでしょう?。
鬼畜
2003-06-16 00:18:23 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
流れ者さん、検証ありがとうございます。
再エンコード回数が少ないとminとmaxのみの比較では誤差の範囲に隠れてしまう
可能性もありますね。出来ればavgも欲しいと思うのは贅沢ですか?
余裕があればお願いしたいですm(__)m
とりあえず私の方でもデータをアップしておきます。以下長文失礼します。
各ファイルをm2v.vfp(ストレート)経由でTMPGEncで開きヒストグラム(YCbCr)を
表示させたものです。
0.元ソース
http://members.jcom.home.ne.jp/kichikunoheya/test_00_source.png
1.Ligos MPEG-2 Decoder,「YUVデータを....」にチェックしない(x10回)
http://members.jcom.home.ne.jp/kichikunoheya/test_01_ligos.png
2.m2v.vfp(伸張),「YUVデータを....」にチェックしない(x10回)
http://members.jcom.home.ne.jp/kichikunoheya/test_02_m2v_ex.png
3.m2v.vfp(ストレート),「YUVデータを....」にチェックする(x10回)
http://members.jcom.home.ne.jp/kichikunoheya/test_03_m2v_st.png
流れ者さんと同様の検証(上記0から3までのファイルでの結果)
http://members.jcom.home.ne.jp/kichikunoheya/test_yuv.txt
これらのデータを見ていただくと 06/15 (日) 16:05 の私の発言にある、
> 「コントラスト(0原点)」をマイナス側にしたような物になります。
の意味がわかっていただけるのではないかと思います。
ZACKさん、画面見ました。エンコード後の方がコントラストが落ちているような感じですね。
私の方の検証結果とも違っている感じもしますし、1回のエンコードだけでは
一目見てわかるような違いはこちらではありません。
試しにm2v.vfp(ストレート)経由で開いて「YUVデータをCCIR601ではなく....」に
チェックするパターンで試してみてください。
xxx
2003-06-16 02:09:54 ( ID:5r/fkf3e8h. )
[ 削除 / 引用して返信 ]
YV12->YUY2補間処理でデータはコントラストが縮小方向に進みます。
(補間とは言ってみれば、前後のデータから中間値を求めてそれに置き換える訳ですから)
これは、最大・最小で5〜10程度、平均で0.5程度は違ってきます。
さらに、この補間は非可逆なので繰り返すとどんどん誤差は大きくなってきます。
テスト結果は、この補間での誤差程度に思われます。
Avisynth使っている人なら、
YV12での色分布と
ConvertToYUY2(又はYV12ToYUY2)した後での色分布を
比較してみてください。言っていることが判ると思います。
鬼畜
2003-06-16 19:00:08 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
xxxさん、情報ありがとうございます。
また以下長文になります。何度もすいませんm(__)m
>YV12->YUY2補間処理でデータはコントラストが縮小方向に進みます。
>(補間とは言ってみれば、前後のデータから中間値を求めてそれに置き換える訳ですから)
>これは、最大・最小で5〜10程度、平均で0.5程度は違ってきます。
>さらに、この補間は非可逆なので繰り返すとどんどん誤差は大きくなってきます。
>テスト結果は、この補間での誤差程度に思われます。
m2v.vfpではストレート,伸張ともYUV420->YUV422補間を行っていたと記憶しています。
またLigos使用時の補間処理がどうなっているかは全くわかりません。
ですが確かに影響は考えられますね。
今回のテスト結果になる要因は
-------------------------------------------------------------------------
補間による誤差はYUV420->YUV422->RGB24(またはYUV420->RGB24?)の過程と
RGB24->YUV420の過程で発生してるが、伸張と圧縮を行う場合は
ストレート変換の時に比べて誤差が拡大される。
-------------------------------------------------------------------------
との認識でよろしいでしょうか?
また
-------------------------------------------------------------------------
伸張して開いた場合は、コントラスト(0原点)のYの値を若干上げてから
エンコードしないと、ストレート変換の時と同等のヒストグラムは得られない。
-------------------------------------------------------------------------
と思って間違い無いでしょうか?
コントラスト(0原点)のYの値をどれくらい上げたら良いのかを調べるため
2のデータを元にテストしてみました。Yの補正の最小値が1なので、10回かけると
10補正が最小単位となります。そこでまず+10してみるとほぼ元ソースの範囲に
準拠したものとなりました。
http://members.jcom.home.ne.jp/kichikunoheya/test_02_m2v_ex_Y10.png
従って1回のエンコードでコントラスト(0原点)のYの値を+1してやれば
良いことになります。
ということで新たな条件でテストしてみました。
4.m2v.vfp(伸張),「YUVデータを....」にチェックしない,
コントラスト(0原点)のYを+1にする(x10回)
http://members.jcom.home.ne.jp/kichikunoheya/test_04_m2v_ex_Y1.png
この設定でほぼ元ソースやストレート変換時のヒストグラムと同じになりました。
画像自体の見た目では3と4の判別はつきません。通常は1回エンコードなので
ほぼ同等と見て良いと思います。
データ量的には4の方が流れ者さんが最初に説明してくださった理由があるので
有利だと考えられます。
この結果がxxxさんのおっしゃった誤差の分の影響なのか、RGB->YCbCr変換の問題なのか
私では判断ができませんが、今後のエンコードでは3か4の設定を使おうと思います。
他のいくつかの画像でも同じ設定で同様の結果となったので、この設定であれば
問題無いと思います。
またTMPGEncのVerは2.55まで遡ってテストしましたが結果に変化は無かったことも
付け加えておきます。以上で検証終わります。
お付き合い下さった方々ありがとうございました。
ということで本題のZACKさんの方にお返しいたします。
長々と占拠して申し訳ありませんでした。
xxx
2003-06-17 03:10:28 ( ID:vi/bqiz5qdw )
[ 削除 / 引用して返信 ]
昨日は迂闊なことを言ったかも知れません。
YV12->YUY2補間では、Yは変化せず、UVのみ変化(コントラストが下がる)します。
その後、YUY2->RGBでUVの変化はRGB全てに波及します。
さらにエンコ時に、2x2pixelのRGBをブレンドしてYV12にすると考えられます。
なので、エンコ後はYも変化して当然なんですが、BT.601の正規データだったら
やっぱりYの変化はUVほどは大きくないと考えられます。
テスト結果は、Yの変化が一番激しいみたいなので
やっぱり何かあるのかも知れません。
ZACK
2003-06-17 08:49:25 ( ID:fbyjprituu6 )
[ 削除 / 引用して返信 ]
鬼畜さん、xxxさん、色々とありがとうございます。ここまで深い領域になると理解できません。とりあえずいままで試したことが無かったのですが、m2v.vfpをインストールして実験をはじめました。エンコードしているとエラーが出て途中で止まってしまい苦労していますが、出来あがり次第またUPします。それでは。
ZACK
2003-06-17 22:50:31 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
流れ者さん、お礼が遅れて申し訳ありません。まさかこんなにレスがあるとは思ってもみませんでした。
とりあえず、m2v.vfpを使用して作成した比較静止画をUPしましたのでご覧ください。どれもOriginalと比較すると多かれ少なかれ差はあるようです。Ligosの画質はその中でもはっきり分かるレベルです。
http://photos.yahoo.co.jp/zack03jp
流れ者
2003-06-17 23:11:31 ( ID:sys8jafxvjg )
[ 削除 / 引用して返信 ]
>>JACKさん
もはや勝手に楽しんでるだけなんで細かいことは気にしないでください♪
MPEGデコーダによる色再現性の誤差については特に検証はいたしませんが、
LigosであろうがCyberLinkであろうが市販のデコーダはメーカー独自のチューニングが行われます。
市販デコーダ経由の読みこみを否定するつもりはありませんが、
純粋な色再現性ということであれば、茂木氏のプラグインが一番かと思われます。
レスを読む限り、無事プラグイン使用の環境が整ったようですので喜ばしいかぎりです。
完全にソース再現することはいずれにしても不可能ですので、
m2v.vfp経由鬼畜さんの回避方がもっともよろしいのではないでしょうか?
長々とお付き合いいただきありがとうございました。
流れ者
2003-06-17 23:14:44 ( ID:sys8jafxvjg )
[ 削除 / 引用して返信 ]
ご、ごめんなさい。
ZACKさんでしたね・・・。
流れてきます・・・・・
ZACK
2003-06-17 23:40:20 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
そういえばPegasysから返事が届いていました。結構まめに返答してくれています。
結論はデコーダーを変えてみるか、今年度中に予定されているTMPGEnc3(Mpegデコーダー内臓)をトライしたら、ということでした。Cyberlinkより新バージョンに投資したほうがいいかな、などと考え始めています。
鬼畜
2003-06-18 00:29:00 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
流れ者さん、検証ありがとうございます。
当方はCCEでの検証は出来ないので参考になります。
xxxさん、情報参考になります。流れ者さんの検証結果と合わせて見ると
平均化などの誤差の蓄積の方が原因のようですね。
ZACKさん、環境出来たみたいで良かったですね。
検証の中では触れませんでしたが、再エンコードを重ねたLigosでの画質は
見れたものではありませんので、流れ者さんの推奨するようにm2v.vfpを
お勧めしておきます。
また、CyberLinkは最新パッチを当てると使えなくなる等の問題があり、
今後のバージョンで使える保証もありませんので、お勧めできません。
どらさん、返事できなくて済みませんでした。
お使いの設定だと、私のテストの3に相当しますので問題無いと思います。
エンコード前後のヒストグラムを比較して、大きく変わっていないのなら大丈夫です。
ZACK
2003-06-18 21:28:59 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
このスレも最後になるかもしれませんが、UPしたJPGの輝度ヒストグラムを貼り付けましたので時間がありましたらご覧ください。目視ではオリジナルに近いのがm2vストレートでYCbCr出力したもの、及びm2v伸張でYCbCr出力にチェックなしのものでしたが、データもほぼそれを実証しています。
http://photos.yahoo.co.jp/zack03jp
もともとDVDを作成するなら初めからMTVで行えば良いのですが、私はプロレスが好きでたびたび最高ビットレート(15M)でキャプチャーしています。8Mですと動きの激しい部分でどうしても画質が悪くなってしまいます。ただし莫大な大きさのファイルが朝起きてみると出来上がっていますが。この中で残しておきたい部分だけ8Mで再エンコかけています。こんなことをやり始めている最中、気がついたので調べ始めました。
お付き合いいただいた皆様、大変ありがとうございました。
ZACK
|