映像の【色】総合スレ
|
|
|
>>1
乙
乙
ｸﾙｯﾌﾟｰ
>>1
手抜き
手抜き
ここでいいのかな？
もう一度聞きなおしますが、
映像制作時に15以下があった場合は放送時に切られるってこと？
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
そういうことですか？
もう一度聞きなおしますが、
映像制作時に15以下があった場合は放送時に切られるってこと？
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
そういうことですか？
MPEG2を再生するときに、明るい部分が黒く再生されてしまうんですが、
これって伸張に間違いがあるということでしょうか？
と前スレに書いた者です。
書き忘れましたが、コーデックをNECのものからサイバーリンクのものに変えたらおきました。
>>前スレで答えてくれた方
故障って、それもふざけてますか？
真面目にお願いできないものでしょうか。
これって伸張に間違いがあるということでしょうか？
と前スレに書いた者です。
書き忘れましたが、コーデックをNECのものからサイバーリンクのものに変えたらおきました。
>>前スレで答えてくれた方
故障って、それもふざけてますか？
真面目にお願いできないものでしょうか。
ちなみに、全部のMPEG2がそうなるわけではありません。
8 ：名無しさん＠編集中：03/08/29 18:34
というかさぁ、おまい、ちゃんと状況書けよ。
テレビで見てんのか？パソモニ。？プロジェクタぁ？
状況詳しくわかんないと書けんだろが。
テレビで見てんのか？パソモニ。？プロジェクタぁ？
状況詳しくわかんないと書けんだろが。
すいません。
パソコンの画面です。
自分でエンコードしたMPEG2では起こらず、拾ったMPEG2では起きます。
MPEG1とAVIでは起きません。
謎なんです。
パソコンの画面です。
自分でエンコードしたMPEG2では起こらず、拾ったMPEG2では起きます。
MPEG1とAVIでは起きません。
謎なんです。
10 ：名無しさん＠編集中：03/08/29 18:45
一言「黒」といったってなぁ・・・・・
何IREくらい？
何IREくらい？
なんと言うか…。
画面の所々に黒い穴が開いたような…
□＝明るい部分の1ドット
■＝黒くなってしまってる部分の1ドット
□□□□□□□□□□□□
□□□■□□■■□□□□
□□□□□■■□□□□□
□□□□□□□□□□□□
□□□■□□□□□□□□
□□□□□□□□□□□□
□□■□■□□□□□□□
□□□□□□□□□□□□
画面の所々に黒い穴が開いたような…
□＝明るい部分の1ドット
■＝黒くなってしまってる部分の1ドット
□□□□□□□□□□□□
□□□■□□■■□□□□
□□□□□■■□□□□□
□□□□□□□□□□□□
□□□■□□□□□□□□
□□□□□□□□□□□□
□□■□■□□□□□□□
□□□□□□□□□□□□
何IREなのかはわからないんです。
IRE自体がわかりませんし。
IRE自体がわかりませんし。
13 ：名無しさん＠編集中：03/08/29 18:48
暗くなってるの？それとも真っ黒になってるの？
みんな好きだなぁ。
>009
単に 235 以上の pel が伸張の結果オーバーフローして 0 とか 1 とかになっ
てるんじゃないの？
サイバーリンクに変えてからなったていうのなら、サイバーリンク捨てて元に
もどせばいいだけじゃん。
>009
単に 235 以上の pel が伸張の結果オーバーフローして 0 とか 1 とかになっ
てるんじゃないの？
サイバーリンクに変えてからなったていうのなら、サイバーリンク捨てて元に
もどせばいいだけじゃん。
>>13
真っ黒です。
>>14
戻したくないんです。
NECのではMPEG2の60fps再生が出来ないので…。
それと、伸張がおかしいのが原因かどうかさえわかればいいんです。
おかしかったら戻すように再エンコするので。
もっとはっきり言うと、伸張がおかしいかどうかが自分ではわからないので、
その現象が起きるか起きないかで判断できたらいいと思ってるんです。
真っ黒です。
>>14
戻したくないんです。
NECのではMPEG2の60fps再生が出来ないので…。
それと、伸張がおかしいのが原因かどうかさえわかればいいんです。
おかしかったら戻すように再エンコするので。
もっとはっきり言うと、伸張がおかしいかどうかが自分ではわからないので、
その現象が起きるか起きないかで判断できたらいいと思ってるんです。
16 ：名無しさん＠編集中：03/08/29 19:01
オーバーロードしても真っ黒にはならんだろうから、
例えばY=255とか平気で記録しちゃってるMPEGかもしれない。
要するにネットに乗っけた奴のエンコがタコ。
ところでその真っ黒の領域って四角形でいいのかな？
不定形だと話も変わってくるんだが
例えばY=255とか平気で記録しちゃってるMPEGかもしれない。
要するにネットに乗っけた奴のエンコがタコ。
ところでその真っ黒の領域って四角形でいいのかな？
不定形だと話も変わってくるんだが
デジタル化（キャプチャ）したものに対して、何IREとか無意味なこと問うな。
IREはアナログ信号の単位だ。(Vp-pが何mVかってことなのでデジタルにとって意味なし）
IREはアナログ信号の単位だ。(Vp-pが何mVかってことなのでデジタルにとって意味なし）
18 ：＞＞17：03/08/29 19:12
くだらんことをいちいち知ったかぶりして解説して得意になってるヴァカﾊｹｰﾝ
まー、中学生にしちゃ、IREを知ってるのは優等生かな？
明るいだの暗いだの言っても日本語じゃ３段階くらいにしか表現で禁から、
アナログだとどのくらいの明るさか、という意味で問うたまで。
べつにデジタルの量子化何段階目？と聞いてもよいが、
イパーン的ではないからな。
ま、おまいのような奴シロートはすっこんどれ。
まー、中学生にしちゃ、IREを知ってるのは優等生かな？
明るいだの暗いだの言っても日本語じゃ３段階くらいにしか表現で禁から、
アナログだとどのくらいの明るさか、という意味で問うたまで。
べつにデジタルの量子化何段階目？と聞いてもよいが、
イパーン的ではないからな。
ま、おまいのような奴シロートはすっこんどれ。
>>16
四角は四角なんですが、16×16ドットくらいの■ではなく、1ドットの■なんです。
こんな感じで明るい部分にポツポツと。
← 704 →
---------------------------- ↑
l l
l , ; l
l :. , l
l ; .^ ; l
l , l 480
l l
l l
l l ↓
----------------------------
>要するにネットに乗っけた奴のエンコがタコ。
かもしれません。2コマ進んで1コマ戻るような再生でしたし。
四角は四角なんですが、16×16ドットくらいの■ではなく、1ドットの■なんです。
こんな感じで明るい部分にポツポツと。
← 704 →
---------------------------- ↑
l l
l , ; l
l :. , l
l ; .^ ; l
l , l 480
l l
l l
l l ↓
----------------------------
>要するにネットに乗っけた奴のエンコがタコ。
かもしれません。2コマ進んで1コマ戻るような再生でしたし。
IREも量子化段階と同じくらいイパーン的ではないわな
21 ：名無しさん＠編集中：03/08/29 20:08
>>19
ドット単位ということなら、やはりＹ＝255を許しちゃってるコーデックのような・・・・
エラー防止のために255→1とかに変換してるのかも知れん。
コーデックが糞と言うよりも、コーデック前のＡＶＩが腐っとる可能性があるな。
Premiereを使い、「色の置き換え」でRGB＝1,1,1→RGB＝254,254,254などとして最エンコすると言うのはどうだろ？
ドット単位ということなら、やはりＹ＝255を許しちゃってるコーデックのような・・・・
エラー防止のために255→1とかに変換してるのかも知れん。
コーデックが糞と言うよりも、コーデック前のＡＶＩが腐っとる可能性があるな。
Premiereを使い、「色の置き換え」でRGB＝1,1,1→RGB＝254,254,254などとして最エンコすると言うのはどうだろ？
20⇒負け犬の遠吠え・・・・・
じゃあ下が3IREだったらどうだってんだよ。
キャプチャしたら、これが0になっらたり30になったりするじゃんか。
意味あるの？
キャプチャしたら、これが0になっらたり30になったりするじゃんか。
意味あるの？
？？？？？？？？？
その前に、スペアナとか持ってる奴じゃないと信号なんて測れない。
キャプしてる奴に、何IREって聞くのは何の意図があるのか？
キャプしてる奴に、何IREって聞くのは何の意図があるのか？
粘着君？粘着君？粘着君？
>>18
いいかげん、自分の非を認めたら？
いいかげん、自分の非を認めたら？
あの・・・誰か>>5に答えてくれません？
相変わらず此処は混沌としているな
>>21
そうですか…。
くどいようですが、エンコード時に伸張されてしまってるということでしょうか？
普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね？
変なこと言ってたらすいません。
そうですか…。
くどいようですが、エンコード時に伸張されてしまってるということでしょうか？
普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね？
変なこと言ってたらすいません。
>>30
>普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね？
それが多い。というか再生時に YUV オーバーレイで勝手に伸張される（nVidia 以外では）
30 の場合問題なのは、235 以上の Y 成分が含まれていた際に、伸張されて 255 を超えた
（例えば 260 とかになった）のが 255 にクリップ（飽和）されずに、最上位ビットが削ら
れて 0～16 ぐらいの RGB 値になってしまっている点。
いくらサイバーリンクがアホでも DVD 再生ソフト販売はじめて３年以上経つ企業の製品で
そんなバグが残ってる訳がないので、30 の環境が腐ってるに一票。
再生時に余計なフィルタが挟まってないか調べてみた方がいい。
>普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね？
それが多い。というか再生時に YUV オーバーレイで勝手に伸張される（nVidia 以外では）
30 の場合問題なのは、235 以上の Y 成分が含まれていた際に、伸張されて 255 を超えた
（例えば 260 とかになった）のが 255 にクリップ（飽和）されずに、最上位ビットが削ら
れて 0～16 ぐらいの RGB 値になってしまっている点。
いくらサイバーリンクがアホでも DVD 再生ソフト販売はじめて３年以上経つ企業の製品で
そんなバグが残ってる訳がないので、30 の環境が腐ってるに一票。
再生時に余計なフィルタが挟まってないか調べてみた方がいい。
>>30
ハードウェア動画支援切るとどう？
あと、再エンコしても構わないと書いてるようだが
それならm2v.aui経由でAviutlで表示するとどうよ
Aviutlでもおかしいなら該当ピクセルをGNBのベクトル表示で確認してみよ
現象自体は3DYCやアンチクロスカラーフィルタの色抜けに似てるけどな
ハードウェア動画支援切るとどう？
あと、再エンコしても構わないと書いてるようだが
それならm2v.aui経由でAviutlで表示するとどうよ
Aviutlでもおかしいなら該当ピクセルをGNBのベクトル表示で確認してみよ
現象自体は3DYCやアンチクロスカラーフィルタの色抜けに似てるけどな
>30 の環境が腐ってるに一票。
腐ってました。
再生支援をOFFにしたら起きなくなりました。
しかし、ONにしないと60fps再生できない…。
難しいですね…。
腐ってました。
再生支援をOFFにしたら起きなくなりました。
しかし、ONにしないと60fps再生できない…。
難しいですね…。
なんて書いてたら、
>>33
>ハードウェア動画支援切るとどう？
やっぱりそれなんですね。起きなくなりましたよ。
GNBのベクトル表示とかの話は全然わかりません。
その辺は自分で調べてみようと思います。
>>33
>ハードウェア動画支援切るとどう？
やっぱりそれなんですね。起きなくなりましたよ。
GNBのベクトル表示とかの話は全然わかりません。
その辺は自分で調べてみようと思います。
>>20
おまえ、この業界の人間ではないな。旅に出ろ
>>25
おまえ、スペアななんかで計ってるのか。だからバカなんだよ
>>27
おまえは前スレから居住し続けている嫌われ者君なので、逝ってよし
で、結局は同一君ってか・・・・
おまえ、この業界の人間ではないな。旅に出ろ
>>25
おまえ、スペアななんかで計ってるのか。だからバカなんだよ
>>27
おまえは前スレから居住し続けている嫌われ者君なので、逝ってよし
で、結局は同一君ってか・・・・
藻前らウザイぞ
厨もうざけりゃ、いちいち喰ってかかるプロももっとうざい
とっととよそへ逝け！
厨もうざけりゃ、いちいち喰ってかかるプロももっとうざい
とっととよそへ逝け！
38や39がうるさいので・・・・・・
居 座 り ま す ！
居 座 り ま す ！
41 ：Y田：03/08/30 09:51
お い ら も 居 座 り ま す ！
42 ：名無しさん＠編集中：03/08/30 09:57
どうぞ。
44 ：名無しさん＠編集中：03/08/30 10:11
20が荒らしたから見難い。。。。。。
動画の一部うｐした方が早いぞ、もはや
動画だけうpしてどないすんねん。
環境ごとじゃないと。
環境ごとじゃないと。
誰か>>5に・・・
yes,noでいいので答えてもらえませんか？
yes,noでいいので答えてもらえませんか？
48 ：名無しさん＠編集中：03/08/30 15:31
yes
49 ：名無しさん＠編集中：03/08/30 15:33
no
yes
カワイソーな47・・・・・・・
52 ：名無しさん＠編集中：03/08/30 16:31
yes,no
53 ：名無しさん＠編集中：03/08/30 16:36
>>52
今夜はどっち？
今夜はどっち？
枕かよっ
ちゃんと否定してくれる人がいないってことはなんとなくは正解なんだろうきっと
そう思っときます・・・
そう思っときます・・・
>55
だいたいそういう意味だと思っていいはず。
ただし、ここでいう 0-15 ってのはアナログ NTSC-J での IRE 0～7 に相当するので
NTSC(Setup 7.5) 設定のキャプチャボードで取り込むと Y=0～15 がバリバリに出てくる。
だいたいそういう意味だと思っていいはず。
ただし、ここでいう 0-15 ってのはアナログ NTSC-J での IRE 0～7 に相当するので
NTSC(Setup 7.5) 設定のキャプチャボードで取り込むと Y=0～15 がバリバリに出てくる。
57 ：名無しさん＠編集中：03/08/30 22:27
＞ここでいう 0-15 ってのはアナログ NTSC-J での IRE 0～7 に相当するので
何いってんの？
何いってんの？
58 ：DVE：03/08/31 00:47
DVDのsuper blackってIRE 15 ?
16daro
わけわからんやつが混ざってるな。
61 ：名無しさん＠編集中：03/08/31 13:19
居座ってる山田だろ。
>>57
たしかに訳わからんこと書いてた。もういちど整理して書き直す
・前スレで放送系プロが（テスト信号以外では）絶対にないと言って
いた Y=0～15 のデータは、NTSC-J では IRE -7～0 に相当する
・NTSC-J では IRE 0～7.5 は映像信号として存在する
・NTSC-J のアナログ信号を NTSC (setup 7.5) に設定されたキャプ
チャボードで取り込むと、IRE 0～7.5 の部分が Y=0～15 として
出てくる
以上。
たしかに訳わからんこと書いてた。もういちど整理して書き直す
・前スレで放送系プロが（テスト信号以外では）絶対にないと言って
いた Y=0～15 のデータは、NTSC-J では IRE -7～0 に相当する
・NTSC-J では IRE 0～7.5 は映像信号として存在する
・NTSC-J のアナログ信号を NTSC (setup 7.5) に設定されたキャプ
チャボードで取り込むと、IRE 0～7.5 の部分が Y=0～15 として
出てくる
以上。
63 ：名無しさん＠編集中：03/08/31 20:22
それならわかるよ
↑脳味噌腐ってんな。
YC伸張ですが、基本的には、エンコード時等には行わず、再生時に
プレイヤー側が伸張するのが、正しいと認識していますが、パッと見、
再生時に伸張されてるように、あまり見えません。
使用カードは、Radeon9000なんで、オーバーレイはYUV伸張に対応
してると思うんですが、プレイヤーとかcodecとかの相性とか有るんでしょうか。
DivXもmpeg2(CyberLink)も、伸張してるように見えないです。
プレイヤー側が伸張するのが、正しいと認識していますが、パッと見、
再生時に伸張されてるように、あまり見えません。
使用カードは、Radeon9000なんで、オーバーレイはYUV伸張に対応
してると思うんですが、プレイヤーとかcodecとかの相性とか有るんでしょうか。
DivXもmpeg2(CyberLink)も、伸張してるように見えないです。
パッと見とかじゃなくてストレート展開したものと並べて見比べてみたら？
↑脳味噌腐ってんな。
>>65
編集ソフトのプレビュと同じ見え方だったら伸張されてるんだけど、
再生時伸張されてないってことは、
編集時よりコントラストが低く（暗い所が薄明るく明るい所が暗く）見えたり
色が淡くなったりして見えているということですか？
編集ソフトのプレビュと同じ見え方だったら伸張されてるんだけど、
再生時伸張されてないってことは、
編集時よりコントラストが低く（暗い所が薄明るく明るい所が暗く）見えたり
色が淡くなったりして見えているということですか？
>>65
ソースがRGBとか？
ソースがRGBとか？
>>70
コンポジット入力でキャプってます。
コンポジット入力でキャプってます。
>>71
釣れますか？
釣れますか？
mpeg2キャプチャ(スマビHG/V) -> aviutl+m2v.aui(YUY2入力) -> ノイズ除去等
-> DivX出力(YUY2圧縮)
もしくは、-> Huffyuv(YUY2圧縮) -> CCE(YUY2での入力)
で、出来たDivXをXBOXで再生したり、CCEで作ったmpeg2をDVD-VIDEOに
焼いてDVDデッキにて再生すると、録画時と同じくらいの明るさで表示されます
が、DivXをPC上で再生すると、暗くぼやけた感じにしか表示されません。
Aviutlで編集の際、YC伸張フィルタをかけると、TVでの表示に近く
なるので、PC上での再生では、YC伸張されてないような気がします。
>68
プレビューと同じ見え方だと伸張されてるんですか？
YUY2 -> Aviutl内部YUV -> YUY2(->YV12)の流れになってると思うのです
が、そうすると、出力されたYUY2(or YV12)を再生する際、オーバーレイにて、
YC伸張されて、プレビューより明るくなる、と考えていたんですが・・
実際、XBOXやDVDデッキでの表示では、同データで明るめに表示されてますし。
-> DivX出力(YUY2圧縮)
もしくは、-> Huffyuv(YUY2圧縮) -> CCE(YUY2での入力)
で、出来たDivXをXBOXで再生したり、CCEで作ったmpeg2をDVD-VIDEOに
焼いてDVDデッキにて再生すると、録画時と同じくらいの明るさで表示されます
が、DivXをPC上で再生すると、暗くぼやけた感じにしか表示されません。
Aviutlで編集の際、YC伸張フィルタをかけると、TVでの表示に近く
なるので、PC上での再生では、YC伸張されてないような気がします。
>68
プレビューと同じ見え方だと伸張されてるんですか？
YUY2 -> Aviutl内部YUV -> YUY2(->YV12)の流れになってると思うのです
が、そうすると、出力されたYUY2(or YV12)を再生する際、オーバーレイにて、
YC伸張されて、プレビューより明るくなる、と考えていたんですが・・
実際、XBOXやDVDデッキでの表示では、同データで明るめに表示されてますし。
･hunuaaCapでキャプチャ → huffyuvS、YUY2
･AviUtl 0.98dで読み込み → YUY2で展開、圧縮チェックなし
･huffyuvSで中間ファイル出力 → YUY2=Predict median(best)、RGB=Convert to YUY2
･TMPGEncでエンコード → Basic YCbCrチェックあり
今まで↑のようにやっていたんですがAviUtl 0.99になってからちょっと混乱してきたのでおしえてください
･hunuaaCapでキャプチャ → huffyuv、YUY2
･AviUtl 0.99で読み込み → YUY2で展開、圧縮チェックあり、YUY2変換時に～飽和チェックなし
･huffyuvで中間ファイル出力 → YUY2=Predict median(best)、RGB=Predict gradient(best)
･TMPGEncでエンコード → Basic YCbCrチェックなし
↑のように変えてみたんですがこれであってますか？
･AviUtl 0.98dで読み込み → YUY2で展開、圧縮チェックなし
･huffyuvSで中間ファイル出力 → YUY2=Predict median(best)、RGB=Convert to YUY2
･TMPGEncでエンコード → Basic YCbCrチェックあり
今まで↑のようにやっていたんですがAviUtl 0.99になってからちょっと混乱してきたのでおしえてください
･hunuaaCapでキャプチャ → huffyuv、YUY2
･AviUtl 0.99で読み込み → YUY2で展開、圧縮チェックあり、YUY2変換時に～飽和チェックなし
･huffyuvで中間ファイル出力 → YUY2=Predict median(best)、RGB=Predict gradient(best)
･TMPGEncでエンコード → Basic YCbCrチェックなし
↑のように変えてみたんですがこれであってますか？
>>73
MPEG2をATi+CyberLinkなら
デフォで伸張より明るくなるくらいなんだが？
DirectXが古いとかかなぁ
DivXに関してはプレイヤーによりけり
Aviutl99だとGDI表示時に伸張変換でRGBになると思うが
（勿論内部的にはYUV444。）
Aviutlでオーバーレイ表示オンオフだとどう？
↑の環境ならオーバーレイのほうがやや明るい
MPEG2をATi+CyberLinkなら
デフォで伸張より明るくなるくらいなんだが？
DirectXが古いとかかなぁ
DivXに関してはプレイヤーによりけり
Aviutl99だとGDI表示時に伸張変換でRGBになると思うが
（勿論内部的にはYUV444。）
Aviutlでオーバーレイ表示オンオフだとどう？
↑の環境ならオーバーレイのほうがやや明るい
>>74
TMPGEncはRGB入力のみ
この場合RGB化はHuffyuvが行う
Huffyuv内部でのYUY2>RGBは伸張変換
伸張RGBはBasic YCbCrチェキなしで受ける
つまりあってるけど
”YUY2変換時に～飽和チェック ”
はいれてもいれなくても伸張されて渡されるから同じ
TMPGEncはRGB入力のみ
この場合RGB化はHuffyuvが行う
Huffyuv内部でのYUY2>RGBは伸張変換
伸張RGBはBasic YCbCrチェキなしで受ける
つまりあってるけど
”YUY2変換時に～飽和チェック ”
はいれてもいれなくても伸張されて渡されるから同じ
エンコード後の結果は同じでも
中間ファイルのサイズは飽和させたほうが小さくなる
中間ファイルのサイズは飽和させたほうが小さくなる
>75
mpeg2が明るくなっているのは、CyberLinkのデコーダーデフォルトが、ビビット色調に
なってて、明るめに表示されてるからで、伸張とは関係ない気がします。
実際、ビビットからデフォルトにすると、うす暗い配色になります。
DirectXは、9.0b、メインマシンとサブで、それぞれ、Radeon9500と9000が入ってます
が、どちらも、伸張されてる気配はなく、Aviutlでの明るさもオーバーレイとGDIで、
あんまり差がないような感じです。
mpeg2が明るくなっているのは、CyberLinkのデコーダーデフォルトが、ビビット色調に
なってて、明るめに表示されてるからで、伸張とは関係ない気がします。
実際、ビビットからデフォルトにすると、うす暗い配色になります。
DirectXは、9.0b、メインマシンとサブで、それぞれ、Radeon9500と9000が入ってます
が、どちらも、伸張されてる気配はなく、Aviutlでの明るさもオーバーレイとGDIで、
あんまり差がないような感じです。
単にテレビとPCディスプレイの明るさの違いというオチだったりして。
DVD2AVIのプレビューで
「YUV422」と「RGB PC色調」/「RGB TV色調」を切り替えてみれば分かるよ。
「YUV422」と「RGB PC色調」が同じに見えればRADEONはYC伸張してる。
「YUV422」と「RGB TV色調」が同じに見えればRADEONはYC伸張してない。
「YUV422」と「RGB PC色調」/「RGB TV色調」を切り替えてみれば分かるよ。
「YUV422」と「RGB PC色調」が同じに見えればRADEONはYC伸張してる。
「YUV422」と「RGB TV色調」が同じに見えればRADEONはYC伸張してない。
ﾗﾃﾞのオーバーレイがYC伸張してなかったという衝撃の新事実
87 ：名無しさん＠編集中：03/09/04 00:11
i845GE内蔵グラフィックを使用しているのですが
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ここから拾ってきた調整用映像を使い、
非オーバーレイとオーバーレイを並べて表示してみると
オーバーレイにするとR,G,Bそれぞれワンランク足されたような感じです。
つまり、
・黒が浮き
・白も飛ぶ
→RGB=1,1,1をオーバーレイ表示すると非オーバーレイのRGB=16,16,16ぐらいに見える
→RGB=235,235,235をオーバーレイ表示すると非オーバーレイのRGB=254,254,254ぐらいに見える
モニター調整にも限度があるし、見づらくて困っています。
ドライバのバージョンは 6.13.01.3307 なんですが何か悪いのでしょうか。
それとも845GEはそういうものなのでしょうか。
分かる人教えてください。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ここから拾ってきた調整用映像を使い、
非オーバーレイとオーバーレイを並べて表示してみると
オーバーレイにするとR,G,Bそれぞれワンランク足されたような感じです。
つまり、
・黒が浮き
・白も飛ぶ
→RGB=1,1,1をオーバーレイ表示すると非オーバーレイのRGB=16,16,16ぐらいに見える
→RGB=235,235,235をオーバーレイ表示すると非オーバーレイのRGB=254,254,254ぐらいに見える
モニター調整にも限度があるし、見づらくて困っています。
ドライバのバージョンは 6.13.01.3307 なんですが何か悪いのでしょうか。
それとも845GEはそういうものなのでしょうか。
分かる人教えてください。
TMPGEncで、
「DVはCCIR60で記録されてるから、Basic YCbCrで出力した方がいい場合がある」
みたいなことが書いてありますが、DVDレコで録画したものをソースにする場合もそうした方がいいんでしょうか？
そんなことをしたら、DVDに焼いてDVDプレイヤーで再生させた時に、明るすぎるような気がするのですが。
「DVはCCIR60で記録されてるから、Basic YCbCrで出力した方がいい場合がある」
みたいなことが書いてありますが、DVDレコで録画したものをソースにする場合もそうした方がいいんでしょうか？
そんなことをしたら、DVDに焼いてDVDプレイヤーで再生させた時に、明るすぎるような気がするのですが。
>>89
これはTMPGEncが生まれた当時の状況を反映した結果です。
当時、まともに使えるDV-CodecはCanopusDVだけであり、
CanopusDVはRGB展開するときにストレート変換を行います。
ところがYUV系Codecは一般的に
エンコードする時はYC圧縮をおこない、
デコードする時はYC伸張するものです。
そこでRGB内部処理のTMPGEncでは、
YUV系Codecに倣ってYC伸張済みRGB入力を基本とした設計がなされました。
最終的にはMPEGにするわけですから、
ファイル出力時にYC圧縮してYUVに変換するわけです。
ところがCanopusDVをソースにした場合これでは困るわけです。
そこで"Basic YCbCr～"のオプションが作られたわけです。
これをonにすることによりストレートRGBでも不具合なくエンコードできるわけです。
「DVはCCIR60で記録されてるから、Basic YCbCrで出力した方がいい場合がある」
というのを説明しますと、
「DVCodecはBT.601に規定された変換であるストレートRGBしか
吐き出さないものがあるため、その場合はCodecの変換に頼らず
YUV系Codecでは一般的なのBasic YCbCr処理により伸張したほうがいい場合がある。」
となります。
質問のDVDレコに関してですが、
勿論DVデッキ同様BT.601規定のYUVで記録されてるわけですが
ここで問題になるのはRGBへの変換式であって
データソースがBT.601であるかどうかは関係ありません。
デコードするときに伸張させてるかどうかが重要です。
つまり ”何を使って””どんな設定で””TMPGEncに読み込ませているのか？”
によって回答は変わります。
これはTMPGEncが生まれた当時の状況を反映した結果です。
当時、まともに使えるDV-CodecはCanopusDVだけであり、
CanopusDVはRGB展開するときにストレート変換を行います。
ところがYUV系Codecは一般的に
エンコードする時はYC圧縮をおこない、
デコードする時はYC伸張するものです。
そこでRGB内部処理のTMPGEncでは、
YUV系Codecに倣ってYC伸張済みRGB入力を基本とした設計がなされました。
最終的にはMPEGにするわけですから、
ファイル出力時にYC圧縮してYUVに変換するわけです。
ところがCanopusDVをソースにした場合これでは困るわけです。
そこで"Basic YCbCr～"のオプションが作られたわけです。
これをonにすることによりストレートRGBでも不具合なくエンコードできるわけです。
「DVはCCIR60で記録されてるから、Basic YCbCrで出力した方がいい場合がある」
というのを説明しますと、
「DVCodecはBT.601に規定された変換であるストレートRGBしか
吐き出さないものがあるため、その場合はCodecの変換に頼らず
YUV系Codecでは一般的なのBasic YCbCr処理により伸張したほうがいい場合がある。」
となります。
質問のDVDレコに関してですが、
勿論DVデッキ同様BT.601規定のYUVで記録されてるわけですが
ここで問題になるのはRGBへの変換式であって
データソースがBT.601であるかどうかは関係ありません。
デコードするときに伸張させてるかどうかが重要です。
つまり ”何を使って””どんな設定で””TMPGEncに読み込ませているのか？”
によって回答は変わります。
>>80
お返事遅れてごめんなさい
前者はできてるはずだけど後者は分かんないや・・・・
飽和させたほうがサイズも縮むみたいだし飽和させることにしました
禁句なのに答えてくれてありがとー♪ヽ（・∀・）ﾉ
お返事遅れてごめんなさい
前者はできてるはずだけど後者は分かんないや・・・・
飽和させたほうがサイズも縮むみたいだし飽和させることにしました
禁句なのに答えてくれてありがとー♪ヽ（・∀・）ﾉ
だからテンプレ作れば良かったのに。
↑すいません。途中で書き込んでしまいました。
なるほど。
ということは、「YUVデータをCCI601ではなく…」という項目は、圧縮するかどうかということなんですね。
カノープスDVは伸張されず16-235のまま扱われるから、チェックを入れないと、圧縮されてしまってまずいということですか。
最終的に16-235にしたい場合、読み込まれた状態が16-235ならチェックを入れ、0-255ならチェックを入れないと。
よくわかりました。ありがとうございます。
なるほど。
ということは、「YUVデータをCCI601ではなく…」という項目は、圧縮するかどうかということなんですね。
カノープスDVは伸張されず16-235のまま扱われるから、チェックを入れないと、圧縮されてしまってまずいということですか。
最終的に16-235にしたい場合、読み込まれた状態が16-235ならチェックを入れ、0-255ならチェックを入れないと。
よくわかりました。ありがとうございます。
>>93
テンプレ作るとオレのやることなくなるからな
テンプレ作るとオレのやることなくなるからな
テンプレ
PCでしか見ないときはPC色調にします
TV出力をするときはTV色調にします
PCでしか見ないときはPC色調にします
TV出力をするときはTV色調にします
テンプレで嘘ついてどうする
え？>>96って嘘なの？
96の後者だけは合ってない？
PCでしか見ないとき とか TV出力をするとき とか
そういう区分が間違ってるんだよ
あと、PC色調にします とか TV色調にします とか
何？意味が分からん
みんな同じソフト使ってるわけじゃないんだからちゃんとした用語を使ってくれ
そういう区分が間違ってるんだよ
あと、PC色調にします とか TV色調にします とか
何？意味が分からん
みんな同じソフト使ってるわけじゃないんだからちゃんとした用語を使ってくれ
ネタにマジレスの典型が見られました
TVで見ようがPCで見ようが16-235が正解
え・・・
RGBフルスケールになるようにしてるよ・・・
RGBフルスケールになるようにしてるよ・・・
メディアプレイヤーでの再生時に、伸張させないようにするにはどうすればいいんでしょう？
↑オーバーレイとかいうやつのチェックをはずしても色が変わりませんでした。
映像の色範囲を変えずに編集をする方法とか、サチュレートする方法やしない方法など
そういったものならテンプレにできるかもな
でも、どういう色が正しいのかみたいなのは好みの問題も多く含んでくるから無理かもね
ちゃんとした色で放送してるとは限らないしキャプボのくせもあるだろうし
そういったものならテンプレにできるかもな
でも、どういう色が正しいのかみたいなのは好みの問題も多く含んでくるから無理かもね
ちゃんとした色で放送してるとは限らないしキャプボのくせもあるだろうし
前から思ってたんだけどさ
音声だとノーマライズってあるじゃん？一番大きな音が、フルスケールになるように調整される
やつ。
これの映像版ってある？
一番大きなRGBのどれかの成分にあわせて、それがフルスケールになるように調節される
機能とかってない？
音声だとノーマライズってあるじゃん？一番大きな音が、フルスケールになるように調整される
やつ。
これの映像版ってある？
一番大きなRGBのどれかの成分にあわせて、それがフルスケールになるように調節される
機能とかってない？
個人的にはノーマライズも欲しいが
コンプレッサーも欲しい
拡張色調補正のガンマ調整だけではキツイ
たぶん業務用ソフトには当然ついてる機能だとは思うが
コンプレッサーも欲しい
拡張色調補正のガンマ調整だけではキツイ
たぶん業務用ソフトには当然ついてる機能だとは思うが
なんかプロのオーサリング屋からして混乱しているが
http://pc.2ch.net/test/read.cgi/avi/1048403135/191-
http://pc.2ch.net/test/read.cgi/avi/1048403135/191-
113 ：名無しさん＠編集中：03/09/07 00:37
>>112
意図してやってんのか、無知でそうなってんのか分からんな。
意図してやってんのか、無知でそうなってんのか分からんな。
あまりプロを馬鹿にしないほうがいいよ、ｷｬﾌﾟ厨さん（ﾌﾟ
テレビで放送する映画って画質ザラザラして汚いね
>>114
>いや、テレビ（＠スカパ）もやってるCG屋だよ
>16-235の仕組みを教えてあげて、
>http://www6.ocn.ne.jp/~whkawan/OverlayAdjust.pdf
>このページを見るように、忠告してみた
>それ以上は、教えん（教えられんｗ
編集マンのつぶやき
http://pc.2ch.net/test/read.cgi/avi/1040907007/778-
>いや、テレビ（＠スカパ）もやってるCG屋だよ
>16-235の仕組みを教えてあげて、
>http://www6.ocn.ne.jp/~whkawan/OverlayAdjust.pdf
>このページを見るように、忠告してみた
>それ以上は、教えん（教えられんｗ
編集マンのつぶやき
http://pc.2ch.net/test/read.cgi/avi/1040907007/778-
118 ：名無しさん＠編集中：03/09/08 00:46
>>117
>そのPDFやってる有限なんだが、なんだよあそこ。
>http://www6.ocn.ne.jp/~whkawan/editroom-1.html
>これがレンタル編集室？プッ！
>爆笑もんだろ。ピクモニくらい置いとけや。
>なんだ、あのベクトル。潜水艦に積んであるソナーでも改造したのか？？
>DVCAMはDSR-30だろ。型番くらい把握しとけ。
>１ コンピュータ映像処理に関する教育、コンサルタント
>おまえみたいな奴にコンサルタントなんかしてもらいたくないね。
>６ 乗用車、自動二輪車及び付属品の輸入販売
>って、おいおい、じつは何でも屋ってオチかい。
>ギョーカイも結構ちんけなところと付き合ってんだな。
>これじゃ、ろくな素材集まらんだろ。
>そのPDFやってる有限なんだが、なんだよあそこ。
>http://www6.ocn.ne.jp/~whkawan/editroom-1.html
>これがレンタル編集室？プッ！
>爆笑もんだろ。ピクモニくらい置いとけや。
>なんだ、あのベクトル。潜水艦に積んであるソナーでも改造したのか？？
>DVCAMはDSR-30だろ。型番くらい把握しとけ。
>１ コンピュータ映像処理に関する教育、コンサルタント
>おまえみたいな奴にコンサルタントなんかしてもらいたくないね。
>６ 乗用車、自動二輪車及び付属品の輸入販売
>って、おいおい、じつは何でも屋ってオチかい。
>ギョーカイも結構ちんけなところと付き合ってんだな。
>これじゃ、ろくな素材集まらんだろ。
AviUtl→中間出力→Avisynthで仕上げ
てな感じでエンコードしているのですが、
色はどの段階でいじるのがBestですか？
てな感じでエンコードしているのですが、
色はどの段階でいじるのがBestですか？
最後
再生時
キャプチャ時
くだらねーこと言ってないでマジレスしろや
カス共
カス共
124 ：名無しさん＠編集中：03/09/09 20:02
↑
こいつのチンコは尻穴みたいに臭い。
こいつのチンコは尻穴みたいに臭い。
>>119
>>120
”フィルタの副作用で色変化がおきる可能性があるから、
最後に目で見て調整”＜正解
>>121
"所詮キャプチャー時に色を調整しても民生レベルではｱﾃにならん。
ｿｰｽﾃﾞｰﾀは維持しといて再生ｱﾌﾟﾘで自分好みにしてる”＜正解
>>122
”ｶﾗｰﾊﾞｰを基本にｷｬﾌﾟﾁｬｰ機器のｷｬﾘﾌﾞﾚｰﾄをしてる。
ﾌｨﾙﾀによる色変化なんてたかがしれてるし、
ﾃﾞﾌｫﾙﾄでｷｬﾌﾟするとﾚﾍﾞﾙｵｰﾊﾞｰが怖いしね”＜正解
どれもﾏｼﾞﾚｽなんだが？
>>120
”フィルタの副作用で色変化がおきる可能性があるから、
最後に目で見て調整”＜正解
>>121
"所詮キャプチャー時に色を調整しても民生レベルではｱﾃにならん。
ｿｰｽﾃﾞｰﾀは維持しといて再生ｱﾌﾟﾘで自分好みにしてる”＜正解
>>122
”ｶﾗｰﾊﾞｰを基本にｷｬﾌﾟﾁｬｰ機器のｷｬﾘﾌﾞﾚｰﾄをしてる。
ﾌｨﾙﾀによる色変化なんてたかがしれてるし、
ﾃﾞﾌｫﾙﾄでｷｬﾌﾟするとﾚﾍﾞﾙｵｰﾊﾞｰが怖いしね”＜正解
どれもﾏｼﾞﾚｽなんだが？
最初（キャプ時）にやっちゃえば後々楽だと思うけどね
マスターからして激しく白飛びしてたりしたらどーにもならんが
マスターからして激しく白飛びしてたりしたらどーにもならんが
>再生時
正解かどうかはともかく、一番安全だから初心者はこれ。
正解かどうかはともかく、一番安全だから初心者はこれ。
しかし元がダメじゃどうしようもないだろ
やはりキャプチャ時が一番重要
まあ本当に一番重要なのは撮影時なんだろうけどね
やはりキャプチャ時が一番重要
まあ本当に一番重要なのは撮影時なんだろうけどね
キャプチャ時の調整ってこんな感じで良いのでしょうか？
ttp://cwaweb.bai.ne.jp/~icchan/Data/hard/saa7130b.htm
ttp://cwaweb.bai.ne.jp/~icchan/Data/hard/saa7130b.htm
>>131-132
ありがとうございます。
良く読むと我が家ではカラーバーを出力する環境がないので^^; 同じ方法は採れないですが
動画連盟という所にカラーバーを作る方法が書いてあったのでちょっとやってみます。
（ここなんですけど）
ttp://www.katch.ne.jp/~sakaki/douga/kiji/mpeg1colorbar/mpeg1colorbar.html
ありがとうございます。
良く読むと我が家ではカラーバーを出力する環境がないので^^; 同じ方法は採れないですが
動画連盟という所にカラーバーを作る方法が書いてあったのでちょっとやってみます。
（ここなんですけど）
ttp://www.katch.ne.jp/~sakaki/douga/kiji/mpeg1colorbar/mpeg1colorbar.html
135 ：名無しさん＠編集中：03/09/20 01:59
348 ：[名無し]さん(bin+cue).rar ：03/09/19 22:29 ID:BLMMKtmN
>DVD-RAM/Rへ焼いて家電で見る。
無理。
ちゃんと規格に沿ったものが殆どないから。
まあ見るだけなら見れるが。
散々既出だが、テレビ出力用動画は
・音量上げるな
・色を伸張するな
・横720にするなら無効領域を足せ
・横704、480、352にするなら無効領域を削れ
・フィールドオーダー間違えるな。
・縦方向は一切いじるな
352 ：[名無し]さん(bin+cue).rar ：03/09/20 00:30 ID:VQwhoMMV
>>348
アニメはちょっと伸張した方がDVDに近づく
353 ：[名無し]さん(bin+cue).rar ：03/09/20 00:52 ID:1VopQfkT
>>352
伸張にちょっとも糞もあるかよ。
大体DVD自体が16-235の範囲に収まってるはずだから、
伸張したらDVDから遠ざかる。
>DVD-RAM/Rへ焼いて家電で見る。
無理。
ちゃんと規格に沿ったものが殆どないから。
まあ見るだけなら見れるが。
散々既出だが、テレビ出力用動画は
・音量上げるな
・色を伸張するな
・横720にするなら無効領域を足せ
・横704、480、352にするなら無効領域を削れ
・フィールドオーダー間違えるな。
・縦方向は一切いじるな
352 ：[名無し]さん(bin+cue).rar ：03/09/20 00:30 ID:VQwhoMMV
>>348
アニメはちょっと伸張した方がDVDに近づく
353 ：[名無し]さん(bin+cue).rar ：03/09/20 00:52 ID:1VopQfkT
>>352
伸張にちょっとも糞もあるかよ。
大体DVD自体が16-235の範囲に収まってるはずだから、
伸張したらDVDから遠ざかる。
まー、アニメに限らず地上波放送用マスターは、
クロマが高すぎると放送局に納品を拒否されるので、
下げられてることが多々ある。
クロマが高すぎると放送局に納品を拒否されるので、
下げられてることが多々ある。
まー君、出たな。
盛り下がってますね
前は盛り上がってたんですけどね
情報も議論も出尽くしたのかな？
ところで誰かBT.709の有効範囲知らない？
ところで誰かBT.709の有効範囲知らない？
知ってるがお前の態度が気に食わない
saa7130のチップで、0-255でキャプするのは間違ってるの？
143 ：名無しさん＠編集中：03/10/06 13:04
>>142
一度16-235でキャプしてみ。
一度16-235でキャプしてみ。
あ、俺0-255でやってる・・・(；´Д`)ﾄﾞｷﾄﾞｷ
そもそも色範囲指定で取り込めるのか？
編集時じゃなくて？
つーかYUVは0-15と236以降にもデータが入っててもかまわないことに
はなっているが、ヒストグラム見たところあんま超えてる画像って
無くない？だいたい範囲内だよね？
編集時じゃなくて？
つーかYUVは0-15と236以降にもデータが入っててもかまわないことに
はなっているが、ヒストグラム見たところあんま超えてる画像って
無くない？だいたい範囲内だよね？
明るさコントラストでどうにでもなるでしょ
>>142も質問がおかしいよ
0-255でキャプするとか16-235でキャプするとかどういう意味だよ
意味分かって使ってるの？
>>142はどういう状態を0-255でキャプするって言うわけ？
>>142も質問がおかしいよ
0-255でキャプするとか16-235でキャプするとかどういう意味だよ
意味分かって使ってるの？
>>142はどういう状態を0-255でキャプするって言うわけ？
わかってるくせに
huffyuvでYUY2でキャプしてるんですけど、
カラーバーをキャプして
波形表示プラグイン を使って調整してるんだけど、
補助線をCCIR601用にする にチェックつけても付けなくても
明るさとコントラストしだいで、どちらにも対応できるように
キャプできてしまうんで・・・
どっちが、いいのかな～と。
カラーバーをキャプして
波形表示プラグイン を使って調整してるんだけど、
補助線をCCIR601用にする にチェックつけても付けなくても
明るさとコントラストしだいで、どちらにも対応できるように
キャプできてしまうんで・・・
どっちが、いいのかな～と。
huffyuvならYUY2はAviUtlに読み込ませたときに伸張するから
0-255にあわせるのが正解
簡単に言えば、RGB展開するときに伸張するものは0-255、伸張しないものは16-235に合わせる
0-255にあわせるのが正解
簡単に言えば、RGB展開するときに伸張するものは0-255、伸張しないものは16-235に合わせる
>>149
huffyuvのYUY2って伸張してたっけ？ >AviUtil
huffyuvのYUY2って伸張してたっけ？ >AviUtil
RGBで読み込み > 伸張している
YUY2で読み込み > 伸張していない
この認識で良いか？
YUY2で読み込み > 伸張していない
この認識で良いか？
どっちも伸張してる
huffyuvのバグでチェックをしようがしまいが
常に伸張されるんじゃなかったか？
常に伸張されるんじゃなかったか？
>>151
補助線をどの位置にするのが正しいのかは伸張するしないで変わるから
コーデックによって変わるもので、デジタイザによって変わるわけではない
>>SAA7130の色範囲が16～235なので、補助線をCCIR601用にチェックを付けて見ていきます。
そのページは全く読んでないが、この一文から察するにたぶん、
「SAA7130は16-235の範囲外も録れるから、伸張しないで範囲外も見ていく」ってこと
正しい正しくないの話ではない
補助線をどの位置にするのが正しいのかは伸張するしないで変わるから
コーデックによって変わるもので、デジタイザによって変わるわけではない
>>SAA7130の色範囲が16～235なので、補助線をCCIR601用にチェックを付けて見ていきます。
そのページは全く読んでないが、この一文から察するにたぶん、
「SAA7130は16-235の範囲外も録れるから、伸張しないで範囲外も見ていく」ってこと
正しい正しくないの話ではない
>>155
そのページでは、使用コーデックはhuffyuv(YUY2)と明記されているんだけど・・・
そのページでは、使用コーデックはhuffyuv(YUY2)と明記されているんだけど・・・
>>154
バグっていうかYUVでもWYSIWYGで作業できるように親切設計になってるんじゃないの。
それを余計な親切はすな！と言って出てきたのがHuffyuvS。
RGB圧縮のhuffyuvの展開はストレート変換だよ。
バグっていうかYUVでもWYSIWYGで作業できるように親切設計になってるんじゃないの。
それを余計な親切はすな！と言って出てきたのがHuffyuvS。
RGB圧縮のhuffyuvの展開はストレート変換だよ。
親切設計のつもりで伸張しないオプションまで用意してあるのだが、
伸張されちゃうんだな、これが。
伸張されちゃうんだな、これが。
160 ：名無しさん＠編集中：03/10/07 22:52
HuffyuvSは最早過去の遺物ですよ
Aviutlのｻﾁｭﾚｰﾄ対策用だからな
99が出た今、使うﾒﾘｯﾄがない
99が出た今、使うﾒﾘｯﾄがない
TMPGユーザーを無視するなよ
長時間録画をする場合などにはRGBとYUVの容量の差は無視できない
TMPGEncにｶﾉｺﾃﾞ用だけじゃなくて
どんな入力に対しても色空間変換式を選択できるｵﾌﾟｼｮﾝがありゃいいんだな
正確にはVFAPIの問題だが
どんな入力に対しても色空間変換式を選択できるｵﾌﾟｼｮﾝがありゃいいんだな
正確にはVFAPIの問題だが
なんかちょっと前からHDDの値段がほとんど落ちなくなっててムカつく。
それ以前は毎年2倍ペースで同じ値段で容量倍になってたのに。
それ以前は毎年2倍ペースで同じ値段で容量倍になってたのに。
なんかﾁｮｿっぽい日本語になった。
まぁ大和魂で判れ。
まぁ大和魂で判れ。
誤爆か？
ニガーの漏れはどうしたらいいですか？
170 ：名無しさん＠編集中：03/10/08 23:09
>>165 に関連して
CanopusDV + TMPGEnc の組み合わせで今まで使ってきたのですが
環境設定→設定→色空間変換式のところで、
指定しない（チェック外す）にして変換をDVcodecにさせる（とポップアップに書いてある）と
その結果は 指定→BasicYCbCr とほぼ同じになる。
んで、今日たまたまAviUtl使ってみたんだけど
TMPGEncでいうところの 指定→CCIR-601 の結果とほぼ同じになってる。
TMPGEncの指定なしとAviUtlは同じになるとばかり思っていたのだが
これってどういうことですか？
CanopusDV + TMPGEnc の組み合わせで今まで使ってきたのですが
環境設定→設定→色空間変換式のところで、
指定しない（チェック外す）にして変換をDVcodecにさせる（とポップアップに書いてある）と
その結果は 指定→BasicYCbCr とほぼ同じになる。
んで、今日たまたまAviUtl使ってみたんだけど
TMPGEncでいうところの 指定→CCIR-601 の結果とほぼ同じになってる。
TMPGEncの指定なしとAviUtlは同じになるとばかり思っていたのだが
これってどういうことですか？
CanopusDV + Aviutl（0.98d）でエンコしてますが、
拡張色補正のTV->PCスケール補正のチェックボックスはオフ
環境設定のコーデックの設定でCanopusDV CodecのYUY2で展開と圧縮はオフ
で色補正は各パラメータを調整してやっています。
これって、おかしいですか？
拡張色補正のTV->PCスケール補正のチェックボックスはオフ
環境設定のコーデックの設定でCanopusDV CodecのYUY2で展開と圧縮はオフ
で色補正は各パラメータを調整してやっています。
これって、おかしいですか？
173 ：名無しさん＠編集中：03/10/09 00:23
>>172
ソースがDV？最終形式がDV？
ソースがDV？最終形式がDV？
174 ：170：03/10/09 00:42
>>172 とは別人です。
TMPGEncで連番BMP書き出ししたものと
AviUtlでは現在のフレームをコピペしてBMP保存したものを比べてました。
AviUtlのコーデックの設定はYUY2展開です。
huffyuv(YUY2)ほかいくつかのCODECで書き出して比べてみます・・・
TMPGEncで連番BMP書き出ししたものと
AviUtlでは現在のフレームをコピペしてBMP保存したものを比べてました。
AviUtlのコーデックの設定はYUY2展開です。
huffyuv(YUY2)ほかいくつかのCODECで書き出して比べてみます・・・
175 ：名無しさん＠編集中：03/10/09 00:44
176 ：名無しさん＠編集中：03/10/09 00:58
>>175
AVIUTLからCodec（VP3orXvid）にRGB、YUY2どちらで渡すにしても、
「拡張色補正のTV->PCスケール補正のチェックボックス」はオン
にしとかないとまずいね。
貴方の設定だとコントラストが足りない映像が出来上がるよ。VP3かXvidが
RGB→YUY2へのストレート変換に対応してればそれでも問題ないが、
恐らく対応してないのでどこかでYC伸張しないといけないね。
AVIUTLからCodec（VP3orXvid）にRGB、YUY2どちらで渡すにしても、
「拡張色補正のTV->PCスケール補正のチェックボックス」はオン
にしとかないとまずいね。
貴方の設定だとコントラストが足りない映像が出来上がるよ。VP3かXvidが
RGB→YUY2へのストレート変換に対応してればそれでも問題ないが、
恐らく対応してないのでどこかでYC伸張しないといけないね。
178 ：名無しさん＠編集中：03/10/09 02:04
家庭用DVカメラだと、環境変化によって
そもそも黒と白が変なレベルで記録されるので調整は難しいっす
あのシーンに合わせるとこっちがおかしくなる、みたいな感じで。
そういう意味では「拡張色調補正のTV→PCスケール」は
ぜんぜん役に立たないことがあります。
あと家庭用は全体的に色のりが悪いことがおおいので
彩度をちょっと上げてやったほうが見栄えがしますね。
そもそも黒と白が変なレベルで記録されるので調整は難しいっす
あのシーンに合わせるとこっちがおかしくなる、みたいな感じで。
そういう意味では「拡張色調補正のTV→PCスケール」は
ぜんぜん役に立たないことがあります。
あと家庭用は全体的に色のりが悪いことがおおいので
彩度をちょっと上げてやったほうが見栄えがしますね。
179 ：名無しさん＠編集中：03/10/09 02:28
家庭用DVのキャリブレートはほんと難しい。というかソフトじゃなくて
撮影技術の話になってくる。
撮影技術の話になってくる。
180 ：178：03/10/09 23:48
ふと思い立って、家庭用DV撮影の素材を編集後、
いったんテープに書き出し後、
オートゲインコントロール付のキャプチャボードでアナログキャプチャ
してみました。
結果、輝度レベルは満足できる程度にそろいました。
補正が面倒なときには使えるかな。
いったんテープに書き出し後、
オートゲインコントロール付のキャプチャボードでアナログキャプチャ
してみました。
結果、輝度レベルは満足できる程度にそろいました。
補正が面倒なときには使えるかな。
>176
VP3,Xvid がストレート変換に対応してないって話ですが、DivX5とか
WMV9 codecはどういった扱いなんでしょうか。
VP3,Xvid がストレート変換に対応してないって話ですが、DivX5とか
WMV9 codecはどういった扱いなんでしょうか。
>>183
DivXもWMV9も全部VP3、XviDと同じ。YUV->RGBは伸張、RGB->YUVは圧縮
ただし、DV CODECはストレート変換するものもあり、その場合は自分で伸張しないといけない。
TMPGEncなんかだとそのためのチェックボックスもあるが。
DivXもWMV9も全部VP3、XviDと同じ。YUV->RGBは伸張、RGB->YUVは圧縮
ただし、DV CODECはストレート変換するものもあり、その場合は自分で伸張しないといけない。
TMPGEncなんかだとそのためのチェックボックスもあるが。
>>184
WMVは兎も角DivXやXviDはYUY2入力可能
YUV系CodecでYUY2展開にチェックした場合や
MPEGをm2v.aui入力した場合は
「拡張色補正のTV->PCスケール補正のチェックボックス」はオフでいい
そもそも
>>172のCanopusDV CodecのYUY2で展開と圧縮はオフ
がおかしい
展開をオンにしとけばずっとYUV色空間処理になるから
スケール変換のことなど考える必要がない
WMVは兎も角DivXやXviDはYUY2入力可能
YUV系CodecでYUY2展開にチェックした場合や
MPEGをm2v.aui入力した場合は
「拡張色補正のTV->PCスケール補正のチェックボックス」はオフでいい
そもそも
>>172のCanopusDV CodecのYUY2で展開と圧縮はオフ
がおかしい
展開をオンにしとけばずっとYUV色空間処理になるから
スケール変換のことなど考える必要がない
>185
ということは、敢えて遠回しな表現で書くと、
YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オン -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
いや、すいません。自分で書いてみて、余計分からなくなってきました。
ということは、敢えて遠回しな表現で書くと、
YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オン -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
いや、すいません。自分で書いてみて、余計分からなくなってきました。
>>186
いや
YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オフ(nonexp.codec CanopusDVなど) -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
=YUY2展開オフ(expcodec. Huffyuvなど) -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
いや
YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オフ(nonexp.codec CanopusDVなど) -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
=YUY2展開オフ(expcodec. Huffyuvなど) -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
あー、誰か波形表示DirectShowフィルタ作ってくれねかな。
これなら、録画してAviUtlに読んで…の繰り返ししなくても
リアルタイムでhunuaaCapで色合わせできるのに。
ヒストグラムフィルタも使ってはいるけどねん。
これなら、録画してAviUtlに読んで…の繰り返ししなくても
リアルタイムでhunuaaCapで色合わせできるのに。
ヒストグラムフィルタも使ってはいるけどねん。
リアルタイムで表示できたら確かにかなり便利だな
てめえで作れ♪
自分で作れるぐらいならとっくに作っとるわ♪
192 ：名無しさん＠編集中：03/10/18 00:16
AviUtl掲示板でスケール変換議論再燃。
カノプーってRGBとYUVの変換精度が悪いみたいですね。↓ここ
http://pc.2ch.net/test/read.cgi/avi/1063191060/666-667
http://pc.2ch.net/test/read.cgi/avi/1063191060/666-667
AVIUTLで同じDivX動画を読み込み
DIVXのYUY2で展開するにチェックとYUY2で展開するを空白とで見比べても
全く同じ何も変わらん
DIVXのYUY2で展開するにチェックとYUY2で展開するを空白とで見比べても
全く同じ何も変わらん
YUY2で展開するのチェックOFF YUY2 16-235→RGB 0-255
YUY2で展開するのチェックON YUY2 16-235→RGB 16-235
か逆かしらないけど、色範囲大幅に変わってますよ
YUY2で展開するのチェックON YUY2 16-235→RGB 16-235
か逆かしらないけど、色範囲大幅に変わってますよ
>>196
YUY2で展開するのチェックOFF YUY2 16-235→codecがRGB変換を行う
CanopusDVなどはRGB 16-235
DivX,HuffyuvなどはRGB 0-255
その後内部YUVに変換
YUY2で展開するのチェックON YUY2 16-235→Aviutlが内部YUVに変換
表示はRGB24で 0-255
YUY2で展開するのチェックOFF YUY2 16-235→codecがRGB変換を行う
CanopusDVなどはRGB 16-235
DivX,HuffyuvなどはRGB 0-255
その後内部YUVに変換
YUY2で展開するのチェックON YUY2 16-235→Aviutlが内部YUVに変換
表示はRGB24で 0-255
YUY2展開・圧縮の利点はYUVでずっと処理できることにあり
RGB変換がおこらない
そのためYUV<>RGB変換誤差がないのは勿論
わずらわしいスケール（伸張・圧縮）のことを考える必要がない
RGB変換がおこらない
そのためYUV<>RGB変換誤差がないのは勿論
わずらわしいスケール（伸張・圧縮）のことを考える必要がない
フィルタがほとんどRGB前提だから関係ないよ。
ここは亜空間ですか？
0.97までのフィルタだったらRGBで動作するんじゃない？
ところでYC伸張フィルタって古いよね（俺の持ってるやつは2000年製）
これ絶対RGB空間で動作してるな。
ところでYC伸張フィルタって古いよね（俺の持ってるやつは2000年製）
これ絶対RGB空間で動作してるな。
lotus m4cもRGB空間だろうね。
外部プラグインについては古いのはダメだろうね
しかしYC伸張フィルタがYUV色空間で動作したら、
それはそれでおかしな話だが
GNBのYC伸張フィルタはどうなってるんかな？
まぁYUV48ならYUV空間ならYC伸張相当の動作はできるけど
しかしYC伸張フィルタがYUV色空間で動作したら、
それはそれでおかしな話だが
GNBのYC伸張フィルタはどうなってるんかな？
まぁYUV48ならYUV空間ならYC伸張相当の動作はできるけど
では、波形表示プラグインのIRT601に補助線を表示って全く無意味なんだね
>>206
全くわかってないのでは？
表示用ﾃﾞｰﾀとして常にRGB24bitﾃﾞｰﾀを持つが
ﾌｨﾙﾀ処理に使われるのはYUV48bitﾃﾞｰﾀ
だから出力されたﾃﾞｰﾀは処理段でYUV<->RGB変換がおきないって話でしょ
表示ﾌﾟﾗｸﾞｲﾝなんて出力とも内部色空間とも無関係
全くわかってないのでは？
表示用ﾃﾞｰﾀとして常にRGB24bitﾃﾞｰﾀを持つが
ﾌｨﾙﾀ処理に使われるのはYUV48bitﾃﾞｰﾀ
だから出力されたﾃﾞｰﾀは処理段でYUV<->RGB変換がおきないって話でしょ
表示ﾌﾟﾗｸﾞｲﾝなんて出力とも内部色空間とも無関係
まあまあ
普段は死にスレ同様の静けさなんだしたまに初心者が来るのを相手するぐらいいいだろ
めんどくさいなら放置すればいいんだし
普段は死にスレ同様の静けさなんだしたまに初心者が来るのを相手するぐらいいいだろ
めんどくさいなら放置すればいいんだし
そんな難しいこと考えんでも
TV出力前提ならTVスケール、
PCでしか見ないならPCスケールの原則を守ってればいい
TV出力前提ならTVスケール、
PCでしか見ないならPCスケールの原則を守ってればいい
>>211
それはげふぉ厨の考え
それはげふぉ厨の考え
>>211
アホな発言禁止
アホな発言禁止
しかし波形プラグインで0-255範囲にあわせてもイマイチパッとしない
あれより若干広めにあわせるのがプロの仕事だと思わんかね？
あれより若干広めにあわせるのがプロの仕事だと思わんかね？
あのー、全部のデータを読み込んで、自動的にフルスケールにしてくれる
プラグインが存在したと思ったんですけどありか知ってる人います？
妙に時間かかった記憶はあるんだけど。
プラグインが存在したと思ったんですけどありか知ってる人います？
妙に時間かかった記憶はあるんだけど。
現実問題としてアナログキャプしたものって、
真っ白な画面のはずなのに画面上部と下部で明るさが違ったりとか
そこに例えば文字とかが出てくると画面全体の明るさが微妙に変化したりとか
そういうことあるんで結局どこに合わせるかは見た目と好みで決めるしかないような気がします
真っ白な画面のはずなのに画面上部と下部で明るさが違ったりとか
そこに例えば文字とかが出てくると画面全体の明るさが微妙に変化したりとか
そういうことあるんで結局どこに合わせるかは見た目と好みで決めるしかないような気がします
>>215
ColorYUY2のlevels
ColorYUY2のlevels
16-235に合わせても伸張してテレビと同じ見た目の筈が薄いのはなぜですか？
皆さんの見解と現実がまるっきり違うんだよ！
皆さんの見解と現実がまるっきり違うんだよ！
意味が分からん
TVは16と235を黒、白として表示する
AVIUTLは16と235を伸張してテレビと同じ色で表示する
基本ですね
AVIUTLは16と235を伸張してテレビと同じ色で表示する
基本ですね
PC環境がかわっても
BT.601にのっとった方法でﾌｧｲﾙを作成しておけば
環境をｷｬﾘﾌﾞﾚｰﾄすることにより
同じ見た目で再生できる。
それはつまり
ｷｬﾘﾌﾞﾚｰﾄされた環境であれば
例え他人のPCであっても
上記のﾌｧｲﾙは常に同じ見た目。
もし上記のﾌｧｲﾙが.vobであれば
DVD-VIDEOとして据え置きﾌﾟﾚｲﾔｰでﾃﾚﾋﾞ視聴したとき
おかしな色合いにはならない。
ただし、据え置きﾌﾟﾚｲﾔｰの多くはｷｬﾘﾌﾞﾚｰﾄできないし
ﾓﾆﾀとﾃﾚﾋﾞの色温度が異なる以上
同じ色合いにはならない。
ではBT.601にのっとった方法とは？
というのがこのｽﾚの趣旨
BT.601にのっとった方法でﾌｧｲﾙを作成しておけば
環境をｷｬﾘﾌﾞﾚｰﾄすることにより
同じ見た目で再生できる。
それはつまり
ｷｬﾘﾌﾞﾚｰﾄされた環境であれば
例え他人のPCであっても
上記のﾌｧｲﾙは常に同じ見た目。
もし上記のﾌｧｲﾙが.vobであれば
DVD-VIDEOとして据え置きﾌﾟﾚｲﾔｰでﾃﾚﾋﾞ視聴したとき
おかしな色合いにはならない。
ただし、据え置きﾌﾟﾚｲﾔｰの多くはｷｬﾘﾌﾞﾚｰﾄできないし
ﾓﾆﾀとﾃﾚﾋﾞの色温度が異なる以上
同じ色合いにはならない。
ではBT.601にのっとった方法とは？
というのがこのｽﾚの趣旨
何でわからないかな
AVIUTL波形プラグインでBT601補助線に合わせた場合は
テレビとの見た目で明らかに画質が違うだろうがよ
少し違うぐらいなら誤差の範囲だが、データの表示手順はテレビと同じなのに
全然違うじゃねーかといってんの
AVIUTL波形プラグインでBT601補助線に合わせた場合は
テレビとの見た目で明らかに画質が違うだろうがよ
少し違うぐらいなら誤差の範囲だが、データの表示手順はテレビと同じなのに
全然違うじゃねーかといってんの
>>225
ファイルを補助線にあわせてどうする？
補助線に合うようにキャプチャボードを調整するんだよ
キャリブレート用プラグインでしょ
キャリブレートしてないキャプボで作ったファイルが
補助線に合わせたらテレビと違うって、そりゃそうだろ
大体表示環境自体キャリブレートしてるのか？
ファイルを補助線にあわせてどうする？
補助線に合うようにキャプチャボードを調整するんだよ
キャリブレート用プラグインでしょ
キャリブレートしてないキャプボで作ったファイルが
補助線に合わせたらテレビと違うって、そりゃそうだろ
大体表示環境自体キャリブレートしてるのか？
このスレは難解で衝撃的で自分の理解の範囲を超えています
つーか、ガンマ値とかも違うし（6500-9300 Vs 13000越え（テレビは一般的な
標準が無いから、もっと上だったりもする）
し、そもそもCRTとTVでは方式違うから同じになるわけ無いじゃん。
標準が無いから、もっと上だったりもする）
し、そもそもCRTとTVでは方式違うから同じになるわけ無いじゃん。
ﾃﾞﾌｫでNTSC (setup 7.5) 設定の糞ｷｬﾌﾟﾎﾞでも使っているのか？？
ﾃﾞﾌｫのまんまｹﾞﾌｫｸﾞﾗﾎﾞでも使っているのか？
そもそもPCﾓﾆﾀとﾃﾚﾋﾞの色合いの差は誤差ﾚﾍﾞﾙじゃないってのに
はなから違うものを「違う！違う！！」と騒いでいるのか？
それは違うよ。
45wと100wの電球で明るさが同じにならないっていわれてもねぇ。
ﾃﾞﾌｫのまんまｹﾞﾌｫｸﾞﾗﾎﾞでも使っているのか？
そもそもPCﾓﾆﾀとﾃﾚﾋﾞの色合いの差は誤差ﾚﾍﾞﾙじゃないってのに
はなから違うものを「違う！違う！！」と騒いでいるのか？
それは違うよ。
45wと100wの電球で明るさが同じにならないっていわれてもねぇ。
231 ：名無しさん＠編集中：03/10/19 13:11
ここは亜空間ですね。
232 ：名無しさん＠編集中：03/10/19 13:13
BT.601基準で作られたファイルの
PCモニタ表示と民生テレビ表示が一致するって言ってるヤシなんているのか？
PCモニタ表示と民生テレビ表示が一致するって言ってるヤシなんているのか？
>>226
んなこと等の昔に理解し知ってる
カラーバーをキャプチャーしてIT601補助線にあわせるんだろ
色相も明るさも彩度も全部601にあわせた
テレビと見比べた
zん全治げー世ボケ桁ら絵羽。0-255であわせてもまだ薄い世あほ足れば
表示環境は完璧ジャワ
明るさ最大、9300kにしてバッチリテレビに最大限ちかづけてそれでこれかよ
ここで語ってること自体が棚上の空論で現実とかみ合ってねーんだよ
んなこと等の昔に理解し知ってる
カラーバーをキャプチャーしてIT601補助線にあわせるんだろ
色相も明るさも彩度も全部601にあわせた
テレビと見比べた
zん全治げー世ボケ桁ら絵羽。0-255であわせてもまだ薄い世あほ足れば
表示環境は完璧ジャワ
明るさ最大、9300kにしてバッチリテレビに最大限ちかづけてそれでこれかよ
ここで語ってること自体が棚上の空論で現実とかみ合ってねーんだよ
234 ：名無しさん＠編集中：03/10/19 13:14
色が薄いとか言ってるからガンマ値の問題でしょ。
DVDをPCモニタで見れば色が薄い。
それだけのことでしょ。
DVDをPCモニタで見れば色が薄い。
それだけのことでしょ。
(ﾟДﾟ)ﾊｧ?わけわからんSinmaiKeiji(新米刑事)逝ってよし!!
236 ：名無しさん＠編集中：03/10/19 13:20
>>233
お前がわかってないだけ。
あるDVDをPCで見たときとテレビで見たときの差、と
ある番組をキャプ・エンコしたものをPCで見たときとテレビで見たときの差、を
一致させる手順の話だって
差をなくす話じゃない
こうしておけば据え置きプレイヤー(MPEG1,2 DivX)でそのファイルをテレビ表示させた時に
おかしな色合いにならない。
また、色温度13000kのPCモニタやそれに合わせたグラボが市販化されたときに
テレビと同じ色合いになるよ。
つーか昔はあったんだがな。
お前がわかってないだけ。
あるDVDをPCで見たときとテレビで見たときの差、と
ある番組をキャプ・エンコしたものをPCで見たときとテレビで見たときの差、を
一致させる手順の話だって
差をなくす話じゃない
こうしておけば据え置きプレイヤー(MPEG1,2 DivX)でそのファイルをテレビ表示させた時に
おかしな色合いにならない。
また、色温度13000kのPCモニタやそれに合わせたグラボが市販化されたときに
テレビと同じ色合いになるよ。
つーか昔はあったんだがな。
237 ：名無しさん＠編集中：03/10/19 13:22
民生レベルでキャリブレートは完璧とか言ってるヤシが
キャリブレートできてるとは思えない。
キャリブレートできてるとは思えない。
238 ：名無しさん＠編集中：03/10/19 13:26
ｽﾄﾚｰﾄ派vs伸張派
ﾉﾝｻﾁｭﾚｰﾄ派vsｻﾁｭﾚーﾄ派
とかやってたころが懐かしいな・・・・。
ﾉﾝｻﾁｭﾚｰﾄ派vsｻﾁｭﾚーﾄ派
とかやってたころが懐かしいな・・・・。
>>236
どんなPCモニタとVGAのつもり？藁
色温度に関しては13000程度までなら現状ので13000程度なら
合わせられるよ？
んで色温度が同じならば、PCモニタとTVが同じ色になるって言ってるん
だからCRTとTVの仕組み（CRT側が新方式？）の説明よろしくね。
方式はTV側はプログレって事で好意的に解釈してあげるから。
どんなPCモニタとVGAのつもり？藁
色温度に関しては13000程度までなら現状ので13000程度なら
合わせられるよ？
んで色温度が同じならば、PCモニタとTVが同じ色になるって言ってるん
だからCRTとTVの仕組み（CRT側が新方式？）の説明よろしくね。
方式はTV側はプログレって事で好意的に解釈してあげるから。
240 ：名無しさん＠編集中：03/10/19 13:53
ｵﾚは色温度に関してはよくわからんが
>>236の後半は間違ってるな
ｸﾞｸﾞってみたらそういう問題じゃないような
ただ、>>236の前半はあってるわな
>>239は自分が「これで完璧！」ていう調整したﾌｧｲﾙ作って
家電DVDﾌﾟﾚｲﾔｰでﾃﾚﾋﾞ視聴していただきたいね
>>236の後半は間違ってるな
ｸﾞｸﾞってみたらそういう問題じゃないような
ただ、>>236の前半はあってるわな
>>239は自分が「これで完璧！」ていう調整したﾌｧｲﾙ作って
家電DVDﾌﾟﾚｲﾔｰでﾃﾚﾋﾞ視聴していただきたいね
241 ：名無しさん＠編集中：03/10/19 13:56
>>238
結局どっちが勝ったの？
結局どっちが勝ったの？
242 ：名無しさん＠編集中：03/10/19 14:05
カラーバーをBT601にあわせて、それをDVDに焼いてテレビで見たら
DVDレコで録画した映像をDVDプレイヤーでテレビで見たときと
同じ見え方をするんだな？
それでOKですか？実際テストした有識者のお答えを待ってます
ちなみにカラーバーを0-255範囲にあわせてPCで再生したら
伸張しすぎの破綻映像が再生されるということでOKですね？
DVDレコで録画した映像をDVDプレイヤーでテレビで見たときと
同じ見え方をするんだな？
それでOKですか？実際テストした有識者のお答えを待ってます
ちなみにカラーバーを0-255範囲にあわせてPCで再生したら
伸張しすぎの破綻映像が再生されるということでOKですね？
244 ：名無しさん＠編集中：03/10/19 16:40
>>243
OKじゃないでしょ
少なくともRDX3で録画したものは
BT.601をきっちりまもってない
前ｽﾚでｶﾞｲｼｭﾂだが、ﾁｭｰﾅｰってのはどいつもこいつも
ﾁｭｰﾅｰ独自の味付けがある
だからこそｷｬﾌﾟﾎﾞ側を調整しとこうってことでしょ
もしRDX3のﾁｭｰﾅｰでﾃﾚﾋﾞを調整したら
他のｶﾗｰﾊﾞｰで調整したｷｬﾌﾟﾎﾞでとった画とは違うでしょ
個人的にはｶﾗｰﾊﾞｰどうこうというのは正確じゃないとは思うが
あてずっぽうよりﾏｼな基準だとも思うけどね
OKじゃないでしょ
少なくともRDX3で録画したものは
BT.601をきっちりまもってない
前ｽﾚでｶﾞｲｼｭﾂだが、ﾁｭｰﾅｰってのはどいつもこいつも
ﾁｭｰﾅｰ独自の味付けがある
だからこそｷｬﾌﾟﾎﾞ側を調整しとこうってことでしょ
もしRDX3のﾁｭｰﾅｰでﾃﾚﾋﾞを調整したら
他のｶﾗｰﾊﾞｰで調整したｷｬﾌﾟﾎﾞでとった画とは違うでしょ
個人的にはｶﾗｰﾊﾞｰどうこうというのは正確じゃないとは思うが
あてずっぽうよりﾏｼな基準だとも思うけどね
245 ：名無しさん＠編集中：03/10/19 16:45
ちなみにカラーバーを0-255範囲にあわせてPCで再生したら
っていうのだけじゃOKもへったくれもないよ
っていうのだけじゃOKもへったくれもないよ
246 ：波形表示ソフトを使用した調整：03/10/19 16:45
（個人用覚え書きURL）
ttp://hajimehp.hp.infoseek.co.jp/scope.html
ttp://hajimehp.hp.infoseek.co.jp/scope.html
>>246
IOのカードかな
IOのカードかな
248 ：名無しさん＠編集中：03/10/19 16:55
>>244-245
簡単なことをあたかも難しく言って初心者を混乱させる天才だな
簡単なことをあたかも難しく言って初心者を混乱させる天才だな
250 ：名無しさん＠編集中：03/10/19 17:38
もう4ヶ月以上勉強してるんですが
てかOKだろ
あくまで一般的にAVIUTLの波形フィルタでBT601の範囲に収まるように
カラーバーを調節すればデータ的にはテレビと同じと考えていい
それをテレビに表示したとき本当に同じに見えるかは放送局が流す信号による
知りたければスペクトルアナライザーでも用意しろと
てかOKだろ
あくまで一般的にAVIUTLの波形フィルタでBT601の範囲に収まるように
カラーバーを調節すればデータ的にはテレビと同じと考えていい
それをテレビに表示したとき本当に同じに見えるかは放送局が流す信号による
知りたければスペクトルアナライザーでも用意しろと
243は「DVDレコで録画した映像をDVDプレイヤーでテレビで見たとき」と
比べてるから全然OKじゃない
比べてるから全然OKじゃない
253 ：名無しさん＠編集中：03/10/19 17:58
>>251
伸張済みRGB読み込みだと補助線は意味ないな
伸張済みRGB読み込みだと補助線は意味ないな
伸張済みのRGBなんて存在し無いじゃん
ありえないたとえだして人を惑わすなよ
DVDもキャプチャーも全てYUV
つうか素材は全て伸張前なんだよ素人さん
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない
ありえないたとえだして人を惑わすなよ
DVDもキャプチャーも全てYUV
つうか素材は全て伸張前なんだよ素人さん
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない
255 ：名無しさん＠編集中：03/10/19 18:08
>>254
あのな、波形表示プラグインの話だぞ？
それにbt系なら伸張済み非圧縮RGBキャプできるよ。
つーか非圧縮にせよHuffyuvにせよRGBキャプするヤシは
ストレートRGBは使わないでしょ。
まぁ
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない
なら波形表示プラグインなんていらないけどな。
あのな、波形表示プラグインの話だぞ？
それにbt系なら伸張済み非圧縮RGBキャプできるよ。
つーか非圧縮にせよHuffyuvにせよRGBキャプするヤシは
ストレートRGBは使わないでしょ。
まぁ
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない
なら波形表示プラグインなんていらないけどな。
256 ：名無しさん＠編集中：03/10/19 18:13
>>254
作者のGNB自身が、
16-235ｷｬﾌﾟだからまるもでｽﾄﾚｰﾄRGB読み込みしているわけだが
”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。”
とも書いてあるが
作者のGNB自身が、
16-235ｷｬﾌﾟだからまるもでｽﾄﾚｰﾄRGB読み込みしているわけだが
”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。”
とも書いてあるが
257 ：名無しさん＠編集中：03/10/19 18:14
258 ：名無しさん＠編集中：03/10/19 18:18
259 ：名無しさん＠編集中：03/10/19 18:20
YUY2読み込みでも補助線は意味ないような・・・。
抜け殻sage忘れてるよ抜け殻
261 ：名無しさん＠編集中：03/10/19 20:13
PCとTVの見え方の違いは
0-100IREをRGBにどうマッピングするかという話か思ったら
本当にヒトの見た目で話してるのな。
0-100IREをRGBにどうマッピングするかという話か思ったら
本当にヒトの見た目で話してるのな。
ある意味正解だと思うです
何の為にキャプチャして何の為にエンコしてるのか……
本来の目的を忘れて数字や手順とかに縛られてる奴多すぎ
何の為にキャプチャして何の為にエンコしてるのか……
本来の目的を忘れて数字や手順とかに縛られてる奴多すぎ
263 ：名無しさん＠編集中：03/10/19 20:26
huffyuvのように（？）RGB変換時に伸長されるコーデックを、
ラデ系のグラボでオーバーレイ表示すると、
伸長＆伸長になってしまうのですか？
ラデ系のグラボでオーバーレイ表示すると、
伸長＆伸長になってしまうのですか？
264 ：263：03/10/19 20:27
あと、前スレがdat落ちしたのはいつごろでしょう
html化を心待ちにしているのですが。
html化を心待ちにしているのですが。
265 ：名無しさん＠編集中：03/10/19 20:32
>>263
それはないです。
それはないです。
267 ：名無しさん＠編集中：03/10/19 20:49
＞本来の目的を忘れて数字や手順とかに縛られてる奴多すぎ
こういう人たちがいるから
知識や知恵となって残って横着者や後の人が結果だけを得ることが出来るんではないかなあと思うんですが。
こういう人たちがいるから
知識や知恵となって残って横着者や後の人が結果だけを得ることが出来るんではないかなあと思うんですが。
268 ：名無しさん＠編集中：03/10/19 20:58
269 ：263：03/10/19 20:58
270 ：名無しさん＠編集中：03/10/19 21:06
>>269
旧ビデオレンダラでメディアプレーヤ再生時にPrintscreen可能なことから
オーバーレイ表示ではないと思われ。
つまりTMPGEncのプレビュー画面がディスプレイに表示されるのと同じことだと思われ。
旧ビデオレンダラでメディアプレーヤ再生時にPrintscreen可能なことから
オーバーレイ表示ではないと思われ。
つまりTMPGEncのプレビュー画面がディスプレイに表示されるのと同じことだと思われ。
Huffyuvのオーバーレイ表示とGDI表示の区別はどこでつければ良いのでしょう？
DVDを作成する時、メニュー画面もやはり16-235にしないとまずいんでしょうか？
ペイントで適当に作ったやつじゃ駄目なんですよね？
ペイントで適当に作ったやつじゃ駄目なんですよね？
276 ：263=269：03/10/19 21:21
>>270-271
なるほど、だいぶ分かってきました。
では、今試しに RGB24非圧縮 で作ったデータを
AviUtlで開いてオーバーレイON/OFFすると色合いが変化しました。
（i845GE内臓で確認）
グラボにはRGBでデータが渡ってると思うのですがなんで色合いが変わるのでしょう？？
なるほど、だいぶ分かってきました。
では、今試しに RGB24非圧縮 で作ったデータを
AviUtlで開いてオーバーレイON/OFFすると色合いが変化しました。
（i845GE内臓で確認）
グラボにはRGBでデータが渡ってると思うのですがなんで色合いが変わるのでしょう？？
今の時期、一言にハードウェアオーバーレイといっても
レンダラがVMR9かVideoRendererかで違うと思うんですが。
レンダラがVMR9かVideoRendererかで違うと思うんですが。
>>276
前ｽﾚでもｶﾞｲｼｭﾂだが
ｲﾝﾃﾙ系VGAのｵｰﾊﾞｰﾚｲ表示は非BT.601
まぁどこも一緒だけど
ﾒｰｶｰ独自の味付けが確実にあるよ
GDIもｵｰﾊﾞｰﾚｲもｷｬﾘﾌﾞﾚｰﾄしておくのが基本
ﾃﾞﾌｫﾙﾄはﾀﾞﾒﾀﾞﾒよ（ｲﾝﾃﾙ系はまともにｷｬﾘﾌﾞﾚｰﾄすらできないが）
>>277
詳しく
前ｽﾚでもｶﾞｲｼｭﾂだが
ｲﾝﾃﾙ系VGAのｵｰﾊﾞｰﾚｲ表示は非BT.601
まぁどこも一緒だけど
ﾒｰｶｰ独自の味付けが確実にあるよ
GDIもｵｰﾊﾞｰﾚｲもｷｬﾘﾌﾞﾚｰﾄしておくのが基本
ﾃﾞﾌｫﾙﾄはﾀﾞﾒﾀﾞﾒよ（ｲﾝﾃﾙ系はまともにｷｬﾘﾌﾞﾚｰﾄすらできないが）
>>277
詳しく
自分で書いておいててなんですが
DX9にハードウェアで対応してないビデオチップで
レンダラをVMR9に指定してメディアを再生した場合
果たしてハードウェアオーバーレイなのかソフトウェア(?)オーバーレイなのか
どちらなんでしょうかね。
DX9にハードウェアで対応してないビデオチップで
レンダラをVMR9に指定してメディアを再生した場合
果たしてハードウェアオーバーレイなのかソフトウェア(?)オーバーレイなのか
どちらなんでしょうかね。
VMR9かVideoRendererかで色かわるか？
281 ：263=269=276：03/10/19 21:39
>>278
いやそれは分かっているのですが、
>>271氏がオーバーレイんときゃグラボがYUV>RGBをやるから
GDIのときと色が違うんだ、みたいな書き方をしてたので
じゃあはじめからRGB24で作ったデータはどういう処理になってんの？
YUV>RGB処理はないからオーバーレイとGDIが一致するのか？
・・・と思って実際にやってみたら色が違ってたのでこれはなぜだろうと。
いやそれは分かっているのですが、
>>271氏がオーバーレイんときゃグラボがYUV>RGBをやるから
GDIのときと色が違うんだ、みたいな書き方をしてたので
じゃあはじめからRGB24で作ったデータはどういう処理になってんの？
YUV>RGB処理はないからオーバーレイとGDIが一致するのか？
・・・と思って実際にやってみたら色が違ってたのでこれはなぜだろうと。
伸張読み込み派はデータを破壊して何がしたいの？
0-255の範囲で保存したらどのプレイヤーで再生しても
白とび黒つぶれで苦しむのに
0-255の範囲で保存したらどのプレイヤーで再生しても
白とび黒つぶれで苦しむのに
AviUtlのオーバーレイ表示はYUVでグラボに渡してるんじゃないの？
それはともかく、うちのRADEON9000ではhuffyuv(YUY2)を
AviUtlのGDIとオーバーレイ表示で比べて色味の違いはほとんど分からないし
AviUtlのGDIとMediaPlayerの表示でも違いは分からない。
それはともかく、うちのRADEON9000ではhuffyuv(YUY2)を
AviUtlのGDIとオーバーレイ表示で比べて色味の違いはほとんど分からないし
AviUtlのGDIとMediaPlayerの表示でも違いは分からない。
>>283
0-255がRGBなのかYUVなのか分からん
0-255がRGBなのかYUVなのか分からん
ストレート変換した動画を人に見せたら
「色が薄い」・「白っぽい」だのと散々突っ込まれて凹みますた。
「色が薄い」・「白っぽい」だのと散々突っ込まれて凹みますた。
君の周りはｹﾞﾌｫ厨ばかりですね
） ） ） おまいら、お茶のんどけ
（ （ （ ∧_∧
┌───┐ （ ´･ω） 从／
│ ├ （つ旦と）──┐＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
├───┤ `ｕ―ｕ' . │－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
│ ├──────┘＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
└───┘ Ｗ＼
───── ﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞ
（ （ （ ∧_∧
┌───┐ （ ´･ω） 从／
│ ├ （つ旦と）──┐＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
├───┤ `ｕ―ｕ' . │－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
│ ├──────┘＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~－＝≡旦~
└───┘ Ｗ＼
───── ﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞ
>>288
同じじゃないよ
同じじゃないよ
RGBもYUVも同じと言う香具師はもれなくｹﾞﾌｫ厨。
16-235がフルスケールなのがYUV
0-255がフルスケールなのがRGB
ってのは判った。フルスケールってのは真っ黒から真っ白の事
であってる？
より細かく分解できるのがRGBなの？
>>293
調べるつもりは無い。なぜならめんどくさいからだ。
http://pc.2ch.net/test/read.cgi/avi/1061527402/l50
これの定義に従って判りやすく教えろ。
調べるつもりは無い。なぜならめんどくさいからだ。
http://pc.2ch.net/test/read.cgi/avi/1061527402/l50
これの定義に従って判りやすく教えろ。
295 ：名無しさん＠編集中：03/10/20 00:51
誰かLを救ってやれよ
296 ：名無しさん＠編集中：03/10/20 01:51
以下は 非オーバーレイ の話
あの～メディアプレーヤー９って
CODECにかかわらず伸長表示するようになったんですか？
CanopusDV再生してたんですがなんかおかしいなと思って
システムディレクトリに残ってた mplay32.exe（Version5.1）で
再生するといわゆるストレート変換で再生されていて
MediaPlayer9のほうは伸長されてるようです。
気づくの遅すぎ？
ちなみにMP9でCODECにRGB変換させる（この場合ストレート変換）
にはどうすればいいのでしょうか？
あの～メディアプレーヤー９って
CODECにかかわらず伸長表示するようになったんですか？
CanopusDV再生してたんですがなんかおかしいなと思って
システムディレクトリに残ってた mplay32.exe（Version5.1）で
再生するといわゆるストレート変換で再生されていて
MediaPlayer9のほうは伸長されてるようです。
気づくの遅すぎ？
ちなみにMP9でCODECにRGB変換させる（この場合ストレート変換）
にはどうすればいいのでしょうか？
知ってるがお前の態度が気に食わない
教えたいがお前の態度が気に食わない
分からないがお前の態度が気に食わない
そんなことより総括まだー？
まるもmpeg2VFPAIプラグインなんかで伸張読み込みする意味はなんですか？
>>302
まるものとこに書いてある
まるものとこに書いてある
まるもの所とここの主張が食い違って無いか？
まるもはストレート変換についてPCで作成した0-255範囲のCGを
破綻するのを防ぐ場合に使うとしてるからスケールをそのままRGBに変換するのがこれだよな
BT601伸張について文字通り伸張してPCディスプレイで表示したとき
実際テレビで見た画面に近くするためのあると書いてる
それで、一般的には伸張を選ぶべきとも書いてる
しかし、ここのスレではAVIUTLやメディアプレイヤーで再生した段階で
強制的に表示上は伸張すると書いてあるからまるもの表示上の見栄えを
テレビに近づけるという主張と矛盾してる
まるもVFPAIでBT601伸張して読み込むと16-235範囲のデータはVAFPI経由で
0-255に伸張されAVIUTLによって-16-275に伸張された色を見ていることになるんだよな？
それに、0-255に伸張したはいいけど、圧縮するとき0-255のままデータを
残したら再生時に-16-275で表示されることになるし
だからストレート変換が正しいと思うんだがどうか？
まるもはストレート変換についてPCで作成した0-255範囲のCGを
破綻するのを防ぐ場合に使うとしてるからスケールをそのままRGBに変換するのがこれだよな
BT601伸張について文字通り伸張してPCディスプレイで表示したとき
実際テレビで見た画面に近くするためのあると書いてる
それで、一般的には伸張を選ぶべきとも書いてる
しかし、ここのスレではAVIUTLやメディアプレイヤーで再生した段階で
強制的に表示上は伸張すると書いてあるからまるもの表示上の見栄えを
テレビに近づけるという主張と矛盾してる
まるもVFPAIでBT601伸張して読み込むと16-235範囲のデータはVAFPI経由で
0-255に伸張されAVIUTLによって-16-275に伸張された色を見ていることになるんだよな？
それに、0-255に伸張したはいいけど、圧縮するとき0-255のままデータを
残したら再生時に-16-275で表示されることになるし
だからストレート変換が正しいと思うんだがどうか？
そもそもYUV-RGB変換を行わなければ全て解決だな
>>305
うむ。YUV の光が見える我等超人には YUV-RGB 変換など不要だ
うむ。YUV の光が見える我等超人には YUV-RGB 変換など不要だ
結論を言うと
AVIUTLの画面表示は伸張表示してるは嘘
が正しいなら全てが丸く収まる
AVIUTLの画面表示は伸張表示してるは嘘
が正しいなら全てが丸く収まる
伸張はあくまでYUV→RGB変換時に起こるもの
それを理解してるか？
それを理解してるか？
Lはまだ混乱しとるのか？
まるもVFAPIプラグインで伸張読み込みしたら
圧縮時に逆操作の縮小をしなければならない
しないとプレイヤーソフトで再生時やDVDに焼いてテレビで見た場合
-15-275に伸張された白飛び黒潰れ映像が再生されるんですよね？
まるも製作所で伸張読み込みを使えというのは編集時の色をテレビに近づけるためで
圧縮時に縮小することを前提で言ってる
で、まるも製作所で圧縮時に縮小しろと書いてないのが問題なんだな
圧縮時に逆操作の縮小をしなければならない
しないとプレイヤーソフトで再生時やDVDに焼いてテレビで見た場合
-15-275に伸張された白飛び黒潰れ映像が再生されるんですよね？
まるも製作所で伸張読み込みを使えというのは編集時の色をテレビに近づけるためで
圧縮時に縮小することを前提で言ってる
で、まるも製作所で圧縮時に縮小しろと書いてないのが問題なんだな
-15-275とか-16-275という数値はちゃんと変換式から出した数値なのか？
単純に16-235から0-255時の増分を、さらに0-255に加算しただけなら
そうはならないんじゃないの？
どっちにしろ白飛び・黒潰れという結果は同じだが
単純に16-235から0-255時の増分を、さらに0-255に加算しただけなら
そうはならないんじゃないの？
どっちにしろ白飛び・黒潰れという結果は同じだが
前スレが資料価値高いと聴いたのだけど､どっかにミラーないかね｡
>>315
とりあえずDivX5.05で試してみたが全然縮小してなかったぞ
とりあえずDivX5.05で試してみたが全然縮小してなかったぞ
そりゃ伸張してるからだろ
またはRGB変換してないか
>>319
何がしたいの？
何がしたいの？
321 ：名無しさん＠編集中：03/10/21 19:43
茂木さんが伸張したほうがいいって言うから伸張します
>>319
コーデックの設定でDivXをYUY2圧縮させない
そうすれば頭がなんでも縮小
伸張済みなら縮小の結果適正なYV12空間のファイルになり
伸張してなければ縮小の結果二重圧縮された不適正なYV12空間のファイルになる
コーデックの設定でDivXをYUY2圧縮させない
そうすれば頭がなんでも縮小
伸張済みなら縮小の結果適正なYV12空間のファイルになり
伸張してなければ縮小の結果二重圧縮された不適正なYV12空間のファイルになる
まだ亜空間をさまよってますか？
おいら、出口が見えません。
なんだがもーのすごーく疑い深い人が常駐しちゃってるな
何も信じないなら何も質問しなきゃいいのに
何も信じないなら何も質問しなきゃいいのに
信用して実験までしたのに全部裏切られたからだよ
>>332
DIVX5.05で圧縮した動画を一つ用意
AVIUTL側の設定
オーバーレイ表示と非オーバーレイ表示ともに試した
環境設定＞コーデックの設定＞DivX5.05＞YUY2で展開する YUY2で圧縮する 設定を保持する
YUY2で展開する YUY2で圧縮する は共に○○、○X、X○、XXの4通りで試した
設定を保持するは常に○
この設定でQB95でエンコード
出来上がった動画をそれぞれ波形プラグイン、見た目で確認
見た目での変化はなし、波形プラグインでの変化は同じレベルでの変動程度で
とてもスケール圧縮した結果とは思えない
こんな感じでどうでしょうか？
DIVX5.05で圧縮した動画を一つ用意
AVIUTL側の設定
オーバーレイ表示と非オーバーレイ表示ともに試した
環境設定＞コーデックの設定＞DivX5.05＞YUY2で展開する YUY2で圧縮する 設定を保持する
YUY2で展開する YUY2で圧縮する は共に○○、○X、X○、XXの4通りで試した
設定を保持するは常に○
この設定でQB95でエンコード
出来上がった動画をそれぞれ波形プラグイン、見た目で確認
見た目での変化はなし、波形プラグインでの変化は同じレベルでの変動程度で
とてもスケール圧縮した結果とは思えない
こんな感じでどうでしょうか？
まあ予想通りの勘違いだな
DivXをRGB展開するときに伸張が起こってるんだよ
だからエンコード時にスケール圧縮して変動なしになる
どうしてもDivXをストレート展開したいならAvisynthのConvToでも使え
DivXをRGB展開するときに伸張が起こってるんだよ
だからエンコード時にスケール圧縮して変動なしになる
どうしてもDivXをストレート展開したいならAvisynthのConvToでも使え
違う
結論いうと
ふだんまるもVFAPIプラグインのBT601伸張を使ってる奴は馬鹿
それをデフォで奨めるまるもも馬鹿ってことでOK？
ふだんまるもVFAPIプラグインのBT601伸張を使ってる奴は馬鹿
それをデフォで奨めるまるもも馬鹿ってことでOK？
簡単に言えば、YUVのまま処理しようよという事です。
ｍ２ｖ．ａｕｉ
YUV16-235の映像をPCモニタに表示した段階で
伸張されて0-255に見えるんだよ。
波形プラグインの結果が本当の値では無い
と言う事に早く気付け！
伸張されて0-255に見えるんだよ。
波形プラグインの結果が本当の値では無い
と言う事に早く気付け！
341 ：名無しさん＠編集中：03/10/22 19:28
>>337
おまえが一番馬鹿なのは既出か
おまえが一番馬鹿なのは既出か
>>333
まずAviutlのYUY2展開のとき内部YUV48へのマッピングがおこなわれるが
このマッピングはCODECのYUV->RGB変換に依存する
RGB入力のときはストレート変換をする
またRGB出力のときもストレート変換する
DivXの場合伸張変換(RGB->YUVは圧縮変換)
そのやり方だと
○○
YUY2展開(YUV)->内部YUV変換(伸張RGB同等)->YUY2圧縮(YUV)->DivX(YUV)
*CODECにYUVで渡してるのでスケール変換がない（圧縮伸張がない）
○X
YUY2展開(YUV)->内部YUV変換（伸張RGB同等）->YUY2圧縮しないためAviutlがRGB変換(ストレート変換だが元が伸張済みなので伸張RGB)->DivX(YUV)
*RGB->YUV変換はDivXが行い、圧縮変換
X○
YUY2展開しない(伸張RGB)->内部YUV変換（伸張RGB同等）->YUY2圧縮(YUV)->DivX(YUV)
*DivXがRGB変換をしAviutlが内部YUV変換
XX
YUY2展開しない(伸張RGB)->内部YUV変換（伸張RGB同等）->YUY2圧縮しないためAviutlがRGB変換(ストレート変換だが元が伸張済みなので伸張RGB)->DivX(YUV)
*DivXがRGB変換をしAviutlが内部YUV変換,YUV変換もDivXが行い、圧縮変換
まずAviutlのYUY2展開のとき内部YUV48へのマッピングがおこなわれるが
このマッピングはCODECのYUV->RGB変換に依存する
RGB入力のときはストレート変換をする
またRGB出力のときもストレート変換する
DivXの場合伸張変換(RGB->YUVは圧縮変換)
そのやり方だと
○○
YUY2展開(YUV)->内部YUV変換(伸張RGB同等)->YUY2圧縮(YUV)->DivX(YUV)
*CODECにYUVで渡してるのでスケール変換がない（圧縮伸張がない）
○X
YUY2展開(YUV)->内部YUV変換（伸張RGB同等）->YUY2圧縮しないためAviutlがRGB変換(ストレート変換だが元が伸張済みなので伸張RGB)->DivX(YUV)
*RGB->YUV変換はDivXが行い、圧縮変換
X○
YUY2展開しない(伸張RGB)->内部YUV変換（伸張RGB同等）->YUY2圧縮(YUV)->DivX(YUV)
*DivXがRGB変換をしAviutlが内部YUV変換
XX
YUY2展開しない(伸張RGB)->内部YUV変換（伸張RGB同等）->YUY2圧縮しないためAviutlがRGB変換(ストレート変換だが元が伸張済みなので伸張RGB)->DivX(YUV)
*DivXがRGB変換をしAviutlが内部YUV変換,YUV変換もDivXが行い、圧縮変換
DivXが圧縮変換することをチェックしたいなら
ストレートRGBをソースにしないとわからない
MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする（DivXがRGB->YUV変換を行う）
こうするとストレートRGBを圧縮することになるので
二重圧縮YUVになる
で、なんでそんなことしたいの？
ストレートRGBをソースにしないとわからない
MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする（DivXがRGB->YUV変換を行う）
こうするとストレートRGBを圧縮することになるので
二重圧縮YUVになる
で、なんでそんなことしたいの？
>>340
それはオーバーレイ表示したときのはなしか？なら知らんが
非オーバーレイ表示時はファイルのデータと画面表示されるデータは同じだぞ
波形プラグインの結果と表示画面は同じということにここの書き込みに惑わされず
しっかり認識しろ
それはオーバーレイ表示したときのはなしか？なら知らんが
非オーバーレイ表示時はファイルのデータと画面表示されるデータは同じだぞ
波形プラグインの結果と表示画面は同じということにここの書き込みに惑わされず
しっかり認識しろ
>>342
惜しい
>まずAviutlのYUY2展開のとき内部YUV48へのマッピングがおこなわれるが
>このマッピングはCODECのYUV->RGB変換に依存する
ではなく
必ず伸張変換のﾏｯﾋﾟﾝｸﾞがおこなわれるよ
だからCODEC内の 変換式がBT.601ｽﾄﾚｰﾄであるCanopusDVの場合
YUY2展開ｵﾝ＞伸張RGB(必ず伸張されるから)
YUY2展開ｵﾌ＞ｽﾄﾚｰﾄRGB(CanopusDVの仕様)
>>345
Aviutlは内部YUVを表示するときに
ｵｰﾊﾞｰﾚｲ・・・ｿｰｽのYUVｽｹｰﾙ（へんな表現だが）でOSに渡す
あとは環境依存
非ｵｰﾊﾞｰﾚｲ（GDI）・・・内部YUV>RGB24変換をAviutlが行う
この変換自体はｽﾄﾚｰﾄだが内部YUVは伸張済みRGB相当で処理するので
伸張RGBとして表示される
惜しい
>まずAviutlのYUY2展開のとき内部YUV48へのマッピングがおこなわれるが
>このマッピングはCODECのYUV->RGB変換に依存する
ではなく
必ず伸張変換のﾏｯﾋﾟﾝｸﾞがおこなわれるよ
だからCODEC内の 変換式がBT.601ｽﾄﾚｰﾄであるCanopusDVの場合
YUY2展開ｵﾝ＞伸張RGB(必ず伸張されるから)
YUY2展開ｵﾌ＞ｽﾄﾚｰﾄRGB(CanopusDVの仕様)
>>345
Aviutlは内部YUVを表示するときに
ｵｰﾊﾞｰﾚｲ・・・ｿｰｽのYUVｽｹｰﾙ（へんな表現だが）でOSに渡す
あとは環境依存
非ｵｰﾊﾞｰﾚｲ（GDI）・・・内部YUV>RGB24変換をAviutlが行う
この変換自体はｽﾄﾚｰﾄだが内部YUVは伸張済みRGB相当で処理するので
伸張RGBとして表示される
>>345
YUV > RGB をストレート変換するならその通りだが
huffyuvやDivXは伸張している。
codecが伸張するのかAVIUtilが伸張するのかの違いだけ。
ふふああのヒストグラムとAVIUtilの波形プラグインを良く見比べてみ。
YUV > RGB をストレート変換するならその通りだが
huffyuvやDivXは伸張している。
codecが伸張するのかAVIUtilが伸張するのかの違いだけ。
ふふああのヒストグラムとAVIUtilの波形プラグインを良く見比べてみ。
カノプーDV codecが普通じゃないだけ。
MorganのCODECも普通じゃないんじゃなかった？
有益な情報ありが㌧です。>>all
厨な質問ですみませんが、皆様はエンコ後の動画の色を「妥当」と
判断するのため、どのようなツールを使っていらっしゃいますか？
厨な質問ですみませんが、皆様はエンコ後の動画の色を「妥当」と
判断するのため、どのようなツールを使っていらっしゃいますか？
AviUtlの波形表示プラグイン
あとは（キャリブレーションされた環境での）見た目
あとは（キャリブレーションされた環境での）見た目
354 ：名無しさん＠編集中：03/10/23 13:17
ここは議論だけでソースや実験結果なんかはまったく出ないんだね
そういう流れにしたければ別にそれでもいいと思うけど
今の流れではその必要がないからね
今の流れではその必要がないからね
>>353
なんか俺の反論を期待しているみたいだな。
なんか俺の反論を期待しているみたいだな。
>>355
知識のない煽り合いが好きな人達には今の流れは楽しいだろうね
知識のない煽り合いが好きな人達には今の流れは楽しいだろうね
今の流れ？
初心者が質問して知識のある人が答えるってのが今の流れじゃん
なんで君は突然煽り始めてるの？
初心者が質問して知識のある人が答えるってのが今の流れじゃん
なんで君は突然煽り始めてるの？
この争いは地上デジタルになったら消えるの？
エンコされたものが、伸張されてるかされてないかって
もう一度編集ソフトに読み込ませて、ソースと見比べりゃわかりそうなもんだが？
もう一度編集ソフトに読み込ませて、ソースと見比べりゃわかりそうなもんだが？
とりあえずですが、0.16.235.255なBMPをhuffyuv DivX CanopusDV の各codecでエンコードして
AviUtilでYUY RGBそれぞれで波形Plug-in表示してみました。
ttp://www.xxxx.nu/upload/upload.cgi?page=Download&dir=&sort=date&filename=AviUtil.zip
Premiereで0.16.235.255なBMPを読み込みhuffyuv DivX canopusDVでAVI出力。
変換されたAVIは
huffyuv DivXの場合、
画面上RGB0-255 ＞ codec内部によりYUY16-235に圧縮 ＞ YUY16-235の範囲のデータを持つAVI
となります。これをAvitilで読み込むと、
YUY読込み : YUY16-235 > YUY16-235のままAviUtilに渡される > AviUtilが画面上RGB0-255に変換。
RGB読込み : YUY16-235 > codecでRGB0-255に伸張 > そのままRGB0-255で画面に出力。
canopusDVcodecの場合、
画面上RGB0-255 ＞ BT601ストレート変換（YUY0-255） ＞ YUY0-255の範囲のデータを持つAVI
になりますが、再度AviUtilでRGB読み込みをすると
YUY読込み : YUY0-255 > YUY0-255のままAviUtilに渡される > AviUtilが画面上RGB 0以下-255以上に変換（0-255を超えている）。
RGB読込み : YUY0-255 > BT601ストレート変換（RGB0-255) > そのままRGB0-255で画面に出力。
それからMPEG2変換 > DVDオーサリング とかやってる人はご存知だと思いますが、
たとえばCCEでエンコする場合、CCEはYUY16-235なデータを要求します。
上記の手順で作成したAVIはhuffyuvやDivXの場合はこのままCCEに喰わせてもOKですが
（DivXをMPEG2に変換する人はいないと思いますが）canopusDVcodecの場合は16-235の範囲に収めていないとおかしな階調になります。
AviUtilでYUY RGBそれぞれで波形Plug-in表示してみました。
ttp://www.xxxx.nu/upload/upload.cgi?page=Download&dir=&sort=date&filename=AviUtil.zip
Premiereで0.16.235.255なBMPを読み込みhuffyuv DivX canopusDVでAVI出力。
変換されたAVIは
huffyuv DivXの場合、
画面上RGB0-255 ＞ codec内部によりYUY16-235に圧縮 ＞ YUY16-235の範囲のデータを持つAVI
となります。これをAvitilで読み込むと、
YUY読込み : YUY16-235 > YUY16-235のままAviUtilに渡される > AviUtilが画面上RGB0-255に変換。
RGB読込み : YUY16-235 > codecでRGB0-255に伸張 > そのままRGB0-255で画面に出力。
canopusDVcodecの場合、
画面上RGB0-255 ＞ BT601ストレート変換（YUY0-255） ＞ YUY0-255の範囲のデータを持つAVI
になりますが、再度AviUtilでRGB読み込みをすると
YUY読込み : YUY0-255 > YUY0-255のままAviUtilに渡される > AviUtilが画面上RGB 0以下-255以上に変換（0-255を超えている）。
RGB読込み : YUY0-255 > BT601ストレート変換（RGB0-255) > そのままRGB0-255で画面に出力。
それからMPEG2変換 > DVDオーサリング とかやってる人はご存知だと思いますが、
たとえばCCEでエンコする場合、CCEはYUY16-235なデータを要求します。
上記の手順で作成したAVIはhuffyuvやDivXの場合はこのままCCEに喰わせてもOKですが
（DivXをMPEG2に変換する人はいないと思いますが）canopusDVcodecの場合は16-235の範囲に収めていないとおかしな階調になります。
>>367
惜しい・・・
CanopusDVへのエンコード方式が間違ってるよ
CanopusDVCodecへのエンコードはストレートRGB(16-235)を食わせるのが基本
素のCanopusDVCodecは
YUY2読込み : YUV16-235有効 > YUV16-235のままAviUtilに渡される > AviUtilが画面上RGB 0-255に変換。
RGB読込み : YUV16-235有効 > BT601ストレート変換（RGB16-235) > そのままRGB16-235で画面に出力。
になる。
なんといっても元々CCESP系はDVソースをターゲットに開発されたもの
そのためずーっとボトムファーストソースがデフォルトだったくらいだよ
つまり素のCanopuDVCodecを読み込ませてなんの問題もないよ
あとBT.601の変換式はあくまでもストレート変換（YUV16-235->RGB16-235）
YUV16-235->RGB0-255は伸張変換だよ（BASICYCbCr式）
それとYUVとYUY2とは区別してくれ
惜しい・・・
CanopusDVへのエンコード方式が間違ってるよ
CanopusDVCodecへのエンコードはストレートRGB(16-235)を食わせるのが基本
素のCanopusDVCodecは
YUY2読込み : YUV16-235有効 > YUV16-235のままAviUtilに渡される > AviUtilが画面上RGB 0-255に変換。
RGB読込み : YUV16-235有効 > BT601ストレート変換（RGB16-235) > そのままRGB16-235で画面に出力。
になる。
なんといっても元々CCESP系はDVソースをターゲットに開発されたもの
そのためずーっとボトムファーストソースがデフォルトだったくらいだよ
つまり素のCanopuDVCodecを読み込ませてなんの問題もないよ
あとBT.601の変換式はあくまでもストレート変換（YUV16-235->RGB16-235）
YUV16-235->RGB0-255は伸張変換だよ（BASICYCbCr式）
それとYUVとYUY2とは区別してくれ
要は
BT.601変換式のCodecはYUV->RGBでもRGB->YUVでもストレート
BASICCbCr変換式のCodecはYUV->RGBは伸張、RGB->YUVは圧縮
ってこと
BT.601変換式のCodecはYUV->RGBでもRGB->YUVでもストレート
BASICCbCr変換式のCodecはYUV->RGBは伸張、RGB->YUVは圧縮
ってこと
もうひとつ蛇足だが
以上のことから
Canopus>DivXの場合
CanopusDVCodecをYUY2展開（読み込み）させれば
なんの問題もなくエンコードできる
DivX->Canopus(こんなことしないけどw)の場合
CanopusDVCodecをYUY2圧縮させれば
なんの問題もない
BT.601系CodecとBASICYCbCr系Codecの相互変換は
途中でRGBにしないかぎり問題はおきない
なぜならYUV16-235有効なのは一緒だから
以上のことから
Canopus>DivXの場合
CanopusDVCodecをYUY2展開（読み込み）させれば
なんの問題もなくエンコードできる
DivX->Canopus(こんなことしないけどw)の場合
CanopusDVCodecをYUY2圧縮させれば
なんの問題もない
BT.601系CodecとBASICYCbCr系Codecの相互変換は
途中でRGBにしないかぎり問題はおきない
なぜならYUV16-235有効なのは一緒だから
>>368
フォローどうもです。
>YUVとYUY2とは
はい。私のミスです。
>CanopusDVへのエンコード方式が間違ってるよ
>CanopusDVCodecへのエンコードはストレートRGB(16-235)を食わせるのが基本
それは理解しています。比較の為あえてRGB0-255を喰わせています。
いつもはきちんと16-235に収めています。
>そのためずーっとボトムファーストソースがデフォルトだったくらいだよ
いまでもそうですね。
フォローどうもです。
>YUVとYUY2とは
はい。私のミスです。
>CanopusDVへのエンコード方式が間違ってるよ
>CanopusDVCodecへのエンコードはストレートRGB(16-235)を食わせるのが基本
それは理解しています。比較の為あえてRGB0-255を喰わせています。
いつもはきちんと16-235に収めています。
>そのためずーっとボトムファーストソースがデフォルトだったくらいだよ
いまでもそうですね。
372 ：名無しさん＠編集中：03/10/24 00:08
>>367
ちょっと脱線だが
＞CCEはYUY16-235なデータを要求します。
＞（中略）
＞canopusDVcodecの場合は16-235の範囲に収めていないと
＞おかしな階調になります
これは本当？
家庭用DVカメラで撮るとどうしてもその範囲からはみ出ることがある。
（カメラによるが）
そういう用途でCCEは使ってはいけない？
ちょっと脱線だが
＞CCEはYUY16-235なデータを要求します。
＞（中略）
＞canopusDVcodecの場合は16-235の範囲に収めていないと
＞おかしな階調になります
これは本当？
家庭用DVカメラで撮るとどうしてもその範囲からはみ出ることがある。
（カメラによるが）
そういう用途でCCEは使ってはいけない？
テレビキャプチャでもDVDでもはみだしてるよ。
＞それからMPEG2変換 > DVDオーサリング とかやってる人はご存知だと思いますが、
＞たとえばCCEでエンコする場合、CCEはYUY16-235なデータを要求します。
これ嘘だろ
＞たとえばCCEでエンコする場合、CCEはYUY16-235なデータを要求します。
これ嘘だろ
＞ 画面上RGB0-255 ＞ codec内部によりYUY16-235に圧縮 ＞ YUY16-235の範囲のデータを持つAVI
ここの「YUY16-235の範囲のデータを持つAVI」が16-235の範囲のデータを持つという証拠は？
確か前にAVIUTLの波形プラグインはAVIデータの値をそのまま反映してると誰かが発言していたはずだが
どうなってるんだ？
見てる側からすれば言い分が２転3転してるとしか思えない
ここの「YUY16-235の範囲のデータを持つAVI」が16-235の範囲のデータを持つという証拠は？
確か前にAVIUTLの波形プラグインはAVIデータの値をそのまま反映してると誰かが発言していたはずだが
どうなってるんだ？
見てる側からすれば言い分が２転3転してるとしか思えない
AviUtl099でYUVデータを扱ったとき
ヒストグラムのYCbCrと波形プラグインでは扱うスケールが違ったりするんだよねえ。
わざわざ書くこともないと思うけど
例えば、YUV16-235なデータをYUY2読み込みすると
ヒストグラムYCbCr：YUV16-235
ヒストグラムRGB：RGB0-255
波形表示プラグイン：YUV0-255
編集画面表示：RGB0-255
だから波形表示プラグインの表示は、
編集画面のために伸張された後のデータを反映している、と言ってもいいかもしれない。
ヒストグラムのYCbCrと波形プラグインでは扱うスケールが違ったりするんだよねえ。
わざわざ書くこともないと思うけど
例えば、YUV16-235なデータをYUY2読み込みすると
ヒストグラムYCbCr：YUV16-235
ヒストグラムRGB：RGB0-255
波形表示プラグイン：YUV0-255
編集画面表示：RGB0-255
だから波形表示プラグインの表示は、
編集画面のために伸張された後のデータを反映している、と言ってもいいかもしれない。
言ってもいいっていうかそういうものなんじゃないのかあれは
>>374
わかってないんだよ、>>340は
YUVで渡せばスケール変換が起きないってことがな
例えばYUV0-255のソースをYUY2読み込みさせれば
CCEはそのままYUV0-255のMPEGを吐くだけなんだけどな
>>371で素直にミスを認めればいいものを・・・。
わかってないんだよ、>>340は
YUVで渡せばスケール変換が起きないってことがな
例えばYUV0-255のソースをYUY2読み込みさせれば
CCEはそのままYUV0-255のMPEGを吐くだけなんだけどな
>>371で素直にミスを認めればいいものを・・・。
つーか>>340は伸張派なんで有効範囲外データはゴミかなんかだと思ってるんだろうな
範囲外はゴミでしょ
ゴミだけど残そうよ。
ゴミじゃねえっての
でも、どーせ見えないんでしょ
>>376
>例えば、YUV16-235なデータをYUY2読み込みすると
そのファイルがYUV16-235であるとどうして言い切れるんだ
波形表示プラグインでさえ信頼できないのに、そのデータが本当に
YUV16-235の範囲にあると言い切れる根拠は何だ？
>例えば、YUV16-235なデータをYUY2読み込みすると
そのファイルがYUV16-235であるとどうして言い切れるんだ
波形表示プラグインでさえ信頼できないのに、そのデータが本当に
YUV16-235の範囲にあると言い切れる根拠は何だ？
ストレート変換で
RGB 1-254 あたりになるんならYUVで16-235ってのでいいんじゃねえの？
0-255になっちゃったら、YUVで16以下235以上の可能性があるけど。
RGB 1-254 あたりになるんならYUVで16-235ってのでいいんじゃねえの？
0-255になっちゃったら、YUVで16以下235以上の可能性があるけど。
だから範囲外はいらねーんだってば
範囲外にデータがあった場合、サチュレートすると当然ながら内部データは変わる
そのときPCでの表示、いわゆる伸張状態では色は変わらないが、
DVDプレイヤーなどでテレビに出力する場合は色が変わってくる
ものによってはかなり変わる
なのでテレビ出力を全く考えてないならサチュレートしてもなんの問題もない
テレビ出力を考えてるならサチュレートするしないで色が変わるから好みで使い分けろ
そういうことだから範囲外はゴミだとかいらねーだとか一言で片付けるな
そのときPCでの表示、いわゆる伸張状態では色は変わらないが、
DVDプレイヤーなどでテレビに出力する場合は色が変わってくる
ものによってはかなり変わる
なのでテレビ出力を全く考えてないならサチュレートしてもなんの問題もない
テレビ出力を考えてるならサチュレートするしないで色が変わるから好みで使い分けろ
そういうことだから範囲外はゴミだとかいらねーだとか一言で片付けるな
>>388
PCだけで見るのがDTVじゃないからね。
PCだけで見るのがDTVじゃないからね。
だまされないぞ！
TVってYUVの0-15までと、236以降ってどの変まで表示できるのが多いの？
規格上は、その範囲は規定無し なだけだから各社さまざまなんだろうけど・・・
色温度が規定なくてもなんとなく13000-16000とかくらいに各社そろえてる
（そろった？）みたいに傾向があったりするん？
規格上は、その範囲は規定無し なだけだから各社さまざまなんだろうけど・・・
色温度が規定なくてもなんとなく13000-16000とかくらいに各社そろえてる
（そろった？）みたいに傾向があったりするん？
で、普段おまえらは何をキャプってるの？
モ
>>386
Avisynthでつくればいいだけでしょ
Avisynthならソースだって公開されてるんだから
ソースの工程が正しいかどうかは日欧米のエンコ厨がチェックしてるよ
納得できなければ自分でチェックすればいい
そのデータが厳密にYUV16-235であるクリップを作ればいいだけだよ
で、それをAviutlの検証用に使う、と
Avisynthでつくればいいだけでしょ
Avisynthならソースだって公開されてるんだから
ソースの工程が正しいかどうかは日欧米のエンコ厨がチェックしてるよ
納得できなければ自分でチェックすればいい
そのデータが厳密にYUV16-235であるクリップを作ればいいだけだよ
で、それをAviutlの検証用に使う、と
>>387
それは伸張変換
それは伸張変換
>>398
Y=16にした場合、UVの取る値にも気をつけろよ。
伸張式
R = 1.164(Y-16) + 1.596(Cr-128)
G = 1.164(Y-16) - 0.391(Cb-128) - 0.813(Cr-128)
B = 1.164(Y-16) + 2.018(Cb-128)
ストレート変換式
R = 1.000Y + 1.402(Cr-128)
G = 1.000Y - 0.344(Cb-128) - 0.714(Cr-128)
B = 1.000Y + 1.772(Cb-128)
つまり、Y=16のとき、UVは128にしとけ。上も同じY=235の時、UV=128
(つまり最低輝度や最高輝度には色を付けてはいけない）
Y=16にした場合、UVの取る値にも気をつけろよ。
伸張式
R = 1.164(Y-16) + 1.596(Cr-128)
G = 1.164(Y-16) - 0.391(Cb-128) - 0.813(Cr-128)
B = 1.164(Y-16) + 2.018(Cb-128)
ストレート変換式
R = 1.000Y + 1.402(Cr-128)
G = 1.000Y - 0.344(Cb-128) - 0.714(Cr-128)
B = 1.000Y + 1.772(Cb-128)
つまり、Y=16のとき、UVは128にしとけ。上も同じY=235の時、UV=128
(つまり最低輝度や最高輝度には色を付けてはいけない）
波形表示プラグインの601補助線の意味を教えてください
>>401
本質だよ
Y = 0.299R + 0.587G + 0.114B
U = -0.169R - 0.331G + 0.500B
V = 0.500R - 0.419G - 0.081B
R = 1.000Y + 1.402V
G = 1.000Y - 0.344U - 0.714V
B = 1.000Y + 1.772U
UVを120にしてどうする？
本質だよ
Y = 0.299R + 0.587G + 0.114B
U = -0.169R - 0.331G + 0.500B
V = 0.500R - 0.419G - 0.081B
R = 1.000Y + 1.402V
G = 1.000Y - 0.344U - 0.714V
B = 1.000Y + 1.772U
UVを120にしてどうする？
>>403
その式使う時は、UVは-128～127の数値を使えよ。
でバイナリデータにした場合、>>407も言ってるが、0～255になるから
結局>>399と同じなんだよ。
単なる表記の違い。
>>405
YUVでは、色情報の削減に人間の目の特性も利用している。
つまり輝度は極端な方向に行く場合、どんどん色情報は減るようにする。
これは人間の目が極端に暗い場合や明るい場合、色を見分けられない特性を利用している。
つまり、YUVデータ上、Y:16-235, UV:16-240(-112～+112)の任意の範囲を取れるといっても、
Yが大きく（小さく）なるに従って、UVは取りえる振幅を小さくしないといけない。
>399の伸張式で、Y=16,Cb=Cr=128で計算すると、R=G=B=0になるだろう？
その式使う時は、UVは-128～127の数値を使えよ。
でバイナリデータにした場合、>>407も言ってるが、0～255になるから
結局>>399と同じなんだよ。
単なる表記の違い。
>>405
YUVでは、色情報の削減に人間の目の特性も利用している。
つまり輝度は極端な方向に行く場合、どんどん色情報は減るようにする。
これは人間の目が極端に暗い場合や明るい場合、色を見分けられない特性を利用している。
つまり、YUVデータ上、Y:16-235, UV:16-240(-112～+112)の任意の範囲を取れるといっても、
Yが大きく（小さく）なるに従って、UVは取りえる振幅を小さくしないといけない。
>399の伸張式で、Y=16,Cb=Cr=128で計算すると、R=G=B=0になるだろう？
>>403
で、どこが本質だと思ってるの？
CbCrとUVの違い？
俺の思う本質は括弧の中
＞(つまり最低輝度や最高輝度には色を付けてはいけない）
YとUVは関連性があり、独立して考えちゃダメって点だと思うが？
で、どこが本質だと思ってるの？
CbCrとUVの違い？
俺の思う本質は括弧の中
＞(つまり最低輝度や最高輝度には色を付けてはいけない）
YとUVは関連性があり、独立して考えちゃダメって点だと思うが？
>>408
>Yが大きく（小さく）なるに従って、UVは取りえる振幅を小さくしないといけない。
ということはないよ。
YUV16-235の間では元から振幅幅は充分に小さいし
PCモニタやテレビという自然と比較して圧倒的に表現の幅が狭い系では
人間は色を充分区別できる。
YUV(16,239,239)とYUV(16,240,240)は違う色として見えるよ。
YUVの値が2違ったらRGBで最大8違うわけだし。
それ以前にキャプやリップだとUVの幅は規定値より狭い（限界値付近を取らない）。
>つまり最低輝度や最高輝度には色を付けてはいけない
んじゃなくて
>YとUVは関連性があり、独立して考えちゃダメって点だと思うが？
つーのはその通りだけどね。
>Yが大きく（小さく）なるに従って、UVは取りえる振幅を小さくしないといけない。
ということはないよ。
YUV16-235の間では元から振幅幅は充分に小さいし
PCモニタやテレビという自然と比較して圧倒的に表現の幅が狭い系では
人間は色を充分区別できる。
YUV(16,239,239)とYUV(16,240,240)は違う色として見えるよ。
YUVの値が2違ったらRGBで最大8違うわけだし。
それ以前にキャプやリップだとUVの幅は規定値より狭い（限界値付近を取らない）。
>つまり最低輝度や最高輝度には色を付けてはいけない
んじゃなくて
>YとUVは関連性があり、独立して考えちゃダメって点だと思うが？
つーのはその通りだけどね。
ふぬああでYUY2無圧縮録画、RGB24bit無圧縮録画したものをAVIUTLに読み込む
YUY2はRGB24を伸張したデータになった
ここでYUY2はAVIUTLで読み込むときに強制伸張、RGB24はストレートだと考えて
ふぬああでHuffyuvにして録画すればどっちのケースでも強制伸張が起きて
RGB24録画した物が伸張されYUY2録画した物と同じになるはずだったが結果は変わらず
Huffyuvは可逆圧縮なので変わりにDIVXを使うも結果は同じ
YUY2はRGB24を伸張したデータになった
ここでYUY2はAVIUTLで読み込むときに強制伸張、RGB24はストレートだと考えて
ふぬああでHuffyuvにして録画すればどっちのケースでも強制伸張が起きて
RGB24録画した物が伸張されYUY2録画した物と同じになるはずだったが結果は変わらず
Huffyuvは可逆圧縮なので変わりにDIVXを使うも結果は同じ
>>343
おっしゃるとおりに
ストレート変換でMpeg2を読み込ませDivXの圧縮設定をYUY2で圧縮するのチェックを
入れたものと外したもので試したが
圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
おっしゃるとおりに
ストレート変換でMpeg2を読み込ませDivXの圧縮設定をYUY2で圧縮するのチェックを
入れたものと外したもので試したが
圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
大成功ですね
＞＞４１４
ポイントはここ
MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする（DivXがRGB->YUV変換を行う）
このYUY2圧縮なし の部分
ということはYUY2圧縮するにチェックを入れれば2重スケール圧縮にならないと受け取れる
実際はどっちに設定しても2重スケール圧縮されましたよ
ポイントはここ
MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする（DivXがRGB->YUV変換を行う）
このYUY2圧縮なし の部分
ということはYUY2圧縮するにチェックを入れれば2重スケール圧縮にならないと受け取れる
実際はどっちに設定しても2重スケール圧縮されましたよ
ん？何か問題でも？
あっちのスレが高度すぎて着いていけなくなってきているのですが、
MPEG2をm2v.aui使ってAvuUtlに読み込んでDivXで出力するとした場合、
コーデックの設定で「YUY2で圧縮する」のチェックを外す
ってことでよろしいでしょうか？
すでにYUY2になっているので、
MPEG2をm2v.aui使ってAvuUtlに読み込んでDivXで出力するとした場合、
コーデックの設定で「YUY2で圧縮する」のチェックを外す
ってことでよろしいでしょうか？
すでにYUY2になっているので、
よろしくないです。
>>416
あぁそういう意味じゃないよ
YUY2圧縮にチェックだとBT.601変換であるCanopusDVCodecだって圧縮されるんだから
無論この場合はチェックなしだと圧縮されない
YUY2圧縮にチェックを入れるとAviutlが圧縮変換するから
DivXがRGB->YUVをするかどうかの検証にならないでしょ
だから>>343のように書いただけ
で、二重圧縮になるでしょ？
DivXはRGB->YUVに圧縮変換を行うことが証明されたじゃん
と思ったら
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってなんだ？
あぁそういう意味じゃないよ
YUY2圧縮にチェックだとBT.601変換であるCanopusDVCodecだって圧縮されるんだから
無論この場合はチェックなしだと圧縮されない
YUY2圧縮にチェックを入れるとAviutlが圧縮変換するから
DivXがRGB->YUVをするかどうかの検証にならないでしょ
だから>>343のように書いただけ
で、二重圧縮になるでしょ？
DivXはRGB->YUVに圧縮変換を行うことが証明されたじゃん
と思ったら
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってなんだ？
>>419>>421
AviUtlのスレで質問しようとしたらこっちに書いちゃいまいた（ｗ
違いはAviUtlが圧縮するかコーデック側がやるかの違いで、結局どちらも圧縮されるってことですね
ありがとうございました
AviUtlのスレで質問しようとしたらこっちに書いちゃいまいた（ｗ
違いはAviUtlが圧縮するかコーデック側がやるかの違いで、結局どちらも圧縮されるってことですね
ありがとうございました
あぁわかった
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってのは
DivXが伸張変換してRGBになるが
作成手順 で二重圧縮してるから
結果的に一段圧縮されてストレートRGBと同じ色範囲を持つってことね
あってるじゃないの
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってのは
DivXが伸張変換してRGBになるが
作成手順 で二重圧縮してるから
結果的に一段圧縮されてストレートRGBと同じ色範囲を持つってことね
あってるじゃないの
>>421
YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
これは、Aviutlが伸張して表示していて
チェックなしだと、ビデオ展開形式がRGBになるけど、
これは、コーデックがYUV<->RGB変換して
表示させているということでいいでしょうか？
YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
これは、Aviutlが伸張して表示していて
チェックなしだと、ビデオ展開形式がRGBになるけど、
これは、コーデックがYUV<->RGB変換して
表示させているということでいいでしょうか？
あぁちがうｗ
表示の話か
>>YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
>>これは、Aviutlが伸張して表示していて
>>チェックなしだと、ビデオ展開形式がRGBになるけど、
ここまではそのとおり
で、
RGB後内部YUV48にマッピングされ
内部YUV48->RGB24にAviutlが変換して表示する
表示の話か
>>YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
>>これは、Aviutlが伸張して表示していて
>>チェックなしだと、ビデオ展開形式がRGBになるけど、
ここまではそのとおり
で、
RGB後内部YUV48にマッピングされ
内部YUV48->RGB24にAviutlが変換して表示する
で、AVIUTLの波形表示プラグインでBT601線にあわせてエンコしたとある？
基本的にRGB読み込みの時に使うものでしょうに
↓
基本的にストレートRGB読み込みの時に使うものでしょうに
”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB
↓
基本的にストレートRGB読み込みの時に使うものでしょうに
”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB
>>431
何のチェックに使えるんだ？
>>432
ストレートRGB読み込みでも最終的に０－２５５ラインに合わせればいいから
601ラインは不必要では？
＞”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB
０－２５５を一杯に使うキャプチャーカードって何だよ
０－２５５を一杯に使うコーデックって何だよ
ちゃんとここを説明しておかないと混乱の元になるわな
だいたい０－２５５を一杯に使わないコーデックってあるのか？
コーデックのスケールの概念を持たないのが普通で、その知らない人たちに
たった一行でとても重要なことをあっさり済ませる態度が気にきらない
お陰で何ヶ月という時間を無駄にしたか分からん
何のチェックに使えるんだ？
>>432
ストレートRGB読み込みでも最終的に０－２５５ラインに合わせればいいから
601ラインは不必要では？
＞”0～255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB
０－２５５を一杯に使うキャプチャーカードって何だよ
０－２５５を一杯に使うコーデックって何だよ
ちゃんとここを説明しておかないと混乱の元になるわな
だいたい０－２５５を一杯に使わないコーデックってあるのか？
コーデックのスケールの概念を持たないのが普通で、その知らない人たちに
たった一行でとても重要なことをあっさり済ませる態度が気にきらない
お陰で何ヶ月という時間を無駄にしたか分からん
単にお前が理解していないだけだろ。
んなのに引っかかるの一人ぐらいのものだろう
ストレート変換しなきゃ黒レベルが適切かどうか判定できない
(SMPTE カラーバーの -5% 領域が意味を持たない)から BT.601
チェックは一応意味があるし
ストレート変換しなきゃ黒レベルが適切かどうか判定できない
(SMPTE カラーバーの -5% 領域が意味を持たない)から BT.601
チェックは一応意味があるし
BT8x8とかCXとかだと、16～253の範囲の値をとる。
0-15,254,255は存在しない。
こんなキャプチャボードの場合、16-235で調整するわけ。
別に他のキャプチャボードでも16-235で調整するのが混乱しない標準設定だと思うけど。
0-15,254,255は存在しない。
こんなキャプチャボードの場合、16-235で調整するわけ。
別に他のキャプチャボードでも16-235で調整するのが混乱しない標準設定だと思うけど。
>>435
伸張読み込みして0-255の範囲に入ってたら黒レベルは適切だと分かるんだがな
>>436
それはBT,CXチップがアナログ信号の16-253の範囲をサンプリングしてデジタル化するわけですか？
それで16-235に調整してもファイルの値は31-215なのですが、それに意味があるのか分からない
伸張読み込みして0-255の範囲に入ってたら黒レベルは適切だと分かるんだがな
>>436
それはBT,CXチップがアナログ信号の16-253の範囲をサンプリングしてデジタル化するわけですか？
それで16-235に調整してもファイルの値は31-215なのですが、それに意味があるのか分からない
そもそもアナログ信号を
16～253の範囲の値をとる
ってICがどうやって判断してるの？（Pu
16～253の範囲の値をとる
ってICがどうやって判断してるの？（Pu
>>437
なにを勘違いしてるのか解らんが、アナログ信号のmVは相対的なものだよ。
信号的に0IREはXXmVて決まってるかも知れんが、
ICの場合、Gain調整で上下限を決めてるだけ。
だから、プロパティ設定で、Brightness,Contrast,Hue,Saturationの設定により
変化するわけ。
で、元のアナログ値じゃなくて取り込んだ後のデジタルデータが、16-253の範囲になっちゃうってこと。
なにを勘違いしてるのか解らんが、アナログ信号のmVは相対的なものだよ。
信号的に0IREはXXmVて決まってるかも知れんが、
ICの場合、Gain調整で上下限を決めてるだけ。
だから、プロパティ設定で、Brightness,Contrast,Hue,Saturationの設定により
変化するわけ。
で、元のアナログ値じゃなくて取り込んだ後のデジタルデータが、16-253の範囲になっちゃうってこと。
だから31-215なんかにはならない。あくまで16-253
>>440
CX系は持って無いので知りませんが、明るさやコントラストを
どんなに上げ下げして真っ白真っ黒な画像をキャプチャーしても
波形表示プラグインでみれば16-253のラインでYの値が切れてるんですか？
SAA系はデータとしてなら-20～270くらいまで取れてるようなんですけど
CX系は持って無いので知りませんが、明るさやコントラストを
どんなに上げ下げして真っ白真っ黒な画像をキャプチャーしても
波形表示プラグインでみれば16-253のラインでYの値が切れてるんですか？
SAA系はデータとしてなら-20～270くらいまで取れてるようなんですけど
>>442
いったいどうやって0-255を超えるデータを保持できるの？
いったいどうやって0-255を超えるデータを保持できるの？
なんだか素人の猛者がうじゃうじゃ湧いて出る気がするな。
>>442
>SAA系はデータとしてなら-20～270くらいまで取れてるようなんですけど
Datasheetに "Sampling according ITU-R BT.601" と書いてあるぞ。
輝度やコントラストを弄れば波形は動くが、取り込みのスパンはあくまでも16-235の範囲内。
>SAA系はデータとしてなら-20～270くらいまで取れてるようなんですけど
Datasheetに "Sampling according ITU-R BT.601" と書いてあるぞ。
輝度やコントラストを弄れば波形は動くが、取り込みのスパンはあくまでも16-235の範囲内。
>>445
SAA7133でYUY2で取り込んだデータなんだけど、コントラスト弄ると
0～255のデータがちゃんと入ってるんだが、これは
SAA71xxで取り込んだ時点じゃ16-235だけど、その後スケール変換して0-255にされたってことですか？
（ちなみにバイナリエディタで覗いた16進数ダンプデータで確認）
SAA7133でYUY2で取り込んだデータなんだけど、コントラスト弄ると
0～255のデータがちゃんと入ってるんだが、これは
SAA71xxで取り込んだ時点じゃ16-235だけど、その後スケール変換して0-255にされたってことですか？
（ちなみにバイナリエディタで覗いた16進数ダンプデータで確認）
447 ：名無しさん＠編集中：03/10/26 05:04
素人がこんな難しいスレに質問投げてすみません。
専門的な話をばっさり切ってしまって大雑把に言えば、ＴＶ放送開始前の
カラーパターンのなかの、黒０％のところがＰＣ上で(R,G,B)=(0,0,0)に
なるように調整し、白100%の部分がPC上で(R,G,B)=(255,255,255)になる
ようにすればよいのでしょうか？
白100%の部分が(R,G,B)=(255,255,255)となるように調整すると、実際に
放送をキャプチャしたものが白飛びを起こすので何か違うような気もする
んですが・・・
#MTV2000
専門的な話をばっさり切ってしまって大雑把に言えば、ＴＶ放送開始前の
カラーパターンのなかの、黒０％のところがＰＣ上で(R,G,B)=(0,0,0)に
なるように調整し、白100%の部分がPC上で(R,G,B)=(255,255,255)になる
ようにすればよいのでしょうか？
白100%の部分が(R,G,B)=(255,255,255)となるように調整すると、実際に
放送をキャプチャしたものが白飛びを起こすので何か違うような気もする
んですが・・・
#MTV2000
放送されたカラーバーがそもそもそんな綺麗な数字ではないはず
>>447
放送局のカラーバーはあまり信じないほうがいい
とくに明るさ・コントラストはカラーバーを使わなくても調整できるから必要ない
色合い・色の濃さは他に基準がないのでカラーバーを使うしかないけど
最終的には見た目を信じるしかないね
放送局のカラーバーはあまり信じないほうがいい
とくに明るさ・コントラストはカラーバーを使わなくても調整できるから必要ない
色合い・色の濃さは他に基準がないのでカラーバーを使うしかないけど
最終的には見た目を信じるしかないね
450 ：447：03/10/26 05:25
SMPTEカラーバーなら一番左は黒じゃないし0じゃないよ
456 ：名無しさん＠編集中：03/10/26 15:27
>>447
MTV2000使ってる時点でそのへんは「機械任せ」になるんだけど。
望むと望まざるにかかわらず。
（G.I.ワークスのページでもそこら辺についての記述あり）
エンコ時に１フレームずつ手動で調整するわけにもいかないだろ？
MTV2000使ってる時点でそのへんは「機械任せ」になるんだけど。
望むと望まざるにかかわらず。
（G.I.ワークスのページでもそこら辺についての記述あり）
エンコ時に１フレームずつ手動で調整するわけにもいかないだろ？
AVIキャプなら自分で調整できる
難しい話は分からないのでもう見た目で調整することにしました。
CS23881って、カノプのより100位色が薄い気がするんだけど…
aviutlで100位濃くするべき？
aviutlで100位濃くするべき？
>>460
CX23881のことだと思いますが、
カノプのと同じ色がいいと思ったらそうしてもいいかと。
ただ、カノプも独自の味付けを色に施しているはずです。
色の好みって結構個人差があるから、自分の納得いくようにしても
いいと思う。
一度カラーバーキャプしてAviutlの波形表示プラグインで見てみれば
参考になるかもしれません。
CX23881のことだと思いますが、
カノプのと同じ色がいいと思ったらそうしてもいいかと。
ただ、カノプも独自の味付けを色に施しているはずです。
色の好みって結構個人差があるから、自分の納得いくようにしても
いいと思う。
一度カラーバーキャプしてAviutlの波形表示プラグインで見てみれば
参考になるかもしれません。
>CS23881
CX23881の間違えでした
以前同じ設定でキャプしたカラーバーを使って、
Aviutlの波形表示プラグインで調べてみましたが、
やはり薄すぎる様でチョット鬱。
でも、色調整したところかなりいい感じになりました。
感謝。
CX23881の間違えでした
以前同じ設定でキャプしたカラーバーを使って、
Aviutlの波形表示プラグインで調べてみましたが、
やはり薄すぎる様でチョット鬱。
でも、色調整したところかなりいい感じになりました。
感謝。
>>453は結構なバカ。まるで分かっていない。
デジタル放送の話であり、局の友人から下のデータが正しいというのを
確認してあり、そのままコピーしたという前提なら彼は
正しい。
まちがってるのは463-464
確認してあり、そのままコピーしたという前提なら彼は
正しい。
まちがってるのは463-464
このスレでコンセンサスがとれた話題ってありますでしょうか？
おいら全然わかんないんで確実な所から理解していきたいです(；´Д`)
おいら全然わかんないんで確実な所から理解していきたいです(；´Д`)
>>466
一般論で話す奴、
自分の環境でだけで話す奴、
極端な場合や例外を取り上げて反論する奴、
現実を無視して理論的な話だけで反論する奴、
揚げ足とる奴、
なんか入れ混じっているけど、概ねコンセンサスは取れてる。
結論が出てる話に、特殊環境や極例を持ち出してきて話題にしてるだけ。
一般論で話す奴、
自分の環境でだけで話す奴、
極端な場合や例外を取り上げて反論する奴、
現実を無視して理論的な話だけで反論する奴、
揚げ足とる奴、
なんか入れ混じっているけど、概ねコンセンサスは取れてる。
結論が出てる話に、特殊環境や極例を持ち出してきて話題にしてるだけ。
白とび防止でしょ
Lが救われてから話題がないな
本日は晴天なり 本日は晴天なり
>>473
二日前の天気に文句言っても．．．
二日前の天気に文句言っても．．．
ﾜﾗﾀｗ
>>471
奴が帰ってきたぞ
奴が帰ってきたぞ
>>476
どのスレ？
どのスレ？
>>476
何時の間にか奴はバージョンアップされてるぞ(MMMMMMMMMM
何時の間にか奴はバージョンアップされてるぞ(MMMMMMMMMM
479 ：名無しさん＠編集中：03/11/12 23:31
過去ログ読んだのですがわからなかったので質問させてください。
AviUtlを使ってDivX5.0.5のファイルを作成しましたが、AviUtlのプレビューと実際にできたファイルの色合いが異なってしまいました。
DivXの方が全体的に暗くなっているような感じです。
Geforceなのでオーバーレイの設定がおかしいのかと思い、非圧縮のAVIファイルを作成して再生してみたところ(オーバーレイ表示されていると思っています)、プレビューと同じ色でした。
また、このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。
どうもメディアプレイヤーで再生した場合だけ色がおかしいようです。
DivX再生時のコーデック設定をいろいろ変更してみましたが、色は変わりませんでした。
実は先日ハードディスクがクラッシュしてしまいまして、OS入れなおしたらDivXファイルを再生すると色が全部おかしくなっていてびっくりしました。
以前はAviUtlのプレビュー通りに再生できていたのですが．．．。
対処方法などおわかりの方お助けください。
環境
再生：Windows2000 Media Player 9
ビデオカード：Geforce4MX
DivX：5.0.5
ソース：MTV2000でキャプチャしたMPEG2ファイル (m2v.aui経由で読み込み)
AviUtlを使ってDivX5.0.5のファイルを作成しましたが、AviUtlのプレビューと実際にできたファイルの色合いが異なってしまいました。
DivXの方が全体的に暗くなっているような感じです。
Geforceなのでオーバーレイの設定がおかしいのかと思い、非圧縮のAVIファイルを作成して再生してみたところ(オーバーレイ表示されていると思っています)、プレビューと同じ色でした。
また、このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。
どうもメディアプレイヤーで再生した場合だけ色がおかしいようです。
DivX再生時のコーデック設定をいろいろ変更してみましたが、色は変わりませんでした。
実は先日ハードディスクがクラッシュしてしまいまして、OS入れなおしたらDivXファイルを再生すると色が全部おかしくなっていてびっくりしました。
以前はAviUtlのプレビュー通りに再生できていたのですが．．．。
対処方法などおわかりの方お助けください。
環境
再生：Windows2000 Media Player 9
ビデオカード：Geforce4MX
DivX：5.0.5
ソース：MTV2000でキャプチャしたMPEG2ファイル (m2v.aui経由で読み込み)
質問が悪い
質問自体がすでに間違ってる
質問からして何も分かってないのが伝わってくる
ただ、何が聞きたいかは分かる
もしその質問に答えようと思ったら、30分ぐらいかけて長文を作成しなければならない
もちろんいろんなサイトへのリンクも貼りつつね
そんな面倒なことをする人はなかなかいない
とりあえず質問からしてちゃんと理解できてないみたいですよ？という意味で
( ﾟДﾟ)ﾊｧ?
( ﾟДﾟ)ﾎﾟｶｰﾝ
( ´,_ゝ｀)ﾌﾟｯ
という優しい反応が返ってきたということだよ
質問自体がすでに間違ってる
質問からして何も分かってないのが伝わってくる
ただ、何が聞きたいかは分かる
もしその質問に答えようと思ったら、30分ぐらいかけて長文を作成しなければならない
もちろんいろんなサイトへのリンクも貼りつつね
そんな面倒なことをする人はなかなかいない
とりあえず質問からしてちゃんと理解できてないみたいですよ？という意味で
( ﾟДﾟ)ﾊｧ?
( ﾟДﾟ)ﾎﾟｶｰﾝ
( ´,_ゝ｀)ﾌﾟｯ
という優しい反応が返ってきたということだよ
>>479
DivXのデコーダの設定ぐらいかけよ
DivXのデコーダの設定ぐらいかけよ
482 ：名無しさん＠編集中：03/11/13 01:05
>>480
非圧縮って非圧縮RGBか？
それはRGBオーバーレイになるんでDivXの再生のときとは無関係
DivXはYUVオーバーレイ
また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
といっているがYUY2展開はオンオフ？
作成するときもYUY2展開はオンオフ？
そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ？
非圧縮って非圧縮RGBか？
それはRGBオーバーレイになるんでDivXの再生のときとは無関係
DivXはYUVオーバーレイ
また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
といっているがYUY2展開はオンオフ？
作成するときもYUY2展開はオンオフ？
そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ？
>>479だった・・・
あとAviutlのﾌﾟﾚﾋﾞｭｰじゃなくてオーバレイ表示オンと比較してくれ
486 ：479：03/11/14 01:57
>>483
すみません返事が遅れてしまいました
> あとAviutlのﾌﾟﾚﾋﾞｭｰじゃなくてオーバレイ表示オンと比較してくれ
まずこれですが、オーバーレイ表示をオンにすると暗くなります
> 非圧縮って非圧縮RGBか？
> それはRGBオーバーレイになるんでDivXの再生のときとは無関係
> DivXはYUVオーバーレイ
大変勉強になりました
オーバーレイには１種類しかないと思っていましたので
> また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
> といっているがYUY2展開はオンオフ？
> 作成するときもYUY2展開はオンオフ？
よくわからないのですべてオンにしております
> そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ？
元のMPEG2をメディアクルーズで再生している際は、元の色（暗くない）で再生されます
やはりオーバーレイがおかしいのでしょうか？
心配なのはDivXの作成方法が正しくないから暗くなってしまったのではないかということなのです
ビデオカードの設定でオーバーレイの色合いを変えられますが、単純に非オーバーレイと同じ色にするという項目はないようですね
目視で変更する以外に方法があるのでしょうか？
質問ばかりですみませんが、よろしくお願いいたします
すみません返事が遅れてしまいました
> あとAviutlのﾌﾟﾚﾋﾞｭｰじゃなくてオーバレイ表示オンと比較してくれ
まずこれですが、オーバーレイ表示をオンにすると暗くなります
> 非圧縮って非圧縮RGBか？
> それはRGBオーバーレイになるんでDivXの再生のときとは無関係
> DivXはYUVオーバーレイ
大変勉強になりました
オーバーレイには１種類しかないと思っていましたので
> また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
> といっているがYUY2展開はオンオフ？
> 作成するときもYUY2展開はオンオフ？
よくわからないのですべてオンにしております
> そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ？
元のMPEG2をメディアクルーズで再生している際は、元の色（暗くない）で再生されます
やはりオーバーレイがおかしいのでしょうか？
心配なのはDivXの作成方法が正しくないから暗くなってしまったのではないかということなのです
ビデオカードの設定でオーバーレイの色合いを変えられますが、単純に非オーバーレイと同じ色にするという項目はないようですね
目視で変更する以外に方法があるのでしょうか？
質問ばかりですみませんが、よろしくお願いいたします
>>486
m2v.aui>DivX(YUY2圧縮オン)＜正解
作り方はあっている
ではなぜメディクルとWMPでオーバーレイの色合いが違うか、というと
ttp://pc.2ch.net/test/read.cgi/avi/1067427169/141-148
m2v.aui>DivX(YUY2圧縮オン)＜正解
作り方はあっている
ではなぜメディクルとWMPでオーバーレイの色合いが違うか、というと
ttp://pc.2ch.net/test/read.cgi/avi/1067427169/141-148
488 ：479：03/11/15 22:28
>>487
大変助かりました
Media Player ClasicでVMR9を選択してみたところ、メディアクルーズも、Windows Media Playerもすべて色が直りました。
どうもありがとうございました
大変助かりました
Media Player ClasicでVMR9を選択してみたところ、メディアクルーズも、Windows Media Playerもすべて色が直りました。
どうもありがとうございました
ふぬああでRGB録画すると色が薄いんだけど何ででしょうか？
それはたぶんストレート展開されてるからだね
>>487が見たい…
同じようなことで悩んでるぽいです…。
同じようなことで悩んでるぽいです…。
>>487
DAT落ち？
DAT落ち？
>>491
DirectX9からくっついてくるVMR9の仕業
VMR9経由だと本来
ファイル＞デコーダ（コーデック）がYUVへデコード＞グラボがRGBへ変換＞モニタ（ハードウェアYUVオーバーレイ）
ファイル＞デコーダ（コーデック）がRGBへデコード＞グラボ＞モニタ（いままでのビデオレンダラーやGDI）
だったものが
ファイル＞デコーダ（コーデック）がYUVへデコード＞VMR9がRGBへ変換＞モニタ
になる
プレイヤーがVMR9配下だとYUV->RGBはすべてVMR9が行う
デコーダによるRGB変換が起こらないため
デコーダ（コーデック）毎の色味の違いは起こらない
が、
VMR9の色調整をする方法が現状では、ない
また旧VMRと異なりいかなるWinでも動作する
自動ソフトウェアBob出力とか、いいとこもあるんだがな＞VMR9
DirectX9からくっついてくるVMR9の仕業
VMR9経由だと本来
ファイル＞デコーダ（コーデック）がYUVへデコード＞グラボがRGBへ変換＞モニタ（ハードウェアYUVオーバーレイ）
ファイル＞デコーダ（コーデック）がRGBへデコード＞グラボ＞モニタ（いままでのビデオレンダラーやGDI）
だったものが
ファイル＞デコーダ（コーデック）がYUVへデコード＞VMR9がRGBへ変換＞モニタ
になる
プレイヤーがVMR9配下だとYUV->RGBはすべてVMR9が行う
デコーダによるRGB変換が起こらないため
デコーダ（コーデック）毎の色味の違いは起こらない
が、
VMR9の色調整をする方法が現状では、ない
また旧VMRと異なりいかなるWinでも動作する
自動ソフトウェアBob出力とか、いいとこもあるんだがな＞VMR9
まあDX9ハードじゃなければ無理にVMR9を使う必要はないよ。
D3DがしょぼいビデオチップでVMR9再生したところで
ハードウェアOverlayに比べてパフォーマンスが（画質も？）低下するだけだから。
D3DがしょぼいビデオチップでVMR9再生したところで
ハードウェアOverlayに比べてパフォーマンスが（画質も？）低下するだけだから。
>>496
huffyuのバグじゃなくてmsyuv.dllの仕様。
それとDX9を入れてても旧オーバーレイは使えるからレンダラは好きなのにすればいい。
つまりDX9にする必要は無いということではなくて、レンダラをVMR9にする必要は無いと言うこと。
huffyuのバグじゃなくてmsyuv.dllの仕様。
それとDX9を入れてても旧オーバーレイは使えるからレンダラは好きなのにすればいい。
つまりDX9にする必要は無いということではなくて、レンダラをVMR9にする必要は無いと言うこと。
結構常駐者はチェックしてるのね、このスレ
やっぱ質問者がいないとネタがないだけか
やっぱ質問者がいないとネタがないだけか
このスレで勉強させてもらって Y をAVIUTLの波形プラグインで調整する方法は分かったのですが
Cb Crは基準線が無いため合わせ方が分かりません
みなさん、どんな風に調整してますか？
Cb Crは基準線が無いため合わせ方が分かりません
みなさん、どんな風に調整してますか？
>>499
ベクトル表示にて
ベクトル表示にて
501 ：名無しさん＠編集中：03/12/02 17:14
まず、信頼できるSMPTEカラーバーが手に入りにくい。
これが色で苦労する最大の原因だと思う。
これが色で苦労する最大の原因だと思う。
全然最大じゃないと思う。
>>501
もれは夜中にCSで流れてたの使ってるが、これ自体絶対色調がおかしいと思う
もれは夜中にCSで流れてたの使ってるが、これ自体絶対色調がおかしいと思う
>>503
論外
論外
俺は自分で作ったよ
でも表示装置のキャリブレートぐらいにしか使わないし
なくても普通は大丈夫だと思うけど
でも表示装置のキャリブレートぐらいにしか使わないし
なくても普通は大丈夫だと思うけど
色を合わせるのが難しいね。
・まず表示装置を、自分でカラーバー作成して目視して合わせる。
・その後、キャプチャを通して放送電波のカラーバーをキャプチャ。
これを作成したカラーバーに合わせるように調整。
ちゃんとした測定機械が無いから、波形表示プラグインとかColorYUY2とか使い、
最後は目視で微調整。結局全然いい加減なものになってしまう。
まあ最終的には「（調整を）やった」という自己満足だけか。
・その後、各番組をキャプチャしても、番組ごとにレベルが違ってて
結局またまた色補正することになっちゃうし。
・まず表示装置を、自分でカラーバー作成して目視して合わせる。
・その後、キャプチャを通して放送電波のカラーバーをキャプチャ。
これを作成したカラーバーに合わせるように調整。
ちゃんとした測定機械が無いから、波形表示プラグインとかColorYUY2とか使い、
最後は目視で微調整。結局全然いい加減なものになってしまう。
まあ最終的には「（調整を）やった」という自己満足だけか。
・その後、各番組をキャプチャしても、番組ごとにレベルが違ってて
結局またまた色補正することになっちゃうし。
ペイントツールでカラーバーをbitmapで作成（これは自分で作らなくてもWeb探せば簡単に見つかる）
↓
AVIにする
↓
MPEG2にする
↓
DVDに焼く
↓
キャプ（以下略
このDVD、一枚千円ぐらいでヤフオクに出したら売れるかな
↓
AVIにする
↓
MPEG2にする
↓
DVDに焼く
↓
キャプ（以下略
このDVD、一枚千円ぐらいでヤフオクに出したら売れるかな
VideoGateでがんばる。、
SAAチップは緑を下げた方がいいのかな？
下げたら下げたで赤っぽくなるのが悩みなのだが
下げたら下げたで赤っぽくなるのが悩みなのだが
赤くならない程度に下げるとｸﾞｯ
ほんと糞の役にも立たないレスだな
緑を下げるって何をする気だ？
>>514
小川を後列に回すということだ
小川を後列に回すということだ
なるほど
518 ：名無しさん＠編集中：03/12/10 09:03
彩度を上げたいんだけど、avisynthのColorYUY2だとどう記述すればいいのかよくわからない
Y、U、V どれをどういじれば彩度が上がるのか教えて下さい
Y、U、V どれをどういじれば彩度が上がるのか教えて下さい
Yは輝度、UとVは色差
cont_uとcont_vを同じ数値ずつプラスすれば彩度が上がる
cont_uとcont_vを同じ数値ずつプラスすれば彩度が上がる
ありがとう
上手くいきました
彩度を上げると見栄えが良くなるね
そのぶん縮まなくなるけど
上手くいきました
彩度を上げると見栄えが良くなるね
そのぶん縮まなくなるけど
522 ：名無しさん＠編集中：03/12/11 12:07
わらひもある日突然WMP９の主にDivXあたりが妙な色合いになって
>>479と一緒です。ｵｰﾊﾞｰﾚｲ全オフでましになったけど
Media Player ClassicでVMR9オフで更にましに。
ただなんつうか好きな色味がWMCだけになってもうた。まあﾃﾚﾋﾞｱｳﾄもするからいいっすけど
>>479と一緒です。ｵｰﾊﾞｰﾚｲ全オフでましになったけど
Media Player ClassicでVMR9オフで更にましに。
ただなんつうか好きな色味がWMCだけになってもうた。まあﾃﾚﾋﾞｱｳﾄもするからいいっすけど
523 ：名無しさん＠編集中：03/12/12 01:10
なんつうかそれはちょっと違うような オーバーレイしなきゃそもそもテレビに出ないんじゃ・・・
ﾌﾟﾚｲﾔいじるんじゃなしに画面のオーバーレイをいぢれ
明るさいぢるだけで希望の近づける事は出来るから
要はAviUtlで見れる色味じゃないのは何故？と思ってるわけでしょう。
そこで見れる色味はｵｰﾊﾞｰﾚｲ無視されてるはずだから
ﾌﾟﾚｲﾔいじるんじゃなしに画面のオーバーレイをいぢれ
明るさいぢるだけで希望の近づける事は出来るから
要はAviUtlで見れる色味じゃないのは何故？と思ってるわけでしょう。
そこで見れる色味はｵｰﾊﾞｰﾚｲ無視されてるはずだから
もちろんオーバーレイ表示にしてみる方法も知ってるよな？ 479
知らないみたいだから
知らないみたいだから
Aviutl上でGDIとオーバーレイの色味が同じになるように調整しても
VMR9再生だと色が変わるが・・・
VMR9再生だと色が変わるが・・・
>>523
VMR9でオーバーレイの調整って出来るの？
VMR9でオーバーレイの調整って出来るの？
VMR9は、GDI表示とも、オーバーレイ表示とも違うと思うが？
これは、Videoチップの3D表示機能を使って表示させることだよ。
これは、Videoチップの3D表示機能を使って表示させることだよ。
無知でスマソ。どうも有り難う。
まあ今のところオーバーレイ表示の方が、画質(10bitだし)も良いし、帯域も使わないし良いよね。
でも今後のビデオチップ如何によってはVMR表示の方が良くなるかも。
でも今後のビデオチップ如何によってはVMR表示の方が良くなるかも。
ソフト何もインストしてないのに色が濃い
と思ったらディスプレイのコントラスト設定を大幅に下げてただけだった
と思ったらディスプレイのコントラスト設定を大幅に下げてただけだった
以前XviDは伸張・圧縮を行うと書いているレスを見たが、伸張・圧縮は行わないよ。
バイナリによって違うのか？
当方 Koepi's Stable を使用している。
MS-MPEGやDivX4.12も同様。
バイナリによって違うのか？
当方 Koepi's Stable を使用している。
MS-MPEGやDivX4.12も同様。
突然わけの分からんことを言い出す奴が現れたな
詳細を確認するのも面倒だからほっとくか
詳細を確認するのも面倒だからほっとくか
してるよ
YUY入力してしてないとかいってんじゃないの？
YUY入力してしてないとかいってんじゃないの？
>>533
RGBで見ることもないってのが判らなかったんだろう？
確かに表示はRGBだけど、表示の仕方がYUVオーバーレイだから、XviDはYV12データを渡すだけ。
あとはビデオカードの仕様によるってだけ。
XviDの変換方法とは無関係だということを言いたかった。
RGBで見ることもないってのが判らなかったんだろう？
確かに表示はRGBだけど、表示の仕方がYUVオーバーレイだから、XviDはYV12データを渡すだけ。
あとはビデオカードの仕様によるってだけ。
XviDの変換方法とは無関係だということを言いたかった。
してるとか、してないとか言ったって環境を書かないと分からない。
参考にもならない。
参考にもならない。
CODECが圧縮・伸張しているかどうか？だろ？
それは
そのCODECにRGBを渡したときに圧縮するか？
そのCODECにRGB展開させたときに伸張するか？
って意味だよな
YUVで入力させたときや再生・表示させたときにどうなるか、は
CODECの圧縮・伸張とは無関係（というか環境、手段に依存）
MPEG4系CODEC(クローン含む)はみんな圧縮・伸張型だよ
というより圧縮・伸張型じゃないのって
MotionJPEGの一部とCanopusDV以外あるのか？
HuffyuvSは独自型だし
それは
そのCODECにRGBを渡したときに圧縮するか？
そのCODECにRGB展開させたときに伸張するか？
って意味だよな
YUVで入力させたときや再生・表示させたときにどうなるか、は
CODECの圧縮・伸張とは無関係（というか環境、手段に依存）
MPEG4系CODEC(クローン含む)はみんな圧縮・伸張型だよ
というより圧縮・伸張型じゃないのって
MotionJPEGの一部とCanopusDV以外あるのか？
HuffyuvSは独自型だし
DVは圧縮するだろ
まさか・・・
伸張の対義語で使う”圧縮”と
可逆圧縮などで使う”圧縮”の
区別がついてないわけじゃないよな？
伸張の対義語で使う”圧縮”と
可逆圧縮などで使う”圧縮”の
区別がついてないわけじゃないよな？
>>543
もしそんな勘違いしてたら、MotionJPEGも全部が圧縮って書いていそうなもんだが。
もしそんな勘違いしてたら、MotionJPEGも全部が圧縮って書いていそうなもんだが。
>>542
YUVっつったって4:1:1だろ?
YUVっつったって4:1:1だろ?
DVって1/5圧縮ではないのですか？
コーデックの伸縮の可否をどうのようにして検証しているんだ？
ファイルのスケールが違っても、表示上は見分けがつかないと思うんだけど？
ファイルのスケールが違っても、表示上は見分けがつかないと思うんだけど？
みんな英語読んでるんだよ
まじれすすると、ソースコード読んだりメモリ上に展開されたデータ読んだり圧縮されたデータ読んだり
>>550
マジレスではないな。
マジレスではないな。
「コーデックが伸縮しない場合」
ソース(MPEG2)を準備する。
(ａ)
AVIUTLでYUY2圧縮オンにしてAVI出力する。－１
それをAVIUTLでYUY2展開オンで読み込む。＋１ ∴±０ -> 表示：１
(ｂ)
AVIUTLでYUY2圧縮オフにしてAVI出力する。０
それをAVIUTLでYUY2展開オフで読み込む。０ ∴±０ -> 表示：０
「コーデックが伸縮する場合」
ソース(MPEG2)を準備する。
(ａ)
AVIUTLでYUY2圧縮オンにしてAVI出力する。－１
それをAVIUTLでYUY2展開オンで読み込む。＋１ ∴±０ -> 表示：１
(ｂ)
AVIUTLでYUY2圧縮オフにしてAVI出力する。－１
それをAVIUTLでYUY2展開オフで読み込む。＋１ ∴±０ -> 表示：１
※(ａ)と(ｂ)が一致しているのでコーデックは伸縮する。
こういう理解をしているんだが？
ソース(MPEG2)を準備する。
(ａ)
AVIUTLでYUY2圧縮オンにしてAVI出力する。－１
それをAVIUTLでYUY2展開オンで読み込む。＋１ ∴±０ -> 表示：１
(ｂ)
AVIUTLでYUY2圧縮オフにしてAVI出力する。０
それをAVIUTLでYUY2展開オフで読み込む。０ ∴±０ -> 表示：０
「コーデックが伸縮する場合」
ソース(MPEG2)を準備する。
(ａ)
AVIUTLでYUY2圧縮オンにしてAVI出力する。－１
それをAVIUTLでYUY2展開オンで読み込む。＋１ ∴±０ -> 表示：１
(ｂ)
AVIUTLでYUY2圧縮オフにしてAVI出力する。－１
それをAVIUTLでYUY2展開オフで読み込む。＋１ ∴±０ -> 表示：１
※(ａ)と(ｂ)が一致しているのでコーデックは伸縮する。
こういう理解をしているんだが？
ぺぐ2をソースにしてる時点で問題外
553は映像を見てコーデックの区別が付くようだ。（ｗ
どうでもいい話が展開してるな
相手をするのも面倒だしほっとくか
相手をするのも面倒だしほっとくか
>>556
それならいちいち書き込むな。
それならいちいち書き込むな。
>>552
正解
正解
2. 汎用性・拡張性に優れた動画編集エンジン “VME(Video Mastering Engine)” 新規搭載
TMPGEnc 3.0 XPress の動画制御エンジンとして新たにVMEを開発し、搭載しました。
VMEは動画の入力から加工、出力までを総合的に扱う専用エンジンとして動画を扱う上で優れたパフォーマンスを発揮します。 RGB色空間に加えYUV色空間にも対応し、さらなる高速化を実現しました。
(※一部フィルターはYUV色空間に対応しておりませんので、RGB色空間での処理となります)
ついにきたか
TMPGEnc 3.0 XPress の動画制御エンジンとして新たにVMEを開発し、搭載しました。
VMEは動画の入力から加工、出力までを総合的に扱う専用エンジンとして動画を扱う上で優れたパフォーマンスを発揮します。 RGB色空間に加えYUV色空間にも対応し、さらなる高速化を実現しました。
(※一部フィルターはYUV色空間に対応しておりませんので、RGB色空間での処理となります)
ついにきたか
それでもCCEのがいいと思うﾔｼ↓
ｴﾝｺｰﾀﾞは使ってみないことにはなんとも・・・
563 ：名無しさん＠編集中：03/12/27 01:12
>>540
独自ってなんだよ
独自ってなんだよ
独自じゃなくて ストレート（伸張、圧縮しない）だと思うが。
勿論Conv.YUVを使えば圧縮しない。
というかそのためのオプション。
というかそのためのオプション。
567 ：名無しさん＠編集中：03/12/27 21:07
YUV使ってる分にはSも無印も同じということでよいか
>>567
そ。
そ。
なるほど！
で、色は再生時にいじるのがベストなんですか？
俺はいつもYC伸張してるよ。TV出力できる環境のほうが少ないしな。
手軽にPCで見れるってことがいい。
手軽にPCで見れるってことがいい。
573 ：名無しさん＠編集中：03/12/30 11:49
未だにTV出力云々でYC伸張するのしないの言ってる人がいるのか。
>>572
DTV板住人とは思えんな
DTV板住人とは思えんな
575 ：名無しさん＠編集中：03/12/30 13:54
1、画像の調整の明るさ、コントラストを調整
2、Huffyuvでカラーバーをキャプ
3、aviutlでコーデックの設定でHuffyuv v2.1.1のYUY2で展開する、YUY2圧縮する、圧縮の設定を保持するにチェック
波形表示の補助線をCCIR601用にするにチェック入れて確認
1、2、3の繰り返しでチャンネル毎に調整したのを基本に、エンコ時にYC拡張してた
今まで間違てたか？
2、Huffyuvでカラーバーをキャプ
3、aviutlでコーデックの設定でHuffyuv v2.1.1のYUY2で展開する、YUY2圧縮する、圧縮の設定を保持するにチェック
波形表示の補助線をCCIR601用にするにチェック入れて確認
1、2、3の繰り返しでチャンネル毎に調整したのを基本に、エンコ時にYC拡張してた
今まで間違てたか？
ビデオカードが勝手に伸張してしまうのですがどうすればいいですか？
>>572はウンコスレ住人
579 ：名無しさん＠編集中：03/12/30 14:59
581 ：名無しさん＠編集中：03/12/30 17:09
YUY2展開圧縮しといて、なんでYC拡張するのやら
坊やだからさ
坊やでもマナー違反は如何なものか。
585 ：名無しさん＠編集中：03/12/31 00:27
VFAPIConvでaviにした場合って、YUY2のデータでも強制的に
RGBに変換されるってどこかで見た気がするんだけど、ホント？
RGBに変換されるってどこかで見た気がするんだけど、ホント？
>>585
本当もなにもVFAPI(Conv .d2v .aup .tbr)って全部RGBだよ
本当もなにもVFAPI(Conv .d2v .aup .tbr)って全部RGBだよ
>>585
ttp://jumper-x.hp.infoseek.co.jp/begin/column/1/
プログラム読めるなら↓見てもわかる
ttp://www.yks.ne.jp/~hori/data/VFAPI.zip
ttp://jumper-x.hp.infoseek.co.jp/begin/column/1/
プログラム読めるなら↓見てもわかる
ttp://www.yks.ne.jp/~hori/data/VFAPI.zip
しかしこのスレは同じ話題が何度もループするよね。
そういうスレだからな
新しいことなんてほとんどない
分からなくなった人や誘導された人が聞きに来るだけ
新しいことなんてほとんどない
分からなくなった人や誘導された人が聞きに来るだけ
ｲﾝﾀﾚｽﾚ、ｱｽﾍﾟｸﾄｽﾚもそうだからな。
勇者がＨＰにまとめてくれれば三つともいらないんだよね。
勇者がＨＰにまとめてくれれば三つともいらないんだよね。
でも似非勇者がまとめたHPは結構あるよな。内容はアレだが・・・。
YUY2 と YUV422 の違いについて教えてください。
どっちも16bitで同じような気がするのですが…。
どっちも16bitで同じような気がするのですが…。
595 ：名無しさん＠編集中：04/01/01 02:48
うんちくはどーでもいいから君望を正しい色に補正してみろ
できねーから
できねーから
596 ：名無しさん＠編集中：04/01/01 05:14
その>>594のヒロアキって奴は、なにか勘違いしてるな。
京大のくせに頭悪い！
京大のくせに頭悪い！
年明けそうそう”正しい色”厨か
”正しい色”再現は不可能ってことでとっくに決着ついてるのに
”正しい色”再現は不可能ってことでとっくに決着ついてるのに
598 ：名無しさん＠編集中：04/01/01 13:10
お、やっとヒロアキが登場したな。
あんたの書いてる式、間違ってるよ。
叶社員よりバカだね
あんたの書いてる式、間違ってるよ。
叶社員よりバカだね
このサイト、2002.2で更新とまってる廃墟だし
本人がこんなとこ書くとは思えないがな
突っ込みだったらメールやれば？
メアドも死んでるような気もするが
本人がこんなとこ書くとは思えないがな
突っ込みだったらメールやれば？
メアドも死んでるような気もするが
602 ：名無しさん＠編集中：04/01/02 00:52
Last Modified 2001/07/17
って書いてある。廃墟。
リンクをたどっていくと、現在は京大の助手をやってるみたいだな
専門は
マルチメディア統合
時系列パターン認識
マン・マシン・インタラクション
>>600は論戦を挑んで来いよ
って書いてある。廃墟。
リンクをたどっていくと、現在は京大の助手をやってるみたいだな
専門は
マルチメディア統合
時系列パターン認識
マン・マシン・インタラクション
>>600は論戦を挑んで来いよ
助手になれるってことは成績も上位だな。
一流大の一流と戦争。
一流大の一流と戦争。
勝ったらなにくれる？
ﾌｰﾝ
糞～
インテリって煽りに弱いなぁ（藁
ちょっと小馬鹿にされるとすぐヒステリーだよ>ヒロアキ
ちょっと小馬鹿にされるとすぐヒステリーだよ>ヒロアキ
また低レベルに荒れとるな
でもさ、一週間位してHPが修正されてたら結構笑えるよね。
どうだろ？
一応ここのURL貼ってメール送ってみたけどな
一応ここのURL貼ってメール送ってみたけどな
612 ：名無しさん＠編集中：04/01/03 00:42
613 ：名無しさん＠編集中：04/01/03 01:05
だいじょうび。漏れは既に保存したから。
オレも保存したけどねw
615 ：名無しさん＠編集中：04/01/03 13:24
Mpeg4系のコーデックは大体が伸張、縮小するのは分かったのですが
Mpeg2系のコーデックはどうなるんですか？
DVDにオーサリングするときの基準になるようにAVIUTLで調整するには
ITU601に合わせるのか、０、２５５ラインに合わせるのか分かりません
Mpeg2系のコーデックはどうなるんですか？
DVDにオーサリングするときの基準になるようにAVIUTLで調整するには
ITU601に合わせるのか、０、２５５ラインに合わせるのか分かりません
＞Mpeg2系のコーデックはどうなるんですか？
TMPGEnc内蔵デコーダーは伸張。
DVD2AVIやMPEG2 VIDEO VFAPI Plug-inならデコードオプションで好きな方にすればいい。
TMPGEnc内蔵デコーダーは伸張。
DVD2AVIやMPEG2 VIDEO VFAPI Plug-inならデコードオプションで好きな方にすればいい。
>DVDにオーサリングするときの基準になるように
こんなこと言ってる時点で全く理解してないな
こんなこと言ってる時点で全く理解してないな
>>617
ありがとうございます
VFAIPの挙動が分かったのでMpeg2エンコソフトを使うたびに地道に調査したいと思います
>>618
DVDにオーサリングする段階で元のファイルを16-235近辺に納める事が基準になると思うのだが
ありがとうございます
VFAIPの挙動が分かったのでMpeg2エンコソフトを使うたびに地道に調査したいと思います
>>618
DVDにオーサリングする段階で元のファイルを16-235近辺に納める事が基準になると思うのだが
>>619
少なくともCCE系やTMPGEnc3.0ならRGB入力する必要はないんだが
というか伸張も縮小も意識しない
それと
DVDにオーサリングもなにも関係ないんだよ
どんな場合でもYUV16-235近辺に収めないでどうする？
少なくともCCE系やTMPGEnc3.0ならRGB入力する必要はないんだが
というか伸張も縮小も意識しない
それと
DVDにオーサリングもなにも関係ないんだよ
どんな場合でもYUV16-235近辺に収めないでどうする？
>>620
だからこそ16-235に納める方法を知っておく必要がある
AVIUTLと波形表示フィルターをはじめて使った頃は
誰もが波形表示フィルターの16-235ラインに納めるんだと勘違いしていたはずだ
そして、DIVX化
もちろんできたファイルは16-235を更に縮小した動画になるから糞ファイル
AVIUTLやDivXが強制的に伸張、圧縮することを知ってないと間違った動画を作る
Mpeg2でもコーデックや使用するソフトの特徴をつかまないと同じ間違えする
だからこそ16-235に納める方法を知っておく必要がある
AVIUTLと波形表示フィルターをはじめて使った頃は
誰もが波形表示フィルターの16-235ラインに納めるんだと勘違いしていたはずだ
そして、DIVX化
もちろんできたファイルは16-235を更に縮小した動画になるから糞ファイル
AVIUTLやDivXが強制的に伸張、圧縮することを知ってないと間違った動画を作る
Mpeg2でもコーデックや使用するソフトの特徴をつかまないと同じ間違えする
Σ(*゜ェ゜*)ﾊｯ 今までDVD2AVIでRGBで出して
VfapiConvでAviUtl→VirtualDubでDivX作ってたけど大間違いか？だめなのか？？ｗ
別にどっちにしても大して変わんないし・・・（DVDｿｰｽの実写多し）
TV出力はやったりやらなかったり
VfapiConvでAviUtl→VirtualDubでDivX作ってたけど大間違いか？だめなのか？？ｗ
別にどっちにしても大して変わんないし・・・（DVDｿｰｽの実写多し）
TV出力はやったりやらなかったり
それだけではダメかどうかは一概には言えないが、アホくさとは思うね
しかたねーColorSpaceをちゃんとYUV4.2.2選ぶわ
AviUtl→VirtualDub ｱﾎくさいのは多分ここだろうがｗ Bふれ使う時仕方ねーのだ
AviUtl→VirtualDub ｱﾎくさいのは多分ここだろうがｗ Bふれ使う時仕方ねーのだ
>>622
VfapiConv使わなくてもDVD2AVIのプロジェクト食うよ > AVIUtl
VfapiConv使わなくてもDVD2AVIのプロジェクト食うよ > AVIUtl
mpeg2やvobもまるもでいけるし＞aviutl
VFAPIとは
VFAPIConv.は勿論.d2v.aup.tbrやm2v.vfpなどを含む
堀氏作成のﾌﾚｰﾑｾｰﾊﾞｰ・ﾛｰﾀﾞｰﾌﾟﾗｸﾞｲﾝであり
全て入出力はRGB24で行う
つまり
VFAPIConv.使おーが
.d2v経由にしようが
ColorSpaceを何にしようが
m2v.vfpにしようが
ぜーんぶRGB
m2v.auiを使いましょう
VFAPIConv.は勿論.d2v.aup.tbrやm2v.vfpなどを含む
堀氏作成のﾌﾚｰﾑｾｰﾊﾞｰ・ﾛｰﾀﾞｰﾌﾟﾗｸﾞｲﾝであり
全て入出力はRGB24で行う
つまり
VFAPIConv.使おーが
.d2v経由にしようが
ColorSpaceを何にしようが
m2v.vfpにしようが
ぜーんぶRGB
m2v.auiを使いましょう
うむ
DVD2AVI側でColorSpaceを何にしようが、それはd2vを開くソフトが決めることなんで
d2vファイルを他のソフトで開くときはそこの設定には意味がない
DVD2AVI側でColorSpaceを何にしようが、それはd2vを開くソフトが決めることなんで
d2vファイルを他のソフトで開くときはそこの設定には意味がない
まるも使えばYUVで出てくれるというわけですか？そしたらAviUtlだけで出してみよう
短編多いからBふれ使わないでもいいし
一応まるもでvob、mpeg2読めるようになってる
どうせ音声分けなきゃ駄目かもしれんけど。
短編多いからBふれ使わないでもいいし
一応まるもでvob、mpeg2読めるようになってる
どうせ音声分けなきゃ駄目かもしれんけど。
嫁
うむm2vconf.exe熟読した
(´∀｀) 元のYUVデータを維持するんですね、そうですね こーやって使うﾂｰﾙだったんか。。
どうせ音声のためDVD2AVIしそうだけどやってみるでし
(´∀｀) 元のYUVデータを維持するんですね、そうですね こーやって使うﾂｰﾙだったんか。。
どうせ音声のためDVD2AVIしそうだけどやってみるでし
632 ：名無しさん＠編集中：04/01/07 04:00
音声分けツールなど他にも沢山あるべな まあYUV反映させたければまるも使うこと（設定もな
”元のYUVデータを維持する”と
出力がRGBかYUVかは無関係
出力がRGBかYUVかは無関係
ところでaviutlのフィルタはRGBでしか使えないので、結局RGBに変換されてしまうのでは？
YUVのまま処理したければAvisynth使う
こんなの基本だろ
こんなの基本だろ
このすれみてm2v.vfpからm2v.auiに変えたらエンコ時間が早くなりました。どうも
639 ：名無しさん＠編集中：04/01/08 20:47
(´･ω･｀)ｼｮﾎﾞｰﾝ m2v.auiってなんですか・・・？？
ｿﾌﾄでもなし・・・
そんな拡張子を出すｿﾌﾄも・・・うううｸﾞｸﾞりまくっても、わかりまへんでー！
もしかしてｷｬﾌﾟﾁｬしなきゃ分からない？ｗ
YUVでｴﾝｺするならまあまるもでやれるからいーんですが
ｿﾌﾄでもなし・・・
そんな拡張子を出すｿﾌﾄも・・・うううｸﾞｸﾞりまくっても、わかりまへんでー！
もしかしてｷｬﾌﾟﾁｬしなきゃ分からない？ｗ
YUVでｴﾝｺするならまあまるもでやれるからいーんですが
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=m2v%2Eaui
|･ω･｀) ｺｿｺｿ だって検索結果これだけなんでしｗ
|･ω･｀) ｺｿｺｿ だって検索結果これだけなんでしｗ
642 ：名無しさん＠編集中：04/01/09 09:10
|ﾟ∀ﾟ)
でｷﾀ━━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━━━!!!!
ｴﾝｺも速くなる・・・かも
|∀ﾟ)っω お礼に置いてくね
|≡ ｻｯ ω
でｷﾀ━━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━━━!!!!
ｴﾝｺも速くなる・・・かも
|∀ﾟ)っω お礼に置いてくね
|≡ ｻｯ ω
>>644
YUY2ﾓｰﾄﾞだろうがなんだろうが
Aviutlは内部YUVなんだっつーの
・Aviutlの標準モードの内部色空間はYUV48である
・入出力がCODEC展開の場合（YUY2展開・圧縮ｵﾌ）RGB入出力となる
・入出力がVFAPI経由の場合（VFAPIﾌﾟﾗｸﾞｲﾝ含む）RGB入出力となる
・入出力がRGBの場合、RGB24<>YUV48展開をAviutlが行う。RGB<>YUV誤差有
勿論、ﾃﾞｰﾀ精度は丸め込みにより落ちる
・古いﾌｨﾙﾀや一部の内蔵ﾌｨﾙﾀ（拡張色調補正？未確認）の場合RGB24で処理される
・入出力がAviutl展開の場合（YUY2展開･圧縮ｵﾝ）YUY2入出力となる
・入力が.auiの場合（avsinp.auiやm2v.aui）YUY2入出力となる
・入出力がYUY2の場合、YUY2<>YUV48ﾏｯﾋﾟﾝｸﾞをAviutlが行う。色変換誤差は起きない
ただしYUV48>YUY2のﾏｯﾋﾟﾝｸﾞの際、ﾃﾞｰﾀ精度が丸め込みにより落ちる
・古いﾌｨﾙﾀや一部の内蔵ﾌｨﾙﾀ（拡張色調補正？未確認）の場合RGB24で処理される
・AviutlのYUY2ﾓｰﾄﾞの内部色空間はYUY2である
・入出力関係は標準ﾓｰﾄﾞに従う
・YUY2ﾓｰﾄﾞ時、現状では内蔵ﾌｨﾙﾀしか動作は保障されない
あとは過去ﾛｸﾞ読め
YUY2ﾓｰﾄﾞだろうがなんだろうが
Aviutlは内部YUVなんだっつーの
・Aviutlの標準モードの内部色空間はYUV48である
・入出力がCODEC展開の場合（YUY2展開・圧縮ｵﾌ）RGB入出力となる
・入出力がVFAPI経由の場合（VFAPIﾌﾟﾗｸﾞｲﾝ含む）RGB入出力となる
・入出力がRGBの場合、RGB24<>YUV48展開をAviutlが行う。RGB<>YUV誤差有
勿論、ﾃﾞｰﾀ精度は丸め込みにより落ちる
・古いﾌｨﾙﾀや一部の内蔵ﾌｨﾙﾀ（拡張色調補正？未確認）の場合RGB24で処理される
・入出力がAviutl展開の場合（YUY2展開･圧縮ｵﾝ）YUY2入出力となる
・入力が.auiの場合（avsinp.auiやm2v.aui）YUY2入出力となる
・入出力がYUY2の場合、YUY2<>YUV48ﾏｯﾋﾟﾝｸﾞをAviutlが行う。色変換誤差は起きない
ただしYUV48>YUY2のﾏｯﾋﾟﾝｸﾞの際、ﾃﾞｰﾀ精度が丸め込みにより落ちる
・古いﾌｨﾙﾀや一部の内蔵ﾌｨﾙﾀ（拡張色調補正？未確認）の場合RGB24で処理される
・AviutlのYUY2ﾓｰﾄﾞの内部色空間はYUY2である
・入出力関係は標準ﾓｰﾄﾞに従う
・YUY2ﾓｰﾄﾞ時、現状では内蔵ﾌｨﾙﾀしか動作は保障されない
あとは過去ﾛｸﾞ読め
646 ：名無しさん＠編集中：04/01/12 22:13
哀王のLinkPlayerとかで見る用のaviは16-235で作った方がいいんすか？
Y16-235ね
隔離スレ浮上age
650 ：名無しさん＠編集中：04/01/14 17:45
sageてたw
651 ：名無しさん＠編集中：04/01/14 22:28
なんかAvisynthスレが荒れてんな。
あれは荒れてるとは言わない
653 ：名無しさん＠編集中：04/01/14 23:10
すいません
荒らしてましたw
何度もこっちでやろう、と書いたんだが
荒らしてましたw
何度もこっちでやろう、と書いたんだが
654 ：名無しさん＠編集中：04/01/18 01:33
BCTV9スレでお前さん方の出番ですよ。
http://pc.2ch.net/test/read.cgi/avi/1074046153/247-
http://pc.2ch.net/test/read.cgi/avi/1074046153/247-
出張サービスは行っておりません。
ここは釣り氏が釣られるバカどもを見て、笑うスレですか??(・∀・)ﾆﾔﾆﾔ
657 ：名無しさん＠編集中：04/01/18 09:30
Dubｽﾚでもやっとるな
みんなここでやれっての
あっちゃこっちゃで釣り糸垂れるなよ・・・
みんなここでやれっての
あっちゃこっちゃで釣り糸垂れるなよ・・・
AviUtlのYUY2展開にバグが発見されました。ご臨終。
YUY2で読み込んでもゴーストなんかでないのですが。DubとAviUtl0.99でエンコしたファイルをを比べたら同じだったのですが。
>>659
DivXコーデックで出るよ
DivXコーデックで出るよ
661 ：名無しさん＠編集中：04/01/26 21:26
>>660
YUY2展開は
YUY2デコードはCodecが行い
YUY2->YUV48変換をAviutlが行う
このときYC補間が入るため
モスキートノイズやリンギングなどが発生しているソースは
ゴーストが出ているように見える
これをそのままYUY2圧縮しても
ゴーストのようなものは出ない
なぜならYUV48->YUY2はleft originだからだ
YUV48による擬似ゴーストは
ソースの動画再生時にはみえにくいノイズが表示されてるにすぎない
無論、これをフィルタリングで消せば
より綺麗な動画が作れる
素晴らしい仕様ですな
YUY2展開は
YUY2デコードはCodecが行い
YUY2->YUV48変換をAviutlが行う
このときYC補間が入るため
モスキートノイズやリンギングなどが発生しているソースは
ゴーストが出ているように見える
これをそのままYUY2圧縮しても
ゴーストのようなものは出ない
なぜならYUV48->YUY2はleft originだからだ
YUV48による擬似ゴーストは
ソースの動画再生時にはみえにくいノイズが表示されてるにすぎない
無論、これをフィルタリングで消せば
より綺麗な動画が作れる
素晴らしい仕様ですな
前半は分かるけど、後半の意味が分からない
なんでより綺麗な動画になるんだ？
なんでより綺麗な動画になるんだ？
663 ：名無しさん＠編集中：04/01/26 22:53
>>662
ﾓｽｷｰﾄﾉｲｽﾞやﾘﾝｷﾞﾝｸﾞが消えるからでは？
ﾓｽｷｰﾄﾉｲｽﾞやﾘﾝｷﾞﾝｸﾞが消えるからでは？
見えにくいノイズが見えやすくなることで補正しやすくなり、
きっちり補正すれば綺麗になる と言いたいのでは?
きっちり補正すれば綺麗になる と言いたいのでは?
665 ：名無しさん＠編集中：04/01/27 00:30
YUY2->YUV48変換でゴーストが出るって言うのはなに？
新手のプラシーボ？
新手のプラシーボ？
667 ：名無しさん＠編集中：04/01/27 05:12
つまり、バグではないのですね。
そうみたい
で、ノイズが見えるというより補完からはみ出た要素がゴーストになって現れるとかではないと？
で、ノイズが見えるというより補完からはみ出た要素がゴーストになって現れるとかではないと？
今までどうやらそうらしいとは言われてきてましたが。
NVIDIAの関係者が、NVIDIAのグラフィックチップの色空間変換はYUVとRGBを１：１でマッピングする、
つまりYUV(0-255)->RGB(0,0,0-255,255,255)であることを認めてますな。
http://www.avsforum.com/avs-vb/showthread.php?postid=3273410#post3273410
NVIDIAの関係者が、NVIDIAのグラフィックチップの色空間変換はYUVとRGBを１：１でマッピングする、
つまりYUV(0-255)->RGB(0,0,0-255,255,255)であることを認めてますな。
http://www.avsforum.com/avs-vb/showthread.php?postid=3273410#post3273410
671 ：名無しさん＠編集中：04/01/27 20:06
>>668
そもそもYUY2をそのままRGBにすると
UVﾃﾞｰﾀは2ﾋﾟｸｾﾙ毎同じﾃﾞｰﾀになる
これをそのまま表示するとｼﾞｬｷﾞｰが発生するため
これを緩和するための処理がYC補間
ほとんどのｱﾌﾟﾘｹｰｼｮﾝ・CODECに実装されている
一般にYUY2->RGBのYC補間には二系統のｱﾙｺﾞﾘｽﾞﾑがある
ｱﾌﾟﾘｹｰｼｮﾝの内部処理に使われるのはkeep origin系が多い
これはUVデータの同一数値をもつ並んだ2ﾋﾟｸｾﾙのうち
片方は周囲との差分をとり
片方はｿｰｽﾃﾞｰﾀのままを維持する方法
ｼﾞｬｷﾞｰの緩和は甘いがｿｰｽを維持するため
中間処理に向く
Aviutlの内部変換がこれ
そのためYUY2->YUV48->YUY2とｽﾙｰさせてもﾃﾞｰﾀは変わらない
AvisynthのConvToRGB（ConvTo.dll）がこれにあたるが
作者が2chに怒ってｻｲﾄ閉じたんで入手困難
codecのRGB変換に使われるのは平均画素系が多い
anti-aliasingやbi-linearなどいろいろあるが
要は隣り合うピクセルの色を補間して平均化する
このためｿｰｽのﾃﾞｰﾀは保持されないが
ｼﾞｬｷﾞｰの緩和には極めて有効
そのため人の目にはより自然な画像になるため
画像表示に向く
HuffyuvやMPEG4ｸﾛｰﾝがこれ
勿論YUY2->RGB->YUY2という処理をすると
色がどんどん拡散することになる
Avisynth内蔵のConvertToRGBもこれの一種
そもそもYUY2をそのままRGBにすると
UVﾃﾞｰﾀは2ﾋﾟｸｾﾙ毎同じﾃﾞｰﾀになる
これをそのまま表示するとｼﾞｬｷﾞｰが発生するため
これを緩和するための処理がYC補間
ほとんどのｱﾌﾟﾘｹｰｼｮﾝ・CODECに実装されている
一般にYUY2->RGBのYC補間には二系統のｱﾙｺﾞﾘｽﾞﾑがある
ｱﾌﾟﾘｹｰｼｮﾝの内部処理に使われるのはkeep origin系が多い
これはUVデータの同一数値をもつ並んだ2ﾋﾟｸｾﾙのうち
片方は周囲との差分をとり
片方はｿｰｽﾃﾞｰﾀのままを維持する方法
ｼﾞｬｷﾞｰの緩和は甘いがｿｰｽを維持するため
中間処理に向く
Aviutlの内部変換がこれ
そのためYUY2->YUV48->YUY2とｽﾙｰさせてもﾃﾞｰﾀは変わらない
AvisynthのConvToRGB（ConvTo.dll）がこれにあたるが
作者が2chに怒ってｻｲﾄ閉じたんで入手困難
codecのRGB変換に使われるのは平均画素系が多い
anti-aliasingやbi-linearなどいろいろあるが
要は隣り合うピクセルの色を補間して平均化する
このためｿｰｽのﾃﾞｰﾀは保持されないが
ｼﾞｬｷﾞｰの緩和には極めて有効
そのため人の目にはより自然な画像になるため
画像表示に向く
HuffyuvやMPEG4ｸﾛｰﾝがこれ
勿論YUY2->RGB->YUY2という処理をすると
色がどんどん拡散することになる
Avisynth内蔵のConvertToRGBもこれの一種
色スレにはやさしい人が多いですね～
673 ：名無しさん＠編集中：04/01/27 21:17
674 ：名無しさん＠編集中：04/01/27 22:34
>>673
UV成分は色ではないし
単純に差分をとっただけならﾎﾞｹるだけ
それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意
今回のはjumperの手順に問題がある
RGB24->Huffyuvのとき
HuffyuvによるYC補間と逆の操作がおこる
単純に間引くのではなく差分をとって間引いている
ﾃﾞｰﾀ的には輪郭外周ににじみがでる
これを今度はAviutl内部で->RGB
このときはleft originで補間される
滲み成分が2ﾋﾟｸｾﾙごと1ﾋﾟｸｾﾙ外にずれて補間される
left originであるために対象物の右側に発生する
UV成分は色ではないし
単純に差分をとっただけならﾎﾞｹるだけ
それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意
今回のはjumperの手順に問題がある
RGB24->Huffyuvのとき
HuffyuvによるYC補間と逆の操作がおこる
単純に間引くのではなく差分をとって間引いている
ﾃﾞｰﾀ的には輪郭外周ににじみがでる
これを今度はAviutl内部で->RGB
このときはleft originで補間される
滲み成分が2ﾋﾟｸｾﾙごと1ﾋﾟｸｾﾙ外にずれて補間される
left originであるために対象物の右側に発生する
675 ：名無しさん＠編集中：04/01/27 23:19
>>674
何か話が見えにくいな。Huffyuvなんか俺にはどうでもｲｲ
＞それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意
色差にローパス掛けたらゴーストでるのか？
彩度を思いっきり上げない限りは大したエッジ誤差になるはずがない
色ゴーストなんてよほど強く出てないと気付かないと思うが・・
何か話が見えにくいな。Huffyuvなんか俺にはどうでもｲｲ
＞それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意
色差にローパス掛けたらゴーストでるのか？
彩度を思いっきり上げない限りは大したエッジ誤差になるはずがない
色ゴーストなんてよほど強く出てないと気付かないと思うが・・
676 ：名無しさん＠編集中：04/01/27 23:25
>>675
いやｱﾙｺﾞﾘｽﾞﾑの異なるﾛｰﾊﾟｽが二重にかかるからこうなる
なんだか説明しづらいので図式
xを求める時上下左右との平均をとる単純な補間式で考えてみる
またYUVのUVの取りえる範囲を0-9とする
以下の図において表記していない領域は
右・上は0,左・下は9とする
全ての図はある画像のU値だとする
ｿｰｽ
00
70
9700
9970
999700
999970
続く
いやｱﾙｺﾞﾘｽﾞﾑの異なるﾛｰﾊﾟｽが二重にかかるからこうなる
なんだか説明しづらいので図式
xを求める時上下左右との平均をとる単純な補間式で考えてみる
またYUVのUVの取りえる範囲を0-9とする
以下の図において表記していない領域は
右・上は0,左・下は9とする
全ての図はある画像のU値だとする
ｿｰｽ
00
70
9700
9970
999700
999970
続く
677 ：名無しさん＠編集中：04/01/27 23:26
単純に平均化（RGB24->YUY2をCODECが行った場合の処理前半）
10
5300
8530
985300
99853000
99985300
YUY2化（RGB24->YUY2をCODECが行った場合の処理後半）
1100
5500
883300
995500
99883300
99995500
left originでRGB24化（↑のYUY2をAviutlでRGB化）
1100
5401
873200
985401
99873200
99985400
二段目、四段目に01という並びが発生する
この1が擬似ｺﾞｰｽﾄ
10
5300
8530
985300
99853000
99985300
YUY2化（RGB24->YUY2をCODECが行った場合の処理後半）
1100
5500
883300
995500
99883300
99995500
left originでRGB24化（↑のYUY2をAviutlでRGB化）
1100
5401
873200
985401
99873200
99985400
二段目、四段目に01という並びが発生する
この1が擬似ｺﾞｰｽﾄ
0.98ではjumperが言うような問題は見えないんだけどな。
679 ：名無しさん＠編集中：04/01/27 23:43
というか問題点そのものが理解できない。
出力に影響がないのに何が問題なんだろ？
表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。
出力に影響がないのに何が問題なんだろ？
表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。
結局、内部処理的には問題ないんでしょ？
でもプレビューがあの調子だと、色タイミング補正とかがし難い。
でもプレビューがあの調子だと、色タイミング補正とかがし難い。
681 ：675：04/01/28 00:10
>>676
図まで書いてもらってすまんのだが
さっぱり分からん(図が)
＞ｱﾙｺﾞﾘｽﾞﾑの異なるﾛｰﾊﾟｽが二重にかかるからこうなる
っていうのはそれが事実なら当たり前だろうが
その影響がどの程度のものなのかこの例えから読み取れない
(そもそも何故縦方向に平均化するのか・・)
まぁ暇な時にでも自分で調べてみるよ
>>679
＞表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。
まじで？少なくともVFAPIで渡した時は表示通りじゃないとおかしくないか？
図まで書いてもらってすまんのだが
さっぱり分からん(図が)
＞ｱﾙｺﾞﾘｽﾞﾑの異なるﾛｰﾊﾟｽが二重にかかるからこうなる
っていうのはそれが事実なら当たり前だろうが
その影響がどの程度のものなのかこの例えから読み取れない
(そもそも何故縦方向に平均化するのか・・)
まぁ暇な時にでも自分で調べてみるよ
>>679
＞表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。
まじで？少なくともVFAPIで渡した時は表示通りじゃないとおかしくないか？
久しぶりに一般人には到底理解出来ない話題で盛り上がってるな
散々迷惑をかけて申し訳ないです。
また変な事いいだしますが聞いてください。
>>671>>674 さん
非常に参考になりました。でも
>>676>>677
の図がわかりません_|￣|○
それで、left originとkeep originの横4ピクセルの
意味を理解しようと色々やってみました。
ttp://jumper-x.hp.infoseek.co.jp/yuy21.png
これはAviUtl掲示板と同じ原理です。（ソースが違います）
これにより、0.99と0.98が別物であることはわかりました。
>>678 さん
ごめんなさい ｡゜（ﾟ´Д｀ﾟ）0.98は別ものです。
ttp://jumper-x.hp.infoseek.co.jp/yuy22.png
傍から見てもわからないと思いますが、
TMPGEncで読み込んでみました。
やっぱり、AviUtl0.99は「left origin」で、
TMPGEncは「keep origin」ですね。
また変な事いいだしますが聞いてください。
>>671>>674 さん
非常に参考になりました。でも
>>676>>677
の図がわかりません_|￣|○
それで、left originとkeep originの横4ピクセルの
意味を理解しようと色々やってみました。
ttp://jumper-x.hp.infoseek.co.jp/yuy21.png
これはAviUtl掲示板と同じ原理です。（ソースが違います）
これにより、0.99と0.98が別物であることはわかりました。
>>678 さん
ごめんなさい ｡゜（ﾟ´Д｀ﾟ）0.98は別ものです。
ttp://jumper-x.hp.infoseek.co.jp/yuy22.png
傍から見てもわからないと思いますが、
TMPGEncで読み込んでみました。
やっぱり、AviUtl0.99は「left origin」で、
TMPGEncは「keep origin」ですね。
つづき
AviUtl0.99でYUY2展開して出力したものは、
「left origin」になり、「keep origin」でアルゴリズムで展開すると
必ず激しくずれます。
逆に元が「keep origin」であると、「left origin」アルゴリズムで展開すると
これまた激しくずれます。だから、手順に問題があるということですね。
AviUtl0.99の「left origin」同士ではズレはありませんでした。
つまりバグではなく、「left origin」「keep origin」の差だけある
ということはわかりました。
ただ、Huffyuvを中間ファイルに吐く時は注意が必要では
ないでしょうか？AviUtl0.99Huffyuv出力で他の「keep origin」
フロントエンドに渡したら、このズレが残りますし、
一般のプレーヤーなどの処理は「keep origin」ではないのでしょうか？
AviUtl0.99でYUY2展開して出力したものは、
「left origin」になり、「keep origin」でアルゴリズムで展開すると
必ず激しくずれます。
逆に元が「keep origin」であると、「left origin」アルゴリズムで展開すると
これまた激しくずれます。だから、手順に問題があるということですね。
AviUtl0.99の「left origin」同士ではズレはありませんでした。
つまりバグではなく、「left origin」「keep origin」の差だけある
ということはわかりました。
ただ、Huffyuvを中間ファイルに吐く時は注意が必要では
ないでしょうか？AviUtl0.99Huffyuv出力で他の「keep origin」
フロントエンドに渡したら、このズレが残りますし、
一般のプレーヤーなどの処理は「keep origin」ではないのでしょうか？
0.99は他ツールとの連携がしにくいってことか。
686 ：名無しさん＠編集中：04/01/28 20:21
>>683
根本的にわかっていない部分があり過ぎ
展開と圧縮は違うって何度もここに書いてあるだろ？
せっかちすぎる
検証向きではないな
内部データと表示されてるものと出力データは異なるってことも理解できない？
しかもkeep originとleft originの意味もわかっていない
読んでないだろ？
keep originのうち左端ピクセルを維持するのがleft originなんだってわからない？
TMPGEncのYUY2展開ってなに？
3.0か？
流石、横のみリサイズだとインターレースが壊れないと
自サイトに書くだけのことはある
もう一回情報収集と自分の検証方法を全てにおいて見直せ
まずはこのスレを全部読み直せ
次にまるもの戯言を全部読み直せ
基本的なアプリの動作がわかってないとどうにもならない
そして他の人間にもどういう手順でなにをやったかきっちり書いてくれ
個人的にはこの件は表示バグではないかと思っているけどな
根本的にわかっていない部分があり過ぎ
展開と圧縮は違うって何度もここに書いてあるだろ？
せっかちすぎる
検証向きではないな
内部データと表示されてるものと出力データは異なるってことも理解できない？
しかもkeep originとleft originの意味もわかっていない
読んでないだろ？
keep originのうち左端ピクセルを維持するのがleft originなんだってわからない？
TMPGEncのYUY2展開ってなに？
3.0か？
流石、横のみリサイズだとインターレースが壊れないと
自サイトに書くだけのことはある
もう一回情報収集と自分の検証方法を全てにおいて見直せ
まずはこのスレを全部読み直せ
次にまるもの戯言を全部読み直せ
基本的なアプリの動作がわかってないとどうにもならない
そして他の人間にもどういう手順でなにをやったかきっちり書いてくれ
個人的にはこの件は表示バグではないかと思っているけどな
>>686 さん
展開と内部データとプレビューが一致してないことは理解してます。
PCに表示できるデータはYUVから必ずRGBに変換され、
「PCに映る」状態にフロントエンドがもってきて、プレビューとして表示してます。
「プリントスクリーン=RGB補完がある」ということは理解しています。
プレビュー表示バグであるなら、0.99を通しても0.98を通しても
YUY2（展開）→YUV48（AviUtl内部、データ量最大）→YUY2（圧縮、データ丸め込み）
であることは間違えないと思います。
ここで、AviUtlのプレビューは「YUV48（AviUtl内部）」のデータを
RGB補完しながら変換して「目視」出来るデータにしていると私は判断しています。
だから、プレビューと圧縮とは違うと言いたいのはわかります。
あてにならないプレビューをRGBでPrintScreenしているから、
そのものがあてにならないとおっしゃるのもごもっともです。
でも、RGBプレビューで示すしかないんです(つд・)
>しかもkeep originとleft originの意味もわかっていない
これについては、100%の理解には至っていません。
この板とグーグルとまるもで勉強させていただきます。
わかってから使えるように努力します。
展開と内部データとプレビューが一致してないことは理解してます。
PCに表示できるデータはYUVから必ずRGBに変換され、
「PCに映る」状態にフロントエンドがもってきて、プレビューとして表示してます。
「プリントスクリーン=RGB補完がある」ということは理解しています。
プレビュー表示バグであるなら、0.99を通しても0.98を通しても
YUY2（展開）→YUV48（AviUtl内部、データ量最大）→YUY2（圧縮、データ丸め込み）
であることは間違えないと思います。
ここで、AviUtlのプレビューは「YUV48（AviUtl内部）」のデータを
RGB補完しながら変換して「目視」出来るデータにしていると私は判断しています。
だから、プレビューと圧縮とは違うと言いたいのはわかります。
あてにならないプレビューをRGBでPrintScreenしているから、
そのものがあてにならないとおっしゃるのもごもっともです。
でも、RGBプレビューで示すしかないんです(つд・)
>しかもkeep originとleft originの意味もわかっていない
これについては、100%の理解には至っていません。
この板とグーグルとまるもで勉強させていただきます。
わかってから使えるように努力します。
つづき
>流石、横のみリサイズだとインターレースが壊れないと
>自サイトに書くだけのことはある
Σ(ﾟДﾟ；ｴｰｯ!
リサイズアルゴリズムによる色変化と関係してますか？
ピクセル座標連続性と関係してますか？
質問ばかりだと悪いのでこちらで考えます。
せっかちでごめんなさい_|￣|○
ちょっとでも理解できたと思うと、うれしくて先走ってしまいます。
少々お時間を下さい。
>>672
良スレじゃないと私は書き込みませんよ。
他のDTVスレッドは良くないインターネットですからね。
私みたいに正確性に欠けた人が板を汚すのも悪いですが。
>流石、横のみリサイズだとインターレースが壊れないと
>自サイトに書くだけのことはある
Σ(ﾟДﾟ；ｴｰｯ!
リサイズアルゴリズムによる色変化と関係してますか？
ピクセル座標連続性と関係してますか？
質問ばかりだと悪いのでこちらで考えます。
せっかちでごめんなさい_|￣|○
ちょっとでも理解できたと思うと、うれしくて先走ってしまいます。
少々お時間を下さい。
>>672
良スレじゃないと私は書き込みませんよ。
他のDTVスレッドは良くないインターネットですからね。
私みたいに正確性に欠けた人が板を汚すのも悪いですが。
＞他のDTVスレッドは良くないインターネットですからね。
てめぇ、AviUtlスレ馬鹿にしてんのか！？
てめぇ、AviUtlスレ馬鹿にしてんのか！？
>横のみリサイズだとインターレースが壊れない
拡大縮小のアルゴリズムによっては、上下のピクセルからも補間するからねぇ。
拡大縮小のアルゴリズムによっては、上下のピクセルからも補間するからねぇ。
純粋に研究を志す椰子にとってあのｽﾚはって気持ちはﾜｶﾗﾝでもないが
でも一言よけいは大人げない、黙ってればいい
でも一言よけいは大人げない、黙ってればいい
悪いけど
上に色々書かれていることは、ここに書かれた文章から理解しようとするよりも
この分野の入門書や仕様書を読んだ方がわかりやすいしそんなに難しい話ではない。
上に色々書かれていることは、ここに書かれた文章から理解しようとするよりも
この分野の入門書や仕様書を読んだ方がわかりやすいしそんなに難しい話ではない。
huffyuvで16-235キャプ
AVIは0-255に伸張してavisynth+Dubエンコ
mpeg2は16-235でエンコしてたんだが、これだとTV出力の際に具合悪い
よってmpeg2も伸張して0-255でCCEエンコすることにした
AVIを16-235エンコしてるやつってほとんど居ないだろうなぁ
いったいmpeg2エンコするときどうしてるんだろ
AVIは0-255に伸張してavisynth+Dubエンコ
mpeg2は16-235でエンコしてたんだが、これだとTV出力の際に具合悪い
よってmpeg2も伸張して0-255でCCEエンコすることにした
AVIを16-235エンコしてるやつってほとんど居ないだろうなぁ
いったいmpeg2エンコするときどうしてるんだろ
また別のあほがきた
どこで勉強したらこんな意味不明なことをしゃべるようになるのか・・・
32-215キャプかよ
>これはAviUtlのPCスケール補正での演算誤差なのか、
>CCIR601用チェックでの誤差なのか、
>ReelTimeが信用できないのか、
>huffyuvの圧縮が信用できないのか、
>huffyuv.dllのYUY2展開精度が信用できないのか、
>SAA7130のA/D精度がそういうものなのか、不明です。
明らかなのは、信用できないのは ICZ だってことだな。
>CCIR601用チェックでの誤差なのか、
>ReelTimeが信用できないのか、
>huffyuvの圧縮が信用できないのか、
>huffyuv.dllのYUY2展開精度が信用できないのか、
>SAA7130のA/D精度がそういうものなのか、不明です。
明らかなのは、信用できないのは ICZ だってことだな。
動画仲間は誰も突っ込まないのかな？
ふつうのOPEDエンコ人はインタレ解除したらとりあえずRGBで保存しちゃうからあんまり関係ない。
ICZ氏もそうだろうと思う
ICZ氏もそうだろうと思う
>>702
SAA7130+huffyuv(YUY2)をAviUtl0.98d+波形表示といった環境で
Y16-235に調整してる時点で入力時のダイナミックレンジを損してるっつうか・・・
RGBでキャプチャすんなら分かるけど
SAA7130+huffyuv(YUY2)をAviUtl0.98d+波形表示といった環境で
Y16-235に調整してる時点で入力時のダイナミックレンジを損してるっつうか・・・
RGBでキャプチャすんなら分かるけど
俺はAviUtlのほうは古いの使ってるから98dだか99の展開（展開表示）の挙動はｼﾗﾈ-ですが
あんなﾏﾒなら2重伸長のことも知ってるんじゃないかなと、ﾒﾝﾄﾞｲから更新してないぽいし
まあ想像ですが。
あんなﾏﾒなら2重伸長のことも知ってるんじゃないかなと、ﾒﾝﾄﾞｲから更新してないぽいし
まあ想像ですが。
YUY2で記録したHuffyuvはRGBで展開してもスケールを伸張するんだから
AviUtlが古かろうと新しかろうと関係ないし、
ICZのやってることは２重伸張どころかその逆の行為なんだから
704の想像も明後日を向いてるな。
AviUtlが古かろうと新しかろうと関係ないし、
ICZのやってることは２重伸張どころかその逆の行為なんだから
704の想像も明後日を向いてるな。
ふつうhuffyuv(YUY2)なんか使わないから分からんつーの
まあ俺はCCIR601やスケールにうるさい連中が
YUY2をhuffyuv(YUY2)でキャプチャしろなんてアホなこと言い出したんだと思ってるが
まあ俺はCCIR601やスケールにうるさい連中が
YUY2をhuffyuv(YUY2)でキャプチャしろなんてアホなこと言い出したんだと思ってるが
ふつうhuffyuvはYUY2で使うと思っていたが…
ICZは、暗い絵が好きなんだって。
ただ、それだけ。
ただ、それだけ。
アニペグコミュニティにはアニペグコミュニティの文化があるんだよ。
中間ファイルにyuy2を使うなよ低脳
中間ファイルにRGBを使えというのか
全工程においてRGBには一度も変換しません
それはAviUtlを使うなってこと？
2002/5/3 ver 0.98 YUY2入出力に対応。
2.2.0やhuffyuvsのYUY2は伸長展開しないよね？
yes and no
質問よろしいでしょうか？
YUY2の共有UV2ピクセルには、上下方向の
補完は入るのでしょうか？
どう考えても、横方向の色しか丸め込みも
補完も働いていない気がします。
>>711
YUY2を知れば知るほど理解できます。
ソースがRGBなんですね。
YUY2の共有UV2ピクセルには、上下方向の
補完は入るのでしょうか？
どう考えても、横方向の色しか丸め込みも
補完も働いていない気がします。
>>711
YUY2を知れば知るほど理解できます。
ソースがRGBなんですね。
>>719
普通はやりません
ソフトによっては斜め方向も考慮した補間を使うかもしれないけど、
計算量が増えるので、補間を行う場合でも隣しか見ないのが普通です
あと、最近の MPEG-2 VIDEO VFAPI Plug-In は 422 -> 444 への色差
補間はやってません (420 -> 422 はインタレース対応で必須だから
やってるけど)
422 の色差をそのまま使って RGB に変換しています
普通はやりません
ソフトによっては斜め方向も考慮した補間を使うかもしれないけど、
計算量が増えるので、補間を行う場合でも隣しか見ないのが普通です
あと、最近の MPEG-2 VIDEO VFAPI Plug-In は 422 -> 444 への色差
補間はやってません (420 -> 422 はインタレース対応で必須だから
やってるけど)
422 の色差をそのまま使って RGB に変換しています
>>720 さん
ご回答サンクスです。
>>676-677 図のゴースト理論が嘘という事と、
4:2:2補完がされていない映像がゴーストの正体とわかりました。
YC伸張フィルタ（AviUtlプラグイン）の4:2:2→4:4:4補完を使ってみたら
AviUtl0.99のプレビューのゴースト消えました。
お騒がせしました。
私があること無い事言ってかき乱してしまいました。申し訳ないです。
輝度で悩んでる方々もがんばってください。
ご回答サンクスです。
>>676-677 図のゴースト理論が嘘という事と、
4:2:2補完がされていない映像がゴーストの正体とわかりました。
YC伸張フィルタ（AviUtlプラグイン）の4:2:2→4:4:4補完を使ってみたら
AviUtl0.99のプレビューのゴースト消えました。
お騒がせしました。
私があること無い事言ってかき乱してしまいました。申し訳ないです。
輝度で悩んでる方々もがんばってください。
>>721
AviUtl掲示板のあのスレッドはあの結論のままにしておくのでしょうか。
AviUtl掲示板のあのスレッドはあの結論のままにしておくのでしょうか。
DXSDKに付属のproppage.dllをregsvr32で登録すると、GraphEditのFilter Propertysで
DirectShowFilteを通過するときのInとOutの色空間（Sub Type）が分かって面白い。
で、ffdshowを使うとOutputの色空間を強制できるわけだけど、
うちのRADEON9000ではYV12でVMR9に接続したときだけ色伸張はかからなかったな。
ここの議論はCODECやフロントエンド内の色空間変換が主だけど、
DShowプレーヤー再生での色空間変換がドキュメントを見てもよく分からん人は
proppage.dllを登録してGraphEditで覗いてみると、直感的になにか掴めるかもしれん。
DXSDKのインストールが面倒人にはproppage.dllのありかとか
http://safariexamples.informit.com/0672325969/DirectX%20SDK/Utilities/
DirectShowFilteを通過するときのInとOutの色空間（Sub Type）が分かって面白い。
で、ffdshowを使うとOutputの色空間を強制できるわけだけど、
うちのRADEON9000ではYV12でVMR9に接続したときだけ色伸張はかからなかったな。
ここの議論はCODECやフロントエンド内の色空間変換が主だけど、
DShowプレーヤー再生での色空間変換がドキュメントを見てもよく分からん人は
proppage.dllを登録してGraphEditで覗いてみると、直感的になにか掴めるかもしれん。
DXSDKのインストールが面倒人にはproppage.dllのありかとか
http://safariexamples.informit.com/0672325969/DirectX%20SDK/Utilities/
huffyuv(YUY2)でキャプ、ここからMPEG2にしたいんだけど、
avisynth挟んでyuv411->422補間するのって意味あるかな？
やってもやらなくても一緒のような気がした、といかむしろチラついておかしくなった気がする。
avisynth挟んでyuv411->422補間するのって意味あるかな？
やってもやらなくても一緒のような気がした、といかむしろチラついておかしくなった気がする。
>>724
YUY2というのはyuv422の事なんだからyuv411->422補間など無駄。
YUY2というのはyuv422の事なんだからyuv411->422補間など無駄。
キャプった時点で422だったね。吊ってくる
420を補完すると何かいいことあるの？
>>722 さん
AviUtl掲示板のものは謝罪と解説付きで
しっかり謝罪しますm( __ __ )m
>>728 さん
AviSynthとYV12の関係を調べたサイトがありますよ。
ttp://members.at.infoseek.co.jp/kiraru2002/
意味合いは少し違いますが（汗
AviUtl掲示板のものは謝罪と解説付きで
しっかり謝罪しますm( __ __ )m
>>728 さん
AviSynthとYV12の関係を調べたサイトがありますよ。
ttp://members.at.infoseek.co.jp/kiraru2002/
意味合いは少し違いますが（汗
jumperさんは誠実な人ですね。
一応ぼくも見てます(謎)
723？
！
AviUtlのRGBの色ゴーストね・・・
クロマアップサンプリングバグとでも言った方が格好いいな。
クロマアップサンプリングバグとでも言った方が格好いいな。
>>733
図星？
図星？
736 ：slave：04/02/03 20:53
723さん(>>723ではありません)は読んでても理解できてないと思います
オマイが指導してヤレ
と言いたいとこだけど破門したんだよね
と言いたいとこだけど破門したんだよね
>>735
●
●
739 ：名無しさん＠編集中：04/02/05 15:22
radeonのオーバーレイってどう弄べばyc伸張に匹敵するのですか？
明るさ -10
コントラスト 30
ガンマ 0
輝度 20
色の濃さ 10
色合い 0
コントラスト 30
ガンマ 0
輝度 20
色の濃さ 10
色合い 0
RADEON使いだけど、改めてOverlayのカラーコントロールを弄ってみた。
なるほど、Y16-235をRGB0-255にマッピングしてるように見えるが
Y1-15,236-254を完全には飽和はさせてはいないようだ。
Overlayの明るさとコントラストを弄れば
ここのグレースケールの階調がすべて現れる。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ITU-601 変換後 16-235 to 0-255 に見えるような
デフォルト値が内部で設定されてるってことかな？
なるほど、Y16-235をRGB0-255にマッピングしてるように見えるが
Y1-15,236-254を完全には飽和はさせてはいないようだ。
Overlayの明るさとコントラストを弄れば
ここのグレースケールの階調がすべて現れる。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ITU-601 変換後 16-235 to 0-255 に見えるような
デフォルト値が内部で設定されてるってことかな？
その辺の調整が各社腕の見せ所
"Longhorn"のドライバでは次のようなことが要求されるんだってさ。
Color-space conversion requirements
・ Support programmable color converting YUV-to-RGB blit. Color conversion hardware must support color conversions that preserve video headroom and toeroom (levels above 235 or below 16 in 8-bit color formats) as defined in ITU-R 601 and ITU-R 709.
http://www.microsoft.com/whdc/hwdev/tech/display/graphics-reqs.mspx#XSLTsection124121120120
Color-space conversion requirements
・ Support programmable color converting YUV-to-RGB blit. Color conversion hardware must support color conversions that preserve video headroom and toeroom (levels above 235 or below 16 in 8-bit color formats) as defined in ITU-R 601 and ITU-R 709.
http://www.microsoft.com/whdc/hwdev/tech/display/graphics-reqs.mspx#XSLTsection124121120120
744 ：名無しさん＠編集中：04/02/15 21:44
ＮＴＳＣ基準の色ぐらいポンと設定できないものでつかね。
キャリブレーションなんか。。。
キャリブレーションなんか。。。
745 ：名無しさん＠編集中：04/02/15 22:20
国内向けに作られてる民生AV機器ですら
「メーカー色付け」がなされてるのに
開発国がNTSC-JですらないPC機器にそんなこと期待しても・・・
「メーカー色付け」がなされてるのに
開発国がNTSC-JですらないPC機器にそんなこと期待しても・・・
WindowsXP、DirectX9.0b、RADEON9700です。
なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
正直困っています。だから、MPCのVMR9モード使いたくても使えません。
どうしたらいいでしょうか?
なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
正直困っています。だから、MPCのVMR9モード使いたくても使えません。
どうしたらいいでしょうか?
あげます。
>>746
RADEONはオーバーレイで伸張。
VMR9にYV12接続で非伸張。
例えば、DivXをVMR9で再生するなら
デコーダオプションのYuｖ Extended Modeを外すと
YUY2で出力されるのでVMR9で伸張される。
ffdshowを使うならoutput coloerspaceのYV12のチェックを外しておけばいい。
RADEONはオーバーレイで伸張。
VMR9にYV12接続で非伸張。
例えば、DivXをVMR9で再生するなら
デコーダオプションのYuｖ Extended Modeを外すと
YUY2で出力されるのでVMR9で伸張される。
ffdshowを使うならoutput coloerspaceのYV12のチェックを外しておけばいい。
>>748
ありがとうございます。
しかし、それは実はもう試していて、今改めてデコーダーの設定を変えてみましたがやっぱりだめでした。
VMR9に限らず、オーバーレイじゃない場合は色がくすんでしまいます。
また、DivXだけでなく、WMV9、VP6、RV9・10でもだめです。
また、huffyuvでは伸長された色になります。
ffdshowは使っていません。
ありがとうございます。
しかし、それは実はもう試していて、今改めてデコーダーの設定を変えてみましたがやっぱりだめでした。
VMR9に限らず、オーバーレイじゃない場合は色がくすんでしまいます。
また、DivXだけでなく、WMV9、VP6、RV9・10でもだめです。
また、huffyuvでは伸長された色になります。
ffdshowは使っていません。
>>749
MPC使ってみました。
うちではVMR9（windowed） と VMR9（renderless）では色が違って見えるんですが
それは確認されてますか？
VMR9（renderless）だとOverlayMixerと同じに見えます。
MPC使ってみました。
うちではVMR9（windowed） と VMR9（renderless）では色が違って見えるんですが
それは確認されてますか？
VMR9（renderless）だとOverlayMixerと同じに見えます。
>VMR9（renderless）だとOverlayMixerと同じに見えます。
ああ、これは "こうなるべき" と言う意味ではなくて
うちではそう見えますがどうですか？と言う意味です。
ああ、これは "こうなるべき" と言う意味ではなくて
うちではそう見えますがどうですか？と言う意味です。
>>750-751
VMR9(windowed)→伸長しない
renderlessはDivXと他のコーデックで結果が変わりました。
DivX以外では
VMR9(renderless)の横の"VMR7/9(renderless)"&"DirctX7/9"settings
Use regular offscreen plain surfaces→伸長しない色
Use texture surfaces and render video in 2d/3d→伸長した色
DivXでは、ファイルによって変わりました。
あるファイル→DivX以外と同じ結果
またあるファイル
Use regular offscreen plain surfaces→フィルター一覧がVMR9(renderless)＆伸長しない色
Use texture surfaces and render video in 2d/3d→フィルター一覧にはVideo Renderer&オーバーレイ&伸長
VMR9(windowed)→伸長しない
renderlessはDivXと他のコーデックで結果が変わりました。
DivX以外では
VMR9(renderless)の横の"VMR7/9(renderless)"&"DirctX7/9"settings
Use regular offscreen plain surfaces→伸長しない色
Use texture surfaces and render video in 2d/3d→伸長した色
DivXでは、ファイルによって変わりました。
あるファイル→DivX以外と同じ結果
またあるファイル
Use regular offscreen plain surfaces→フィルター一覧がVMR9(renderless)＆伸長しない色
Use texture surfaces and render video in 2d/3d→フィルター一覧にはVideo Renderer&オーバーレイ&伸長
DivXでうまく行ったファイルと行かなかったファイルの違いは良くわかりません。
＞Use texture surfaces and render video in 2d/3d→フィルター一覧にはVideo Renderer&オーバーレイ&伸長
これわかりにくいかもなんで説明しますと、VMR9が使われなかったということです。
＞Use texture surfaces and render video in 2d/3d→フィルター一覧にはVideo Renderer&オーバーレイ&伸長
これわかりにくいかもなんで説明しますと、VMR9が使われなかったということです。
754 ：名無しさん＠編集中：04/02/18 23:20
ドライバによるのでは？
755 ：>>746,747,749,752,753：04/02/19 09:32
BSPlayerでオーバーレイの時の色がForceRGBで表示した時の色が同じなら
伸張しているってことでいいの？
伸張しているってことでいいの？
757 ：名無しさん＠編集中：04/02/19 19:39
>>755
なんか勘違いしてるような？
Radeonはオーバレイのとき伸張するよ。
ただし
BT.601通りの伸張にならない
じゃぁBT.601伸張と同等にするには？
が、現在の話題。
つまり
>なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
逆。GDIはソフト依存、オーバーレイは 伸張。
>おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
みんなそうです。ただし正確じゃない。
なんか勘違いしてるような？
Radeonはオーバレイのとき伸張するよ。
ただし
BT.601通りの伸張にならない
じゃぁBT.601伸張と同等にするには？
が、現在の話題。
つまり
>なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
逆。GDIはソフト依存、オーバーレイは 伸張。
>おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
みんなそうです。ただし正確じゃない。
＞じゃぁBT.601伸張と同等にするには？
＞が、現在の話題。
そんなの誰も話題にしてないぞ。
＞が、現在の話題。
そんなの誰も話題にしてないぞ。
まあ伸張が正確ではないというのが分かるぐらいなら
正確な伸張との差を取って補正値を見つければ良いだけですな。
その答えを757さんは知ってるんでしょう。
正確な伸張との差を取って補正値を見つければ良いだけですな。
その答えを757さんは知ってるんでしょう。
760 ：名無しさん＠編集中：04/02/19 20:47
DOS/V magazine No.247 2/15号
オーバーレイの明るさ、色調を
（＊）非オーバーレイ描写と同一に調節する方法
（＊）マイクロソフトが推称しているDirectDrawでの
動画再生描写結果と近い画質になります
①GeforceFX5600（Forceドライバ）・・・デトネーターは設定値が違うので注意
色相2%
彩度98%
明るさ122%
コントラスト107%
※デトネタは
明るさ120
コントラスト98
色相+4
彩度104
②RADEON9600XT（恐らく純正ドライバ）
明るさ20%
コントラスト90%
彩度95%
＊ラデは動画を再生中でなければ
オーバーレイ画質の調節はできない
オーバーレイの明るさ、色調を
（＊）非オーバーレイ描写と同一に調節する方法
（＊）マイクロソフトが推称しているDirectDrawでの
動画再生描写結果と近い画質になります
①GeforceFX5600（Forceドライバ）・・・デトネーターは設定値が違うので注意
色相2%
彩度98%
明るさ122%
コントラスト107%
※デトネタは
明るさ120
コントラスト98
色相+4
彩度104
②RADEON9600XT（恐らく純正ドライバ）
明るさ20%
コントラスト90%
彩度95%
＊ラデは動画を再生中でなければ
オーバーレイ画質の調節はできない
こーゆーのは色ｽﾚだと言われたので同じ事聞きますがすみません。
AviUtlでまるもでm2v.auiで直接読んで色空間は「元のYUVﾃﾞｰﾀ維持」
はまずいっすか？ 実写が主です
PCもﾃﾚﾋﾞもどっちも見れる事を前提に一応作ってまつ
使用ｸﾞﾗﾎﾞはGeForce4 MX420
RGBより色くっきり、AviUtlにしてはｴﾝｺも早い気がしていいと思いましたが。
AviUtlでまるもでm2v.auiで直接読んで色空間は「元のYUVﾃﾞｰﾀ維持」
はまずいっすか？ 実写が主です
PCもﾃﾚﾋﾞもどっちも見れる事を前提に一応作ってまつ
使用ｸﾞﾗﾎﾞはGeForce4 MX420
RGBより色くっきり、AviUtlにしてはｴﾝｺも早い気がしていいと思いましたが。
763 ：名無しさん＠編集中：04/02/20 23:51
>>762
BSDや地上Dじゃないならそれでいいでしょう。
BSDや地上Dじゃないならそれでいいでしょう。
>>762まずいというよりそれが推奨
PCでの鑑賞前提ならYC伸張した方がいい
>>765
おまえこのスレの内容理解してないだろ
おまえこのスレの内容理解してないだろ
767 ：名無しさん＠編集中：04/02/21 09:03
アフォジャンパもそんなこと書いてるしな。
こういう初心者は減らないよ。
こういう初心者は減らないよ。
さんきゅらちょ まるもで直接が楽だし好きなほう選んでやりまふ
そうです、地上Dエンコするわけでもありませんので
YC伸張フィルタてのは使ったことありません
そうです、地上Dエンコするわけでもありませんので
YC伸張フィルタてのは使ったことありません
>>767
2chの人にはジャンパさんの言うことが伝わらんのです。
2chの人にはジャンパさんの言うことが伝わらんのです。
772 ：名無しさん＠編集中：04/02/22 14:52
>>771
>これは、PC用のAVI動画にするなら、YC伸張をします
これ読んだ初心者がAviutlにMPEG2読ませてYC伸張して.aup
.aupをVFAPI経由でデフォルト設定のCCEにつっこむとどうなるのかな？
>この伸張された状態で、PC用のAVI（WMV9VCMやVP6）に出力すれば問題ありません
DVもMJPEGもHuffyuvSも一緒なのか？
それともPC用AVIじゃないとでも？
そもそも伸張圧縮型CODECだって内部有効範囲はY(16-235)。
>PCで再生する時にMPEG2のデコーダは伸張して再生するのが普通だからです。
DiVXでもそうでしょうに。
>動画編集初心者・中級者の為のページ
2chの人とかじゃなくて初心者に誤解されないようにしろよ。
初心者のためのページなんだろ？
>これは、PC用のAVI動画にするなら、YC伸張をします
これ読んだ初心者がAviutlにMPEG2読ませてYC伸張して.aup
.aupをVFAPI経由でデフォルト設定のCCEにつっこむとどうなるのかな？
>この伸張された状態で、PC用のAVI（WMV9VCMやVP6）に出力すれば問題ありません
DVもMJPEGもHuffyuvSも一緒なのか？
それともPC用AVIじゃないとでも？
そもそも伸張圧縮型CODECだって内部有効範囲はY(16-235)。
>PCで再生する時にMPEG2のデコーダは伸張して再生するのが普通だからです。
DiVXでもそうでしょうに。
>動画編集初心者・中級者の為のページ
2chの人とかじゃなくて初心者に誤解されないようにしろよ。
初心者のためのページなんだろ？
初心者はaupを別のフロントエンドに突っ込んだりしません
774 ：名無しさん＠編集中：04/02/22 15:09
それはあなたの判断。
初心者が何したいかはわからないだろ？
だいたいジャンパのとこにやり方書いてあるでしょう？
もっとおかしいのは、
・ジャンパはm2v.auiを推奨している。
・ジャンパはPC動画は伸張しろと書いてある。
・AviutlではデフォルトでYUV展開・圧縮はON。
m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力
↑こうやることになるぞ？
本当にこれでいいと思ってる？
初心者が何したいかはわからないだろ？
だいたいジャンパのとこにやり方書いてあるでしょう？
もっとおかしいのは、
・ジャンパはm2v.auiを推奨している。
・ジャンパはPC動画は伸張しろと書いてある。
・AviutlではデフォルトでYUV展開・圧縮はON。
m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力
↑こうやることになるぞ？
本当にこれでいいと思ってる？
>>767
アフォなのは否定しません。よく間違えますし。
ということで、
ttp://jumper-x.hp.infoseek.co.jp/study/6/index.html
どうぞ。
YC伸張が必要なのは、「目で見る時」の
YUV→RGBにする時であって、
前スレの真意はそこに集約されると
おっしゃってる人の通りであって・・・
（このスレの真意はYUV→RGB小数点切捨て回避ですが）
AviUtlのYCｂCrのヒストグラム範囲が
0-255じゃないことなどで、
真意が伝わればいいのですが_|￣|○
AviUtlで「YUY2読み込みした時」の
RGBのヒストグラムやプレビューが
PCディスプレイに映せるRGBに伸張されているものだと、
理解してもらえればうれしいのですが。
|-`).｡oO(出来た動画を再生して見ないのかな)
アフォなのは否定しません。よく間違えますし。
ということで、
ttp://jumper-x.hp.infoseek.co.jp/study/6/index.html
どうぞ。
YC伸張が必要なのは、「目で見る時」の
YUV→RGBにする時であって、
前スレの真意はそこに集約されると
おっしゃってる人の通りであって・・・
（このスレの真意はYUV→RGB小数点切捨て回避ですが）
AviUtlのYCｂCrのヒストグラム範囲が
0-255じゃないことなどで、
真意が伝わればいいのですが_|￣|○
AviUtlで「YUY2読み込みした時」の
RGBのヒストグラムやプレビューが
PCディスプレイに映せるRGBに伸張されているものだと、
理解してもらえればうれしいのですが。
|-`).｡oO(出来た動画を再生して見ないのかな)
776 ：謎の645：04/02/22 15:16
>>775
乙。
それは兎も角
>じゃあ、AviUtlでMPEG2をYUY2読み込みして、WMV9VCMなどのYUY2入力に対応したAVIに出力する場合は？
という質問が多いですが、Yは「内部で」0-235の範囲にすればいいのです。
16-235の打ち間違いですな。
まったくせっかちなんだから・・・。
乙。
それは兎も角
>じゃあ、AviUtlでMPEG2をYUY2読み込みして、WMV9VCMなどのYUY2入力に対応したAVIに出力する場合は？
という質問が多いですが、Yは「内部で」0-235の範囲にすればいいのです。
16-235の打ち間違いですな。
まったくせっかちなんだから・・・。
うお。書き込み中に新レスが。
>>772 さん
>>774 さん
そういうことなのね･･･CCE持って無いので
わかりませんが。
>・ジャンパはm2v.auiを推奨している。
してるように見えますか_|￣|○
>・ジャンパはPC動画は伸張しろと書いてある。
書いてますね。でも、何でもかんでも伸張しろとは
言ってない希ガス。
>m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力
プレビュー見たら、初心者だったら余計に
できないと思いますよ。
伸張無しRGB読み込み→
AviUtlのプレビューが薄いけどいいや→YUY2出力
伸張ミスでシュリンクｱﾎﾞｰﾝ(´・ｪ・｀)
をしてほしく無いから書いたのですが。
>>772 さん
>>774 さん
そういうことなのね･･･CCE持って無いので
わかりませんが。
>・ジャンパはm2v.auiを推奨している。
してるように見えますか_|￣|○
>・ジャンパはPC動画は伸張しろと書いてある。
書いてますね。でも、何でもかんでも伸張しろとは
言ってない希ガス。
>m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力
プレビュー見たら、初心者だったら余計に
できないと思いますよ。
伸張無しRGB読み込み→
AviUtlのプレビューが薄いけどいいや→YUY2出力
伸張ミスでシュリンクｱﾎﾞｰﾝ(´・ｪ・｀)
をしてほしく無いから書いたのですが。
778 ：謎の645：04/02/22 15:29
やはりｼﾞｬﾝﾊﾟはｱﾆｦﾀって感じがするな。
実写だと二重伸張・二重圧縮でも気が付かないﾔｼはいるでしょう。
ﾓｰｦﾀとかﾓｰｦﾀとかﾓｰｦﾀとか。
ぶっちゃけ照明のせいで真っ白・真っ黒がわかりにくいからね。
ｿｰｽと比べりゃわかるんだけどな。
実写だと二重伸張・二重圧縮でも気が付かないﾔｼはいるでしょう。
ﾓｰｦﾀとかﾓｰｦﾀとかﾓｰｦﾀとか。
ぶっちゃけ照明のせいで真っ白・真っ黒がわかりにくいからね。
ｿｰｽと比べりゃわかるんだけどな。
謎の645さんへ
その通りです。アニヲタ寄りです。
ドラマとかも漫画原作のドラマばかりキャプしています。
私自身が、めざせ！あにぺぐの常連ですし。
>実写だと二重伸張・二重圧縮でも気が付かないﾔｼはいるでしょう。
気付いて( ﾟдﾟ)ﾎｽｨ…
打ち間違えのところを直しました(｀･ω･´)ｼｬｷｰﾝ
ご指摘ありがとうございます。
その通りです。アニヲタ寄りです。
ドラマとかも漫画原作のドラマばかりキャプしています。
私自身が、めざせ！あにぺぐの常連ですし。
>実写だと二重伸張・二重圧縮でも気が付かないﾔｼはいるでしょう。
気付いて( ﾟдﾟ)ﾎｽｨ…
打ち間違えのところを直しました(｀･ω･´)ｼｬｷｰﾝ
ご指摘ありがとうございます。
どうせならAviUtl内部フォーマットの詳細な解説を作れば？
どう読み込むとどうなって、表示はどうなり、出力される時にどうなるのかとか。
どう読み込むとどうなって、表示はどうなり、出力される時にどうなるのかとか。
AviutlのYUYフィルタモードでやる場合は、ヒストグラムの左右の線より内側になるようにしておけば安心？
>>780
もうできてるよ
もうできてるよ
783 ：名無しさん＠編集中：04/02/22 21:58
>>782
消えただろ
消えただろ
784 ：名無しさん＠編集中：04/02/23 00:09
jumperさん、YC伸張のコンテンツ乙です。
初心者の私にはとても分かりやすくためになる内容でした。
初心者の私にはとても分かりやすくためになる内容でした。
BS デジタルの場合、m2v.auiの設定はどうするのが正しいの？
正しいの「ですか？」だろ
人に物を尋ねるときは口の利き方に気をつけろや、ｳﾞｫｹ
人に物を尋ねるときは口の利き方に気をつけろや、ｳﾞｫｹ
で、どうするのが正しいの？
どうしようが大してかわらんだろ
好きなのえらんどけ
好きなのえらんどけ
カラーバーをDVDにしたいのですが
このzipファイル内にあるA,Bどちらのファイルを使うのが正しいですか？
http://my.reset.jp/~abon/download/NO_20040224002943.zip.html
このzipファイル内にあるA,Bどちらのファイルを使うのが正しいですか？
http://my.reset.jp/~abon/download/NO_20040224002943.zip.html
両方ともおかくないか？
デザインも微妙に変。
デザインも微妙に変。
ｽﾏｿ。Aだな。
この度MTV1000を中古で買いました。
それでMPEG2を取り込みDivXにしているのですが、その手順は
まるも氏のMPEG2PlugInでAviUtilに読み込みDivX
にしています。
ここで色の伸張に疑問を感じたので質問します。
MPEG2PlugInの設定でYUV→RGB変換で
・ストレート変換
・ITU-R BT.601から伸張
とありますが、この2つの違いは何でしょうか？
現在、「ITU-R BT.601から伸張」に設定しています。
次にDivXコーデックの設定ですが
・YUY2で展開する
・YUY2で圧縮する
とあります。
現在「YUY2で展開・圧縮ともにONにしています。
この場合、
MTVでキャプチャーしたMPEGファイル YUV
AviUtl上 RGB(YUV→ITU-R.601伸張されたため)
DivXファイル YUY2(RGB→YUY2圧縮されたため)
なのでしょうか？
なんとなく色が薄くなっているような気がするのですが、この設定で正しいのでしょうか？
よろしくお願いします。
それでMPEG2を取り込みDivXにしているのですが、その手順は
まるも氏のMPEG2PlugInでAviUtilに読み込みDivX
にしています。
ここで色の伸張に疑問を感じたので質問します。
MPEG2PlugInの設定でYUV→RGB変換で
・ストレート変換
・ITU-R BT.601から伸張
とありますが、この2つの違いは何でしょうか？
現在、「ITU-R BT.601から伸張」に設定しています。
次にDivXコーデックの設定ですが
・YUY2で展開する
・YUY2で圧縮する
とあります。
現在「YUY2で展開・圧縮ともにONにしています。
この場合、
MTVでキャプチャーしたMPEGファイル YUV
AviUtl上 RGB(YUV→ITU-R.601伸張されたため)
DivXファイル YUY2(RGB→YUY2圧縮されたため)
なのでしょうか？
なんとなく色が薄くなっているような気がするのですが、この設定で正しいのでしょうか？
よろしくお願いします。
ああ、コピペがキタ
薄くなってると思うなら調整すればいいだろ
コピペ師ね
コピペ師ね
796 ：名無しさん＠編集中：04/02/25 11:12
その方法だと薄くならないだろうに
797 ：名無しさん＠編集中：04/02/25 11:22
薄くなるのはやりすぎの証拠。
騙されたと思って３日間ガマンしてみ。濃くなるから
騙されたと思って３日間ガマンしてみ。濃くなるから
>>797
そんなことしてたら、また3日我慢しないと濃くならないだろうがよ。
そんなことしてたら、また3日我慢しないと濃くならないだろうがよ。
三日も我慢できないよぉ
800 ：名無しさん＠編集中：04/02/28 01:02
M2Kitの画像を私なりに、補正してみました。
補正の内訳
１．オリジナルのJPEGデータ５０．４KBを、AdobeFhotoDeluxeにてBMP１０１３KBに変換。
２．BMPをAviutlにロードして、YC伸張フィルタと拡張色調補正フィルタをかける。
YC伸張フィルタの設定・・・Y（lower）=16、Y(Upper)=235、Cb=64,Cr=64、YCｂCr補間法＝Yuv4:1:1→Yuv4:2:2
クリッピング・・・右２（補間基準点左側、右側２をクリップし、元サイズに拡大）
拡張色調補正フィルタの設定・・・Cb(gain),+32、R(offs)+32、G(offs)+32B(offs)+40,B(gain)+8,B(gamm)+8
３．未圧縮のYUY2のAVIに保存。６８０KB
４．Videostudio7にYUY2のビデオファイルをロードして、JPEG（品質７０）にて静止画として取り出す。48.9KB
http://www.geocities.co.jp/SilkRoad-Desert/3853/Home1/newpage1.htm
補正の内訳
１．オリジナルのJPEGデータ５０．４KBを、AdobeFhotoDeluxeにてBMP１０１３KBに変換。
２．BMPをAviutlにロードして、YC伸張フィルタと拡張色調補正フィルタをかける。
YC伸張フィルタの設定・・・Y（lower）=16、Y(Upper)=235、Cb=64,Cr=64、YCｂCr補間法＝Yuv4:1:1→Yuv4:2:2
クリッピング・・・右２（補間基準点左側、右側２をクリップし、元サイズに拡大）
拡張色調補正フィルタの設定・・・Cb(gain),+32、R(offs)+32、G(offs)+32B(offs)+40,B(gain)+8,B(gamm)+8
３．未圧縮のYUY2のAVIに保存。６８０KB
４．Videostudio7にYUY2のビデオファイルをロードして、JPEG（品質７０）にて静止画として取り出す。48.9KB
http://www.geocities.co.jp/SilkRoad-Desert/3853/Home1/newpage1.htm
これはデジカメを加工するツールじゃない
YUY色空間等の変換ロスとかどうなるんでしょうね
ちゃんと理解してツールを利用した方がよいと思う
微妙にフィルタかけた後の画像の取り出しもぎこちないし
あー、これたぶん誤爆なんだろうな
YUY色空間等の変換ロスとかどうなるんでしょうね
ちゃんと理解してツールを利用した方がよいと思う
微妙にフィルタかけた後の画像の取り出しもぎこちないし
あー、これたぶん誤爆なんだろうな
802 ：名無しさん＠編集中：04/02/28 23:28
803 ：名無しさん＠編集中：04/03/12 00:05
age
RGBはデータの値のまま編集ソフトに読み込めるのに
YUV系統はなぜ伸張して読み込むのか分かる方いますか？
データ的には15-235で記録されてるんですよね？
では、そのままストレートに読み込む方法があるのかというと私は知りません
YUV系統はなぜ伸張して読み込むのか分かる方いますか？
データ的には15-235で記録されてるんですよね？
では、そのままストレートに読み込む方法があるのかというと私は知りません
806 ：名無しさん＠編集中：04/03/14 19:18
>>805
プロ用だとストレートだったりもする。
まぁ、業務用モニターに出力するから当たり前だが。
基本的に”なぜ伸張して読み込むのか？”というと
Codecの多くが伸張変換だから。
編集時と出力後再生時の色味を一致させようってことだな。
じゃぁなんでCodecの多くがそうなってるからっていうと
PCモニタはRGB0-255しかダイナミックレンジを持たないから。
本来アナログRGBは16-235を有効範囲とする（NTSC-J）
これをそのままA/Dにするとダイナミックレンジが損なわれる（アナログは小数点以下がある）
どうせ16-235しか有効としないならA/D変換で0-255に再マップしちまえ。
それがそのままYUVにも適用されたってとこ。
まぁM＄がそういう実装にしたわけだが。
あとYUV系統は伸張して読み込まれるわけではない。
読み込みはストレートだよ。
YUVは表示できないから表示するときにRGBにする。
そのときに伸張されることが多いだけ。
アプリ・設定・環境によってはストレート変換でRGB表示も可能。
プロ用だとストレートだったりもする。
まぁ、業務用モニターに出力するから当たり前だが。
基本的に”なぜ伸張して読み込むのか？”というと
Codecの多くが伸張変換だから。
編集時と出力後再生時の色味を一致させようってことだな。
じゃぁなんでCodecの多くがそうなってるからっていうと
PCモニタはRGB0-255しかダイナミックレンジを持たないから。
本来アナログRGBは16-235を有効範囲とする（NTSC-J）
これをそのままA/Dにするとダイナミックレンジが損なわれる（アナログは小数点以下がある）
どうせ16-235しか有効としないならA/D変換で0-255に再マップしちまえ。
それがそのままYUVにも適用されたってとこ。
まぁM＄がそういう実装にしたわけだが。
あとYUV系統は伸張して読み込まれるわけではない。
読み込みはストレートだよ。
YUVは表示できないから表示するときにRGBにする。
そのときに伸張されることが多いだけ。
アプリ・設定・環境によってはストレート変換でRGB表示も可能。
>>806
ありがとうございます
ほんとによくわかりました
デコーダーの-5%輝度を取り込むのはアナログ0-255スケーリングのものなんでしょうが
仕様としてはアナログ16-240範囲をスケーリングしてくれた方が精度がよさそうですね
-5%もテレビで確認できるんだからばっさり切ってしまうのは、また反発もありそうですが
ありがとうございます
ほんとによくわかりました
デコーダーの-5%輝度を取り込むのはアナログ0-255スケーリングのものなんでしょうが
仕様としてはアナログ16-240範囲をスケーリングしてくれた方が精度がよさそうですね
-5%もテレビで確認できるんだからばっさり切ってしまうのは、また反発もありそうですが
808 ：名無しさん＠編集中：04/03/17 00:55
YUV<>RGB変換誤差って小数点の丸め込みなの？
jumperさんがそう書いてるんだけど…。
jumperさんがそう書いてるんだけど…。
回りくどい尋ね方で申し訳ない
このヒストグラムはありえますか？
http://with2ch.net/cgi-bin/pict/image-box/img20040317103514.jpg
ビデオデッキチューナーS端子→DVメディアコンバータi-Link→
ふぬああ（コンプレッサなし）DVType2にチェック
DVコーデックとしてirisベータ6.3が入っています。MSDVとの置き換えもしています。
iris設定はストレート変換を行うにチェックが入っています。
メディアプレイヤでオーバーレイを先に占有して
ふぬああでアナログBS1をプレビューした時の画です。
本来ならヒストグラムはもっと中央寄りになっているべき物と
考えているのですが、どうなのでしょう？
この状態だと何かが伸張しているとしか考えられないのですが。
このヒストグラムはありえますか？
http://with2ch.net/cgi-bin/pict/image-box/img20040317103514.jpg
ビデオデッキチューナーS端子→DVメディアコンバータi-Link→
ふぬああ（コンプレッサなし）DVType2にチェック
DVコーデックとしてirisベータ6.3が入っています。MSDVとの置き換えもしています。
iris設定はストレート変換を行うにチェックが入っています。
メディアプレイヤでオーバーレイを先に占有して
ふぬああでアナログBS1をプレビューした時の画です。
本来ならヒストグラムはもっと中央寄りになっているべき物と
考えているのですが、どうなのでしょう？
この状態だと何かが伸張しているとしか考えられないのですが。
>>808
どこに書いてある？
そんなこと書いてあるかなぁ・・・
一応答えるが「小数点丸め込み」よりもっと誤差はでかいよ
>>809
全然ありえます
「全ての民生AV機器は顧客がより綺麗に感じるように表示・信号生成を行うよう設計される」
から
つまり
>>ビデオデッキチューナーS端子
>>DVメディアコンバータi-Link
どちらもBT.601有効範囲を保障するものではありません
またDVだろうがDVDだろうがｷｬﾌﾟﾎﾞだろうが
使用者が、BT.601の有効範囲でA/D変換されるように設定する
のは大前提
もちろんそれができない機器は多いけどなー
つまり>>809がやってることは
”BT.601に準拠してない信号をBT.601の有効範囲を守るかどうかわからない方法でキャプって
ﾋｽﾄｸﾞﾗﾑみたらYがBT.601の有効範囲を大きく逸脱した”
に過ぎない
伸張云々以前の問題
どこに書いてある？
そんなこと書いてあるかなぁ・・・
一応答えるが「小数点丸め込み」よりもっと誤差はでかいよ
>>809
全然ありえます
「全ての民生AV機器は顧客がより綺麗に感じるように表示・信号生成を行うよう設計される」
から
つまり
>>ビデオデッキチューナーS端子
>>DVメディアコンバータi-Link
どちらもBT.601有効範囲を保障するものではありません
またDVだろうがDVDだろうがｷｬﾌﾟﾎﾞだろうが
使用者が、BT.601の有効範囲でA/D変換されるように設定する
のは大前提
もちろんそれができない機器は多いけどなー
つまり>>809がやってることは
”BT.601に準拠してない信号をBT.601の有効範囲を守るかどうかわからない方法でキャプって
ﾋｽﾄｸﾞﾗﾑみたらYがBT.601の有効範囲を大きく逸脱した”
に過ぎない
伸張云々以前の問題
>>810レスポンスありがとうございます。
で、ここからが回りくどさの真骨頂なのですが。
以前は同様の環境でBT.601の有効範囲と思われる範囲で
キャプチャできていたのです。逆にキャプチャ段で縮小されていた
可能性も否定できませんが。
キャプチャしたものをaviutl0.98dで編集するのですが
現在の>>809のような状態だと、YUY2で展開すると
さらに伸張された様なヒストグラムに、RGBで開くと
プレビューとほぼ同じ範囲になります。>>809の通りirisコーデックの
デコードはストレートです。当然フィルタは全てOFFです。
それでも、明るい部分が以前ではありえないほど飛んでしまいます。
以前キャプチャしたものはRGBで展開していましたがaviutlのヒストグラムは
中央よりの狭い範囲によった形でした。
その当時キャプチャ時にはふぬああでのヒストグラムは確認していません。
当然何かきっかけがあってこの様になっているわけですが
はずかしながらいつのまにかこんな状態になっていてわかりません。
ソフトウェアやコーデックの出し入れはしていません。
いくつかの要素からたどってくると結局キャプチャ段階で
変化が起きてしまっていると考え、その段階で伸張（または縮小）
してしまうような要素を探しているのですが、自分ではお手上げ
状態です。
で、ここからが回りくどさの真骨頂なのですが。
以前は同様の環境でBT.601の有効範囲と思われる範囲で
キャプチャできていたのです。逆にキャプチャ段で縮小されていた
可能性も否定できませんが。
キャプチャしたものをaviutl0.98dで編集するのですが
現在の>>809のような状態だと、YUY2で展開すると
さらに伸張された様なヒストグラムに、RGBで開くと
プレビューとほぼ同じ範囲になります。>>809の通りirisコーデックの
デコードはストレートです。当然フィルタは全てOFFです。
それでも、明るい部分が以前ではありえないほど飛んでしまいます。
以前キャプチャしたものはRGBで展開していましたがaviutlのヒストグラムは
中央よりの狭い範囲によった形でした。
その当時キャプチャ時にはふぬああでのヒストグラムは確認していません。
当然何かきっかけがあってこの様になっているわけですが
はずかしながらいつのまにかこんな状態になっていてわかりません。
ソフトウェアやコーデックの出し入れはしていません。
いくつかの要素からたどってくると結局キャプチャ段階で
変化が起きてしまっていると考え、その段階で伸張（または縮小）
してしまうような要素を探しているのですが、自分ではお手上げ
状態です。
>>811
Aviutl98d上で以前ｷｬﾌﾟﾁｬされたものをRGB展開でみたﾋｽﾄｸﾞﾗﾑと
最近ｷｬﾌﾟﾁｬしたものが違うってこと？
ちなみにRGB展開でYUVﾋｽﾄｸﾞﾗﾑみても
有効範囲かどうかはわからないんだけどね
Aviutl98d上で以前ｷｬﾌﾟﾁｬされたものをRGB展開でみたﾋｽﾄｸﾞﾗﾑと
最近ｷｬﾌﾟﾁｬしたものが違うってこと？
ちなみにRGB展開でYUVﾋｽﾄｸﾞﾗﾑみても
有効範囲かどうかはわからないんだけどね
あと基本的な事項を確認したいんだけど
Y値が0-255をとってるから伸張されてる、ってことにならないのはわかってるんだよね
ﾋｽﾄｸﾞﾗﾑを見る限りでは伸張されてるというより
家電にありがちなﾄﾋﾞ気味になってるYUVにしか見えないんだが
Y値が0-255をとってるから伸張されてる、ってことにならないのはわかってるんだよね
ﾋｽﾄｸﾞﾗﾑを見る限りでは伸張されてるというより
家電にありがちなﾄﾋﾞ気味になってるYUVにしか見えないんだが
>>775か
見逃してた
見逃してた
>>812
以前と現在のキャプチャ結果がいつのまにか変わっている、そういうことです。
小数点以下の話が出るような厳密なスレの流れのなか、かなりあいまいな話で
申し訳なく、腰が引けてしまうのですが。正直よくわかってません。
以前はaviutl上でヒストグラムが中央よりになっていた為、YC伸張フィルタで
自分の好みの明るさに伸張していました。Yを10-245くらい。ソースによってまちまち
ですが、明るい部分を絶対飛ばしたくないのでかなり普通じゃない数字だと思いますが。
ところが、現状は既に伸張されたようなヒストグラムの状態なので
伸張する余地も無く、場合によっては明るい部分が飛んでしまいます。
デイリーでキャプチャしている番組のオープニングでは明らかに違います。
放送自体がイレギュラーになった可能性も否定はできませんが。
よくわかっていないのに伸張という言葉を使った理由としては
aviutlにて以前のファイルをRGBで開いて拡張色調補正でTV→PC補正した物と
現状でキャプチャしたもの（無補正）が同じようなヒストグラムになり、
その逆、現状のファイルをRGBで開いてPC→TV補正すると
以前キャプチャしたもの(無補正）とほぼ同じ範囲になります。
自分の中では以前の状態が一応正しい状態と認知していますので
以前の物をスケール補正した物が現状なので、伸張されたのでは
と表現しました。
ちなみにメディコンはcanopusのADVC-100です。色補正と思われる
調整項目は黒レベルのみで0IREになっています。一切調整はしていませんが。
＞家電にありがちなﾄﾋﾞ気味になってるYUVにしか見えないんだが
となると、以前が圧縮補正されてキャプチャされていたという事になってしまうんでしょうか・・・
以前と現在のキャプチャ結果がいつのまにか変わっている、そういうことです。
小数点以下の話が出るような厳密なスレの流れのなか、かなりあいまいな話で
申し訳なく、腰が引けてしまうのですが。正直よくわかってません。
以前はaviutl上でヒストグラムが中央よりになっていた為、YC伸張フィルタで
自分の好みの明るさに伸張していました。Yを10-245くらい。ソースによってまちまち
ですが、明るい部分を絶対飛ばしたくないのでかなり普通じゃない数字だと思いますが。
ところが、現状は既に伸張されたようなヒストグラムの状態なので
伸張する余地も無く、場合によっては明るい部分が飛んでしまいます。
デイリーでキャプチャしている番組のオープニングでは明らかに違います。
放送自体がイレギュラーになった可能性も否定はできませんが。
よくわかっていないのに伸張という言葉を使った理由としては
aviutlにて以前のファイルをRGBで開いて拡張色調補正でTV→PC補正した物と
現状でキャプチャしたもの（無補正）が同じようなヒストグラムになり、
その逆、現状のファイルをRGBで開いてPC→TV補正すると
以前キャプチャしたもの(無補正）とほぼ同じ範囲になります。
自分の中では以前の状態が一応正しい状態と認知していますので
以前の物をスケール補正した物が現状なので、伸張されたのでは
と表現しました。
ちなみにメディコンはcanopusのADVC-100です。色補正と思われる
調整項目は黒レベルのみで0IREになっています。一切調整はしていませんが。
＞家電にありがちなﾄﾋﾞ気味になってるYUVにしか見えないんだが
となると、以前が圧縮補正されてキャプチャされていたという事になってしまうんでしょうか・・・
816 ：名無しさん＠編集中：04/03/17 14:35
>>815
以前キャプチャしたファイルは iris じゃなくて CanopusDVcodecつかってたんじゃない？
CanopusDVcodecってYUV<->RGB変換がストレートだから、AvuUtlでRGB読み込みすりゃ、
そういう状態になるよ。
l
以前キャプチャしたファイルは iris じゃなくて CanopusDVcodecつかってたんじゃない？
CanopusDVcodecってYUV<->RGB変換がストレートだから、AvuUtlでRGB読み込みすりゃ、
そういう状態になるよ。
l
>>816
Irisもストレート指定してるってのはCanopusと同じことになるんじゃないの？
Irisもストレート指定してるってのはCanopusと同じことになるんじゃないの？
>>815
以前も今も”ｵﾚｽｹｰﾙ”ｷｬﾌﾟﾁｬしてるだけでしょ
だったら”ｵﾚｽｹｰﾙ”補正すればいいじゃん
所詮色なんて自分が満足ならそれで構わないんだから
”以前のｵﾚｽｹｰﾙと今のｵﾚｽｹｰﾙが違うのはなぜ？”
といわれても困ってしまうわけだが
以前も今も”ｵﾚｽｹｰﾙ”ｷｬﾌﾟﾁｬしてるだけでしょ
だったら”ｵﾚｽｹｰﾙ”補正すればいいじゃん
所詮色なんて自分が満足ならそれで構わないんだから
”以前のｵﾚｽｹｰﾙと今のｵﾚｽｹｰﾙが違うのはなぜ？”
といわれても困ってしまうわけだが
819 ：809、815：04/03/17 18:56
いじってる自分でもわからないもの
こういう場面にあったことのある人じゃなきゃわからないですね。
いろいろとありがとうございました。
>>818
現状では勝手に伸張されたような状態なので
クリップして飛んでいってしまった部分はどうしたって
帰ってこないわけですよ。だから困っているわけで・・・。
キャプチャする時点でDVなのでコンプレッサも何も使っていないのに
というか、使っていないからスケールがどんなスケールなのか
わからないわけですよ。前の状態が正しいのか今の状態が
ただしいのか。
DV＋ふぬああ環境、コンプレッサ無しで任意のスケールで
キャプチャできるものなのか、できないのか。
で、現状は伸張されたような状態なので元に戻すには
どうしたらいいのかを探してます。
こういう場面にあったことのある人じゃなきゃわからないですね。
いろいろとありがとうございました。
>>818
現状では勝手に伸張されたような状態なので
クリップして飛んでいってしまった部分はどうしたって
帰ってこないわけですよ。だから困っているわけで・・・。
キャプチャする時点でDVなのでコンプレッサも何も使っていないのに
というか、使っていないからスケールがどんなスケールなのか
わからないわけですよ。前の状態が正しいのか今の状態が
ただしいのか。
DV＋ふぬああ環境、コンプレッサ無しで任意のスケールで
キャプチャできるものなのか、できないのか。
で、現状は伸張されたような状態なので元に戻すには
どうしたらいいのかを探してます。
>>819
iLINK転送なんだからPCにくる以前にﾃﾞｼﾞﾀﾙになってるんだよ？
ﾃﾞｼﾞﾀﾙになってる時には既にｸﾘｯﾌﾟされてるんだよ？
ﾃﾞｯｷかｺﾝﾊﾞｰﾀ-つまりｱﾅﾛｸﾞﾚﾍﾞﾙでﾀﾞｲﾅﾐｯｸﾚﾝｼﾞいじらなきゃどうにもならないでしょ
ただ、あのﾋｽﾄｸﾞﾗﾑでｸﾘｯﾌﾟされてるとは思わないけどね
iLINK転送なんだからPCにくる以前にﾃﾞｼﾞﾀﾙになってるんだよ？
ﾃﾞｼﾞﾀﾙになってる時には既にｸﾘｯﾌﾟされてるんだよ？
ﾃﾞｯｷかｺﾝﾊﾞｰﾀ-つまりｱﾅﾛｸﾞﾚﾍﾞﾙでﾀﾞｲﾅﾐｯｸﾚﾝｼﾞいじらなきゃどうにもならないでしょ
ただ、あのﾋｽﾄｸﾞﾗﾑでｸﾘｯﾌﾟされてるとは思わないけどね
使っていないからスケールがどんなスケールなのか
わからないわけですよ
↑
これがそもそも認識不足
ｱﾅﾛｸﾞYUV->ﾃﾞｼﾞﾀﾙYUVでｽｹｰﾙ変換なんてないんだから
ﾃﾞｯｷ->ｺﾝﾊﾞｰﾀorｺﾝﾊﾞｰﾀ内部のA/D変換のときに
ﾒｰｶｰ独自の味付けがされてるってだけ
それはｷｬﾌﾟﾎﾞだって同じなんだよ
わからないわけですよ
↑
これがそもそも認識不足
ｱﾅﾛｸﾞYUV->ﾃﾞｼﾞﾀﾙYUVでｽｹｰﾙ変換なんてないんだから
ﾃﾞｯｷ->ｺﾝﾊﾞｰﾀorｺﾝﾊﾞｰﾀ内部のA/D変換のときに
ﾒｰｶｰ独自の味付けがされてるってだけ
それはｷｬﾌﾟﾎﾞだって同じなんだよ
このスレには魔物が住んでるってこの板では評判ですね。でまともな
職人は寄り付かないと。
職人は寄り付かないと。
コピペか
824 ：名無しさん＠編集中：04/03/27 01:58
保守
わしも似たパターンかな。DR7スルーでふぬああでDVキャプチャ。
TV東京の番組のファイルをColorYUY2のAutoYUVに通してログファイルを
見たらYが0-255になっとる。
TV東京の番組のファイルをColorYUY2のAutoYUVに通してログファイルを
見たらYが0-255になっとる。
サチュレートしなけりゃY0-255は当たり前
>>825
そうなんですよ、テレ東が一番健著。
日テレはYUV16-235範囲で収まってるけど、テレ東はYUV5-255overみたいな。
同じCMみても全然違う。
テレ東も3月の頭まではこんなじゃなかった様な気がするんですけど
そうなんですよ、テレ東が一番健著。
日テレはYUV16-235範囲で収まってるけど、テレ東はYUV5-255overみたいな。
同じCMみても全然違う。
テレ東も3月の頭まではこんなじゃなかった様な気がするんですけど
テレ東全部ってなら受信状態の問題でしょ
ちゃんとチャンネルごとに設定しなよ
または後で補正できるようにキャプしな
ちゃんとチャンネルごとに設定しなよ
または後で補正できるようにキャプしな
テレ東全部ですね。
もちろん、他チャンネルと比べて尋常じゃない状態なので
受信状態うたがいましたよ。
微調整で受信調整しながらキャプチャしてもY255まで
使い切ってるのは変わりませんでしたが。
参考までにDVで後に補正ができるような方法教えてもらえませんか？
全く方法を変えなければ無理ですか？
もちろん、他チャンネルと比べて尋常じゃない状態なので
受信状態うたがいましたよ。
微調整で受信調整しながらキャプチャしてもY255まで
使い切ってるのは変わりませんでしたが。
参考までにDVで後に補正ができるような方法教えてもらえませんか？
全く方法を変えなければ無理ですか？
コントラストを低めにキャプすればいいじゃん
だからDVはキャプじゃないんだって・・・
DVHS=MPEG2TSと一緒でストリーム転送
アナログ＞DVコンバータかなんかで補正できるものはあるけどな
どっちにしろPCへは転送されてるだけなんだって
DVHS=MPEG2TSと一緒でストリーム転送
アナログ＞DVコンバータかなんかで補正できるものはあるけどな
どっちにしろPCへは転送されてるだけなんだって
何言ってんだか
PCで扱うDVは単なるコーデックだぞ
PCで扱うDVは単なるコーデックだぞ
>>832
DVコーデックがやってるのはYUV<>RGB変換だよ
質問者はDVデッキからIEEE1394でPCにもってきてる
データ的にはストリームだよ
CanopusだろうがIrisだろうがこのときコーデックはデコーダになるだけ
MPEG2TSのデコーダがWinDVDだろうがまるもプラグインだろうが
動画データ的には一緒だろ？
DVの場合ヘッダとFourCCは変わるがPC側でエンコードはしてない
キャプチャキャリブレートはA/Dの前に行わないと意味がない
後で行うなうなら色調補正と一緒
ストリーム転送はデジタルデータ貰ってるだけなんだから
キャプチャキャリブレートはPC内でできない
DVコーデックがやってるのはYUV<>RGB変換だよ
質問者はDVデッキからIEEE1394でPCにもってきてる
データ的にはストリームだよ
CanopusだろうがIrisだろうがこのときコーデックはデコーダになるだけ
MPEG2TSのデコーダがWinDVDだろうがまるもプラグインだろうが
動画データ的には一緒だろ？
DVの場合ヘッダとFourCCは変わるがPC側でエンコードはしてない
キャプチャキャリブレートはA/Dの前に行わないと意味がない
後で行うなうなら色調補正と一緒
ストリーム転送はデジタルデータ貰ってるだけなんだから
キャプチャキャリブレートはPC内でできない
訂正
色調補正と=>Aviutlなどのアプリ上で色調補正するのと
色調補正と=>Aviutlなどのアプリ上で色調補正するのと
質問者がDVデッキつかってストリームキャプしてるなんてどこにも書いてないんだが？
ってレス遡ったら書いてたスマン
忘れてくれ
忘れてくれ
罰としてスクワット50回！
なので、わざと質問してみたわけですが。
机上の理論ももちろん重要ですが
皆さんのテレ東受信環境ってどうです？実際。
他のチャンネルと比べて輝度が高くありません？
机上の理論ももちろん重要ですが
皆さんのテレ東受信環境ってどうです？実際。
他のチャンネルと比べて輝度が高くありません？
そうでもない・・・たぶん
GRTやAGCの影響もあるのかもしれないけど
GRTやAGCの影響もあるのかもしれないけど
AviutlのFrameloaderはどうなんでしょ。
ソースをYUV読み込みしたらYUV16-235で中継できるんかな？
それともRGB16-235出力？
ソースをYUV読み込みしたらYUV16-235で中継できるんかな？
それともRGB16-235出力？
>>841
やってみれば？
やってみれば？
>>839>>840
レスポンスありがとうございます
まちまちっぽいですね。ただ、今まで自分の所有した事のある
GRチューナーだとちょっと暗めの画になる感じがするので
それで適度になってるって可能性もあるような。
今使用してるチューナーはGRないんですけど。
833さんと近いと言えば近いですけど、実はUの中継送信
拾って受信してるんで電波は違うかな。
レスポンスありがとうございます
まちまちっぽいですね。ただ、今まで自分の所有した事のある
GRチューナーだとちょっと暗めの画になる感じがするので
それで適度になってるって可能性もあるような。
今使用してるチューナーはGRないんですけど。
833さんと近いと言えば近いですけど、実はUの中継送信
拾って受信してるんで電波は違うかな。
>>843
Uの中継ということはアナアナ変換にひっかかったんでない？
Uの中継ということはアナアナ変換にひっかかったんでない？
俺多摩付近に住んでるけど最近は受信状態が不安定で困る
>>846
受信料払ってるなら、NHKに訴えるとよい。
受信料払ってるなら、NHKに訴えるとよい。
そんなことでいちいち訴えてられるかよ
映らないわけじゃないんだから
映らないわけじゃないんだから
あぁそうかw
NHK" を "じゃなくて
NHK" に "ね
NHK" を "じゃなくて
NHK" に "ね
NHKは受信障害に対応する義務がある
そんな義務いらないから一月の受信料を250円にして欲しい
デジタル放送のタカリテロップうぜぇよ
デジタル放送のタカリテロップうぜぇよ
sage
age
つーかついに存在価値がなくなったのか？
このｽﾚ
このｽﾚ
857 ：名無しさん＠編集中：04/05/02 14:17
DivXやXviDのような16-235の範囲しか扱えないコーデックを使うならTVスケールで。
VP6やWMV9VCMのような0-255迄扱えるコーデックならお好みでいいんじゃね？
VP6やWMV9VCMのような0-255迄扱えるコーデックならお好みでいいんじゃね？
馬鹿がきた
( ´д)ﾋｿ(´д`)ﾋｿ(д` )
全部読んだ挙げ句にあのﾚｽなのかな･･･
全くとんちんかんなこと言ってるんだが、それは無視することにして、
そんなことより間違ったことは言うな。
信じるバカが出るだろが。
＞DivXやXviDのような16-235の範囲しか扱えないコーデック
そんなことより間違ったことは言うな。
信じるバカが出るだろが。
＞DivXやXviDのような16-235の範囲しか扱えないコーデック
まだこのｽﾚには存在意義があることがよーくわかったよ・・・
YUV(16-235・240)ﾃﾞｰﾀは表示される時にRGB(0-255)にﾏｯﾋﾟﾝｸﾞされるのがMS推奨
多くのｱﾌﾟﾘ・再生ｿﾌﾄ・codecもこのような伸張変換をおこなう
つまりYUV(0-16)＆(235・240-255)は真黒＆真白
逆にRGB(0-255)ﾃﾞｰﾀをｿｰｽとすればcodec側はYUV(16-235・240)に再ﾏｯﾌﾟするわけだ
そのためRGBｿｰｽを圧縮変換したYUVには(0-15)＆(236・241-255)のﾃﾞｰﾀが存在しない
ただしYUV>YUVならﾏｯﾋﾟﾝｸﾞは生じないので
YUV(0-255)ｿｰｽでもYUV(0-255)で作れる（ただしﾌﾛﾝﾄｴﾝﾄﾞ内でRGB変換がはいればこの例に違う）
例えば据え置きDivXﾌﾟﾚｲﾔｰはDVDﾌﾟﾚｲﾔｰと同様ｽﾄﾚｰﾄ変換なので
YUV(16-235・240)には(0-15)＆(236・241-255)の諧調は存在しないし真黒・真白だが
YUV(0-255)には(0-15)＆(236・241-255)の諧調が存在するしﾃﾚﾋﾞで確認できる
なおDivX・XviD・VP6・WMV9VCMは全てYUV収納codecなので
上記に準ずる
多くのｱﾌﾟﾘ・再生ｿﾌﾄ・codecもこのような伸張変換をおこなう
つまりYUV(0-16)＆(235・240-255)は真黒＆真白
逆にRGB(0-255)ﾃﾞｰﾀをｿｰｽとすればcodec側はYUV(16-235・240)に再ﾏｯﾌﾟするわけだ
そのためRGBｿｰｽを圧縮変換したYUVには(0-15)＆(236・241-255)のﾃﾞｰﾀが存在しない
ただしYUV>YUVならﾏｯﾋﾟﾝｸﾞは生じないので
YUV(0-255)ｿｰｽでもYUV(0-255)で作れる（ただしﾌﾛﾝﾄｴﾝﾄﾞ内でRGB変換がはいればこの例に違う）
例えば据え置きDivXﾌﾟﾚｲﾔｰはDVDﾌﾟﾚｲﾔｰと同様ｽﾄﾚｰﾄ変換なので
YUV(16-235・240)には(0-15)＆(236・241-255)の諧調は存在しないし真黒・真白だが
YUV(0-255)には(0-15)＆(236・241-255)の諧調が存在するしﾃﾚﾋﾞで確認できる
なおDivX・XviD・VP6・WMV9VCMは全てYUV収納codecなので
上記に準ずる
ややこしいが、YUV(16-235・240)でコーデックに送るのが正解なのか。
PCで再生する場合はグラボまでYUVで逝って、グラボがRGBに変換(この時に伸張)して表示するそうだし。
DivXでもYUV(0-255)ソースからYUV(0-255)で作れるの？
おかしいな・・
PCで再生する場合はグラボまでYUVで逝って、グラボがRGBに変換(この時に伸張)して表示するそうだし。
DivXでもYUV(0-255)ソースからYUV(0-255)で作れるの？
おかしいな・・
そのYUV収納コーデックなんだけど、オーバーレイ再生じゃないと伸長されないみたいで不便です。
色が汚くておかしいなって思ってたりするとなにか起動しっぱなしのウィンドウ忘れてたりするんですよ。
何とかならないでしょうか
色が汚くておかしいなって思ってたりするとなにか起動しっぱなしのウィンドウ忘れてたりするんですよ。
何とかならないでしょうか
>>866
なるよ
ただしYUV入力・処理するようにｱﾌﾟﾘを設定しなければならない
AviutlだとYUV展開やm2v.auiで読み込んでYUV圧縮でcodecに渡す
飽和はoff
Dub系ならfast
TMPGEncやDub系のfullはRGB入力になるので不可
>>867
なんとかもかんとかもおまいがそういう使い方をしてるだけ
本来再生環境と編集環境を一致させるため
ｵｰﾊﾞｰﾚｲ表示とGDI表示は同一になるようにｷｬﾘﾌﾞﾚｰﾄしておくもの
ﾃﾚﾋﾞでもPCでもﾃﾞﾌｫﾙﾄで正しい色味になってるわけではない
勿論環境によってはｷｬﾘﾌﾞﾚｰﾄがまともにできないものもある
IntelVGAとかね
なるよ
ただしYUV入力・処理するようにｱﾌﾟﾘを設定しなければならない
AviutlだとYUV展開やm2v.auiで読み込んでYUV圧縮でcodecに渡す
飽和はoff
Dub系ならfast
TMPGEncやDub系のfullはRGB入力になるので不可
>>867
なんとかもかんとかもおまいがそういう使い方をしてるだけ
本来再生環境と編集環境を一致させるため
ｵｰﾊﾞｰﾚｲ表示とGDI表示は同一になるようにｷｬﾘﾌﾞﾚｰﾄしておくもの
ﾃﾚﾋﾞでもPCでもﾃﾞﾌｫﾙﾄで正しい色味になってるわけではない
勿論環境によってはｷｬﾘﾌﾞﾚｰﾄがまともにできないものもある
IntelVGAとかね
i815EのVGAだと、オーバーレイとGDIの差は判らない程度だよ。
i845以降は傾向が変わったみたいだが。
i845以降は傾向が変わったみたいだが。
>>869
そういや前ｽﾚでもそんな報告あったな
845G以降はしろﾄﾋﾞしまくりでｷｬﾘﾌﾞﾚｰﾄしても諧調が戻らないｽｰﾊﾟｰｺﾝﾄﾗｽﾄになっちったけどね
あと意外とﾗﾃﾞもｷｬﾘﾌﾞﾚｰﾄしづらいね
設定が煮詰めきれない
ﾃﾞﾙﾀｸﾛｰﾑでないかなぁ
雑誌評価はすごかったが＞ｷｬﾘﾌﾞﾚｰﾄ
昔からs3の2D色再現性は高かったんだがな
でないことには
そういや前ｽﾚでもそんな報告あったな
845G以降はしろﾄﾋﾞしまくりでｷｬﾘﾌﾞﾚｰﾄしても諧調が戻らないｽｰﾊﾟｰｺﾝﾄﾗｽﾄになっちったけどね
あと意外とﾗﾃﾞもｷｬﾘﾌﾞﾚｰﾄしづらいね
設定が煮詰めきれない
ﾃﾞﾙﾀｸﾛｰﾑでないかなぁ
雑誌評価はすごかったが＞ｷｬﾘﾌﾞﾚｰﾄ
昔からs3の2D色再現性は高かったんだがな
でないことには
845Gは白が飛ぶだけじゃなくて黒もグレーになっちゃう
買うまで知らなかったからそれに気がついて愕然。
当初考えてなかったグラボ買っちゃったよ
買うまで知らなかったからそれに気がついて愕然。
当初考えてなかったグラボ買っちゃったよ
自作板ではｷｬﾘﾌﾞﾚｰﾄの話題なんかでないし
振ってもﾚｽつかないしね
ｴｿｺ､ｴｿｺばっか書くくせにさ
振ってもﾚｽつかないしね
ｴｿｺ､ｴｿｺばっか書くくせにさ
対抗意識バリバリだな
874 ：名無しさん＠編集中：04/05/11 21:41
このnVIDIAの伸張だけど、最近仕様変わってないすか？
エルザの5900XTカード買って、付属のドライバ入れてXPで使ってるんすけど、
AviUtlで作ったAVIをBSPlayerでオーバーレイ表示時に、
TVスケールのDivXもPCスケールのDivXも、
PCスケールくらいに伸張して表示してるっぽい気がするんすけど。
このTVスケールAVIとPCスケールAVI、
BSPlayerでTVスケールのをオーバーレイ表示させた状態で、
MultiWindowMediaPlayerで両AVIともグラフィック描画で表示させると
明らかに、TVスケールのAVIをグラフィック描画した方はスケール狭くて
オーバーレイ表示の方はPCスケール並に伸張されてるのを確認済みで。
エルザの5900XTカード買って、付属のドライバ入れてXPで使ってるんすけど、
AviUtlで作ったAVIをBSPlayerでオーバーレイ表示時に、
TVスケールのDivXもPCスケールのDivXも、
PCスケールくらいに伸張して表示してるっぽい気がするんすけど。
このTVスケールAVIとPCスケールAVI、
BSPlayerでTVスケールのをオーバーレイ表示させた状態で、
MultiWindowMediaPlayerで両AVIともグラフィック描画で表示させると
明らかに、TVスケールのAVIをグラフィック描画した方はスケール狭くて
オーバーレイ表示の方はPCスケール並に伸張されてるのを確認済みで。
>>874
言ってることがよくわからない
AVIｺﾝﾃﾅにはｽｹｰﾙ情報が埋め込めないから
>TVスケールのDivXもPCスケールのDivXも、
>PCスケールくらいに伸張して表示してるっぽい気がする
つーのはなに？
PCｽｹｰﾙAVIがｼﾛﾄﾋﾞしたってこと？
後半もいまいちつかめないんだが
PCｽｹｰﾙAVI-GDIとTVｽｹｰﾙAVI-ｵｰﾊﾞｰﾚｲが同等になったっていってるのかな？
だとしたら直ってるかもね
そもそもﾊｰﾄﾞｳｪｱﾚﾍﾞﾙ・ﾄﾞﾗｲﾊﾞﾚﾍﾞﾙの問題ではなくﾃﾞﾌｫﾙﾄ設定の問題であって
設定いじればATiﾚﾍﾞﾙにまで修正できてたわけだし
言ってることがよくわからない
AVIｺﾝﾃﾅにはｽｹｰﾙ情報が埋め込めないから
>TVスケールのDivXもPCスケールのDivXも、
>PCスケールくらいに伸張して表示してるっぽい気がする
つーのはなに？
PCｽｹｰﾙAVIがｼﾛﾄﾋﾞしたってこと？
後半もいまいちつかめないんだが
PCｽｹｰﾙAVI-GDIとTVｽｹｰﾙAVI-ｵｰﾊﾞｰﾚｲが同等になったっていってるのかな？
だとしたら直ってるかもね
そもそもﾊｰﾄﾞｳｪｱﾚﾍﾞﾙ・ﾄﾞﾗｲﾊﾞﾚﾍﾞﾙの問題ではなくﾃﾞﾌｫﾙﾄ設定の問題であって
設定いじればATiﾚﾍﾞﾙにまで修正できてたわけだし
○゛んってフランクな書き方をすることにポリシーを持ってるらしいが
はっきり言って、文章にまとまりがなくて読みづらい。
フランクか？
新英和中辞典 第６版 （研究社）
frank1 /frk/→
(〜･er，〜･est; more 〜，most 〜)
1 率直な，腹蔵のない 《★【類語】 frank は人･意見･態度などが率直で
遠慮や隠しだてをせずに本心を打ち明ける; outspoken は無遠慮なほどに
ずけずけしている; open は公然として率直な》.→
2 +with+(代)名〔人に対して〕隠しだてをしないで.→
→to be frnk with you
〈手紙などを〉無料送達にする，無料で送る; 〈手紙の〉封筒に無料送達の印を押す.
1 無料送達の印[署名] 《★昔，英国では貴族･国会議員などは書面の表に署名して
無料で送ることができた》.
2 無料送達郵便物.
(古期)フランス語｢フランク族の，自由な｣の意; フランク族 (Franks) がガリア地方
における自由民であったことから
新英和中辞典 第６版 （研究社）
frank1 /frk/→
(〜･er，〜･est; more 〜，most 〜)
1 率直な，腹蔵のない 《★【類語】 frank は人･意見･態度などが率直で
遠慮や隠しだてをせずに本心を打ち明ける; outspoken は無遠慮なほどに
ずけずけしている; open は公然として率直な》.→
2 +with+(代)名〔人に対して〕隠しだてをしないで.→
→to be frnk with you
〈手紙などを〉無料送達にする，無料で送る; 〈手紙の〉封筒に無料送達の印を押す.
1 無料送達の印[署名] 《★昔，英国では貴族･国会議員などは書面の表に署名して
無料で送ることができた》.
2 無料送達郵便物.
(古期)フランス語｢フランク族の，自由な｣の意; フランク族 (Franks) がガリア地方
における自由民であったことから
だれもGeforce使ってないの？
こんだけユーザーがいれば上の書き込みが正しいかどうかすぐ分かるでしょ。
こんだけユーザーがいれば上の書き込みが正しいかどうかすぐ分かるでしょ。
間違ってます
>>878
nVIDIAは伝統的に2D動画がうまくない。
伸張問題以外に、アナログ接続時の色滲み
Bobデコード不良、高解像度MPEGコマオチなど。
静止画の場合は中域強調による諧調破壊
それに伴うフィルタ設定の難しさ。
つまりDTVには向かない。
ユーザーが多いのはゲーマーが多いってだけのこと。
ここはゲーム板じゃない。
nVIDIAは伝統的に2D動画がうまくない。
伸張問題以外に、アナログ接続時の色滲み
Bobデコード不良、高解像度MPEGコマオチなど。
静止画の場合は中域強調による諧調破壊
それに伴うフィルタ設定の難しさ。
つまりDTVには向かない。
ユーザーが多いのはゲーマーが多いってだけのこと。
ここはゲーム板じゃない。
あにぺぐ界の大御所であるぢんさんもGeforceFXを使ってらっしゃいますが、なにか？
ぢんは古参であって大御所じゃないでしょ。
それ以前に茂木や堀やGNBがGeforceを使っても
Geforceが2D動画に不向きであることは変わらないし
その分野に不向きなものをえんえんと自分の趣味に使うのはどうか？と思う。
「ゲームもやるから」というなら止めないが、
DTVに特化したマシンなら×でしょ。
特にここは色スレ。
この板でも無駄に色にこだわるような連中が集まってる。
連中とは言っても数人だ。
そこで「ユーザーが多い」というのはどうか？
実験方法晒して質問スレで回答集めたほうがよくない？
でも、まDX9になったらどうなるかわからないね。
それ以前にデルタクロームが欲しいんだが・・・。
それ以前に茂木や堀やGNBがGeforceを使っても
Geforceが2D動画に不向きであることは変わらないし
その分野に不向きなものをえんえんと自分の趣味に使うのはどうか？と思う。
「ゲームもやるから」というなら止めないが、
DTVに特化したマシンなら×でしょ。
特にここは色スレ。
この板でも無駄に色にこだわるような連中が集まってる。
連中とは言っても数人だ。
そこで「ユーザーが多い」というのはどうか？
実験方法晒して質問スレで回答集めたほうがよくない？
でも、まDX9になったらどうなるかわからないね。
それ以前にデルタクロームが欲しいんだが・・・。
煽っててもしょうがないので実験。
Geforce 2 MX 400引っ張り出してきた。
伸張問題はハードウェア問題じゃないはずだし、
ドライバはGeforce系は共通だからいいでしょ。
ドライバはLatestの56.72(XP/2000)。
念のためデフォルト設定にしてから。
･････････・・・・・・・・・・・・・・・
あぁ！変わってるね。
ブライトネス・コントラスト100・ヒュー0は兎も角サチュレイション114・・・。
うーん、以前のデフォルトブライトネス90よりはいいけど・・・。
やはりブライトネス120 コントラスト100 ヒュー0 サチュレイション100くらいのがよくないか？
Geforce 2 MX 400引っ張り出してきた。
伸張問題はハードウェア問題じゃないはずだし、
ドライバはGeforce系は共通だからいいでしょ。
ドライバはLatestの56.72(XP/2000)。
念のためデフォルト設定にしてから。
･････････・・・・・・・・・・・・・・・
あぁ！変わってるね。
ブライトネス・コントラスト100・ヒュー0は兎も角サチュレイション114・・・。
うーん、以前のデフォルトブライトネス90よりはいいけど・・・。
やはりブライトネス120 コントラスト100 ヒュー0 サチュレイション100くらいのがよくないか？
>>883
経験的に
ブライトネス120
コントラスト107
ヒュー0
サチュレーション100
で使ってる。とりあえず-5%が識別できないように調整してみた。
某ソフトでオーバーレイと非オーバーレイの体感差が気にならない程度。
経験的に
ブライトネス120
コントラスト107
ヒュー0
サチュレーション100
で使ってる。とりあえず-5%が識別できないように調整してみた。
某ソフトでオーバーレイと非オーバーレイの体感差が気にならない程度。
GeforceTi4200以降のｎVIDIAのオーバーレイは超クソ
ならVMR9使えよ アホが。
VMR9もnVIDIAだとYUVを伸張しないから色薄くて超クソ
>>888
オーバーレイ調整すればいいじゃん。＜YUV伸張
オーバーレイ調整すればいいじゃん。＜YUV伸張
まあVMR9とオーバーレイは別物なんだけどな。
>>889
(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?
VMR9ってなあに？
Microsoft、Windows Media Player 10のテクニカルベータを公開
>アスペクト比の設定機能や、色空間や黒レベル設定も追加されている。
http://www.watch.impress.co.jp/av/docs/20040603/ms.htm
>アスペクト比の設定機能や、色空間や黒レベル設定も追加されている。
http://www.watch.impress.co.jp/av/docs/20040603/ms.htm
>Windows Media Player 10 is only available for
>Windows XP
shine
>Windows XP
shine
>>894
輝け！
輝け！
896 ：名無しさん＠編集中：04/06/17 09:13
保守です。
/|
|/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
/|
|/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
_, ,_ パーン
（ ゜д゜）
⊂彡☆＝＝＝＝＝＝ /|
＿＿ |/
ヽ| l l│
┷┷┷
（ ゜д゜）
⊂彡☆＝＝＝＝＝＝ /|
＿＿ |/
ヽ| l l│
┷┷┷
898 ：名無しさん＠編集中：04/06/22 10:57
/|
|/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
|/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
_, ,_ パーン
（ ゜д゜）
⊂彡☆＝＝＝＝＝＝ /|
＿＿ |/
（ ゜д゜）
⊂彡☆＝＝＝＝＝＝ /|
＿＿ |/
＿＿_ _＿＿ ＿＿_
| ９ | | ０ | | ０ |
￣|￣ミ ￣|￣ミ ￣|￣ミ
∧∧∩ ∧∧∩ ∧∧∩
( ﾟДﾟ)ﾉ ( ﾟДﾟ)ﾉ ( ﾟДﾟ)ﾉ
.| | | | | |
￣￣￣￣￣￣￣￣￣￣￣￣＼
￣￣￣￣￣￣￣￣￣￣￣￣￣|
| ９ | | ０ | | ０ |
￣|￣ミ ￣|￣ミ ￣|￣ミ
∧∧∩ ∧∧∩ ∧∧∩
( ﾟДﾟ)ﾉ ( ﾟДﾟ)ﾉ ( ﾟДﾟ)ﾉ
.| | | | | |
￣￣￣￣￣￣￣￣￣￣￣￣＼
￣￣￣￣￣￣￣￣￣￣￣￣￣|
901 ：名無しさん＠編集中：04/07/01 16:38
人
（＿_）
（＿＿）
/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
（＿_）
（＿＿）
/＿＿
ヽ| l l│＜ﾊｰｲ
┷┷┷
_, ,_ …
（ ゜д゜）∩ 人
ﾉﾉ （＿_）
（＿＿）
（ ゜д゜）∩ 人
ﾉﾉ （＿_）
（＿＿）
903 ：名無しさん＠編集中：04/07/02 13:54
Y＜16、235＜Yを持つデータは不法かどうか
YCbCr（16-235）をStudio RGB(ここで言うTVスケール RGB16-235)にマッピングするのが良いのか
PC RGB（PCスケール）にするのが良いかなどなど
http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=416292&perpage=20&pagenumber=1
で、面白いのはMSのDirectShowチームの人間がいて、彼らが言うには
MSでは一年前からYCbCr（16-235）をstudio RGBに変換する方針に切り替えたらしい。（MCE2004の絡み？）
そしてATIやNVIDIAらのドライバーもすでにそのように作られていること。
実際 RADEON9600で"非オーバーレイ"のVMRで再生するとそうなる。
ただしハードウェアオーバーレイが使われる場合は味付けされた状態がデフォになってるけど。
YCbCr（16-235）をStudio RGB(ここで言うTVスケール RGB16-235)にマッピングするのが良いのか
PC RGB（PCスケール）にするのが良いかなどなど
http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=416292&perpage=20&pagenumber=1
で、面白いのはMSのDirectShowチームの人間がいて、彼らが言うには
MSでは一年前からYCbCr（16-235）をstudio RGBに変換する方針に切り替えたらしい。（MCE2004の絡み？）
そしてATIやNVIDIAらのドライバーもすでにそのように作られていること。
実際 RADEON9600で"非オーバーレイ"のVMRで再生するとそうなる。
ただしハードウェアオーバーレイが使われる場合は味付けされた状態がデフォになってるけど。
MPEG2VFAPIの段階でYC分離するのとaviutlやvdmで分離するのでは
どっちのほうが画質いいでしょうか？
すべきではないような気がして今までストレート変換で編集してきました。
（わからないので元データに忠実に、と思って。）
また、この先の技術的なギミックを見た場合分離すべきなのか
分離しない方がいいのか語っていただけませんか？
どっちのほうが画質いいでしょうか？
すべきではないような気がして今までストレート変換で編集してきました。
（わからないので元データに忠実に、と思って。）
また、この先の技術的なギミックを見た場合分離すべきなのか
分離しない方がいいのか語っていただけませんか？
YC分離が何のことなのか全く理解できてないようなので
もう一度しっかり調べなさい
もう一度しっかり調べなさい
>>904
YC分離じゃなくてYC伸張のことなら
AviutlのYC伸張フィルタ（ルジ作）が最強
”伸張すべきなのか
伸張しない方がいいのか語っていただけませんか？”
前スレでさんざん語ったので・・・
でも前スレ読めないんだよね？
じゃとりあえず↓読んどけ
http://www.marumo.ne.jp/bt601/
尚前スレでは「伸張もストレートもないYUVはずっとYUVで処理しよう」
というのが結論ぽかった
YC分離じゃなくてYC伸張のことなら
AviutlのYC伸張フィルタ（ルジ作）が最強
”伸張すべきなのか
伸張しない方がいいのか語っていただけませんか？”
前スレでさんざん語ったので・・・
でも前スレ読めないんだよね？
じゃとりあえず↓読んどけ
http://www.marumo.ne.jp/bt601/
尚前スレでは「伸張もストレートもないYUVはずっとYUVで処理しよう」
というのが結論ぽかった
機械的に伸張するなら拡張色調補正でも良いと思うがぁ
YUVのままが吉
VFAPI(ﾟ⊿ﾟ)
VFAPI(ﾟ⊿ﾟ)
910 ：名無しさん＠編集中：04/07/21 02:10
VFAPIのYUV対応って無いのかなぁ
微妙な流れだな
913 ：名無しさん＠編集中：04/07/21 15:01
>>911
それはvfpじゃなくてauiじゃん
それはvfpじゃなくてauiじゃん
YUY2ってなんで横の幅が4の倍数じゃないといけないの？2の倍数ならわかるけど。
>>915
あーなるほど、そういうことなのか。ありがとう。いやAvisynthで怒られちゃってさ。
あーなるほど、そういうことなのか。ありがとう。いやAvisynthで怒られちゃってさ。
AviUtl総合スレッド25
http://pc5.2ch.net/test/read.cgi/software/1087188341/490-560
きっとおかしな質問者がやってくるな
暇だったから楽しみだ
ぶっちゃけI845Gのオーバ－レイとか
ハードウェアアクセレーションしてるWinDVDとかは
素でsRGB出力なわけだが
http://pc5.2ch.net/test/read.cgi/software/1087188341/490-560
きっとおかしな質問者がやってくるな
暇だったから楽しみだ
ぶっちゃけI845Gのオーバ－レイとか
ハードウェアアクセレーションしてるWinDVDとかは
素でsRGB出力なわけだが
そういえば色空間はともかく色域を意識したことはなかったな
919 ：名無しさん＠編集中：04/07/27 15:37
これAvisynth版ないの？
これってどれ？
いらん
923 ：名無しさん＠編集中：04/07/28 00:31
なんか色の変換間違ってね？
妙に度ぎつくなる
妙に度ぎつくなる
ディスプレイがおかしい
なんの話してるんだよ
926 ：691：04/07/28 19:53
>>923
DTPに詳しい人には、Photoshopなどのカラープロファイル変換と
比較して精度に不満があるかもしれません。
飽和色の処理や計算精度を向上したバージョンをアップしましたので、
可能でしたら試用してみてください。
DTPに詳しい人には、Photoshopなどのカラープロファイル変換と
比較して精度に不満があるかもしれません。
飽和色の処理や計算精度を向上したバージョンをアップしましたので、
可能でしたら試用してみてください。
927 ：名無しさん＠編集中：04/07/29 19:45
DVDソース → DivXの場合、「YUY2変換時に～飽和」にチェック入れたほうがいいですか？
>>76-80見ると、チェックを入れた場合、中間ファイルのサイズが小さくなる（つまりエンコード時間が短くなる？）
と書いてあるんですが、DVDソースの場合も同様なことが言えるのでしょうか？
「YUY2変換時に～飽和」にチェック入れた場合、入れない場合のメリット、デメリットについてお聞かせ下さい。
>>76-80見ると、チェックを入れた場合、中間ファイルのサイズが小さくなる（つまりエンコード時間が短くなる？）
と書いてあるんですが、DVDソースの場合も同様なことが言えるのでしょうか？
「YUY2変換時に～飽和」にチェック入れた場合、入れない場合のメリット、デメリットについてお聞かせ下さい。
>>929
DVDソースの場合はITU-R BT.601の範囲内に既定されているわけですから、
AviUtl 0.99 へ"YUY2で展開"及び"YUY2で圧縮"にチェックを入れて読み込めば、
その後の処理として「YUY2変換時に～飽和」にチェック入れたほうが良いという事でしょうか？
DVDソースの場合はITU-R BT.601の範囲内に既定されているわけですから、
AviUtl 0.99 へ"YUY2で展開"及び"YUY2で圧縮"にチェックを入れて読み込めば、
その後の処理として「YUY2変換時に～飽和」にチェック入れたほうが良いという事でしょうか？
931 ：名無しさん＠編集中：04/07/29 22:16
>>930
飽和するくらいならRGB出力した方がいい
飽和するくらいならRGB出力した方がいい
932 ：名無しさん＠編集中：04/07/29 22:59
>>930
ITU-R BT.601の範囲内に収まっているなら、結果として飽和させてもさせなくても同じ。
ただ、「YUY2変換時に～飽和」にチェックを入れることにより内部処理がYUY2で行われるため、精度が上がり、かつエンコ時間が短くなる。
したがって、ITU-R BT.601の範囲内に収まっているソースなら、「YUY2変換時に～飽和」にチェックを入れたほうがよい。
ITU-R BT.601の範囲内に収まっているなら、結果として飽和させてもさせなくても同じ。
ただ、「YUY2変換時に～飽和」にチェックを入れることにより内部処理がYUY2で行われるため、精度が上がり、かつエンコ時間が短くなる。
したがって、ITU-R BT.601の範囲内に収まっているソースなら、「YUY2変換時に～飽和」にチェックを入れたほうがよい。
>>932
YUY2モードと「YUY2変換時に～飽和」は無関係だよ
「YUY2変換時に～飽和」は「YUY2圧縮」を指定したCODECに有効なだけで
デフォルトモードであるYUV48モードでも「YUY2変換時に～飽和」は有効
勿論「YUY2展開・圧縮」とYUY2モードも無関係
YUY2モードと「YUY2変換時に～飽和」は無関係だよ
「YUY2変換時に～飽和」は「YUY2圧縮」を指定したCODECに有効なだけで
デフォルトモードであるYUV48モードでも「YUY2変換時に～飽和」は有効
勿論「YUY2展開・圧縮」とYUY2モードも無関係
>>930
”DVDソースの場合はITU-R BT.601の範囲内に既定されている”
んだが”ITU-R BT.601の範囲”と”ITU-R BT.601の有効範囲”は違う
実際”ITU-R BT.601の有効範囲”を逸脱する市販DVDはいくらでもある
ﾓｰｦﾀはそんなのたくさん持ってるw
”DVDソースの場合はITU-R BT.601の範囲内に既定されている”
んだが”ITU-R BT.601の範囲”と”ITU-R BT.601の有効範囲”は違う
実際”ITU-R BT.601の有効範囲”を逸脱する市販DVDはいくらでもある
ﾓｰｦﾀはそんなのたくさん持ってるw
何故ここはいつまでたっても結論が出ないのでしょうか？
>>931-937
レスありがとう御座います。
何だか情報が錯綜しているようですが、、
結局、DVDソース → DivX の場合は、
「YUY2変換時に～飽和」にチェックを入れないということでファイナルアンサーでしょうか？
レスありがとう御座います。
何だか情報が錯綜しているようですが、、
結局、DVDソース → DivX の場合は、
「YUY2変換時に～飽和」にチェックを入れないということでファイナルアンサーでしょうか？
テレビも売り物もちゃんと有効範囲内で作ってくれりゃあ解決なんだが
色なんて非常に単純なことなんだけどね
いろんな表現があるから混乱を招くだけで・・・
使うソフトも３つぐらいに限られてるわけだし
だからまとめようと思えば割と簡潔にまとまると思う
解説ページへのリンクとかも併用すればさ
誰か暇な人次スレに行く前になんとかしてくれんかなぁ
いろんな表現があるから混乱を招くだけで・・・
使うソフトも３つぐらいに限られてるわけだし
だからまとめようと思えば割と簡潔にまとまると思う
解説ページへのリンクとかも併用すればさ
誰か暇な人次スレに行く前になんとかしてくれんかなぁ
942 ：名無しさん＠編集中：04/07/29 23:57
色が簡単だと思う奴はただの無知
>>939
なるほど、ソースがBT.601有効範囲内にデータが収まっているなら「YUY2変換時に～飽和」にチェックということですね。
ただ、>>934さんが仰るには“実際”ITU-R BT.601の有効範囲”を逸脱する市販DVDはいくらでもある”ということなので、
基本はチェックを入れないほうが良さそうですね。
色々と勉強になりました！ありがとうございました。
なるほど、ソースがBT.601有効範囲内にデータが収まっているなら「YUY2変換時に～飽和」にチェックということですね。
ただ、>>934さんが仰るには“実際”ITU-R BT.601の有効範囲”を逸脱する市販DVDはいくらでもある”ということなので、
基本はチェックを入れないほうが良さそうですね。
色々と勉強になりました！ありがとうございました。
>>942
・・・悪いが俺はそれほど無知でもないんで
・・・悪いが俺はそれほど無知でもないんで
>>942
こういうﾔｼが混乱させている。
こういうﾔｼが混乱させている。
無知な人間は自分が無知だということを知らない。
鞭鞭
YUY2変換時に～飽和 は何してるの？
949 ：名無しさん＠編集中：04/07/30 01:39
>>948
YUY2変換時にY16:-235,UV:16-240の範囲に飽和
YUY2へ変換する時
Y=0-15を16、Y=236-255を235
U,V=0-15を16、U,V=241-255を240
に丸める
YUY2変換時にY16:-235,UV:16-240の範囲に飽和
YUY2へ変換する時
Y=0-15を16、Y=236-255を235
U,V=0-15を16、U,V=241-255を240
に丸める
951 ：691：04/07/30 08:06
解説ページへのリンクを置いておきます
Video Rendering with 8-Bit YUV Formats (英語) (YUV)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
sRGB (英語) (sRGB)
http://www.w3.org/Graphics/Color/sRGB
sRGB を使用した色空間の交換 (sRGB)
http://www.microsoft.com/japan/hwdev/tech/color/sRGB.asp
NTSC Tutorials - 6. Color Encoding (英語) (YIQ)
http://www.ntsc-tv.com/ntsc-index-06.htm
JPG Specification (英語) (YCbCr)
http://ioc.unesco.org/oceanteacher/resourcekit/M3/Formats/Integrated/JPG/JpegJfifSpec.htm
Specification of sYCC. (英語) (sYCC)
http://www.color.org/sycc.pdf
色色雑学
http://konicaminolta.jp/entertainment/colorknowledge/index.html
EasyRGB (英語)
http://www.easyrgb.com/index.html
efg's Computer Lab (英語)
http://homepages.borland.com/efg2lab/
前はAll about colorって日本語のページがあったんですけど見当たらないですね
Video Rendering with 8-Bit YUV Formats (英語) (YUV)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
sRGB (英語) (sRGB)
http://www.w3.org/Graphics/Color/sRGB
sRGB を使用した色空間の交換 (sRGB)
http://www.microsoft.com/japan/hwdev/tech/color/sRGB.asp
NTSC Tutorials - 6. Color Encoding (英語) (YIQ)
http://www.ntsc-tv.com/ntsc-index-06.htm
JPG Specification (英語) (YCbCr)
http://ioc.unesco.org/oceanteacher/resourcekit/M3/Formats/Integrated/JPG/JpegJfifSpec.htm
Specification of sYCC. (英語) (sYCC)
http://www.color.org/sycc.pdf
色色雑学
http://konicaminolta.jp/entertainment/colorknowledge/index.html
EasyRGB (英語)
http://www.easyrgb.com/index.html
efg's Computer Lab (英語)
http://homepages.borland.com/efg2lab/
前はAll about colorって日本語のページがあったんですけど見当たらないですね
とりあえず、ずっとYUVで処理すれば問題ないわけですよね？
あとコーデックからRGBに変換して渡されるときはストレートか伸張されるか注意するくらいですか？
あとコーデックからRGBに変換して渡されるときはストレートか伸張されるか注意するくらいですか？
953 ：名無しさん＠編集中：04/07/30 15:43
YUY2変換時に～飽和 はどこにあるのよ？
955 ：691：04/07/30 19:08
>>954
YUY2フォーマットの定義は最初のリンクを参照ください
>Video Rendering with 8-Bit YUV Formats (英語) (YUV)
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
YUY2フォーマットの定義は最初のリンクを参照ください
>Video Rendering with 8-Bit YUV Formats (英語) (YUV)
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
TV出力用とPC出力用に分けて出力します。
ttp://sundaycap.ddo.jp:8025/users/marbo_y/Benkyou/GunslingerGirl06/GunslingerGirl06.html
ttp://sundaycap.ddo.jp:8025/users/marbo_y/Benkyou/GunslingerGirl06/GunslingerGirl06.html
961 ：名無しさん＠編集中：04/08/02 15:54
しかもAviUtl99なんてバグだらけなもの使ってるやつは色のことわかってないんだろうな
わかってたら９９以外使えないじゃん？
>>961
それは使いようだからなんともいえん
でもVFAPI経由だから顕在化しないんじゃない？
RGB入力>YUY2出力でしょう・・・多分
なんかYUY2圧縮してるのかしてないのかよくわからないけど
画像を見る限りでは・・・
24fps化の誤爆はｲﾝﾀﾚ解除2でつぶしまくったんでしょう
それは使いようだからなんともいえん
でもVFAPI経由だから顕在化しないんじゃない？
RGB入力>YUY2出力でしょう・・・多分
なんかYUY2圧縮してるのかしてないのかよくわからないけど
画像を見る限りでは・・・
24fps化の誤爆はｲﾝﾀﾚ解除2でつぶしまくったんでしょう
いやいやわかってたらAviutlでRGB化なんかしないでしょ
ずっとYUVで処理する
がベターって事でいいんだよね？
がベターって事でいいんだよね？
>>967
個人的にはﾍﾞﾀｰどころかﾍﾞｽﾄだと思う
個人的にはﾍﾞﾀｰどころかﾍﾞｽﾄだと思う
ベストかどうかはどういう処理をしたいのかにもよるだろうけどな
959は
DVD2AVIじゃなくて茂木プラグインを使えば
RGB化しなくて済むのにね。
DVD2AVIじゃなくて茂木プラグインを使えば
RGB化しなくて済むのにね。
どっちにしろTMPGEncに突っ込んじゃうなら
ずっとYUVというわけにもいかない
ずっとYUVというわけにもいかない
でもAviUtlでTV用PC用に分ける必要はなくなるわな。
そうか・・・
こいつ中間ファイル二本作るのか
こいつ中間ファイル二本作るのか
dubでfastが最強
515 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：04/08/09 20:39 ID:Xdb6WHbI
再生時に、YM伸張などしてくれるplayer無いでしょうか？
PCで見ることを前提に作られた動画をTVに写すと、白飛びしてしまいます。
よく分からないのですが、YM伸張された動画を元に戻しながら再生してくれるようなのありませんかね。
523 名前：515[sage] 投稿日：04/08/10 00:19 ID:F1nTdlNa
色合い、明るさ、コントラスト、鮮やかさ
とありますけど、少し違うようです。
PC用にYC伸張すると、16～235だったかを、0～255にするんですよね。
で、この0～255になった動画をTVに映すと、0～16の部分が白に、
235～250の部分が黒になってしまって、白飛び、黒つぶれした動画になってしまうんです。
で、この0～255になった動画を元の16～235にしながら再生してくれる、player無いかなと思ったわけです。
ビデオカードの設定も見たんですがそれらしいのが無くて困っています。
動画作成時にYC伸張しなければ良いのですが、G550のDVDMAX出力からRGB-YPbPrのD1出力に変えた時に
RGB-YPbPrが、ストレートでTVに出力してしまうので、DVDMAXで普通に見れていた動画が白飛びしてしまうんです。
ソースがもう無いので、作り直すわけにもいかないので、再生時に何とかできないもんかなと思ったわけです。
再生時に、YM伸張などしてくれるplayer無いでしょうか？
PCで見ることを前提に作られた動画をTVに写すと、白飛びしてしまいます。
よく分からないのですが、YM伸張された動画を元に戻しながら再生してくれるようなのありませんかね。
523 名前：515[sage] 投稿日：04/08/10 00:19 ID:F1nTdlNa
色合い、明るさ、コントラスト、鮮やかさ
とありますけど、少し違うようです。
PC用にYC伸張すると、16～235だったかを、0～255にするんですよね。
で、この0～255になった動画をTVに映すと、0～16の部分が白に、
235～250の部分が黒になってしまって、白飛び、黒つぶれした動画になってしまうんです。
で、この0～255になった動画を元の16～235にしながら再生してくれる、player無いかなと思ったわけです。
ビデオカードの設定も見たんですがそれらしいのが無くて困っています。
動画作成時にYC伸張しなければ良いのですが、G550のDVDMAX出力からRGB-YPbPrのD1出力に変えた時に
RGB-YPbPrが、ストレートでTVに出力してしまうので、DVDMAXで普通に見れていた動画が白飛びしてしまうんです。
ソースがもう無いので、作り直すわけにもいかないので、再生時に何とかできないもんかなと思ったわけです。
976 ：名無しさん＠編集中：04/08/10 18:55
>>975
ffdshowでリアルタイムにレベル補正かける
ffdshowでリアルタイムにレベル補正かける
最近はモニタにファインピクチャとか付いてるから
無理に伸長しなくてもいいかもね
無理に伸長しなくてもいいかもね
映像のエロ総合すれの割には伸びないな
エロ画像の総合スレだったら伸びたかもね
>>1
（TДT；≡；TдT）もうワケワカンネ
（TДT；≡；TдT）もうワケワカンネ
保守
保守