07/05/28 22:21:20 ytNPdy9C
>>232のケースで理論的に正しいのは、ガンマ変換を行わない事だよね。
Y 16-235から0-255への変換とY 16-255から0-255への変換では、
単に明るさが2割違うだけだから。(ガンマ 2.2の場合)
Ａ．Y=16を黒(0),Y=235を白(1)にとる ガンマ 2.2のグラフ
Ｂ．Y=16を黒(0),Y=255を白(1)にとる ガンマ 2.2のグラフ
Ｃ．Y=16を黒(0),Y=235を白''(0.82509)にとる ガンマ 2.2のグラフ
Ｄ．Y=16を黒(0),Y=255を白'(1.21988)にとる ガンマ 2.2のグラフ
を描くと一目瞭然。
ＢとＣ(ＡとＤ)は同じグラフになる。
アナログ時代には白が『基準の白』で、白'は『より明るい白』だった。
でも、デジタルは黒から白の範囲しか表現できない。
家電では白''を『基準の白』にする事で、白で『より明るい白』を表現してる。
でも、PCで白''を『基準の白』にすると、全体的に暗い映像になってしまう。
なぜなら、PCの標準では白が『基準の白』だから。
だから、『基準の白』を白''にするのが正攻法なんだけど、これが難しい。
もしも動画再生がオーバレイだけなら、通常画面をオーバレイより2割暗くして、
通常の白(1')とオーバレイの白''を同じ明るさにする方法が使えるかもしれない。
もし232が、『基準の白』を白(1)のまま16-255をフルに使い画面が暗くならない
方法を求めているなら、232自身の感性を信じて試行錯誤するのが良いと思う。
正しい映像だと「暗くて使い物にならない」のなら、後は好みの問題だから。
251:名無しさん＠編集中
07/05/29 00:39:04 JTzPshyt
>>242
そのHDTVって16未満はそれ相応に表示されるの？
表示されるなら単にストレート変換になるけど。
てかさ、0-255じゃほんとはだめだよ。1-254でないと。
252:名無しさん＠編集中
07/05/29 02:08:48 FHHidpBJ
>>249
TVだと表示デバイス側で出来るけど、PCモニタだと無理だよね。250氏が的を得てる感じだな。
>>251
HDTVだろうがなんだろうが、基本的には16未満は表示されなくてOK。
0と255はアナログ時代だと同期信号だけど、デジタル時代だと問題ないよ。
デジタルで0と255入力しても内部で問題あるなら0と255は自動的にクリップされる。
253:名無しさん＠編集中
07/05/29 02:24:57 FHHidpBJ
>>250
>Y 16-235から0-255への変換とY 16-255から0-255への変換では、 単に明るさが2割違うだけだから。(ガンマ 2.2の場合)
つまり16-255から0-255変換の方が2割暗いって事だよね？2割明るくするってどのくらいのガンマなの？
ってことは、16-235から0-255のYC伸張と16-235のストレート変換でも明るさが違うって事？
254:250
07/05/29 22:51:44 OSQe9dkn
>>253
＞つまり16-255から0-255変換の方が2割暗いって事だよね？
そう、最大輝度が2割違うだけ。
相対的な階調は正しく保たれている。(カラーの場合は、色相と彩度も)
＞2割明るくするってどのくらいのガンマなの？
そんなガンマは無いよ。
あえて答えるなら、1.0～0.0のどこか。(元の映像によって異なる)
好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。
＞16-235から0-255のYC伸張と16-235のストレート変換でも明るさが違うって事？
それは当たり前の事かと。
ストレートだと暗い部分(Y 16-113)は明るくなるし、明るい部分(Y 114-255)は暗くなるのだから。
画像全体でどうなるかは画像次第。
255:名無しさん＠編集中
07/05/30 02:24:25 ftvRBIkp
>>254
＞＞好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
＞＞暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。
俺もガンマ0.9は結構悪くないかも。正確に計算する方法が分かればいいのだが。
＞＞画像全体でどうなるかは画像次第。
画像次第というのはどんな変換でも当たり前だけど、0-255変換と16-235変換は平均的には
画像全体で見た場合は同じ明るさじゃないか？
256:250
07/05/31 00:56:15 RTVARtYE
>>255
＞正確に計算する方法が分かればいいのだが。
白の輝度が480cd/m2の時と同じ画面を白の輝度を400cd/m2に落とした状態で出したい、
必要な補正はなに？
質問がこんなシロモノだと、幾つかの考え方を紹介するのが関の山かと。
ex. 何も補正しない
ex. ガンマ 0.9付近で補正
ex. 16-255ではなく16-245を採用する(暗くなる量を1割に減らす)
ex. 218-255を218-235に押しこんで16-235範囲を使う(Y 16-218を同じカーブに)
＞画像次第というのはどんな変換でも当たり前だけど、0-255変換と16-235変換は平均的には
＞画像全体で見た場合は同じ明るさじゃないか？
殆どの場合にそう扱って問題無いと思う。でも、今回は違う。
16-235範囲のみで構成される全ての画像は、16-255変換で16-235変換時より2割暗くなる。
全ての画像が必ず2割暗くなる。
この変換との比較だったので、画像次第で結果が変わるという答え。
257:名無しさん＠編集中
07/05/31 15:51:56 TgR+YRvz
>>256
なんかややこしくなっているだけの気が。
用はストレート変換の時の16-255の範囲のデータを0-255にリニア変換した場合、
黒の方向に引っ張られるから全体的に暗くなるのをガンマ補正で全体的に明るさを
引き上げて元の画面の明るさに近づけたいという趣旨なんでは？
＞16-235範囲のみで構成される全ての画像は、16-255変換で16-235変換時より2割暗くなる。
16-235範囲のみってのは今の話の筋からするとずれていると思うよ。
あくまでも16-235のストレート変換 + 236-255範囲をそのまま保持なんでは？
2割暗くなるっていう数字の出所が分からん。
258:250
07/06/01 23:35:42 0L7wCrzw
>>257
2割という数字の出所か。それは気がつかなかった。
それじゃ、16-235範囲のみが話の筋からずれていると思うのも当然だね。
たぶんだけど、分らなくても特に問題は無いよ。
論理や計算で答えを求めるという選択肢が消える程度だから。
259:名無しさん＠編集中
07/06/02 04:05:02 kvVZTR3G
>>258
ストレート変換の状態16-235[0-15と236-255はクリップしない]と、
その内の16-255を0-255にリニア変換した場合の明るさの違いの話じゃないの？
260:250
07/06/03 12:22:53 sQJkgEcx
>>259
なぜ、ストレート変換を16-235と表現するの？
261:名無しさん＠編集中
07/06/03 12:43:23 gJ8zyvVr
きっと色空間って概念を全く理解してないからだよ。
262:名無しさん＠編集中
07/06/04 15:15:44 hSQLv5Js
>>260
慣例でしょ？ググってもストレート変換を16-235と表現している方が多いし。
それに259氏は実際に"[0-15と236-255はクリップしない]"と注釈まで付けているじゃん。
てか250氏、揚げ足取るよりも>259が指摘した16-255を0-255とした場合の明るさの違いという指摘の方が大事かと。
263:名無しさん＠編集中
07/06/25 14:12:49 Nq6UpP7a
PS3とかXbox360の最新ファームで設定できるようになってるやつって16-235と0-255の切り替えだよね？
でもXbox360には3種類の設定があってその中間みたいなのが選べるみたいだけど、あれってなに？8-245とかには見えないけど。。。
264:名無しさん＠編集中
07/07/04 15:59:13 +Vx8B1ax
すげえどうしようもない意見なんだけどいいかな。
0-255ストレート表示にして、16以下が真っ黒に見えるようディスプレイを調整すればいい。
たぶん、これがテレビの人の考え方だと思うんだ。
リビング視聴を考えると明るい部屋だから16以下の階調はわからないと思うんだよね。
今のテレビなら16以下でもちゃんと見えるはずなのに、235以上は使うけど
16以下は使ってないことの理由だとも考えてる。
んで、ホームシアターなんかの暗い環境で視聴する場合でもそういう調整にすれば見るだけなら問題ない。
問題になるのは視聴と作成を同じ機器で行おうとする場合と
視聴以外の用途で同じディスプレイを使用する場合。
つまりPCでの使用ね。
これの対策としてはディスプレイに16-255表示用、0-255表示用の二つのプロファイルを作って適宜切り替える。
16-235用のプロファイルも作ってもいいかもね。
んでPC内部では全て伸張無しの0-255ストレートで演算させる。
265:名無しさん＠編集中
07/07/04 20:57:11 wTmbV+oG
> PC内部では全て伸張無しの0-255ストレート
なんだこりゃ
266:名無しさん＠編集中
07/07/04 21:26:18 AHrIg2p1
γが1.0って事じゃねえの？
267:264
07/07/04 22:33:10 HCA1FGWW
ああごめん、その部分は一切伸張等の変換処理をしないって意味で書いた。
改めて簡単に言い直すと、
今まではほとんど16-235の範囲内しか使われてなかったから当然のように0-255へ伸張してたけど、
それが16-255まで使われることもある現状では伸張は行わずに出口(ディスプレイ)で
辻褄を合わせたほうがいいんじゃないかってことね。
268:名無しさん＠編集中
07/07/05 05:02:09 ZZqUKEfW
それはフルスクリーンで、かつ、ビデオ画面のみが表示される場合のみ使える方法。
例えば16-235のストレートを使う場合、ディスプレイで0-16を丸めるとすると、Windowsデスクトップ上の0-16はどうする？
さらにメディアセンターみたいにCGとビデオをミックスする場合はCG部分が0-255だからディスプレイ側で0-16を丸めるとCG部分がおかしくなる。
結論としてはディスプレイ側でどうにかするのが間違っている。ディスプレイはいつも0-255のフルスケールで設計されるべき。
ではどうするか？
ビデオ画面の16-255を0-255に変換し、WindowsデスクトップやCGの0-255とミックスしてから0-255に調節されたディスプレイに表示する。
これがベスト。
それまでは残念だけど16-235を伸張するのが無難。235-255は見えなくても文句を言う人は少ないけど黒が16になると文句を言う人が多いから。
269:名無しさん＠編集中
07/07/06 01:35:49 mFQXzn6S
>>268
これがこのスレのFA？もうこれ以上はこのスレで議論する話もないかな。。。
270:名無しさん＠編集中
07/07/08 07:01:08 wBtlNGR6
このスレでアニメの話して良いのかわかんないけど、
ウミショーって
>>221
に書いてある見たな、
２３５より上の輝度入ってる？
271:名無しさん＠編集中
07/07/09 17:35:39 ZUP50VT4
>>270
DVD?TV?何の話だ？
235より上が入っていても構わない、ただし、それを受け手が表示するかどうかは受け手次第。
逆に、16より下は入っていても構わないが、受けては表示しちゃだめ(もしくは見えないように調節する)。
272:名無しさん＠編集中
07/07/14 21:49:39 cJSPtMDN
>>250 くらい的確な説明が出来る人が理解してる人。
273:名無しさん＠編集中
07/07/14 21:50:51 cJSPtMDN
>>240
頭がかたい
274:名無しさん＠編集中
07/07/15 00:47:00 pI+Mwr6R
16より下を表示しちゃいけない理由がわからないんだけど、
なにか規定があるのかな。
275:名無しさん＠編集中
07/07/15 00:55:40 0Y65Ku51
0と255は同期信号だから使っちゃ駄目ってのはどっかで読んだ
276:名無しさん＠編集中
07/07/15 02:49:12 lN1LHNiQ
>>274
歴史的には、白黒テレビ放送の規格まで遡る。
モニタ調整用信号には黒の調整用に -4%,0%,4% IREの信号が含まれている。
表示側はこれを使い、-4%と0%が区別出来ない，0%と4%が区別出来るように調整した。
この-4%,0%,4%は、それぞれY 8,16,24に相当する。
だから、Y 8と16が区別できたり、Y 16と24が区別できなかったりするのは単なる調整不良。
12と16が区別できたり16と20が区別できない程度なら許容される誤差だけど、
厳密に調整した状態では16未満と16は区別出来ないのが正しい。
277:名無しさん＠編集中
07/07/15 11:53:31 p9uHdJj3
>>275
0-255を直接アナログに変換した場合の0と255にあたるアナログレベルの場合な。
デジタルでは0と255は存在しても構わないし、実際にPCでは表示する。
278:名無しさん＠編集中
07/07/15 14:18:31 pI+Mwr6R
>>276 そんな古い慣習を今まで引きずってるのねえ。
その比率だと16-215が0-100%になるけど実際は16-235だから実際には
1%あたり2.2の計算になるのかな。
なので0-255だと-7.27%から109.09%までの範囲になるような。
んで現在はそのマイナス部分は表示しちゃいけないけどプラス部分は表示してもいいし、
実際に使われてるソースもあるってことなのね。
279:名無しさん＠編集中
07/07/16 14:57:15 4aVb+cno
0-15はデータに入っててもいいけど、表示側は見えないように調節しておいて欲しい。
236-255はデータに入っててもいいし、表示側は出来れば見えるようにがんばって欲しい。
ってのが建前。
あとは結果は受け手次第のベストエフォート型。
280:名無しさん＠編集中
07/07/19 21:24:24 bEE+yokE
質問なんですが、最近BDのAIRというアニメをリップしはじめたのですが
元々BT.601の480iのSDのアニメであり、これがBD収録時にBT.709の1080iのHDにアップコンバートされているのですが
もし、再エンコードで720pにする場合、ColorYUY2でBT.601に変換するのが正解なのでしょうか？
HDTVの規格では720p以上はBT.709が正解だとは思うのですが、
BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
BT.601に変換してからDVD版と色を比べるとDVD版に色が近いので、わからなくなっています。
現在はm2v.auiを使い、BT.709のままYUY2読み込みをしています。
281:名無しさん＠編集中
07/07/19 22:41:47 0DeyL2E3
それはもう、好きなほうをとしか言えない気がする。
HDデータはBT.709でしか再生できないってなら別だけども。
再生できないというか709として再生されてしまうということね。
なので601でエンコしてそれを709プロファイルで再生した場合にどうなるか
逆に709のものを601で再生した場合にどうなるか
ってのも考えに入れておいたほうがいいかもしれない。
んま、ソースが709なのが明らかなら709のままエンコしたほうがいいとは思う。
エンコ時と再生時で二重に変換されるのが防げるし、PC再生ならその差異を埋める設定もできるし。
282:名無しさん＠編集中
07/07/19 23:04:36 dRxMo2eW
もともとRGBのデータをBT.709のYUVで保存したものがあるのですが、これをできるかぎり
元のRGBに近い状態にするにはどのような変換式を使えば良いのでしょうか？
283:名無しさん＠編集中
07/07/19 23:20:19 bEE+yokE
>>281
なるほど。
たしかに、BT.709でエンコードしたものをavsで読ませて
ColorYUY2(
\levels="709->601",
\opt="Y:16-235 UV:16-240",matrix="rec709s",
\debug=0, interlaced=false)
みたいにフィルタを通して変換させながら再生させる手もありますね。
でも、逆に601を709に変換して読ませる方法は何かありますか？
avisynthのフィルタに見あたらなくて…
284:283
07/07/19 23:28:07 bEE+yokE
あと、ソースがBT.709なのは明らかだと思います。
m2v.auiでソースを維持、BT.709、BT.601をそれぞれ選び、
それぞれAviUtlで読み込み、フレームをBMPで保存して見比べたところ
ソースを維持とBT.709はまったく同じ色でした。
他に方法があるのかもしれないですが、もっと楽なやり方があるなら笑ってやってください。
285:名無しさん＠編集中
07/07/20 00:06:15 0DeyL2E3
これでいけない？
URLﾘﾝｸ(avisynth.org.ru)
ファイルはこれね
URLﾘﾝｸ(avisynth.org)
再生確認だけならMediaPlayerClassic HomeCinemaとHaali Renderer(Haali Matroska Splitterに同梱)の
組み合わせで簡単に切り替えができるんだけどね。
Haali Rendererがデコーダを選り好みするからちとアレだけども。
ffdshowと組み合わせればまず再生はできるかと。
286:名無しさん＠編集中
07/07/20 00:07:35 0DeyL2E3
間違えた。
Haali Matroska SplitterじゃなくてHaali Media Splitterだった。
287:名無しさん＠編集中
07/07/20 00:14:37 ddO/yq+C
>>280
質問の中によく解らない部分がありましたので、よろしければ教えて下さい。
＞BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
＞BT.601に変換してからDVD版と色を比べるとDVD版に色が近いので、わからなくなっています。
の部分です。もしも、
１．BD版(BT.709)をBT.709用データとして色空間Xで再生
２．BD版(BT.709)をBT.601へ変換してからBT.601用データとして色空間Xで再生
３．DVD版(BT.601)をBT.601用データとして色空間Xで再生
を比較したならば、１と２は同じ色ですよね。(２と３が同じなら１と３も同じ筈)
そうなっていないという事は、
ａ．BD版(BT.709)を色空間X用データとして色空間Xで再生
ｂ．BD版(BT.709)をBT.601に変換してから色空間X用データとして色空間Xで再生
ｃ．DVD版(BT.601)を色空間X用データとして色空間Xで再生
のような条件で比較されたという事でしょうか？
288:283
07/07/20 01:34:28 hMZV6A4v
>>285
colormatrix、いけそうですね。試してみます。
今初めて、HomeCinemaの存在を知りました
えーと切り替えとは709で再生するか、601で再生するかを選択できるということですか？
できたら説明お願いします。
>>287
あ、色々紛らわしくさせてしまったみたいですね。
基本的に再生時の色で見たのではなくて、
m2v.auiを通して変換させてAviUtlのプレビューを使っています。
ようするに、
まずDVDのVOBをm2vconf.exeを使いBT.601、BT.709、元データ維持を3回設定しなおして
AviUtlでYUY2で読み込み、それぞれの設定で３回読み込ませ、毎回同じフレームをBMPで保存して
すべてを比較します。
次にBDのm2tsをmpgとして同じように3回設定しなおして
AviUtlで３回読み込ませ、すべてBMPで保存して比較しました。
その結果、DVDのBT.601、元データ維持が同じに近い色でした。
ただ、これはBDのほうは変換していると思われ正確にイコールなのかはわかりませんでしたので、「に近い」と表記しました。
DVDのBT.709と、BDの元データ維持、BT.709もほぼ同じでした。
m2v.auiは指定した色空間行列と元データが同じならば何も変換しないそうなので、BDはBT.709と判断しました。
DVDのBT.709はBT.601から変換されているため「ほぼ」としました。
比較方法、間違っていましたか？なら正しい方法を教えていただければその方法で比較したいと思います。
少なくとも、BDソースはBT.709であり、DVDソースはBT.601であることは間違い無いと思うのですが。
289:名無しさん＠編集中
07/07/20 20:07:19 X60N8DXO
>>288
切り替えはそれであってる。
参考用に画像撮ってみた。
URLﾘﾝｸ(www.uploda.net)
ソースはここの動画。
URLﾘﾝｸ(www.gran-turismo.com)
赤はすげえ変わるねえ。
記憶色やシーンは冬ですと言われれば601が正しいように見えるし、
ナチュラルさやシーンは春夏ですと言われれば709が正しいように見える。
290:名無しさん＠編集中
07/07/20 20:09:49 X60N8DXO
ああ、ここ直リンできないのか。
こっちで落として。
URLﾘﾝｸ(ud.gs)
291:287
07/07/20 21:52:33 ddO/yq+C
>>288
詳しい説明ありがとうございます。
＞BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
の「色が違う」は、「BT.709用の画像(BD)をBT.601プロファイルで表示したものと、
BT.601用の画像(DVD)をBT.601プロファイルで表示したもの」の色が違うだったのですね。
・BDソースはBT.709，DVDソースはBT.601
・m2v.auiはYUY2データを出力する、出力色空間はBT.601/BT.709を選択可能
・AVIUTLはYUY2データを受け取るが、色空間は(常に)BT.601(準拠)として扱う
292:名無しさん＠編集中
07/07/21 01:11:04 X9tNrxTT
>>291
709は709で変換しないとおかしくなる。
SD時代の古めのソフトは601専用な事が多いからなHD時代だと基本は709だから量対応が必修。
293:288
07/07/21 02:48:01 /2A9wEhM
>>289
設定画面が違うと思ったら
どうやらHaali Media Splitterが古すぎたようです
こんな便利な手段があるんですね。教えてくださって感謝です。
>>291
AviUtlってBT.601として扱っていたんですね…
一つ聞きたいのですが、例えばBT.709のままでAvisynthにてx264にエンコードをします。
それをMPCでVMR7とCoreAVC(YV12)で再生した場合、
BT.709として扱ってもらえているのでしょうか？
GPUのVMRCCCSStatusは3で伸張されていると思いますが、これがBT.601ならどうしようもないのかもしれませんが。
Media Splitterを使えば確かにBT.709で取り扱い、伸張もできますがオーバーレイと違い
モニタが正確にキャリプレーションされていないと確認する環境によって差が出てしまうと思うので
できればVMR7を使いBT.709のソースをBT.709として、扱い再生する環境を作りたいのですが
どのソフトを使えばよいでしょうか？
294:288
07/07/21 02:52:13 /2A9wEhM
MPCはHomecinema 1.0.8.0です。
295:名無しさん＠編集中
07/07/21 17:00:44 X9tNrxTT
>>293
確かXPのVMRとかVMR9ってBT.601専用だったと思う。
VistaのEVRはBT.601とBT.709の両方対応していたと思うよ。
296:名無しさん＠編集中
07/07/22 12:44:58 o66TfgWH
>>295
確かにVistaだとBT.601とBT.709に対応しているみたいだけど、まだドライバーが安定してないっぽい。
297:288
07/07/24 21:39:06 7OcExHVO
>>295
そうですか…XPだと駄目ですか。
XPでVMR7を使って再生するならBT.601に変換させてしまった方が正しい色でみれるのかもしれませんね。
vistaのEVRでは、XPのVMR7のようなオーバーレイの概念が無くなってしまったということは、
GPUのデスクトップの色設定などが、たとえ動画を伸張再生したとしても、VMR9と同じように動画の色にも連動してしまいますよね？
そうなると、動画再生するディスプレイでも常に正確な色設定をして、そのディスプレイを買い換える毎に正確な色設定をするしかないんでしょうね…
EVRはストレートで、RADEONならドライバで伸張できるみたいですが、
あれはレジストリの項目の通り、ソースに関係なくBT.601扱いで伸張しますよね？
だったらVistaだとドライバで伸張するより、どちらかの色空間行列のソースであるかが指定できて
それに合わせて伸張の有無を選択できるHaaliMediaSplitterのレンダラを使うほうが、
正確な色でみれるということになりますが正しいでしょうか？
298:名無しさん＠編集中
07/07/25 16:48:59 w2mWqxNb
>>297
うーん、正しそうなところもあるけどそうじゃなさそうなところもある。
私が知りうる限りを列挙すると、
XPドライバーやVMR7・VMR9の場合、BT.601かBT.709を決めるのはドライバー。
大抵のXPドライバーは画像の高さでBT.601かBT.709を決める。例えばHD解像度だとBT.709とか。
デスクトップの色設定するとVMR9やEVRの色も連動する。ただし、Vistaドライバーの場合はさらにそれとは別に色空間変換専用の色設定を持っていることが多い。
本来はBT.601とYC伸張はまったく別の話。
EVRはDXVA2を使い、DXVA2を見るとBT.601・BT.709、YC伸張あり・なしをパラメーターで渡せるようになっている。
アプリかEVRのどちらかでパラメーターを指定できるはずだけど、公開していなければお手上げ。
299:名無しさん＠編集中
07/07/26 22:10:33 MZsf6d0Q
>>298
ドライバーとはGPUのドライバーのことですよね？XPドライバーとVistaドライバーとはオーバーレイとEVRのことですか？
>XPドライバーやVMR7・VMR9の場合、BT.601かBT.709を決めるのはドライバー。
>大抵のXPドライバーは画像の高さでBT.601かBT.709を決める。例えばHD解像度だとBT.709とか。
ということはXPでもBT.709がBT.709のまま再生できるということですよね。
となると、VMR7再生するならはBT.709ソースはBT.601へ変換しないほうがいいのかな…
XPだと標準状態でHDソースを見ると、強制的にBT601に変換されてYC伸張されて再生されるのかと、本気で落ち込んでいましたので助かりました。
>ただし、Vistaドライバーの場合はさらにそれとは別に色空間変換専用の色設定を持っていることが多い。
これは、オーバーレイ時のようにデスクトップ設定が反映されないわけではなく
デスクトップの色設定の環境に応じて、正確な色に変換する機能がある、ということで良いのでしょうか？
まとめると(再生色空間はソースと同じとする)
XPのオーバーレイ、VMR7
480pBT.601ソース→BT.601とドライバーが解像度にて判断→オーバーレイ伸張して表示
720pBT.601ソース→BT.709とドライバーが解像度にて判断→オーバーレイ伸張して表示
XPのVMR9
480pBT.601ソース→BT.601とドライバーが解像度にて判断→UseBT601CSC=0かゲフォなら伸張せずに表示
720pBT.601ソース→BT.709とドライバーが解像度にて判断→UseBT601CSC=0かゲフォなら伸張せずに表示
VistaのEVR
480pBT.601ソース→ユーザーがBT.601と伸張ありとアプリかEVRで指定→DXVA2にパラメータが渡される→EVRはその情報を元に表示
720pBT.601ソース→ユーザーがBT.601と伸張ありとアプリかEVRで指定→DXVA2にパラメータが渡される→EVRはその情報を元に表示
と、なると思うのですが、EVR自体に伸張する設定があるということは、
対応するアプリがあれば、GPU側は伸張しなくていいということですよね？
300:名無しさん＠編集中
07/07/27 02:46:34 SSg9HlZy
>>299
>ドライバーとはGPUのドライバーのことですよね？
そう、ビデオカードのドライバー。
>XPドライバーとVistaドライバーとはオーバーレイとEVRのことですか？
そうとは言い切れない。どっちのドライバーでもVMR7使えばオーバーレイを使えるし、XPドライバーでもEVRは使える。
ドライバーとレンダラーは別。実際にはレンダラーがドライバーの違いを吸収してくれる、が、完璧ではない。
>ということはXPでもBT.709がBT.709のまま再生できるということですよね。
出来るけど、デコーダーのBT.709の情報はドライバーには届かないからVMRを使ったときの動作は不定。
>となると、VMR7再生するならはBT.709ソースはBT.601へ変換しないほうがいいのかな…
将来的にVistaとかで同じファイルを再生したいのならそのままの方が良いだろうね。
XPだとドライバーの挙動に合わせて変換するしないが必要かも。ただし、それは保存用としてじゃなくて一時的な再生専用。
>デスクトップの色設定の環境に応じて、正確な色に変換する機能がある、ということで良いのでしょうか？
ちょっと違う。
XP : デスクトップ・オーバーレイは個別に設定。お互いに影響は受けない。
Vista : デスクトップ・オーバーレイ・DXVA2は個別に設定。ただし、DXVA2からの出力はさらにデスクトップの設定の影響を受ける。
>まとめると(再生色空間はソースと同じとする)
合ってそうだね。
>対応するアプリがあれば、GPU側は伸張しなくていいということですよね？
伸張する・しないはGPUが行う。それを指示するのはアプリ(EVR)の役目。
301:名無しさん＠編集中
07/07/27 05:29:16 VbhM82UL
最近変なのが住み着いたんだね、このスレ
302:名無しさん＠編集中
07/07/28 02:06:51 kpavWSQ5
>>301
ん？>280のことか？
303:名無しさん＠編集中
07/08/03 16:05:35 Nzw2XfB2
PCをHDMIでフルHDのTVにつなぐ場合、PCではYC伸張するべき？しないべき？
VistaにCatalyst 7.7入れたらYC伸張しなくなった、これはバグ？それとも仕様？
304:名無しさん＠編集中
07/08/06 13:00:24 CbFoNtus
>>303
たぶんね、もうDisplayPortが出ないとどうにもならないかも。
HDMIって家電用のガチガチ企画っていうし。
305:名無しさん＠編集中
07/08/08 02:28:08 YNaqckaG
709 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:48:02 ID:???0
704x396 24Bit DivX 5.x 23.98fps 34881f 750.63kb/s
704x396 12Bit XviD MPEG4(XviD0047) 119.89fps 174450f 722.59kb/s
^^^^^^^
の12・24Bitって、普通に違いは理解できるものなのか？
714 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:55:00 ID:???0
>>709
256色と6万色の差を見分けられるなら理解できると思う
717 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:56:42 ID:???0
やっぱ24Bitのほうがいいのか？てか、見れりゃあいいか。
721 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 02:01:41 ID:???0
>>719
1677万色(24bit)
256色(8bit)
かｗｽﾏｿｗｗｗ
306:名無しさん＠編集中
07/08/08 03:25:49 D2kdxwUa
見慣れたYV12での24ビット騒動か
307:299
07/08/09 18:41:00 z8uLSEhi
>>300
返信が遅れてしまって申し訳ありません。
>そうとは言い切れない。どっちのドライバーでもVMR7使えばオーバーレイを使えるし、XPドライバーでもEVRは使える。
>ドライバーとレンダラーは別。実際にはレンダラーがドライバーの違いを吸収してくれる、が、完璧ではない。
なるほど。
>出来るけど、デコーダーのBT.709の情報はドライバーには届かないからVMRを使ったときの動作は不定。
>将来的にVistaとかで同じファイルを再生したいのならそのままの方が良いだろうね。
>XPだとドライバーの挙動に合わせて変換するしないが必要かも。ただし、それは保存用としてじゃなくて一時的な再生専用。
うーん…結局は、気にする人は動画再生はVistaで、編集はXPと二台用意するのがベストで
作る動画は色空間行列がそのままのものと、変換したものを二種類作成しておくしかないようですね。
>ちょっと違う。
>ただし、DXVA2からの出力はさらにデスクトップの設定の影響を受ける。
なるほど。理解しました。
>伸張する・しないはGPUが行う。それを指示するのはアプリ(EVR)の役目。
なるほど。それはVMR9の伸張と同じくGPUのドライバが対応しなければ、不可能であり
ラデの最新ドライバは、Vista用のドライバでもVMR7、オーバーレイとVMR9の伸張にしか対応していないので伸張できていない、
ということでよろしいでしょうか？
308:名無しさん＠編集中
07/08/10 01:53:43 BNucx8Ny
>>307
ラデスレによるとラデの最新ドライバはかなりおかしいみたいだよ。
7.6まではオーバーレイ、VMR9とEVRは伸張ON。
7.7ではオーバーレイが伸張ON、VMR9とEVRは伸張OFF。
309:名無しさん＠編集中
07/08/16 16:17:10 +STcBzPQ
>>308
ラデスレより
ｽﾚﾘﾝｸ(jisaku板:337番)
310:名無しさん＠編集中
07/08/22 00:47:30 Tr6RwzoJ
>>309
ゲフォ用の設定もよろしこ
311:名無しさん＠編集中
07/08/29 17:48:43 or3/ZWgR
で、YC伸張するのしないのどっちよ、このスレ的には。
312:名無しさん＠編集中
07/08/29 18:05:40 87P8S1R8
バカ来た
313:名無しさん＠編集中
07/08/30 00:02:16 ZMFJt0vs
伸張するしないとは無縁の世界を構築せよという結論ですよ。
314:名無しさん＠編集中
07/08/30 17:12:54 G2FzpI0C
>>312
じゃああんたはどっち派よｗ
YC伸張する ノ
315:名無しさん＠編集中
07/09/09 07:15:43 P4fPphGz
EVR DShow Vista
Vistaから使えるEVRですが、DirectShowから使う場合について少し調べてみました。
（EVRはXPでも.Net3.0を入れると、一応DLLが入りますが、登録しても使えません）
これまでのDShowでは、YUVからRGBに変換する場合のマトリクスや、伸張するかどうか、などを
明示的に設定する仕組みが標準では存在しませんでした。
EVRでは、このあたりをどうにかできるという噂を聞いたので、調査してみました。
まず、EVR自体とピンが提供するインターフェースを見てみましたが、
それらしきものはありませんでした。
そこで、ふと、VIDEOINFOHEADER2の解説を見てみると、変更点がありました。
（おそらく Windows SDK for Vista 以降）
予約領域の一部を DXVA_ExtendedFormat とみなすようにしたようです。
さて、実際にこの設定が反映されるかを試してみました。
Vista＋GF7300GS(v162.22)では、EVR使用時のみ効果があり、かつ変換マトリクス指定だけが
反映されているようです。
VMR7/VMR9（YUVミキシングモード含む）およびXPではまったく無視されるようです。
どいうわけで、DXVA2フィルタと同じく、Vistaでしかまともに使えないという感じです。
あと、この実験の過程でedvdec.axに上記のパラメータの追加機能を付けてみました。(v0.9.9)
デフォルト値は適当なので、いろいろ試してみてください。
316:名無しさん＠編集中
07/09/09 17:17:44 +XcDO3KJ
>>315
GJ!
EVRはDXVA2を使うはずですからそのお陰でマトリックスや伸張を指定できるのではないでしょうか？
DXVA2はVistaドライバーでしかサポートされていないはずですからXPだと機能限定なのもうなずけます。
ところで当方だとXP上でEVRが使えました。
317:名無しさん＠編集中
07/09/09 18:43:27 ivsYzh/O
ｨｸ
__,､ | | くﾆ} {fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj
i''i;｣. 'ヽｰ' ､
くﾆ} {fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj
//｀`ヽ／/｀`'''''''ヽ
〈;i' ｀`> ヾ｀`i l
/ ／ {二)
ヾ_')
318:名無しさん＠編集中
07/09/12 06:20:20 h+jsmPMQ
すいません少し疑問に思ったので質問させてください。
モンスターXでキャプすると基本的にYが0％は0、100％は255でキャプされます。
さらに付属のPIC MJPEGだと0以下と255以上は完全にカットされます。
で、放送自体はY0％-100％は15-235+αなので、+α部分が255オーバーになってしまいます。
削られる上限域を残そうとマニュアルでYを0-235と言う変則調整を思いついたのですが
この場合、Pb、PrもYと同様に0-235へした方が良いのでしょうか？
それとも15-235もしくは0-255なのでしょうか？
それとも「おめーのやっていることは無意味だろ！！」なのでしょうか？
319:名無しさん＠編集中
07/09/12 18:26:35 7UEThZyN
>>318
キャプチャー時に0-255に伸張されていて基準白が255になっているってこと？
それはキャプチャーデバイスがおかしいね。
基本はキャプチャー時は16-235で再生時に伸張して0-255。
0-235ってのもありだけど、ITUとかで定義されてないからあんまり誰もやりたがらないよね。
↑の方に色々とヒントになりそうなこと書いているけど。
320:名無しさん＠編集中
07/09/12 19:23:47 h+jsmPMQ
>>319
レスありがとうございます。
モンスターXの画像がなぜかコントラストが強かったので波形プラグインで色々調べてたらそうなってました。
D3キャプという特殊性からくるためかな？しかもカラーバー入れてオートゲイン働かせるとYゲインが基準よりデカめに調整されるので
ここでもコントラストがでかくなる要因があった。PV3はどうなってるんだろう。
321:名無しさん＠編集中
07/09/13 01:24:23 GUwd5cmM
>>320
コンポジットだろうとコンポーネントだろうとHDMIであろうと、DVI以外のときは入力は16-235でキャプチャーされるべきだね。
一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。
322:名無しさん＠編集中
07/09/13 02:05:52 8ugE1STt
>>321
＞一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。
モンスターXにおいてはこれはある意味仕方がないという気もするんだけど・・・
だってデコードの再チューナー側でYC伸張されたY0-255のアナログ信号をキャプるものなんだから、
素直ちゃ素直な仕様かなw
ただ後から加工や記録を前提にしているおいらたちから見れば、糞仕様と言われてもしょうがないんだよねぇ・・
とにかく、Pb Pr の答えも見つかりそうにないので0-235はやめて15-235でしばらくキャプって見ようと思います。
323:名無しさん＠編集中
07/09/13 14:45:34 GUwd5cmM
>>322
そもそもなんで途中か最後にRGBに変換してるんだろ？
ずっとYUVのままならYC伸張もなにもいらないのに。
324:名無しさん＠編集中
07/09/13 18:54:41 8ugE1STt
>>323
それって出力までTVで見なさいよってこと？
325:名無しさん＠編集中
07/09/13 21:24:44 /NoMQh50
グラボに直接YUVデータ流し込めば？
326:名無しさん＠編集中
07/09/13 21:50:24 uoV1Y7YI
>>323
勉強不足でおっしゃる意味がわからんのですが ＾＾；
とうぜん、エンコ自体はYUV（YUY2）で通してます。
RGBへ変換しているのはチェックのためにAVIUTL+波形表示プラグインで開くときだけです。
>>323さんがおっしゃるのは、BT709のまますれば？って言ってるんですの？
ちなみに、うちのGF7300ではYUV入れてもYC伸張して表示してくれないので
15-235ものは再生時に補正してます。
327:名無しさん＠編集中
07/09/14 00:42:13 0L3PidzA
波形表示はYC2のまま表示できるじゃん。
328:名無しさん＠編集中
07/09/14 00:51:18 Gooqaxlg
>>326
>とうぜん、エンコ自体はYUV（YUY2）で通してます。
ってことはどこで伸張されてるの？
だってYPbPr→YUY2なら伸張関係ないはず。
どこかにYUV→RGBがなければ輝度そのものはYPbPrのソースのままのはず。
329:名無しさん＠編集中
07/09/14 01:15:25 4FkTMcTk
書き方が悪いのかなぁ・・
キャプボのデフォが0-255でキャプされていて
それを変則Y0-235に調整した場合Pb、Prはどうしたら良いのかって事が元々の質問の趣旨だったんですが・・
330:名無しさん＠編集中
07/09/14 01:19:25 /oxrRaau
色差も0-255でキャプされんの？
331:名無しさん＠編集中
07/09/14 01:20:51 4FkTMcTk
そうです
332:名無しさん＠編集中
07/09/14 01:30:30 /oxrRaau
もうデフォで妥協したら？0-235と言ってもそのままじゃ使えないし、とは言え調整は容易ではないし。
333:名無しさん＠編集中
07/09/14 01:50:44 4FkTMcTk
調整自体は意外と簡単にできるので苦にはならないんですが ＾＾；
一応参考までに
URLﾘﾝｸ(www.borujoa.org)
334:名無しさん＠編集中
07/09/14 16:26:43 Gooqaxlg
>>329
>キャプボのデフォが0-255でキャプされていて
だからこれが糞だって。
IREレベルのYPbPrをデジタルのYCbCrにするときに白黒のリファレンスが16、235になるようにデジタル化するのが普通。
デジタル化されたときに既に0-255になってたら駄目駄目。
335:名無しさん＠編集中
07/09/15 02:08:22 nHDpgRGI
>>334
そうなんだけど、PV3のソース見たらこっちもデフォで0-255になってましたねぇ
モンスターXは一応プレビュー用と言うことで売ってますのでこれも仕様かとは思いますけどねw
ただ、モンスターXスレ見てても誰もこのことに言及してないのが不思議だな。
336:名無しさん＠編集中
07/09/15 03:15:50 qjkrcvQt
白黒リファレンスが16、235で調整されてて
それを超える範囲も一応記録してるんじゃまいか？
リファレンス以上の白黒範囲が存在して色がおかしくなる
機械やソフトは駆逐されたと思ったけど
古い物だと変な色に見えちゃう可能性があるかもしれん
337:336
07/09/15 03:21:00 qjkrcvQt
あ、何か勘違いしてるかも
聞き流して下さいな
338:名無しさん＠編集中
07/09/15 17:36:02 ZK57mHoD
>>335
揚げ足取るつもりはないけど。
プレビュー時にYUV→RGB変換を行うのはモンスターX？それともビデオカード？
ビデオカードならYC伸張されているデータをさらにYC伸張されてしまって黒と白が飛んじゃうよ。
だから、記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。
339:名無しさん＠編集中
07/09/15 19:06:15 +fRPOju3
>>338
YPbPr0-255での表示や記録をRGB変換というのが正しいのかというのはおいておいて、
（正確には色空間変換とかも絡んできますので）
プレビュー時のYC伸張はVGAの種類とドライバとレンダラによって変わってくるので一概には言えませんですし
何度も言うようですがモンスターXのデフォでは出力をYPbPr0-255を目標とした基準値になっているようです。
当然、キャプチャに回されるデータも0-255ですねぇ。
＞記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。
理想はそうかもしれませんが、現実再生時、VGAドライバレベルではYC伸張しないシステムも多数存在する訳なので
（うちのシステムそうです。たぶんこっちの方が多数派？でもそこから直せとは言わないでねw）
ケースバイケーかとは思いますけど・・・と言いつつ、今のうちの記録はHUFFYUV YPbPr 15-235 で記録してますけどね ＾＾；
340:名無しさん＠編集中
07/09/16 03:02:02 YFlcdrm9
>>339
でもDVD、HD DVD、Blu-ray、地デジ、一般に広まっているMPGファイル、WMVファイル、DivXファイル。
どれひとつとっても16-235に正規化された状態で記録されているけどな。
再生時のYC伸張するしないはオーバーレイと非オーバーレイの過度的な理由からでしょう。
Vistaでは伸張に関してもAPIで定義しているからドライバーが安定してくれば統一されてくるんのでは？
341:名無しさん＠編集中
07/09/16 07:57:46 Xe+cQNMU
0-255だと当然、16-235より綺麗なグラデーションになるからね
再縁故前提な設定な気がしないでもない
342:名無しさん＠編集中
07/09/16 12:41:51 YFlcdrm9
>>341
は？取り込むときにソースが16-235に正規化されているんだから
それを変換するときに0-255に伸張したらグラデェーションは変わらないか、
変換誤差のために16-235に変換するより劣るぜ。
0-255にする利点は標準黒と白をRGBの黒と白にマッピングできるということだけなんだが。
343:名無しさん＠編集中
07/09/16 15:50:57 QzOecP32
MonXのフルスケールが気に入らないならキャプった後に編集段階で修正するんではダメなのか？
キャプ段階でやるのとどういう違いが出るかは分からないが。
344:名無しさん＠編集中
07/09/16 18:13:15 uvDRGnda
楽しそうなので上げときますね
345:名無しさん＠編集中
07/09/17 03:03:05 RM/ZqUvR
>>343
キャップした段階で伸張されてしまっていたら0-15と236-255のデータがなくなってしまっているのだが。
0-15はまあ良いとしてもハイデフソースとかだと236-255は普通に使っている。
346:343
07/09/17 03:10:15 09CdCSIN
それは分かってる。そういうことじゃなくてボードがデフォで伸張してしまうのだったら
いくらMonster-X Setting Utilityで16-235になるように設定調整しても意味ないんじゃね？ってこと。
もしPV3もそういう仕様だったならなんで今まで話題にならんかったのが不思議な感じだ。
347:名無しさん＠編集中
07/09/17 09:16:33 vU02pj/E
>>346
意味はあるよ。ちゃんとモンXではY100％輝度以上も出力している。
モンX標準のPIC MJPEGの設定は100％以上と0以下は問答無用にカットされちゃうので
余計に意味が出てくる。
348:名無しさん＠編集中
07/09/17 14:56:35 09CdCSIN
なるほど参考になった。内部的にはどうなってるんだろう。
一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･
349:名無しさん＠編集中
07/09/17 15:51:26 RM/ZqUvR
>>348
もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
いずれにせよ0-255は取り込みようじゃなくてプレビュー用と思うけど。
350:名無しさん＠編集中
07/09/17 20:53:46 kX/QPJjZ
>>348,349
内部的にも何もそもそものデータがアナログ信号なんだから
A/Dがどの範囲でデジタル化するかって事だけでしょう。
351:名無しさん＠編集中
07/09/18 01:42:36 ZHyG5t9G
>>350
ずっとその話をしているんだがｗ
352:名無しさん＠編集中
07/09/18 02:22:13 X+S8a+zv
わかってないのがいるようだから
>>349
＞一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･
余計な工程なんてない。A/Dはただ単に決められた値と解像度で量子化しているだけ。
100％輝度が255と設定されたらそうしているだけ。235でも同じ。
>>349
＞もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
もともとのデータというのがTSデータのことならその通り。ただし一度アナログ変換されたものを戻すのにどこまで意味があるかは考え方次第。
353:名無しさん＠編集中
07/09/18 16:02:19 ZHyG5t9G
>>352
A/Dで16-235と0-255に選択出来るやつもあるが何か？
ようはどうでもいい話で、取り込み時は16-235にするでFAなんだって。
で、再生時に必要に応じて16-235と0-255を切り替える。
普通はPCモニターだから0-255に伸張するで正解。
354:名無しさん＠編集中
07/09/19 01:05:44 +0lVWOJu
>>353
>>352が書いている事に対して全然かみ合ってない気がするがw
結局おまえの考え方を押しつけてるだけなのねw
記録時にどのスケールで記録するかは>>352が言っているように人それぞれだろう。
だいたい記録した物を放送に乗っける訳じゃないんだから規格がどうのとか言っている方が陳腐。
一例としては16-235をRGBに伸張した場合、システムによってはグラデーションにムラができることがある。
実写ではソリッドなバックの光量の差によるグラデーションとかで確認できる。
235を255に延ばすんだから当たり前なんだけど、その辺を嫌って0-255で最初から記録することもありだろう。
だいたい、基準白より明るい白は表示できてもよっぽどでないと視覚的に見えないしね。
355:名無しさん＠編集中
07/09/19 06:09:31 0wjpfMMy
ちょっとお聞きしたいのですが、Haali Video Renderer の Luma range の設定と効果は、
TV ・・・ 素通し（無変換）、PC ・・・ 0-255 → 16-235 へ変換
でいいのでしょうか？ doom9 のフォーラムで書かれてたのとは違う結果なんですが・・・。
やりたいことは、データ（avi）の時点では 16-235 にしておいて、再生時に伸張したいんですが、
Haali だと伸張できてないっぽい（？）ので。（XP SP2、GeForece7600GT）
以下、やったこと。おかしいところがあったら指摘をお願いしたいです。長くてすみません。
1. MonsterX でカラーバーを MJPEG で録画（D3）して aviutl で読み込み。
2. YPｂPrゲイン調整フィルタで、output convert のみチェックを入れ、黒-白 を 0-255 に。
3. x264 で avi 出力。
4. 出力した avi を aviutl でフィルタなしで再度読み込み、黒-白 が 0-255 を確認。
5. Media Player Classic + Haali Video Renderer で再生。Luma rangeの設定を、
TV にすると、再生画面の 黒-白 が 0-255
PC にすると、再生画面の 黒-白 が 16-235 になる。Printscreen で確認。
ちなみに、aviutl で 黒-白 が 16-235 のファイルを作って同じように再生させると、
TV にすると、再生画面の 黒-白 が 16-235
PC にすると、再生画面の 黒-白 が 30-217 になります。
356:名無しさん＠編集中
07/09/19 17:55:27 Wtwyot7W
>>354
>0-255で最初から記録することもありだろう
ってことは基準黒のアナログレベルをデジタルの0、基準白のアナログレベルをデジタルの255にするって事？
つまり、16-235のデジタルを伸張して0-255にするんじゃなくて、アナログから一発で0-255のデジタルにするって事？
そんなのあんまり聞いたことないけど。。。
357:名無しさん＠編集中
07/09/20 03:15:46 fRgafxj8
>>356
＞16-235のデジタルを伸張して0-255にするんじゃなくて
エンコ時に0-255に伸張する人なら最初から0-255へ伸張するのも有りではと言うこと。
別にそれを人に推奨するつもりはないが、自分のシステムがどういう挙動をするのかわかっている人なら、
おかしな考え方でもないと思うがね。
358:名無しさん＠編集中
07/09/20 03:39:49 ptE2UkfB
うちではMonsterXの初期設定＆オートゲイン、オートオフセットONにすると
0％が0、100％が235でキャプチャされる（PIC M-JPEGで）。100%を超えるのは
235-255の範囲に入ってる。100%が255にはなってないみたいだけど。
359:名無しさん＠編集中
07/09/20 04:10:13 Xs8FzPgb
うちのもhuffyuvで、ほぼそんな感じ。1個前のドライバにて。
360:名無しさん＠編集中
07/09/20 06:08:48 2d42orMe
入力機器によって違うのかもね。
AG、AO入れてるとうちでは（RD-E300）Y-0%は0 Y-100%は255以上になるなぁ・・
少なくともゲインだけは弄らないとコントラストがつきすぎる。
361:名無しさん＠編集中
07/09/20 14:12:29 c/y0B0Ek
>>358
AGとAOって結構賢いんだな。0-235なら完璧じゃね？
362:名無しさん＠編集中
07/09/20 19:23:18 A9uhv/26
>>361
カラーバー入れている限りはAG,AFは結構かしこいよ。
ただ、普段の映像を入れてどうかは別問題。
つか、0-235で完璧って・・・・＾＾；
>>358,359にはその時のPbPrの色差100%と-100%の値はどうなっているか教えて欲しい。
363:358
07/09/20 19:38:38 lWsziCi4
>>362 カラーバーでなら、PbPrの色差100%と-100%の値は読めるかもですが
通常の映像ではどうやって読んだら良いですか？
通常の映像での Y100％ は番組提供のテロップとか、時刻表示の文字などが
該当するかと思うんですが、それらも概ね235に合っているようです。
364:名無しさん＠編集中
07/09/20 21:34:33 1UPYTeI8
ならカラーバー入れてみてくださいな。
オートだから当然入力画像によってゲインやオフセットが上下するんだからw
普通0%輝度がY0になってるんなら、100%輝度は255が標準ですよ。
上の方で意図的に0-235にするとどうなるかって事を言ってた人もいたけどね。
365:358
07/09/20 22:10:08 ptE2UkfB
URLﾘﾝｸ(www11.axfc.net)
monx
カラーバーの録画ファイルと MediaPlayerClassic で再生した画面を取り込んだものをアップしてみます。
MonsterX 標準ソフトで録画、オートゲイン、オートオフセットどちらもONです。
思うに、MonsterX では HD 映像で使われている範囲（0%～100%+α）を 0-255 に割り当てているのかな、と。
それが正しいかどうかはともかく。
366:名無しさん＠編集中
07/09/21 02:16:17 K8jsJkUS
>>365
HD素材なら基準黒を0、基準白を235でαの部分のいわゆるスーパーホワイトを236-255にするのが良いかと。
367:名無しさん＠編集中
07/09/21 06:53:58 oDo/VOx9
>>366
なんで0-235なの？？
その際のPbPrはどっちに合わすの？
368:名無しさん＠編集中
07/09/21 07:11:16 oDo/VOx9
>>365
Y0-235になってるねぇ・・・うちではデフォのAG、AO入れてると
Yは0-255ちょいオーバーになるけどねぇ
個体差なのか、うちがおかしいだけなのか、入力機器によって違うのか・・・
PbPrは中間の±242あたりになってるね。
369:名無しさん＠編集中
07/09/25 00:05:04 qT59KP4m
>0-235
普通にわからん。
16-235じゃないのか。
BT601と709の違い？
370:名無しさん＠編集中
07/09/25 00:47:10 uWE59oxC
>>369
16-235と0-255は標準化されているけど、両方とも問題あり。
ようは0-16→0にしたいけど235-255は保持したいということで0-235。
371:名無しさん＠編集中
07/09/25 02:50:03 Czk3k+G9
ｘｖYCC規格とかが関係してるのかのう…
372:名無しさん＠編集中
07/09/25 11:47:42 3du+U6wn
>>370
その考え方はおかしいよ。
100％以上0％以下をカットしないコーデックだっていっぱいあるんだから、気になるならそれ使えば良いだけだし
だいたいそれしちゃうと、思いっきり全体が暗くなるじゃん。
それでなくてもストレート変換された時点でＴＶよりずいぶん暗くなっているんだから。
373:名無しさん＠編集中
07/09/25 16:45:50 uWE59oxC
>>372
もちろん、0-235に変換したときは全体が暗くならないようにある程度のガンマ補正は必要だろうね。
ちなみにストレート変換では暗くならないよ。上が暗くなる分、下が持ち上げられるから画面全体では明るさは保持されている。
考え方がおかしいって言うけど、これって家電に入っているビデオプロセッサーではかなり常識と思うよ。
PCでは標準化という名の下にあまりにもオリジナリティがなくなってきていると思うなー。
374:名無しさん＠編集中
07/09/25 17:34:28 peFtJ/TZ
まぁ自分が0-235で良いって言うんだからそれはそれで良いとは思うけど
ここで断言的に書くのはよくないと思うな。
やっぱり基本は16-235なんだからね。
しかも、PCのVGAドライバもコーデックもすべて16-235を基準として設計されているわけで
独自設計された家電を持ち出されても説得力はないと思うよ。
375:名無しさん＠編集中
07/09/25 18:24:46 uWE59oxC
>>374
基本は16-235ってそれってアナログのYPbPrをデジタルにそのまま変換した場合の話ね。
決してそのまま画面に出したら駄目なのは分かっているよね？
PCの画面はデジタルで0-255だから少なくともアナログの16はデジタルの0にしないといけないよ。
問題はアナログの235なんだよね。そのままデジタルの255にすると所謂YC伸張になる。
これだと最近のHDコンテンツが使っている235-255のスーパーホワイトに対応できない。
よって、アナログの16をデジタルの0にしつつ235-255のスーパーホワイトも保持して画面に出力したい。
これが0-235の所以なんだけど、理解できないかな？
376:名無しさん＠編集中
07/09/25 18:49:34 peFtJ/TZ
だから、何をやりたいのかは理解できていますよ。w
そんなに挑戦的に書かれなくてもね ＾＾；
でもそれはあなたの考え方なんだから、あまり押しつけるのはよくないんでないの？って言っているだけ。
だいたい、YC伸張するドライバではそれしちゃうとダブル伸張になるでしょ？白側は良いとしても黒側が潰れちゃうよね？
YC伸張しない場合で、0-255で記録されていても、コーデックによっては255オーバーも記録できているわけだから
再生時の設定でもスパーホワイトの表示は可能だしね。
それぞれを理解できている人がやるのは別にかまわないけど、それが絶対とは言えないでしょ？環境にもよるでしょってこと。
わかってもらえたかな？
377:名無しさん＠編集中
07/09/26 02:38:59 Vc7YBhsu
>>375
>>376
話がかみ合ってないだけだろ。
>375は変換そのものに関して話しているみたいだからドライバ伸張の話だろ？
>376はどうもコーデックとドライバーを混ぜくちゃにしているみたいだな。大体、今時はコーデックでは伸張なんかしないよ。コーデックはYUVカラースペースのままだから伸張は関係ない。コーデックがRGB変換するってかなり古い知識だと思うぞ。
378:名無しさん＠編集中
07/09/28 15:26:08 gKqKMB5N
ヽ
_,,.,､､,.ｨ-- ti- ､､､....,,,,_ ',
,,..､､ri':'ﾞ/~ ﾚ ' ﾞﾍ:l : : : :~,＞
_,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 !l!;: r '"
'''＜:::::::::::::;､r' `'' ‐-`.､ /
-、 l::::::::::::l ＜"ﾞ'i;ｿ' ',
~.ヽ l:::::::::::l ~' '､
/ .） .l::::::::::! '､
ヽ .l:!l:::::l ヽ '､
＼ ' l! l::!l! ヽ ,'
ﾞ ヾ ‐'" ,. r ﾞ
ｰ-‐i ,.r,,iilll鬚髯ｦ そんなに何も見えてないんじゃ
. l `''' ‐‐ ---t‐'
￣￣￣￣￣￣~"''､' ‐ ､ ー‐ノ 生きてても面白くないでしょう
', ヽ l
ｌ l l
l l ﾉ
379:名無しさん＠編集中
07/10/08 08:37:53 7U//T957
何このマリオ
380:名無しさん＠編集中
07/11/06 19:03:56 7MSa3azk
吉井さんだよ
381:名無しさん＠編集中
07/12/17 09:10:54 r6k/Mv7w
ＶｉｓｔａＳＰ１＋ＮｖｉｄｉａドライバーでＹＣ伸張してくれるようになったお。
382:名無しさん＠編集中
08/01/03 09:33:36 kUstuUcA
age
383:名無しさん＠編集中
08/01/07 15:26:39 jatr8V+y
>>381
本当だ！試しにSP1の評価版と最新の169.25デトネイタを入れたらYC伸張する！
384:名無しさん＠編集中
08/01/18 19:13:18 dIqZ1VjC
>>383
ラデオンだとSP1入れても未だYC伸張してくれない。ジーフォースに買い換えないと駄目？ラデオンは負け組みって事？
385:名無しさん＠編集中
08/01/20 06:30:50 qKn4NFML
>>384
現状だとAMDが死に体だからATIは負け組みかもね。。。
今後はIntel vs NVidiaでATIはS3とかMatrox化していく気がする。。。
386:名無しさん＠編集中
08/01/20 16:55:32 UGOZQUm7
ここDTV板だろ・・・この期に及んでnVidiaがいいとか、ラデがYC伸張しないとかドンだけでたらめなんだよwwww
387:名無しさん＠編集中
08/01/21 14:43:08 7nQnxAf7
>>386
実際、YC伸張にすぐさま対応したのはnVidia、AMDはすでに会社そのものがヤバイだろｗ
388:名無しさん＠編集中
08/01/21 16:38:11 3bbyPTda
>>387
おいおいwwww何言っても良いが嘘はいかんよ、嘘はwwww
389:名無しさん＠編集中
08/01/22 03:41:52 /zpg/jzB
>>388
誰も嘘言ってないけどな。。。
会社の時価総額でもAMD(ATIを含め)はnVidiaの数分の一になってるって知ってるか？
NASDAQで過去一年間くらいの株価見てみろ。
390:名無しさん＠編集中
08/01/22 04:06:29 Fxbgf48Q
>>389
>>388がつついてるのはそこじゃないだろ
＞実際、YC伸張にすぐさま対応したのはnVidia
こっちだろ。どんな認識でこんな大嘘言えるのか俺も思うよ。
391:名無しさん＠編集中
08/01/22 16:56:09 /zpg/jzB
>>390
nvのVistaドライバースレで一ヶ月以上前に報告上がってたよ。
確か169.1xとVistaSP1 BetaでYC伸張がされるようになったとか。
392:名無しさん＠編集中
08/01/22 17:24:39 kxE/tNIn
俺の知っている限りでは
Radeonは7000番台の時代からYC伸張に対応している。
Gefoeceはドライバの84.21からYC伸張できるようになっている。
しかも動画に関してはつい最近までRadeonが2歩先を行っていた。
（ドライバの100番台に入ってやっとだいぶん追いついてきたようだけどまだまだだね。）
３Dに関しては逆の評価みたいだね。使い物にならんのがラデみたいだ。
393:名無しさん＠編集中
08/01/22 17:26:09 CkEl96Ph
( ﾟдﾟ )
394:名無しさん＠編集中
08/01/23 03:01:22 9vQAApKT
>>392
君のは大昔のオーバーレイが全盛だったときの話じゃ。。。
Vistaの話題なんだから非オーバーレイについてに決まっていると思うが？
395:名無しさん＠編集中
08/01/27 18:35:51 zFIAvNr0
いまだにオーバーレイしてますが
396:名無しさん＠編集中
08/02/03 19:10:02 Z+V8klSw
Gefoeceで動画ってどんだけマゾいんだよｗ
397:名無しさん＠編集中
08/02/05 15:18:27 hZhMjXov
>>396
オーバーレイの時代はかなり微妙だったけど、非オーバーレイのVistaになってからは下手するとATIよりも良いという評価も聞かれるけどな。
398:名無しさん＠編集中
08/02/05 22:56:31 7FvsqN7X
すまん便乗で。
XPのオーバーレイ環境下だと今でもnVidiaはいまいちくんなの？
399:名無しさん＠編集中
08/02/06 03:41:07 MlrDLIgF
>>394
大昔ってXPのVMR7もオーバーレイミキサ使っているし、だいたいEVRを使っているユーザーが今いくらくらいいるとお思ってるんだ？
>>398
いまいちどころか最悪でないかな
オーバーレイならあのS3の方が綺麗だしww
400:名無しさん＠編集中
08/02/06 17:55:38 VbrsKj9X
>>399
お前Vista使ってないのばればれ。
VistaのメディアプレイヤーとかメディアセンターはEVRだし、PowerDVD7もEVRだぞ。
いつまでも食わず嫌いだから遅れるんだよｗ
401:名無しさん＠編集中
08/02/09 10:17:23 I/YvmMW0
>>397
それはそうだね。
あとは色空間変換やCRT使いの人向けにDACの性能が良くなれば、
nVIDIAは駄目という声も減ると思うけど。
402:名無しさん＠編集中
08/02/09 13:23:00 HbQT2ot8
RADEONはとりあえず"UseBT601CSC"="1"つっこんどきゃY/C伸張するんじゃねーの
Vistaは知らんけど
403:名無しさん＠編集中
08/02/10 06:19:16 6OTEFHQO
XPでnvdiaグラうボ使ってる人向けの画質設定晒しとく
94.24で確認したから100以降のドライバは知らん
ffdshowの「レベル」を選択
モードはOriginal
フルレンジにチェック
入力16-235
出力0-255
ガンマ補正オフ
ポスタライズ255
これでまともな色になる
404:名無しさん＠編集中
08/02/10 14:30:56 Y3N12W/F
>>402
他スレで散々既出だがVistaにはそのレジストリは存在してないし、同様のNVidiaのやつもXPのみ。
>>403
ffdshowじゃあHD/BDは関係ないからなー。
405:名無しさん＠編集中
08/02/14 17:19:11 7GXiyzhX
Vista SP1+ゲフォ最新βドライバーだとPowerDVDなんかもYC伸張するようになるな。
いったいどれが今までバグってたのか、全くプンスカ。
406:名無しさん＠編集中
08/03/04 10:33:49 abB8HAgX
nVIDIAチップ特有の白っぽくてパサパサした色合いがちょっと苦手
ゲームやるぶんにはnVIDIAが良いんだろうけど、ATIの色味に慣れちゃうとなかなか抜け出せないわ
そろそろ買い替え予定なんで、Vista環境も考えてみるか
407:名無しさん＠編集中
08/03/04 11:05:55 xYUVKfTT
nvidiaは9000番台の次から動画関連に大幅に手を入れるって言ってる
今うんこなのは当たり前ｗ
408:名無しさん＠編集中
08/03/26 15:39:58 0JfwX7St
Friioを購入していろいろやってみましたので、結果を書いておきます。
ビデオカード：GeForce7600GS 93.71 VMRYC伸張有
OS：WindowsXPSP2
プレーヤー：MPC6.4.9.1
MPEG2デコーダ：MPC内蔵・YV12orYUV2出力
ソース：BT.709のカラーバーSD解像度
オーバーレイ・VMR7・VMR9：すべてBT.601として変換
ソース：BT.709のカラーバーHD解像度
オーバーレイ・VMR7W：BT.601として変換
VMR7R・VMR9W・VMR9R：BT.709として変換
上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
しかしBT.709の登場で面倒なことになりましたね。
余談すがデコーダをffdshowにして出力をRGB32にしてffdshow側でBT.709を指定すればどの解像度でも正しい色になります。
409:名無しさん＠編集中
08/03/26 16:37:00 Z2J+WSKO
SDに変換する時はColormatrix等でBT.601にする必要があるな。
410:名無しさん＠編集中
08/03/26 16:51:59 0JfwX7St
DVDもBT.601ですので、HDキャプチャしてDVD出力する場合も変換しないとおかしくなりますね。
DVDレコもちゃんと変換しているみたいです。
あとチューナーのコンポーネント出力はBT.709で出していますが、S端子はちゃんとBT.601に変換されていました。
家電って結構キッチリしているんですね、ずぼらなのはPCだけのようです…orz
411:名無しさん＠編集中
08/03/28 03:49:08 DL/Lx8g8
>>408
>上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
Vista+EVRを使えばDXVA2経由でBT.601とBT.709をドライバーに指示できるみたいよ。
412:名無しさん＠編集中
08/03/28 04:14:15 qRjTrz58
BT.709のカラーバーというものは存在しないんだけど・・・
色域がBT.709になるかBT.601になるかはRGBへマッピングするときに決めるだけ
よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
413:名無しさん＠編集中
08/03/28 18:10:59 DL/Lx8g8
>>412
>よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
これはちょっと誤解を生むよ。HD放送の合間のSDは解像度がHDじゃなくてもBT.709になっているのは常識。
アプリがコンテンツの状況に応じてドライバーに変換関数を知らせた方が正確。
414:名無しさん＠編集中
08/03/28 18:13:58 TXNosBRg
私はFriioを持っていないから確認できませんが、日本のSDのデジタル放送のcolorimetryを
DGIndexはきちんとBT.709だと判定できるのだろうか。
415:名無しさん＠編集中
08/03/28 19:10:24 wG38zexJ
SDってBS1,2か？教育も一部時間はSDか。
416:名無しさん＠編集中
08/03/31 07:45:51 ZNpWyTs8
どっかで見たけど、NHKとかのデジタルSDはmatrix_coefficientが省略されてるみたい。
でもテレビだとBT.709として処理してるようだ。
URLﾘﾝｸ(www.marumo.ne.jp)
＞Digital BS では YUV データは全て ITU-R BT.709 形式で送り出すので、
＞matrix_coefficient が省略されている場合も ITU-R BT.709 が指定されたものとしてデコードするようにと規定されています。
＞HD 放送の場合だけでなく、SD 放送の場合もです。ARIB STD-B32 で確認しました。
DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
なので>>408のSDでmatrix_coefficientが省略されてた場合は、
matrix_coefficientを見てるのか、解像度で判断してるのかわからないな。
matrix_coefficientでBT.709を指定したSDファイルを作ってみれば分かるけど。
417:名無しさん＠編集中
08/03/31 07:57:55 byVcSBaz
BT.601 = BT.470-2(DGIndexの自動判定) = SMPTE 170Mだから、それだったらやはり
ColorMatrix(mode="Rec.709->Rec.601",interlaced=true)とでも書いてBT.601に変換する必要があるな。
418:名無しさん＠編集中
08/04/04 21:51:39 59KSVULO
よくわからんけど、
CCEやTMPGで709→601にするときはどうすればいいの？
0-255か16-235しかないよ。
419:名無しさん＠編集中
08/04/05 02:52:17 fbi2C0NX
>>418
いいよおまいは話に参加しなくても
420:名無しさん＠編集中
08/04/21 15:26:15 gMV7SetX
BT変換とTVスケールへの伸張はどっちを先にやったほうがいいのでしょうか
421:名無しさん＠編集中
08/05/24 20:32:12 EW5fNDtN
> DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
dgindex149のソースとかh.262とか読んだ感じ省略時は
mpeg2はRecommendation ITU-R BT.709
mpeg1はRecommendation ITU-R BT.470-2 System B, G
になりそうなんだけど>416はmpeg1の話をしてるの？
422:名無しさん＠編集中
08/05/24 20:49:02 si+3EZcc
>>421
DGMPGDec 1.5.0では変更された。
URLﾘﾝｸ(forum.doom9.org)
423:名無しさん＠編集中
08/05/24 21:06:55 EW5fNDtN
へー、そーなんだ知らんかった。ゴメン
ついでに聴くけど
何で素直に2(Unspecified)を返すようにしないの？
はっきり言って紛らわしいと思うのは俺だけ？
424:名無しさん＠編集中
08/05/24 21:24:16 si+3EZcc
DGDecodeの判定を読むColorMatrix(hints=true)の様にして使う事もあるし、その方が良いのだろう。
MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
大した手間では無いのだから、最初にMPEG-2 Videoをエンコードする時、colorimetryにきちんと
SMPTE 170Mなりを指定していてくれたら良いのにとは常に思うが。
bt.709 and CCE
URLﾘﾝｸ(forum.doom9.org)
425:名無しさん＠編集中
08/05/24 22:31:12 EW5fNDtN
> MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
そんなにややこしいなら尚更Unspecifiedを返すべきなんじゃ？
DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい
不明な場合の動作をユーザー指定とかなら俺でもすぐ出来そうなんで
ColorMatrixの方はプラグイン側が対応すれば善いだけかと
まあPrimaries、Transferが違うって時点でMatrixだけ教えてくれてもしょうがないとも思うけど
426:名無しさん＠編集中
08/05/24 22:41:27 si+3EZcc
>DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい
Colorimetry: BT.470-2 B,G*
ソースがUnspecifiedならこういう風に*が付くから、Informationやlogを見たらすぐに分かる。
427:名無しさん＠編集中
08/05/24 23:40:16 KJ5Y8Mo3
TSソースで試したら、HDはBT.709になったがSDはBT.470-2 B,G*になった。
色見るとどちらもBT.709なのに、SDでは指定されてないのかな、謎だ。
428:名無しさん＠編集中
08/08/09 22:53:47 rSmXo3C9
PALなら5:1.5:1.5ですね。
429:名無しさん＠編集中
08/08/28 17:54:22 DplL5tuS
430:名無しさん＠編集中
08/08/31 04:04:32 tO/J3aLd
亀だが誰か>>355の内容について教えてください
うちの環境がおかしいのか混乱してきた・・・
YC伸張していない動画(黒16-白235)を再生した時、
Luma rangeを「TV(16-235)」に設定すると黒0-白255で表示される(白が真っ白に見える)
「PC(0-255)」に設定すると白が灰色に見える、16-235より暗い感じだから、
>>355同様、16-235の状態を0-255と仮定して16-235へさらに変換しているように見える
これは表記ミスなのかな？
それともLuma rangeは入力ソースの種類という意味なのだろうか？
431:名無しさん＠編集中
08/08/31 09:50:22 VJQGf6bX
>>430
うちもそうなるよ
432:名無しさん＠編集中
08/08/31 11:56:42 apcIcXt4
PC(0-255)ってことはストレート変換、つまり伸張しない。
TVなら黒を16、白を235としてPCスケールに伸張するっていう意味なんだが。
理解の仕方が反対だよ。
ちなみに>>355の最後は間違いでAviutlのプレビューは伸張してるから
たぶんY30-217のファイルを作ってる。
433:名無しさん＠編集中
08/09/04 18:49:30 qGh5AYHA
RGB24のソースをAVISynthを使ってカット編集して
YV12変換してx264でエンコードするのと
AVIUtlを編集に使ってRGB24→YUY2→YV12と変換するのでは
やはりAVIUｔｌ経由は劣化してしまいますか？
434:名無しさん＠編集中
08/09/04 19:20:34 Ot5eU7BW
AviUtl本体にはYV12へ変換する機能は無い。
435:名無しさん＠編集中
08/09/04 19:43:56 qGh5AYHA
言葉足らずでした
AVIUtlの拡張x264出力プラグインに、
x264に渡す前にYV12に変換する機能がついてるんです
436:名無しさん＠編集中
08/09/04 23:59:11 R68KTdq0
AviUtlでの編集は正確には
RGB24>YC48(これで編集）>YUY2>YV12
色変換だけ考えたらRGB24>YV12と違いはないので
同じだと思うけどAviUtlはフィルタ精度が12bitだから
劣化の具合で言ったら理論的にはUtlのほうが少ない。
つーても肉眼ではわからんだろ。
437:名無しさん＠編集中
08/09/05 02:49:56 Gk5w7tAl
カット編集としか書いてないから、違いはないんじゃないか？
438:435
08/09/05 04:13:38 TbXX27C5
どうもありがとう
フィルタはかけないけど、かけた場合はフィルタの精度も重要ですね
回答してくれた人愛します<3
439:名無しさん＠編集中
08/09/13 14:13:01 21caLQWg
>>432
dgindex150を使用して、PC scaleで出力してエンコーダに渡せばストレート変換？
YV12ソース＞dgindex（PCscale）＞エンコーダ(YV12)出力
これで良いのでしょうか？
440:名無しさん＠編集中
08/09/19 05:24:40 KHzW8kGD
>>439
avisynth経由の話ならdgindexの設定は関係ない
その設定は使われないので意識する必要なし
441:名無しさん＠編集中
08/09/19 10:21:34 E9nS3Lq4
dgindex のPC/TVscaleの設定はVFW経由の場合にのみ有効って認識でいい
たぶん。
442:名無しさん＠編集中
08/09/20 21:14:25 fAg2w24o
今まで9600GT使っててHD 4850に交換したんだけど、RADEONってYC伸張しないんだな
WMV9でYC伸張でエンコした動画ずっと見てたからなんか変な感じ
OSはVistaSP1
443:名無しさん＠編集中
08/09/20 21:59:27 CNZMlSyU
>>442が今時まれに見る情報弱者だということは理解した
444:sage
08/09/20 21:59:58 SyoX7pM0
>>442
ATI HD Registry Tweaks
445:名無しさん＠編集中
08/09/21 14:02:39 LTBBnYvd
ビデオカードにYC伸張やらせるなんてアホらしい
動画側にやらせるべき
446:名無しさん＠編集中
08/09/21 14:05:56 Ro0+EH/h
それだとTVに写すとき困るし～！
447:名無しさん＠編集中
08/09/21 17:57:54 g12aJ8Ao
>>445
データはストレート保存で再生時に伸張。これ常識。
448:名無しさん＠編集中
08/09/21 20:51:09 WS3/bMbQ
>>445
DVDは伸張されてないんですが、それもアホらしんですね
もう何もPCでは見られませんね
伸張して保存するなんていつの時代の話だよ
変な流れを最初に作った諸悪の根源はnVIDIAなんだけどな
>>447氏も言ってるように再生時に伸張するのが常識です
なので動画保存時はストレート保存、伸張保存してたらﾌﾟｷﾞｬｰされるぞ
449:名無しさん＠編集中
08/09/22 02:37:13 vL6DAe5x
Haali's Video Rendererはとても優秀
450:名無しさん＠編集中
08/09/22 21:48:39 /OoVLfz9
NPC内臓のHaali使うと引き伸ばしの画像がおかしくなる。
おかしいというよりはリサイズが糞っぽい。
リサイズはffdshowに任せたほうがよさげ
451:名無しさん＠編集中
08/09/22 21:57:34 /VyuUluT
NPCってなんれすか？
452:名無しさん＠編集中
08/09/22 23:17:29 1A0Ol3pO
少し質問です。
まるも氏のm2vプラグインでストレート変換読み込みした場合と
DGIndexでPCスケールで読み込みをした場合に色合いがほぼ同じになります。
色々な記述を読む限りまるも氏のプラグイン設定でストレート変換を指定した場合
伸張しないと解釈しているのですが、なぜDGIndexのPCスケールと同じ色合いに
なるのか疑問で仕方ありません。
普通PCスケールじゃなくTVスケールと似た色合いになるんじゃ…。
それともDGの方がTV指定時にダウンスケールしてるだけのことですか？
453:名無しさん＠編集中
08/09/22 23:27:35 vL6DAe5x
VFAPIがややこしいのなら、DGDecode_mpeg2sourceでd2vを開けば、YV12のまま伸張も何もしない。
454:名無しさん＠編集中
08/09/22 23:43:43 DIJGvtux
>>452
そもそもまるも氏のストレートとそうでないのとで色ちゃんと変わってる？
話を聞く限りまるも氏のプラグインでRGB展開してない気がするが
455:名無しさん＠編集中
08/09/22 23:57:35 ARySuTFW
>>452
aviutlの仕様です
456:名無しさん＠編集中
08/09/23 08:33:42 t2QFmLhW
m2v.auiはYUY2読み込み
readme読め
457:名無しさん＠編集中
08/09/23 17:12:30 D66+eWYE
超初心者なのですが、伸張するっていうのは0-255なのか16-235のどっちなんでしょうか？
0-255の方が範囲が広いのでこっちにしたいのですが、伸張されるっていうのがどっちなのかわからなくて・・・
ちなみにここの話題とは全然違ってPS3をつないだモニタの設定でどっちにしたらいいのか迷っているからなんで・・・・
458:名無しさん＠編集中
08/09/24 02:27:37 toi/BNHh
16-235としてPCスケールに伸張(0-255)
上に何度も書いてあるけど「伸張保存はするな」
って言っても色空間から理解する必要があるからなあ・・・
伸張云々よりも先にそこから勉強したほうがいいよ
459:名無しさん＠編集中
08/09/26 09:47:47 d9xJhVIR
その前に8bit=255から理解する必要があるのでは？
そして次はYUVを勉強してBT.601を勉強してそれに今時はスーパーホワイト領域の事も考慮して・・・etc
最後は論文かけるようになるかもねw
460:名無しさん＠編集中
08/09/26 14:03:09 EPyHUXU0
エンコ時に伸張するほうが精度が高いって知ってた？
461:名無しさん＠編集中
08/09/26 14:23:46 mjIORAaH
>>460
マジで？
エンコ時なら8bit演算でしか伸張できないけど。
ちゃんとディザリングとかかけたりしてくれるソフト有るの？
再生時なら今の世代だとRadeonもGeForceも10bit演算で伸張するし、
Radeonはちゃんとディザリングかけてから8bitに出力してくれるんだけど。
最新のRadeonHD4だと10bit対応モニタの場合そのまま10bitで出力してくれるし。
ホントにエンコ時に伸張する方が精度高いの？
462:名無しさん＠編集中
08/09/26 15:46:04 Ux/K698u
>>460
どっちにしても大多数のコンテンツがストレート保存だから再生時に伸張するのがデファクトスタンダードである事に変わりない。
もはや精度がうんぬんという話は全く意味もないことだな。
463:名無しさん＠編集中
08/09/26 15:53:29 gIV7Ydpv
昨今（と言っても相当昔から）の動画コーデックは、YUVも含めた上での圧縮。
エンコード時に伸張してやること自体がナンセンス。
464:名無しさん＠編集中
08/09/26 22:49:49 pYp5CLLQ
伸張も圧縮もせず元のYUVをYUVのまま置いとくのが一番でしょ。
465:名無しさん＠編集中
08/09/28 19:29:53 yzQFyw3r
初心者でもしスレ違いだったらすみませんが、詳しい方教えて下さい。
DVDレコーダーと液晶テレビをHDMI接続し、解像度自動設定で強制的にHDで見ている状態です。
この場合に、SDソースのアナログ放送やDVDディスクはDVDレコーダー側でHDにアップコンバートされて出力されていますが、色空間の取扱はどうなっているのでしょうか。
466:名無しさん＠編集中
08/09/28 20:48:43 oGMa9b6c
うちはRD-S300だけどアナログでキャプチャしたカラーバーをHDMIでD3出力させてみたら
ちゃんとSMPTE 170M->BT.709変換が入ってるぽい。
どのメーカーにも信者はいるだろうからそういう変換が入ってなければ真っ先に苦情飛ぶだろうし
そんな初歩的な規格しらない開発者もいないだろうから問題ないんじゃね
467:名無しさん＠編集中
08/09/28 21:53:50 yzQFyw3r
465です。
>>466
早速のレス有難うございました。
うちもRDやスゴ録を某有名メーカーの液晶に接続していて、D1・D2とD3・D4で色が違うのが気になっていました。
レコーダーか液晶かどちらの問題か分からなくて困っていましたが、RD側でちゃんと変換しているとすると液晶側の問題のようですね。
でもそこまで変換するのであれば、やはりアップコンバートはテレビ側でした方が良いでしょうし、HDMI解像度自動設定もSDソースはSDのまま出力してくれないものでしょうかね。
468:名無しさん＠編集中
08/09/28 22:15:57 oGMa9b6c
>>467
液晶って家電のほうだよな？
家電でそういうミスはあんまり考えられない気もするんだけど･･･
うーむ、どうなんだろう。
469:名無しさん＠編集中
08/09/28 22:36:46 yzQFyw3r
>>468
勿論某超一流家電メーカーの液晶テレビで昨年のモデルです。
お騒がせしましたが、このメーカーのテレビ独特の問題がありそうです。
今気付きましたが、テレビのオンスクリーン表示も、解像度によって色か明るさか良く分かりませんが変ってしまうようです。
そういえばこの機種は、液晶のダイナミックコントラスト機能が強すぎて、明るさを調整しようとして画質調整のメニューを出すと、それに引っ張られてバックライトが変化してしまい、まともに調整できないという酷い仕様です。
どうもユーザーが触れないおせっかいな自動補正がありそうです。
470:名無しさん＠編集中
08/10/14 14:05:57 v+GfvfiY
元に居たにいたスレで話していましたがスレ違なのでこちらに来ました。
DGIndexをTVスケールでVFAPI経由読み込みした際にYUVデータを維持したまま
読み込んだ画像に比べて色がかなり薄くなり疑問に思いました。
以下の画像を参照して下さい。
■比較画像
URLﾘﾝｸ(www1.axfc.net)
■ヒストグラム
URLﾘﾝｸ(www1.axfc.net)
パスは両方ともyazawa
この比較からするとDGIndexではTVスケールを選択すると実際のトコロ
0-255を16-235に圧縮してるのではないかと思います。
なのでエンコに使う場合はPCスケールが正解なのかなぁと。
普段はm2v.aufの元のYUVを維持でエンコしてるのですが、どうしても気になって…
471:名無しさん＠編集中
08/10/14 14:09:39 1ThNXYmm
YCbCrはTVスケール、RGBはPCスケールにするのが普通のやり方。
だから、訳が分からないのなら、途中で変換が入るAviUtl等使わず、
変換の入らないAviSynthでx264に渡せば何も考える必要がない。
472:名無しさん＠編集中
08/10/14 14:30:31 v+GfvfiY
d2vファイルをAviUtlで編集する場合、avsから読み込めば問題無しで
VFAPIを用いる場合はPCスケールにすればOKということ？？
その場合二重伸張とかにはならない？
473:名無しさん＠編集中
08/10/14 14:36:09 1ThNXYmm
1. DGIndexでd2vを作って、それを入力にavsを作る。
2. "x264.exe" --crf 20.0 --output "output.mp4" "input.avs"
474:名無しさん＠編集中
08/10/14 14:42:41 v+GfvfiY
x264がYV12入力だからavsから直接やれば無問題ってことは解っていて
とても有りがたい返答ではあるのですが現在知りたいのは
DGIndexとAviUtlを用いた際の色の扱い方なので…。
一般的にYUV維持して読み込むか、TVスケールでVFAPI経由というのが良いという
ことになってますが、VFAPIでTVスケール使うと色縮んでるじゃん。なんで？
っていう所が疑問のスタートなんです。
いや、ホント説明とか出来ないバカですみません。
475:名無しさん＠編集中
08/10/14 14:52:26 1ThNXYmm
DGVfapi.vfpの色空間はRGB24で、RGBは一般的にPCスケールである事を前提として扱われる。
詳しい説明はDGVfapi.txtを読め。
476:名無しさん＠編集中
08/10/14 17:50:08 v+GfvfiY
あーなるほど。
漸く理解できました、本当ありがとう！
477:名無しさん＠編集中
08/10/14 18:04:11 ULjBfQ5G
>>474
こっちに移ってたか。
キミがあげた比較画像だが、m2v.aufの伸張有りってのは
フィルタかなんかでさらにPCスケール変換してるっていう意味かね？
そういうことにしとくけど簡単に言うと
DGIndex(VFAPI)
PC Scale: Y: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換
TV Scale: YUV画像をそのままRGB: 0-255に変換
Aviutl
ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
ソースがRGB: プレビューはそのまま、出力はRGB: 0-255をY: 16-235, UV: 16-255に変換
AviutlでのYUV->RGB変換: DGIndexでいうPC Scaleとおなじ
これでわからんのならもうちょっと色空間勉強したほうがいいと思う。
478:名無しさん＠編集中
08/10/14 18:04:43 ULjBfQ5G
おそかったorz
479:名無しさん＠編集中
08/10/14 18:09:12 v+GfvfiY
ご…ごめんなさい…。
480:名無しさん＠編集中
08/10/14 18:25:18 1ThNXYmm
YV12とRGBの変換は、TV/PCスケールに加えて、BT.601/BT.709、
インターレース/プログレッシブをきちんと把握しないと、変な色になるからとても面倒くさい。
やはりソースがYV12なら、YV12のままでエンコーダに直接渡すのがベスト。
481:名無しさん＠編集中
08/10/14 19:52:24 wMQpUmr7
俺みたないなお馬鹿はVFAPI経由させるなってことか
482:名無しさん＠編集中
08/10/14 22:56:39 VCoPi0+g
動画を扱うこと自体をやめるべきでは
483:名無しさん＠編集中
08/10/14 23:10:23 M0RbEkyM
自分で楽しむだけならいいんじゃね。
484:名無しさん＠編集中
08/10/17 08:25:45 EbrZG3U2
>>477
>ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
出力は変換なしってどういうことですか？
プレビュー（編集時）は伸張しているが、実際の出力は伸張していないという認識でいいのでしょうか？
485:名無しさん＠編集中
08/10/17 10:35:58 G3nEAXVQ
まず477は間違い。初心者を陥れる罠。
伸張が関係するのは、YUV<->RGB変換になる場合だけ。
AviUtlは常にY16-235,UV16-240をRGB0,0,0-255,255,255として扱う。
まずソースがYUY2で展開される場合。
プレビューは、表示→オーバーレイ表示がoffならRGBで表示する。(WindowsGDIの仕様)
無圧縮(RGB)出力やコーデックにRGBで渡す時はプレビューと同じ変換でRGBにしてから出力される。
YUY2出力やコーデックにYUY2で渡す時は(フィルタで弄らない限り)ソースのスケールのまま。
実際は内部形式をはさむ変換なんだけど、16-235->0-255みたいにダイナミックレンジがつぶれたり
0-255->16-235みたいに諧調が失われたりする事の無い内部形式だから気にする必要はない。
486:名無しさん＠編集中
08/10/17 10:38:38 2z8ZQ3vU
AviutlのプレビューはBT.601だから、
デジタル放送だと色がおかしくなるので注意ね
かといってプレビューで正しく見えるように変換しちゃうと、
今度は出力されたファイルがおかしくなるので更に注意
487:名無しさん＠編集中
08/10/17 10:56:02 xMb2oRTj
HD->SDのエンコードにはBT.709->BT.601の変換が必須だけど、
UtlにはSynthのColorMatrixに相当するプラグインはあるの?
488:名無しさん＠編集中
08/10/17 11:00:34 XaaXSGaQ
URLﾘﾝｸ(www.geocities.jp)
あじさんとこの色域変換プラグインがそうじゃないかな
489:名無しさん＠編集中
08/10/17 11:07:25 xMb2oRTj
どうもありがとう。
490:名無しさん＠編集中
08/10/17 13:16:20 EbrZG3U2
詳しい説明をありがとうございます。
まだ混乱しているのですが、下のように理解しました。
ソースをYUY2で読み込んだ場合（YUVで取り扱う）の表示は、AviUtlの内部形式に変換する際16-235->0-255のように変換する為
プレビューは一見ストレートではなく、伸張(16-235->0-255の内部形式への変換)されたように見える。
これをYUY2（YUV)としてそのまま出力すると内部形式は0-255->16-235として処理され、読み込んだときのスケールは保持（伸張されない）される。
しかし、これをRGB出力（VFAPIなど、プロファイルを渡す)した場合、内部形式16-235->0-255がRGBへの変換に適用されYUV->RGBの際に伸張された動画となる。
つまり、Aviutlで元のYUVデータを保持し、伸張は再生側にまかせた動画を作成する場合
rec.709やbt.601の変換を抜きにすれば、YUY2で動画を読み込み、フィルタなどはいじらずYUVでそのまま出力すればいいということでしょうか？
491:名無しさん＠編集中
08/10/17 18:34:24 MRiUv4La
ROMってた初心者なんですが、検索して調べても混乱が増すばかり・・・
動画ファイルがTVorPCスケールか調べたくて
Aviutl0.99fで波形表示プラグインを使ってみたんですが
ソースがYUY2orRGBの展開の違いで波形表示が変わるのでしょうか？
自分のPC環境がVGAでYC伸張がされてるかも怪しくなってきて・・・
混乱しまくりで変な質問すいません。
492:名無しさん＠編集中
08/10/17 20:09:27 ExayxBeC
>>490
utlのプレビューと出力は分けて考えたほうがいい。
utlの内部仕様はあまり公開されてないから想像だけど多分こんな感じになってる
ソース(YUY2/RGB) ─ コーデック設定によるYUY2/RGB変換 ─ 内部形式(YC48変換) ─
─ フィルタ処理(YC48) ┬ 出力形式(YUY2/RGB変換) ─ コーデックへ
├ (非ｵｰﾊﾞｰﾚｲ時)utlによるRGB変換 ─ GDI(ディスプレイ)へ
└ (ｵｰﾊﾞｰﾚｲ時)YUY2変換してOSに渡す ─ VGAによるRGB変換 ─ ディスプレイへ
YUY2/RGB -> YC48変換では伸張処理などなく、完全な無劣化変換。
コーデック設定によるYUY2/RGB変換っていうのは環境設定＞コーデックの設定のところで
YUY2で展開するっていうチェックのON/OFFのことね。OFFだとRGB変換が入る。
ソースがYUY2でかつRGBに変換するときだけYC伸張処理がされ、
ソースがRGBでかつYUY2に変換するときだけYC圧縮処理される。
VGAによるRGB変換は再生時と同じで環境依存。色伸張したりHDのとき自動でBT.709->BT.601変換が入ったりする。
文章下手で申し訳ない。ついでに間違ってる可能性も大いにあるので話半分で読んでくれ。
>>491
同じソースに対して展開方法を変えれば当然データ(波形)も変わるよ。YUV<->RGB変換は基本的にロッシー(劣化する)
ものだから色空間の変換は最小限にするべき。VGAがどういう動作をしているかはオーバーレイ表示にすればわかる。
非オーバーレイと同じになれば伸張してるしHD動画のときさらに色が変わればBT.709->BT.601変換も入ってる。
ただ実際動画をプレイヤーで再生するとき非オーバーレイモードであればまた環境によって違うからその辺気をつけて。
493:名無しさん＠編集中
08/10/17 20:23:21 PpIpzRbE
おや、Makki氏降臨？
494:491
08/10/18 02:13:30 jPlvR2xo
>>492
レスありがとう。用事があってチェックが遅れてしまった。
非オーバーレイってことはMPCだとVMR9とかかな・・・
>>491のことですが
動画ファイルのスケールを知りたくて(PCかTVスケールかを)
波形表示のYgainとoffsetを見れば分からないのかなーと思ったんですが
AviUtlのプレビューがYUY2orRGBの展開の違いで
変化してしまうのではと混乱してしまって・・・
（例えば、展開でTVスケールがPCスケールへ変化することがあるかどうか）
うまく表現できなくてすいません・・・orz
逆に動画がPCスケールかTVスケールかを
調べるいい方法ってあるのでしょうか・・・慣れれば感覚で分かると思うのですが
495:名無しさん＠編集中
08/10/18 02:20:58 fL9tI0O9
＞展開でTVスケールがPCスケールへ変化することがあるかどうか
スケール自体はかわらんだろ
スケールだけの確認ならヒストグラムでYCbCr表示させて明暗のはっきりしてるシーン見れば
一瞬でわかる。縦の薄い線がTVスケールだから。かといってTVスケールでも若干
はみ出してることもなくはないけどな。
496:491
08/10/18 02:29:11 jPlvR2xo
レスサンクス。
色空間は展開で要注意って認識でいいのかな。
いろいろごちゃごちゃしてしまって整理できず混乱してた。
ほんとありがとう。
497:名無しさん＠編集中
08/10/18 02:46:40 HhiL0M+6
自分はこれを使って確かめている。
URLﾘﾝｸ(www.avisynth.info)
例:
ColorBars(960,720).KillAudio
ConvertToYV12(matrix="rec709")
Histogram("levels")
Info
ConvertToRGB24(matrix="rec709")
URLﾘﾝｸ(img380.imageshack.us)
498:491
08/10/18 02:59:03 jPlvR2xo
今までヒストグラムはRGB表示してた・・・
というかRGなんてこった。
>>
499:491
08/10/18 03:01:32 jPlvR2xo
ミスってしもたorz
今までヒストグラムはRGB表示してた・・・
というかYCbCr表示できたんだね、なんてこった。
>>497
うあ、コレも知らなかったよ。例まで張ってくれてアリガト！
500:名無しさん＠編集中
08/10/31 17:11:30 yOSQ1IfA
今VMR9で伸張出来るのと出来ないのどっちの環境が多いんだろ
501:名無しさん＠編集中
08/11/04 23:33:48 Q7hblQOA
去年の5月頃の議論(>>232から)の中で
「最近は235以上のデータを使っているソースがちらほらあって困る」っていうのがあって、
結局グラボ側でオートゲイン的な処理をしてくれるのがいいんじゃね？
っていう意見があったけど
Radeonの4xxxシリーズに搭載されているダイナミックコントラストって機能がまさにこれだね。
結構複雑な演算を必要としているためGPGPUの機能を使っているらしく、
この機能をオンにするとRadeonのActivityが20%程増加する。
502:名無しさん＠編集中
08/11/04 23:40:56 gfCUEmdh
もう色がおかしかったことがばれちゃってるのに
まだRADEONの色が正しい色と盲信してんのか。
しかもUVD2のダイナミックコントラストは
マッハバンドが出る低画質フィルタｗ
カノープスの動画編集ワークステーションに
Nvidia製Quadroが使われてる現実をみろよ。
世論誘導のお仕事なんだろうけど、まるで三亀ボクシングだなｗ
工作すればするほど、なぜかスポンサーが追い詰められるあれ
503:名無しさん＠編集中
08/11/05 01:59:21 UKx9xgRC
つまり、プロだな
プロには、人と金は集まるモノ
504:名無しさん＠編集中
08/11/05 02:10:58 56oSUSHU
いい加減に現実をみろよ、ビデオ編集ワークステーションはNVIDIA
URLﾘﾝｸ(www.thomson-canopus.jp)
プロはNVIDIA
URLﾘﾝｸ(www.thomson-canopus.jp)
カノープスの技術者は才能あるからね。
505:名無しさん＠編集中
08/11/05 22:00:21 hw1NKaBq
そんな1企業の採用事例だけ示されてもな。
俺はどちらかに傾倒しているつもりはないが>>502>>504のほうがよっぽどnVIDIA信者に見える
506:名無しさん＠編集中
08/11/05 22:16:50 mGEWq2RQ
Macは全部Geforceだし。
507:名無しさん＠編集中
08/11/05 23:08:26 UKx9xgRC
>>505
オレにもそう見える。
nVIDIAなら全ておk!! みたいな過度の依存スタンスが、己の目を曇らせ、自らの審美眼を閉ざす
508:名無しさん＠編集中
08/11/05 23:21:22 9MGwgADk
>>506
さらっと嘘つくなよ。
509:名無しさん＠編集中
08/11/06 14:20:45 BAjQOfNE
最近あちこちで必死な書き込みよく見るし、NVIDIAも大変なんだな。
510:名無しさん＠編集中
08/11/06 15:11:56 SYWy3NAB
PCゲーがコピー多すぎて下火になってコンシューマに以降してるからな。
これからは動画再生に強くないと一般のPCに積む意味が無くなるし。
511:名無しさん＠編集中
08/11/09 12:27:33 oYmH7ZjY
だが動画再生についてはPS3が断トツな状況。
512:名無しさん＠編集中
08/11/10 01:16:01 YR4fsrbM
消費電力ありえないから
513:名無しさん＠編集中
08/11/10 01:16:52 ezZcxULD
Vistaから搭載されてるEVRを使ってセカンダリモニタで
再生させているけど、色変換がされないのは仕様？
514:名無しさん＠編集中
08/11/10 16:28:13 DYj8Q7Um
>>513
色変換されなかったらテンでめちゃめちゃに見えると思うけど。
俺はGeForceだけどセカンダリモニタでメディアプレイヤー(EVRを使う)で再生しても問題なし。
515:513
08/11/10 21:49:48 ezZcxULD
>>514
色変換がされていないというより、無駄に明るくなってる感じ
MPC homecinemaだとEVR Custom Presで正しい色で表示できた
ただWMPでは相変わらずです
考えたらスレ違いじゃんorz
516:名無しさん＠編集中
09/01/25 17:53:39 9kWbJuXa
テスト
517:名無しさん＠編集中
09/01/26 00:20:06 xXymHlkA
質問なんですが
DVD→DGindex→AVS（DGDecode）で24fps化→AviutlでCanopusDVコーデックに変換。
この手順だと余計なスケール変換を起こさずにストレート変換になっているのでしょうか。
518:名無しさん＠編集中
09/01/26 00:46:48 HjGrvUZC
AVSにConvertToYUY2を入れてあれば色空間の変換による劣化はないが
519:名無しさん＠編集中
09/01/26 01:32:52 xXymHlkA
DGDecode_mpeg2source("DVD.d2v")
ConvertToYUY2(interlaced=true)
IT(fps = 24, ref = "TOP", diMode = 0)
こんな順番で並べてますが大丈夫でしょうか？
520:名無しさん＠編集中
09/01/26 05:52:49 jgtFxFAw
ffdshowでYC伸張
URLﾘﾝｸ(replaymugen.seesaa.net)
521:名無しさん＠編集中
09/01/26 14:09:55 QrGS90t4
>>517
AviUtlの入力プラグインがAviSynth Script File Readerとかならいいんじゃないか
DGMpgDec とかもAVS読み込みできるがVFAPI経由でRGBに変換されてるから注意な
522:名無しさん＠編集中
09/01/26 14:18:40 l1IkvcKA
最近エンコやりはじめたが、色空間難しいぜ。ちくしょう。
523:名無しさん＠編集中
09/01/26 18:48:36 xXymHlkA
>>521
AviSynth Script File Readerを入れてなかったです。
これでようやくすっきりしました。
みなさまどうもありがとう。
524:名無しさん＠編集中
09/01/26 23:35:48 xXymHlkA
実際にエンコしてみたら今までに比べてかなり満足のいくものができた。
重ね重ねありがとう。
525:名無しさん＠編集中
09/01/31 22:01:33 jB6dv5bG
YUY2で処理したBT.709のﾌｧｲﾙをavisyunthでConvertToYV12する場合
ConvertToYV12()じゃ駄目？
526:名無しさん＠編集中
09/01/31 22:23:32 nLahnMo0
ConvertToYV12するんだからConvertToYV12()するんだろ？
527:名無しさん＠編集中
09/01/31 23:12:46 jB6dv5bG
判りづらくてすんまそん、ConvertToYV12(matrix="")で色空間指定しないと
bt601に変換されちゃうのかな？って事です。
528:名無しさん＠編集中
09/01/31 23:25:12 Kgq3NFlB
YUY2→YV12なら関係ない。
529:名無しさん＠編集中
09/02/01 00:05:19 SE2S103i
BT.601やらBT.709ってのはYUV>RGB変換式の違いなだけでデータの並びとかの
差異はない。だから少なくともYUV色空間内でそのような変換は起こりえない。
530:名無しさん＠編集中
09/02/01 01:19:35 sBtIc6en
なる程RGB変換を挟まない場合は気にしなくていいんですね、
ありがとうございます。
531:名無しさん＠編集中
09/02/05 00:16:23 HBNND2LJ
SD放送のTSもHDと同じくBT.709らしいけど、レコで出力したのをPV4でキャプった場合はどうなってるんだろうか。
レコがBT.601に変換したりしてるんだろうか。
532:名無しさん＠編集中
09/02/05 01:39:38 Ably69zJ
レコによるんだろうが、
D1、D2出力するときはBT.601で
D3、D4出力するときはBT.709で
出力されるのが一般的だと思うが・・
533:名無しさん＠編集中
09/02/05 02:02:34 HBNND2LJ
そーなのかー㌧
あと170M と601の違いがよくわからん。
ググったら同じものって書いてあるのが多いけど色域変換プラグインで170Mと601は全然色が違う。
SD放送のTSはどっちを指定すればいいの？
534:名無しさん＠編集中
09/02/05 03:12:02 ewMuHAv/
3原色のパラメータの違いだって色域変換のテキストに書いてあるじゃん
535:名無しさん＠編集中
09/02/05 04:41:11 HBNND2LJ
調べれば調べるほどわけわかめになってきた…
m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
されないならこの指定は何のためにあるのか？
元の YUV データを維持にして読み込んで色域変換で3原色を601にするのが正解？
AvisynthならColorMatrixでmode="Rec.709->Rec.601"？
536:名無しさん＠編集中
09/02/05 08:52:45 eQ13tqG2
日本のデジタル放送はどれもBT.709と言うことになっているから、HDならそのままで、
SDでエンコードする場合は、ColorMatrix(mode="Rec.709->Rec.601", interlaced=true) としておけば良い。
放送のMPEG-2 MPはYV12(YCbCr 4:2:0)だから、interlacedの指定は必要。
x264に --colormatrix bt709(smpte170m)を付けておけば、デコードで間違える事もなくなる。
私はAviUtlを使わないので、それについてはコメントできない。
537:名無しさん＠編集中
09/02/05 13:18:51 ewMuHAv/
>>535
＞m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
そのくらい自分で試したらわかるだろ常考
普通のレコーダーならSDのTSだろうがアナログだろうがD1・D2ならBT.601に、D3・D4ならBT.709で出力される。
深夜にチャンネル片端から調べたらテストパターンいくらでも見つかるんだからHD、SD、地アナそれぞれ
録画して調べたらわかる。
538:名無しさん＠編集中
09/02/14 11:20:20 dw7BNvr7
じゃあ強引にBT709で作った規格外DVDはどうなるの？
(出来るのか？意味あるのか？というのは置いといて。)
539:名無しさん＠編集中
09/02/16 00:39:33 DOFIC1hR
>>538
おまえは何言ってるんだ？YUVデータにbt.709もbt.601もないだろがww
540:名無しさん＠編集中
09/02/20 01:36:31 iuyWOEIb
mp4の動画をffdshowで再生した時にオンスクリーンディスプレイで色空間を見たら
YV12,adjとなっていた。YV12は分かるとしてadjって何？
541:名無しさん＠編集中
09/02/20 03:08:27 etoDEjkN
あじゃすとじゃね
542:名無しさん＠編集中
09/02/22 02:41:43 geHe90rg
>>520
ちょっと微妙だな。せめて、ディスプレイの色温度ぐらい考慮しろよ・・・
白を基準に判別するなら。
543:名無しさん＠編集中
09/02/23 00:43:28 KBSCBtYv
>>538
ないのじゃなくてどちらの色空間で記録されてるかはあるだろ。
むしろBT.601の色空間で強引に記録したHD放送が欲しい位。
HDがBT.709で記録されたら最後、撮影時の彩度の高い赤も
エメラルドグリーンもxvYCCを使わない限り切り捨てられる点を何故誰も
騒がない？
現時点でDVDの方がBDより色域は広い。特に赤と緑は。
BT.709をBT601にmatrix変換？したら似非色表示で意味がなくなる。
YC伸張や色温度の話も良いが、色空間というなら限りなく狭いHDTVの
色空間を元に広げるハリウッドリマスター機能をフィルターにつけるべき。
そうでないとPC再生は今後絶望的では？
544:名無しさん＠編集中
09/02/23 08:41:40 30x+h4KM
んなキモい変換を前提にしたら互換性もなにもないし
素直に未使用領域使うxvYCCで収録しろ。未対応ならクリップされるから大丈夫だろ。
狭い空間の色を勝手に広帯域の範囲にまで拡張するのはカラーマネージメントを無視してるし
どの環境でもそれなりの色再現性があってこそだろ。
エメラルドグリーンを再現したければそれなりの色空間で近似色に変換させろ
RGBで再現不可能な領域は不可能のままで良い。