5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

映像の【色】総合スレ

1 :クルップー:03/08/29 18:22
前スレ
YC伸張する?しない?総合スレッド
http://pc.2ch.net/test/read.cgi/avi/1050299614/

2 :名無しさん@編集中:03/08/29 18:23
>>1


3 :名無し募集中。。。:03/08/29 18:23
クルップー

4 :名無しさん@編集中:03/08/29 18:26
>>1
手抜き

5 :名無しさん@編集中:03/08/29 18:26
ここでいいのかな?
もう一度聞きなおしますが、
映像制作時に15以下があった場合は放送時に切られるってこと?
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
そういうことですか?

6 :名無しさん@編集中:03/08/29 18:31
MPEG2を再生するときに、明るい部分が黒く再生されてしまうんですが、
これって伸張に間違いがあるということでしょうか?

と前スレに書いた者です。
書き忘れましたが、コーデックをNECのものからサイバーリンクのものに変えたらおきました。

>>前スレで答えてくれた方

故障って、それもふざけてますか?
真面目にお願いできないものでしょうか。

7 :名無しさん@編集中:03/08/29 18:33
ちなみに、全部のMPEG2がそうなるわけではありません。

8 :名無しさん@編集中:03/08/29 18:34
というかさぁ、おまい、ちゃんと状況書けよ。
テレビで見てんのか?パソモニ。?プロジェクタぁ?
状況詳しくわかんないと書けんだろが。

9 :名無しさん@編集中:03/08/29 18:42
すいません。
パソコンの画面です。
自分でエンコードしたMPEG2では起こらず、拾ったMPEG2では起きます。
MPEG1とAVIでは起きません。
謎なんです。

10 :名無しさん@編集中:03/08/29 18:45
一言「黒」といったってなぁ・・・・・
何IREくらい?

11 :名無しさん@編集中:03/08/29 18:45
なんと言うか…。
画面の所々に黒い穴が開いたような…

□=明るい部分の1ドット
■=黒くなってしまってる部分の1ドット

□□□□□□□□□□□□
□□□■□□■■□□□□
□□□□□■■□□□□□
□□□□□□□□□□□□
□□□■□□□□□□□□
□□□□□□□□□□□□
□□■□■□□□□□□□
□□□□□□□□□□□□


12 :名無しさん@編集中:03/08/29 18:46
何IREなのかはわからないんです。
IRE自体がわかりませんし。

13 :名無しさん@編集中:03/08/29 18:48
暗くなってるの?それとも真っ黒になってるの?

14 :名無しさん@編集中:03/08/29 18:49
みんな好きだなぁ。

>009
単に 235 以上の pel が伸張の結果オーバーフローして 0 とか 1 とかになっ
てるんじゃないの?
サイバーリンクに変えてからなったていうのなら、サイバーリンク捨てて元に
もどせばいいだけじゃん。

15 :名無しさん@編集中:03/08/29 18:56
>>13
真っ黒です。

>>14
戻したくないんです。
NECのではMPEG2の60fps再生が出来ないので…。

それと、伸張がおかしいのが原因かどうかさえわかればいいんです。
おかしかったら戻すように再エンコするので。

もっとはっきり言うと、伸張がおかしいかどうかが自分ではわからないので、
その現象が起きるか起きないかで判断できたらいいと思ってるんです。


16 :名無しさん@編集中:03/08/29 19:01
オーバーロードしても真っ黒にはならんだろうから、
例えばY=255とか平気で記録しちゃってるMPEGかもしれない。
要するにネットに乗っけた奴のエンコがタコ。
ところでその真っ黒の領域って四角形でいいのかな?
不定形だと話も変わってくるんだが

17 :名無しさん@編集中:03/08/29 19:07
デジタル化(キャプチャ)したものに対して、何IREとか無意味なこと問うな。
IREはアナログ信号の単位だ。(Vp-pが何mVかってことなのでデジタルにとって意味なし)

18 :>>17:03/08/29 19:12
くだらんことをいちいち知ったかぶりして解説して得意になってるヴァカハケーン
まー、中学生にしちゃ、IREを知ってるのは優等生かな?
明るいだの暗いだの言っても日本語じゃ3段階くらいにしか表現で禁から、
アナログだとどのくらいの明るさか、という意味で問うたまで。
べつにデジタルの量子化何段階目?と聞いてもよいが、
イパーン的ではないからな。
ま、おまいのような奴シロートはすっこんどれ。

19 :名無しさん@編集中:03/08/29 19:30
>>16
四角は四角なんですが、16×16ドットくらいの■ではなく、1ドットの■なんです。
こんな感じで明るい部分にポツポツと。

←       704        →
---------------------------- ↑
l                    l
l      ,    ;          l
l     :.   ,            l
l    ; .^  ;            l
l     ,               l 480
l                    l
l                    l
l                    l ↓
----------------------------

>要するにネットに乗っけた奴のエンコがタコ。

かもしれません。2コマ進んで1コマ戻るような再生でしたし。

20 :名無しさん@編集中:03/08/29 19:37
IREも量子化段階と同じくらいイパーン的ではないわな

21 :名無しさん@編集中:03/08/29 20:08
>>19
ドット単位ということなら、やはりY=255を許しちゃってるコーデックのような・・・・
エラー防止のために255→1とかに変換してるのかも知れん。
コーデックが糞と言うよりも、コーデック前のAVIが腐っとる可能性があるな。
Premiereを使い、「色の置き換え」でRGB=1,1,1→RGB=254,254,254などとして最エンコすると言うのはどうだろ?


22 :悲しい奴・・・:03/08/29 20:10
20⇒負け犬の遠吠え・・・・・

23 :名無しさん@編集中:03/08/29 20:32
じゃあ下が3IREだったらどうだってんだよ。
キャプチャしたら、これが0になっらたり30になったりするじゃんか。
意味あるの?

24 :↑↑↑↑↑:03/08/29 20:36
?????????

25 :名無しさん@編集中:03/08/29 20:37
その前に、スペアナとか持ってる奴じゃないと信号なんて測れない。
キャプしてる奴に、何IREって聞くのは何の意図があるのか?

26 :↑↑↑↑↑:03/08/29 20:39
粘着君?粘着君?粘着君?

27 :名無しさん@編集中:03/08/29 20:54
>>18
いいかげん、自分の非を認めたら?

28 :名無しさん@編集中:03/08/29 21:40
あの・・・誰か>>5に答えてくれません?

29 :名無しさん@編集中:03/08/29 21:56
相変わらず此処は混沌としているな

30 :名無しさん@編集中:03/08/29 22:08
>>21
そうですか…。
くどいようですが、エンコード時に伸張されてしまってるということでしょうか?
普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね?
変なこと言ってたらすいません。

31 :名無しさん@編集中:03/08/29 22:24
>>30
サチュレート派や伸張派はそうする。
アンチサチュレート派やストレート派の多くはしない。

32 :名無しさん@編集中:03/08/29 22:36
>>30
>普通はエンコード時に235に収まるようにして、再生時に伸張で255にするんですよね?

それが多い。というか再生時に YUV オーバーレイで勝手に伸張される(nVidia 以外では)

30 の場合問題なのは、235 以上の Y 成分が含まれていた際に、伸張されて 255 を超えた
(例えば 260 とかになった)のが 255 にクリップ(飽和)されずに、最上位ビットが削ら
れて 0〜16 ぐらいの RGB 値になってしまっている点。

いくらサイバーリンクがアホでも DVD 再生ソフト販売はじめて3年以上経つ企業の製品で
そんなバグが残ってる訳がないので、30 の環境が腐ってるに一票。

再生時に余計なフィルタが挟まってないか調べてみた方がいい。

33 :名無しさん@編集中:03/08/29 23:25
>>30
ハードウェア動画支援切るとどう?
あと、再エンコしても構わないと書いてるようだが
それならm2v.aui経由でAviutlで表示するとどうよ
Aviutlでもおかしいなら該当ピクセルをGNBのベクトル表示で確認してみよ

現象自体は3DYCやアンチクロスカラーフィルタの色抜けに似てるけどな

34 :名無しさん@編集中:03/08/29 23:38
>30 の環境が腐ってるに一票。

腐ってました。
再生支援をOFFにしたら起きなくなりました。
しかし、ONにしないと60fps再生できない…。
難しいですね…。

35 :名無しさん@編集中:03/08/29 23:44
なんて書いてたら、

>>33
>ハードウェア動画支援切るとどう?

やっぱりそれなんですね。起きなくなりましたよ。
GNBのベクトル表示とかの話は全然わかりません。
その辺は自分で調べてみようと思います。

36 :名無しさん@編集中:03/08/30 05:22
>>20
おまえ、この業界の人間ではないな。旅に出ろ

>>25
おまえ、スペアななんかで計ってるのか。だからバカなんだよ

>>27
おまえは前スレから居住し続けている嫌われ者君なので、逝ってよし

で、結局は同一君ってか・・・・

37 :名無しさん@編集中:03/08/30 05:49
>>35
グラボが原因ですな
グラボのメーカー名、ボード名、ドライババージョンを晒してくれると
このスレ的に有意義

38 :名無しさん@編集中:03/08/30 07:04
>>36
このスレはキャプスレでっせ。へたれプロがくるところじゃありません。
場違い君へ。

39 :名無しさん@編集中:03/08/30 07:10
藻前らウザイぞ
厨もうざけりゃ、いちいち喰ってかかるプロももっとうざい
とっととよそへ逝け!

40 :プロ:03/08/30 08:44
38や39がうるさいので・・・・・・












居 座 り ま す !

41 :Y田:03/08/30 09:51





お い ら も 居 座 り ま す !












42 :名無しさん@編集中:03/08/30 09:57





どうぞ。






43 :名無しさん@編集中:03/08/30 09:57
>>37
そういうのってどこに書いてあるんでしょう?
わかったのは、グラボのメーカーがintelというだけです。
ちなみに、PCはNECのバリュースターVT866J/6です。

44 :名無しさん@編集中:03/08/30 10:11
20が荒らしたから見難い。。。。。。

45 :名無しさん@編集中:03/08/30 12:37
動画の一部うpした方が早いぞ、もはや

46 :名無しさん@編集中:03/08/30 12:57
動画だけうpしてどないすんねん。
環境ごとじゃないと。

47 :名無しさん@編集中:03/08/30 13:48
誰か>>5に・・・
yes,noでいいので答えてもらえませんか?

48 :名無しさん@編集中:03/08/30 15:31
yes

49 :名無しさん@編集中:03/08/30 15:33
no

50 :名無しさん@編集中:03/08/30 15:50
yes

51 :名無しさん@編集中:03/08/30 16:29
カワイソーな47・・・・・・・

52 :名無しさん@編集中:03/08/30 16:31
yes,no

53 :名無しさん@編集中:03/08/30 16:36
>>52
今夜はどっち?

54 :名無しさん@編集中:03/08/30 16:42
枕かよっ

55 :5:03/08/30 16:48
ちゃんと否定してくれる人がいないってことはなんとなくは正解なんだろうきっと
そう思っときます・・・

56 :名無しさん@編集中:03/08/30 17:11
>55
だいたいそういう意味だと思っていいはず。

ただし、ここでいう 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 ?

59 :名無しさん@編集中:03/08/31 05:22
16daro

60 :名無しさん@編集中:03/08/31 07:23
わけわからんやつが混ざってるな。

61 :名無しさん@編集中:03/08/31 13:19
居座ってる山田だろ。

62 :56:03/08/31 18:54
>>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 として
 出てくる

以上。

63 :名無しさん@編集中:03/08/31 20:22
それならわかるよ

64 :名無しさん@編集中:03/08/31 21:53
↑脳味噌腐ってんな。


65 :名無しさん@編集中:03/09/02 04:28
YC伸張ですが、基本的には、エンコード時等には行わず、再生時に
プレイヤー側が伸張するのが、正しいと認識していますが、パッと見、
再生時に伸張されてるように、あまり見えません。
使用カードは、Radeon9000なんで、オーバーレイはYUV伸張に対応
してると思うんですが、プレイヤーとかcodecとかの相性とか有るんでしょうか。
DivXもmpeg2(CyberLink)も、伸張してるように見えないです。

66 :名無しさん@編集中:03/09/02 04:42
パッと見とかじゃなくてストレート展開したものと並べて見比べてみたら?

67 :名無しさん@編集中:03/09/02 04:58
↑脳味噌腐ってんな。

68 :名無しさん@編集中:03/09/02 05:08
>>65
編集ソフトのプレビュと同じ見え方だったら伸張されてるんだけど、
再生時伸張されてないってことは、
編集時よりコントラストが低く(暗い所が薄明るく明るい所が暗く)見えたり
色が淡くなったりして見えているということですか?

69 :名無しさん@編集中:03/09/02 05:49
>>65
ソースがRGBとか?

70 :名無しさん@編集中:03/09/02 05:50
>>65
そもそも手順があっているかどうか・・・
手順を全部晒してくれ

71 :名無しさん@編集中:03/09/02 22:38
>>70
コンポジット入力でキャプってます。

72 :名無しさん@編集中:03/09/02 23:25
>>71
釣れますか?

73 :65:03/09/02 23:45
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デッキでの表示では、同データで明るめに表示されてますし。

74 :名無しさん@編集中:03/09/02 23:58
 ・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チェックなし

↑のように変えてみたんですがこれであってますか?


75 :名無しさん@編集中:03/09/02 23:59
>>73
MPEG2をATi+CyberLinkなら
デフォで伸張より明るくなるくらいなんだが?
DirectXが古いとかかなぁ
DivXに関してはプレイヤーによりけり

Aviutl99だとGDI表示時に伸張変換でRGBになると思うが
(勿論内部的にはYUV444。)
Aviutlでオーバーレイ表示オンオフだとどう?
↑の環境ならオーバーレイのほうがやや明るい

76 :名無しさん@編集中:03/09/03 00:03
>>74
TMPGEncはRGB入力のみ
この場合RGB化はHuffyuvが行う
Huffyuv内部でのYUY2>RGBは伸張変換
伸張RGBはBasic YCbCrチェキなしで受ける
つまりあってるけど
”YUY2変換時に〜飽和チェック ”
はいれてもいれなくても伸張されて渡されるから同じ

77 :74:03/09/03 00:09
>>76
むずかしいことはよく分からないけど、とりあえずあってるんですね
安心しました。ありがとー♪ヽ(・∀・)ノ

78 :76:03/09/03 00:11
エンコード後の結果は同じでも
中間ファイルのサイズは飽和させたほうが小さくなる

79 :名無しさん@編集中:03/09/03 00:21
>>78
( ・∀・)つ〃∩ ヘェーヘェーヘェー

ついでに聞いちゃうけど最終的にVirtualDubでDivXやXviDにエンコする場合は
飽和させないほうが(・∀・)イイ?

80 :名無しさん@編集中:03/09/03 05:27
>>79
その質問は禁句なのだが

キャプチャー時にBT.601有効範囲内にデータが収まっている(ノイズ以外で)

再生環境が完全にキャリブレートされている
場合は飽和させたほうがいい

81 :65:03/09/03 20:35
>75
mpeg2が明るくなっているのは、CyberLinkのデコーダーデフォルトが、ビビット色調に
なってて、明るめに表示されてるからで、伸張とは関係ない気がします。
実際、ビビットからデフォルトにすると、うす暗い配色になります。

DirectXは、9.0b、メインマシンとサブで、それぞれ、Radeon9500と9000が入ってます
が、どちらも、伸張されてる気配はなく、Aviutlでの明るさもオーバーレイとGDIで、
あんまり差がないような感じです。

82 :名無しさん@編集中:03/09/03 21:38
単にテレビとPCディスプレイの明るさの違いというオチだったりして。

83 :名無しさん@編集中:03/09/03 21:41
>>82
つーかさ
モニタがキャリブレートされてないんでしょ
ストレートRGB変換したものと見比べりゃわかるでしょ

84 :名無しさん@編集中:03/09/03 21:44
DVD2AVIのプレビューで
「YUV422」と「RGB PC色調」/「RGB TV色調」を切り替えてみれば分かるよ。

「YUV422」と「RGB PC色調」が同じに見えればRADEONはYC伸張してる。
「YUV422」と「RGB TV色調」が同じに見えればRADEONはYC伸張してない。

85 :名無しさん@編集中:03/09/03 21:52
ラデのオーバーレイがYC伸張してなかったという衝撃の新事実

86 :名無しさん@編集中:03/09/03 22:14
>>84
それバグだか相性だかで正確じゃないのは前スレでガイシュツ

>>85
うちのラデ9500はオーバーレイ伸張してるよ

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はそういうものなのでしょうか。

分かる人教えてください。


88 :名無しさん@編集中:03/09/04 05:20
>>87
845G系はみんなそう
苦情はインテルへ

89 :名無しさん@編集中:03/09/04 20:09
TMPGEncで、
「DVはCCIR60で記録されてるから、Basic YCbCrで出力した方がいい場合がある」
みたいなことが書いてありますが、DVDレコで録画したものをソースにする場合もそうした方がいいんでしょうか?
そんなことをしたら、DVDに焼いてDVDプレイヤーで再生させた時に、明るすぎるような気がするのですが。

90 :名無しさん@編集中:03/09/04 21:06
>>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に読み込ませているのか?”
によって回答は変わります。

91 :74:03/09/04 22:15
>>80
お返事遅れてごめんなさい
前者はできてるはずだけど後者は分かんないや・・・・
飽和させたほうがサイズも縮むみたいだし飽和させることにしました
禁句なのに答えてくれてありがとー♪ヽ(・∀・)ノ

92 :名無しさん@編集中:03/09/04 22:23
>>90


93 :名無しさん@編集中:03/09/04 22:31
だからテンプレ作れば良かったのに。

94 :名無しさん@編集中:03/09/04 22:35
↑すいません。途中で書き込んでしまいました。

なるほど。
ということは、「YUVデータをCCI601ではなく…」という項目は、圧縮するかどうかということなんですね。
カノープスDVは伸張されず16-235のまま扱われるから、チェックを入れないと、圧縮されてしまってまずいということですか。
最終的に16-235にしたい場合、読み込まれた状態が16-235ならチェックを入れ、0-255ならチェックを入れないと。
よくわかりました。ありがとうございます。

95 :名無しさん@編集中:03/09/04 22:59
>>93
テンプレ作るとオレのやることなくなるからな

96 :名無しさん@編集中:03/09/04 23:15
テンプレ

PCでしか見ないときはPC色調にします
TV出力をするときはTV色調にします

97 :名無しさん@編集中:03/09/04 23:24
テンプレで嘘ついてどうする

98 :名無しさん@編集中:03/09/05 00:08

え?>>96って嘘なの?

99 :名無しさん@編集中:03/09/05 00:50
96の後者だけは合ってない?

100 :名無しさん@編集中:03/09/05 02:13
PCでしか見ないとき とか TV出力をするとき とか
そういう区分が間違ってるんだよ
あと、PC色調にします とか TV色調にします とか
何?意味が分からん
みんな同じソフト使ってるわけじゃないんだからちゃんとした用語を使ってくれ

101 :名無しさん@編集中:03/09/05 02:38
ネタにマジレスの典型が見られました

102 :名無しさん@編集中:03/09/05 02:44
TVで見ようがPCで見ようが16-235が正解

103 :名無しさん@編集中:03/09/05 05:12
え・・・
RGBフルスケールになるようにしてるよ・・・

104 :名無しさん@編集中:03/09/05 13:45
メディアプレイヤーでの再生時に、伸張させないようにするにはどうすればいいんでしょう?

105 :名無しさん@編集中:03/09/05 13:45
↑オーバーレイとかいうやつのチェックをはずしても色が変わりませんでした。

106 :名無しさん@編集中:03/09/05 15:22
映像の色範囲を変えずに編集をする方法とか、サチュレートする方法やしない方法など
そういったものならテンプレにできるかもな
でも、どういう色が正しいのかみたいなのは好みの問題も多く含んでくるから無理かもね
ちゃんとした色で放送してるとは限らないしキャプボのくせもあるだろうし

107 :名無しさん@編集中:03/09/05 23:49
前から思ってたんだけどさ

音声だとノーマライズってあるじゃん?一番大きな音が、フルスケールになるように調整される
やつ。


これの映像版ってある?
一番大きなRGBのどれかの成分にあわせて、それがフルスケールになるように調節される
機能とかってない?

108 :名無しさん@編集中:03/09/06 00:00
個人的にはノーマライズも欲しいが
コンプレッサーも欲しい
拡張色調補正のガンマ調整だけではキツイ

たぶん業務用ソフトには当然ついてる機能だとは思うが

109 :名無しさん@編集中:03/09/06 05:51
>>107
AviUtlのプラグインならある。
でも音声のノーマライズと同じく、全フレームをまずスキャンするからとっても時間がかかる。

110 :名無しさん@編集中:03/09/06 12:02
>>109
非常に環境に依存しまくると思うんですが、
720*480-22〜24分くらいの生AVIとかって、一時間くらいで終わったりします?

っていうかSCSI-HDDとかあると速いだろうなぁ・・

111 :名無しさん@編集中:03/09/06 22:11
なんかプロのオーサリング屋からして混乱しているが
http://pc.2ch.net/test/read.cgi/avi/1048403135/191-

112 :名無しさん@編集中:03/09/06 23:03
>>111
だからiLinkキャプだって範囲外あるし
市販DVDだって範囲外あるんだって
プロだからって規格に忠実なわけではないってこったろ

113 :名無しさん@編集中:03/09/07 00:37
>>112
意図してやってんのか、無知でそうなってんのか分からんな。

114 :名無しさん@編集中:03/09/07 01:06
あまりプロを馬鹿にしないほうがいいよ、キャプ厨さん(プ

115 :名無しさん@編集中:03/09/07 03:39
>>114

プロでも間違えるのか?
http://pc.2ch.net/test/read.cgi/avi/1057668290/

116 :名無しさん@編集中:03/09/07 13:17
テレビで放送する映画って画質ザラザラして汚いね

117 :名無しさん@編集中:03/09/07 22:14
>>114

>いや、テレビ(@スカパ)もやってるCG屋だよ
>16-235の仕組みを教えてあげて、
>http://www6.ocn.ne.jp/~whkawan/OverlayAdjust.pdf
>このページを見るように、忠告してみた
>それ以上は、教えん(教えられんw

編集マンのつぶやき
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だろ。型番くらい把握しとけ。

>1 コンピュータ映像処理に関する教育、コンサルタント
>おまえみたいな奴にコンサルタントなんかしてもらいたくないね。

>6 乗用車、自動二輪車及び付属品の輸入販売
>って、おいおい、じつは何でも屋ってオチかい。

>ギョーカイも結構ちんけなところと付き合ってんだな。
>これじゃ、ろくな素材集まらんだろ。



119 :名無しさん@編集中:03/09/09 00:15
AviUtl→中間出力→Avisynthで仕上げ
てな感じでエンコードしているのですが、
色はどの段階でいじるのがBestですか?


120 :名無しさん@編集中:03/09/09 01:55
最後

121 :名無しさん@編集中:03/09/09 10:37
再生時

122 :名無しさん@編集中:03/09/09 17:03
キャプチャ時

123 :名無しさん@編集中:03/09/09 18:26
くだらねーこと言ってないでマジレスしろや
カス共

124 :名無しさん@編集中:03/09/09 20:02

こいつのチンコは尻穴みたいに臭い。

125 :名無しさん@編集中:03/09/09 21:18
>>119
>>120
”フィルタの副作用で色変化がおきる可能性があるから、
最後に目で見て調整”<正解

>>121
"所詮キャプチャー時に色を調整しても民生レベルではアテにならん。
ソースデータは維持しといて再生アプリで自分好みにしてる”<正解

>>122
”カラーバーを基本にキャプチャー機器のキャリブレートをしてる。
フィルタによる色変化なんてたかがしれてるし、
デフォルトでキャプするとレベルオーバーが怖いしね”<正解

どれもマジレスなんだが?

126 :名無しさん@編集中:03/09/09 21:24
>>125
要するに、各段階でそれぞれチェックしろってことだな。
当たり前って気がするけど。

127 :名無しさん@編集中:03/09/09 22:07
最初(キャプ時)にやっちゃえば後々楽だと思うけどね
マスターからして激しく白飛びしてたりしたらどーにもならんが

128 :名無しさん@編集中:03/09/10 00:11
>再生時

正解かどうかはともかく、一番安全だから初心者はこれ。

129 :名無しさん@編集中:03/09/10 02:46
しかし元がダメじゃどうしようもないだろ
やはりキャプチャ時が一番重要
まあ本当に一番重要なのは撮影時なんだろうけどね

130 :名無しさん@編集中:03/09/15 22:20
キャプチャ時の調整ってこんな感じで良いのでしょうか?
ttp://cwaweb.bai.ne.jp/~icchan/Data/hard/saa7130b.htm

131 :名無しさん@編集中 :03/09/16 00:41
>>130
いいけど杓子定規にならないように気をつけよう!


132 :名無しさん@編集中:03/09/16 01:14
>>130
それはあくまでもReelTimeでカラーバーを出力した場合の適正値
実際はビデオデッキの種類によってそれぞれ違う

133 :130:03/09/16 20:11
>>131-132
ありがとうございます。
良く読むと我が家ではカラーバーを出力する環境がないので^^; 同じ方法は採れないですが
動画連盟という所にカラーバーを作る方法が書いてあったのでちょっとやってみます。

(ここなんですけど)
ttp://www.katch.ne.jp/~sakaki/douga/kiji/mpeg1colorbar/mpeg1colorbar.html

134 :名無しさん@編集中:03/09/16 21:31
>>133
写真屋のプラグインならこんなのがあるけど
Color Bar Generator v1.3
ttp://www.richardrosenman.com/photoshop.htm

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から遠ざかる。

136 :名無しさん@編集中:03/09/20 05:15
まー、アニメに限らず地上波放送用マスターは、
クロマが高すぎると放送局に納品を拒否されるので、
下げられてることが多々ある。

137 :名無しさん@編集中:03/09/21 18:55
まー君、出たな。

138 :名無しさん@編集中:03/10/02 16:01
盛り下がってますね

139 :名無しさん@編集中:03/10/02 18:12
前は盛り上がってたんですけどね

140 :名無しさん@編集中:03/10/02 21:23
情報も議論も出尽くしたのかな?
ところで誰かBT.709の有効範囲知らない?

141 :名無しさん@編集中:03/10/04 05:47
知ってるがお前の態度が気に食わない

142 :名無しさん@編集中:03/10/06 11:08
saa7130のチップで、0-255でキャプするのは間違ってるの?

143 :名無しさん@編集中:03/10/06 13:04
>>142
一度16-235でキャプしてみ。

144 :名無しさん@編集中:03/10/06 22:16
あ、俺0-255でやってる・・・(;´Д`)ドキドキ

145 :名無しさん@編集中:03/10/07 03:09
そもそも色範囲指定で取り込めるのか?
編集時じゃなくて?

つーかYUVは0-15と236以降にもデータが入っててもかまわないことに
はなっているが、ヒストグラム見たところあんま超えてる画像って
無くない?だいたい範囲内だよね?

146 :名無しさん@編集中:03/10/07 03:24
明るさコントラストでどうにでもなるでしょ

>>142も質問がおかしいよ
0-255でキャプするとか16-235でキャプするとかどういう意味だよ
意味分かって使ってるの?
>>142はどういう状態を0-255でキャプするって言うわけ?

147 :名無しさん@編集中:03/10/07 05:38
わかってるくせに

148 :142:03/10/07 06:09
huffyuvでYUY2でキャプしてるんですけど、
カラーバーをキャプして
波形表示プラグイン を使って調整してるんだけど、
補助線をCCIR601用にする にチェックつけても付けなくても
明るさとコントラストしだいで、どちらにも対応できるように
キャプできてしまうんで・・・
どっちが、いいのかな〜と。

149 :名無しさん@編集中:03/10/07 12:02
huffyuvならYUY2はAviUtlに読み込ませたときに伸張するから
0-255にあわせるのが正解

簡単に言えば、RGB展開するときに伸張するものは0-255、伸張しないものは16-235に合わせる

150 :名無しさん@編集中:03/10/07 13:03
>>149
huffyuvのYUY2って伸張してたっけ? >AviUtil

151 :名無しさん@編集中:03/10/07 13:22
>>149
130のリンク先に書かれている事は正しくないってこと?
>>SAA7130の色範囲が16〜235なので、補助線をCCIR601用にチェックを付けて見ていきます。
ここの部分。



152 :150:03/10/07 13:29
RGBで読み込み > 伸張している
YUY2で読み込み > 伸張していない

この認識で良いか?

153 :名無しさん@編集中:03/10/07 13:47
どっちも伸張してる

154 :名無しさん@編集中:03/10/07 13:58
huffyuvのバグでチェックをしようがしまいが
常に伸張されるんじゃなかったか?

155 :名無しさん@編集中:03/10/07 14:23
>>151
補助線をどの位置にするのが正しいのかは伸張するしないで変わるから
コーデックによって変わるもので、デジタイザによって変わるわけではない

>>SAA7130の色範囲が16〜235なので、補助線をCCIR601用にチェックを付けて見ていきます。
そのページは全く読んでないが、この一文から察するにたぶん、
「SAA7130は16-235の範囲外も録れるから、伸張しないで範囲外も見ていく」ってこと
正しい正しくないの話ではない

156 :名無しさん@編集中:03/10/07 15:09
>>155
そのページでは、使用コーデックはhuffyuv(YUY2)と明記されているんだけど・・・

157 :名無しさん@編集中:03/10/07 15:53
>>156
少し読んでみた
伸張した状態でCCIR601用補助線に合うようにキャプってるのか
それで伸張展開したものをストレート展開したものとしてエンコしてるのね
まともじゃないな

158 :名無しさん@編集中:03/10/07 17:51
>>154
バグっていうかYUVでもWYSIWYGで作業できるように親切設計になってるんじゃないの。
それを余計な親切はすな!と言って出てきたのがHuffyuvS。
RGB圧縮のhuffyuvの展開はストレート変換だよ。

159 :名無しさん@編集中:03/10/07 18:31
親切設計のつもりで伸張しないオプションまで用意してあるのだが、
伸張されちゃうんだな、これが。

160 :名無しさん@編集中:03/10/07 22:52
HuffyuvSは最早過去の遺物ですよ

161 :名無しさん@編集中:03/10/07 22:56
Aviutlのサチュレート対策用だからな
99が出た今、使うメリットがない

162 :名無しさん@編集中:03/10/07 23:05
TMPGユーザーを無視するなよ

163 :名無しさん@編集中:03/10/07 23:31
>>162
だからTMPGEncは内部RGBなんだから
Huffyuv(RGB)でいいじゃん

164 :名無しさん@編集中:03/10/07 23:45
長時間録画をする場合などにはRGBとYUVの容量の差は無視できない

165 :名無しさん@編集中:03/10/07 23:50
TMPGEncにカノコデ用だけじゃなくて
どんな入力に対しても色空間変換式を選択できるオプションがありゃいいんだな
正確にはVFAPIの問題だが

166 :名無しさん@編集中:03/10/08 09:11
なんかちょっと前からHDDの値段がほとんど落ちなくなっててムカつく。
それ以前は毎年2倍ペースで同じ値段で容量倍になってたのに。

167 :名無しさん@編集中:03/10/08 09:13
なんかチョソっぽい日本語になった。
まぁ大和魂で判れ。

168 :名無しさん@編集中:03/10/08 09:26
誤爆か?

169 :名無しさん@編集中:03/10/08 09:48
ニガーの漏れはどうしたらいいですか?

170 :名無しさん@編集中:03/10/08 23:09
>>165 に関連して

CanopusDV + TMPGEnc の組み合わせで今まで使ってきたのですが
環境設定→設定→色空間変換式のところで、

指定しない(チェック外す)にして変換をDVcodecにさせる(とポップアップに書いてある)と
その結果は 指定→BasicYCbCr とほぼ同じになる。

んで、今日たまたまAviUtl使ってみたんだけど
TMPGEncでいうところの 指定→CCIR-601 の結果とほぼ同じになってる。

TMPGEncの指定なしとAviUtlは同じになるとばかり思っていたのだが
これってどういうことですか?


171 :名無しさん@編集中:03/10/08 23:42
>>170
codecまかせならCCIR-601と一緒になると思うが?
Huffyuv(YUY2)かなんかで出力してAvisynthでチェックしてる?
Aviutlに関してはYUY2展開?

172 :名無しさん@編集中:03/10/09 00:17
CanopusDV + Aviutl(0.98d)でエンコしてますが、
拡張色補正のTV->PCスケール補正のチェックボックスはオフ
環境設定のコーデックの設定でCanopusDV CodecのYUY2で展開と圧縮はオフ
で色補正は各パラメータを調整してやっています。
これって、おかしいですか?

173 :名無しさん@編集中:03/10/09 00:23
>>172
ソースがDV?最終形式がDV?

174 :170:03/10/09 00:42
>>172 とは別人です。

TMPGEncで連番BMP書き出ししたものと
AviUtlでは現在のフレームをコピペしてBMP保存したものを比べてました。
AviUtlのコーデックの設定はYUY2展開です。

huffyuv(YUY2)ほかいくつかのCODECで書き出して比べてみます・・・


175 :名無しさん@編集中:03/10/09 00:44
>>173
DVカメラで撮ったものをDVRaptorで取り込んでます。
用途はPCでの鑑賞用(VP3かXviD)です。
DVD-Video化は色補正が難しくてあきらました。。。


176 :名無しさん@編集中:03/10/09 00:58
>>175
AVIUTLからCodec(VP3orXvid)にRGB、YUY2どちらで渡すにしても、
「拡張色補正のTV->PCスケール補正のチェックボックス」はオン
にしとかないとまずいね。

貴方の設定だとコントラストが足りない映像が出来上がるよ。VP3かXvidが
RGB→YUY2へのストレート変換に対応してればそれでも問題ないが、
恐らく対応してないのでどこかでYC伸張しないといけないね。

177 :175:03/10/09 01:46
>>176
そうですか。今度からYC伸張して色補正をしてみます。

家庭用DVカメラで撮影したもの(特に室内)は色補正が難しいですね(´・ω・`)

178 :名無しさん@編集中:03/10/09 02:04
家庭用DVカメラだと、環境変化によって
そもそも黒と白が変なレベルで記録されるので調整は難しいっす
あのシーンに合わせるとこっちがおかしくなる、みたいな感じで。

そういう意味では「拡張色調補正のTV→PCスケール」は
ぜんぜん役に立たないことがあります。

あと家庭用は全体的に色のりが悪いことがおおいので
彩度をちょっと上げてやったほうが見栄えがしますね。


179 :名無しさん@編集中:03/10/09 02:28
家庭用DVのキャリブレートはほんと難しい。というかソフトじゃなくて
撮影技術の話になってくる。

180 :178:03/10/09 23:48
ふと思い立って、家庭用DV撮影の素材を編集後、
いったんテープに書き出し後、
オートゲインコントロール付のキャプチャボードでアナログキャプチャ
してみました。

結果、輝度レベルは満足できる程度にそろいました。
補正が面倒なときには使えるかな。



181 :名無しさん@編集中:03/10/10 19:07
>>177
YC伸張フィルタの方がよくない?
http://c-zone-web4654.hp.infoseek.co.jp/alcv/

182 :名無しさん@編集中:03/10/10 21:21
>>177
>>181
YC伸張だけならこれもいい
ttp://homepage2.nifty.com/GNB/soft/AviUtl/ycexp2_001alpha2.lzh

183 :名無しさん@編集中:03/10/14 05:03
>176
VP3,Xvid がストレート変換に対応してないって話ですが、DivX5とか
WMV9 codecはどういった扱いなんでしょうか。

184 :名無しさん@編集中:03/10/14 09:30
>>183
DivXもWMV9も全部VP3、XviDと同じ。YUV->RGBは伸張、RGB->YUVは圧縮
ただし、DV CODECはストレート変換するものもあり、その場合は自分で伸張しないといけない。
TMPGEncなんかだとそのためのチェックボックスもあるが。



185 :名無しさん@編集中:03/10/14 19:03
>>184
WMVは兎も角DivXやXviDはYUY2入力可能
YUV系CodecでYUY2展開にチェックした場合や
MPEGをm2v.aui入力した場合は
「拡張色補正のTV->PCスケール補正のチェックボックス」はオフでいい
そもそも
>>172のCanopusDV CodecのYUY2で展開と圧縮はオフ
がおかしい
展開をオンにしとけばずっとYUV色空間処理になるから
スケール変換のことなど考える必要がない

186 :183:03/10/14 22:44
>185
ということは、敢えて遠回しな表現で書くと、

YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オン -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)

いや、すいません。自分で書いてみて、余計分からなくなってきました。

187 :名無しさん@編集中:03/10/14 23:11
>>186
いや
YUY2展開オン(m2v.aui含む) -> YUY2圧縮オン -> DivX
=YUY2展開オフ(nonexp.codec CanopusDVなど) -> YC伸張オン -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)
=YUY2展開オフ(expcodec. Huffyuvなど) -> YUY2圧縮オフ -> DivX(Codec内でRGB -> YUV)

188 :名無しさん@編集中:03/10/15 04:26
あー、誰か波形表示DirectShowフィルタ作ってくれねかな。
これなら、録画してAviUtlに読んで…の繰り返ししなくても
リアルタイムでhunuaaCapで色合わせできるのに。
ヒストグラムフィルタも使ってはいるけどねん。


189 :名無しさん@編集中:03/10/15 04:34
リアルタイムで表示できたら確かにかなり便利だな

190 :名無しさん@編集中:03/10/15 05:35
てめえで作れ♪

191 :名無しさん@編集中:03/10/15 06:38
自分で作れるぐらいならとっくに作っとるわ♪

192 :名無しさん@編集中:03/10/18 00:16
AviUtl掲示板でスケール変換議論再燃。

193 :名無しさん@編集中:03/10/18 06:05
カノプーってRGBとYUVの変換精度が悪いみたいですね。↓ここ
http://pc.2ch.net/test/read.cgi/avi/1063191060/666-667

194 :名無しさん@編集中:03/10/18 09:50
AVIUTLで同じDivX動画を読み込み
DIVXのYUY2で展開するにチェックとYUY2で展開するを空白とで見比べても
全く同じ何も変わらん

195 :名無しさん@編集中:03/10/18 10:54
>>194
まったく同じではないと思うよ。
でも色スケールが変わるわけではないので、パッと見変化なしで当たり前、逆に変わってもらっては困る。

196 :名無しさん@編集中:03/10/18 11:47
YUY2で展開するのチェックOFF YUY2 16-235→RGB 0-255
YUY2で展開するのチェックON  YUY2 16-235→RGB 16-235
か逆かしらないけど、色範囲大幅に変わってますよ

197 :名無しさん@編集中:03/10/18 17:19
>>194
huffyuvでやってみたけどやはり全く同じだったよ。
>>196
On Offに関係なく伸張されると思うんだけど。

198 :名無しさん@編集中:03/10/18 19:52
>>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


199 :198:03/10/18 20:01
YUY2展開・圧縮の利点はYUVでずっと処理できることにあり
RGB変換がおこらない
そのためYUV<>RGB変換誤差がないのは勿論
わずらわしいスケール(伸張・圧縮)のことを考える必要がない

200 :名無しさん@編集中:03/10/18 20:28
フィルタがほとんどRGB前提だから関係ないよ。



201 :名無しさん@編集中:03/10/18 21:14
ここは亜空間ですか?

202 :198:03/10/18 21:21
>>200
YUV前提で作られてるよ
RGB変換動作するのは拡張色調補正くらいでしょ
内部YUV48をなめてはイカソ

203 :名無しさん@編集中:03/10/18 21:27
0.97までのフィルタだったらRGBで動作するんじゃない?
ところでYC伸張フィルタって古いよね(俺の持ってるやつは2000年製)
これ絶対RGB空間で動作してるな。

204 :名無しさん@編集中:03/10/18 21:28
lotus m4cもRGB空間だろうね。

205 :198:03/10/18 21:36
外部プラグインについては古いのはダメだろうね
しかしYC伸張フィルタがYUV色空間で動作したら、
それはそれでおかしな話だが
GNBのYC伸張フィルタはどうなってるんかな?
まぁYUV48ならYUV空間ならYC伸張相当の動作はできるけど

206 :名無しさん@編集中:03/10/19 00:13
では、波形表示プラグインのIRT601に補助線を表示って全く無意味なんだね

207 :名無しさん@編集中:03/10/19 00:24
>>206
全くわかってないのでは?
表示用データとして常にRGB24bitデータを持つが
フィルタ処理に使われるのはYUV48bitデータ
だから出力されたデータは処理段でYUV<->RGB変換がおきないって話でしょ
表示プラグインなんて出力とも内部色空間とも無関係

208 :名無しさん@編集中:03/10/19 00:27
>>207
”IRT601”なんて打ち間違ってるようでは、
前スレも読んでない初心者。
そう突っかかるな。

209 :198:03/10/19 00:34
>>201に同意
前スレとはうってかわってレベル低下が烈しいな。
亜空間になってしまったみたいだ。
せめて現スレ全部読んでからカキコせよ、と言いたい。

210 :名無しさん@編集中:03/10/19 00:44
まあまあ
普段は死にスレ同様の静けさなんだしたまに初心者が来るのを相手するぐらいいいだろ
めんどくさいなら放置すればいいんだし

211 :名無しさん@編集中:03/10/19 00:46
そんな難しいこと考えんでも
TV出力前提ならTVスケール、
PCでしか見ないならPCスケールの原則を守ってればいい

212 :名無しさん@編集中:03/10/19 00:48
>>211
それはげふぉ厨の考え

213 :名無しさん@編集中:03/10/19 01:05
>>211
アホな発言禁止

214 :名無しさん@編集中:03/10/19 01:19
しかし波形プラグインで0-255範囲にあわせてもイマイチパッとしない
あれより若干広めにあわせるのがプロの仕事だと思わんかね?

215 :名無しさん@編集中:03/10/19 01:31
あのー、全部のデータを読み込んで、自動的にフルスケールにしてくれる
プラグインが存在したと思ったんですけどありか知ってる人います?

妙に時間かかった記憶はあるんだけど。

216 :名無しさん@編集中:03/10/19 02:23
>>214
地上波として変調した時やTVチューナーで復調した時に
強調されるシュート成分は無視しる

217 :名無しさん@編集中:03/10/19 02:47
現実問題としてアナログキャプしたものって、
真っ白な画面のはずなのに画面上部と下部で明るさが違ったりとか
そこに例えば文字とかが出てくると画面全体の明るさが微妙に変化したりとか
そういうことあるんで結局どこに合わせるかは見た目と好みで決めるしかないような気がします

218 :名無しさん@編集中:03/10/19 09:46
>>215
ColorYUY2のlevels

219 :名無しさん@編集中:03/10/19 09:49
16-235に合わせても伸張してテレビと同じ見た目の筈が薄いのはなぜですか?
皆さんの見解と現実がまるっきり違うんだよ!

220 :名無しさん@編集中:03/10/19 10:00
意味が分からん

221 :名無しさん@編集中:03/10/19 10:58
>>219
>16-235に合わせても伸張してテレビと同じ見た目
なんてバカなこと言ってるヤシいるのか?

222 :名無しさん@編集中:03/10/19 11:10
TVは16と235を黒、白として表示する
AVIUTLは16と235を伸張してテレビと同じ色で表示する
基本ですね

223 :名無しさん@編集中:03/10/19 11:17
>>222
違うって・・・
テレビと同じ色にはけっしてならない
データ的にテレビと近似なものになるってだけ

224 :名無しさん@編集中:03/10/19 11:27
PC環境がかわっても
BT.601にのっとった方法でファイルを作成しておけば
環境をキャリブレートすることにより
同じ見た目で再生できる。

それはつまり
キャリブレートされた環境であれば
例え他人のPCであっても
上記のファイルは常に同じ見た目。

もし上記のファイルが.vobであれば
DVD-VIDEOとして据え置きプレイヤーでテレビ視聴したとき
おかしな色合いにはならない。
ただし、据え置きプレイヤーの多くはキャリブレートできないし
モニタとテレビの色温度が異なる以上
同じ色合いにはならない。

ではBT.601にのっとった方法とは?
というのがこのスレの趣旨

225 :名無しさん@編集中:03/10/19 12:50
何でわからないかな
AVIUTL波形プラグインでBT601補助線に合わせた場合は
テレビとの見た目で明らかに画質が違うだろうがよ
少し違うぐらいなら誤差の範囲だが、データの表示手順はテレビと同じなのに
全然違うじゃねーかといってんの

226 :名無しさん@編集中:03/10/19 12:56
>>225
ファイルを補助線にあわせてどうする?
補助線に合うようにキャプチャボードを調整するんだよ
キャリブレート用プラグインでしょ
キャリブレートしてないキャプボで作ったファイルが
補助線に合わせたらテレビと違うって、そりゃそうだろ
大体表示環境自体キャリブレートしてるのか?

227 :名無しさん@編集中:03/10/19 12:58
>>225
そもそも"データの表示手順はテレビと同じ"ってのがおかしいんだが
”データの表示手順”は波形表示プラグインとは無関係

228 :名無しさん@編集中:03/10/19 13:05
このスレは難解で衝撃的で自分の理解の範囲を超えています

229 :名無しさん@編集中:03/10/19 13:07
つーか、ガンマ値とかも違うし(6500-9300 Vs 13000越え(テレビは一般的な
標準が無いから、もっと上だったりもする)

し、そもそもCRTとTVでは方式違うから同じになるわけ無いじゃん。

230 :名無しさん@編集中:03/10/19 13:10
デフォでNTSC (setup 7.5) 設定の糞キャプボでも使っているのか??
デフォのまんまゲフォグラボでも使っているのか?
そもそもPCモニタとテレビの色合いの差は誤差レベルじゃないってのに
はなから違うものを「違う!違う!!」と騒いでいるのか?
それは違うよ。
45wと100wの電球で明るさが同じにならないっていわれてもねぇ。

231 :名無しさん@編集中:03/10/19 13:11
ここは亜空間ですね。

232 :名無しさん@編集中:03/10/19 13:13
BT.601基準で作られたファイルの
PCモニタ表示と民生テレビ表示が一致するって言ってるヤシなんているのか?


233 :名無しさん@編集中:03/10/19 13:14
>>226
んなこと等の昔に理解し知ってる
カラーバーをキャプチャーしてIT601補助線にあわせるんだろ
色相も明るさも彩度も全部601にあわせた
テレビと見比べた
zん全治げー世ボケ桁ら絵羽。0-255であわせてもまだ薄い世あほ足れば
表示環境は完璧ジャワ
明るさ最大、9300kにしてバッチリテレビに最大限ちかづけてそれでこれかよ
ここで語ってること自体が棚上の空論で現実とかみ合ってねーんだよ

234 :名無しさん@編集中:03/10/19 13:14
色が薄いとか言ってるからガンマ値の問題でしょ。
DVDをPCモニタで見れば色が薄い。
それだけのことでしょ。

235 :名無しさん@編集中:03/10/19 13:15
(゚Д゚)ハァ?わけわからんSinmaiKeiji(新米刑事)逝ってよし!!

236 :名無しさん@編集中:03/10/19 13:20
>>233
お前がわかってないだけ。
あるDVDをPCで見たときとテレビで見たときの差、と
ある番組をキャプ・エンコしたものをPCで見たときとテレビで見たときの差、を
一致させる手順の話だって
差をなくす話じゃない
こうしておけば据え置きプレイヤー(MPEG1,2 DivX)でそのファイルをテレビ表示させた時に
おかしな色合いにならない。
また、色温度13000kのPCモニタやそれに合わせたグラボが市販化されたときに
テレビと同じ色合いになるよ。
つーか昔はあったんだがな。

237 :名無しさん@編集中:03/10/19 13:22
民生レベルでキャリブレートは完璧とか言ってるヤシが
キャリブレートできてるとは思えない。

238 :名無しさん@編集中:03/10/19 13:26
ストレート派vs伸張派
ノンサチュレート派vsサチュレート派
とかやってたころが懐かしいな・・・・。

239 :名無しさん@編集中:03/10/19 13:30
>>236
どんなPCモニタとVGAのつもり?藁
色温度に関しては13000程度までなら現状ので13000程度なら
合わせられるよ?


んで色温度が同じならば、PCモニタとTVが同じ色になるって言ってるん
だからCRTとTVの仕組み(CRT側が新方式?)の説明よろしくね。

方式はTV側はプログレって事で好意的に解釈してあげるから。


240 :名無しさん@編集中:03/10/19 13:53
オレは色温度に関してはよくわからんが
>>236の後半は間違ってるな
ググってみたらそういう問題じゃないような
ただ、>>236の前半はあってるわな
>>239は自分が「これで完璧!」ていう調整したファイル作って
家電DVDプレイヤーでテレビ視聴していただきたいね


241 :名無しさん@編集中:03/10/19 13:56
>>238
結局どっちが勝ったの?

242 :名無しさん@編集中:03/10/19 14:05
>>241
いつまでたっても平行線なんで
思想問題として決着ついた、とオレは判断した

243 :名無しさん@編集中:03/10/19 15:43
カラーバーをBT601にあわせて、それをDVDに焼いてテレビで見たら
DVDレコで録画した映像をDVDプレイヤーでテレビで見たときと
同じ見え方をするんだな?
それでOKですか?実際テストした有識者のお答えを待ってます
ちなみにカラーバーを0-255範囲にあわせてPCで再生したら
伸張しすぎの破綻映像が再生されるということでOKですね?

244 :名無しさん@編集中:03/10/19 16:40
>>243
OKじゃないでしょ
少なくともRDX3で録画したものは
BT.601をきっちりまもってない
前スレでガイシュツだが、チューナーってのはどいつもこいつも
チューナー独自の味付けがある
だからこそキャプボ側を調整しとこうってことでしょ
もしRDX3のチューナーでテレビを調整したら
他のカラーバーで調整したキャプボでとった画とは違うでしょ
個人的にはカラーバーどうこうというのは正確じゃないとは思うが
あてずっぽうよりマシな基準だとも思うけどね


245 :名無しさん@編集中:03/10/19 16:45
ちなみにカラーバーを0-255範囲にあわせてPCで再生したら

っていうのだけじゃOKもへったくれもないよ

246 :波形表示ソフトを使用した調整:03/10/19 16:45
(個人用覚え書きURL)
ttp://hajimehp.hp.infoseek.co.jp/scope.html

247 :名無しさん@編集中:03/10/19 16:49
>>246
IOのカードかな

248 :名無しさん@編集中:03/10/19 16:55
あぁそうか
”煽り訊き”だったのか
下も参照
http://cwaweb.bai.ne.jp/~icchan/Data/iro.htm

249 :名無しさん@編集中:03/10/19 17:36
>>244-245
簡単なことをあたかも難しく言って初心者を混乱させる天才だな

250 :名無しさん@編集中:03/10/19 17:38
>>249
じゃ簡単に

OKじゃねーよ
勉強しなおせ

251 :名無しさん@編集中:03/10/19 17:51
もう4ヶ月以上勉強してるんですが
てかOKだろ
あくまで一般的にAVIUTLの波形フィルタでBT601の範囲に収まるように
カラーバーを調節すればデータ的にはテレビと同じと考えていい
それをテレビに表示したとき本当に同じに見えるかは放送局が流す信号による
知りたければスペクトルアナライザーでも用意しろと

252 :名無しさん@編集中:03/10/19 17:54
243は「DVDレコで録画した映像をDVDプレイヤーでテレビで見たとき」と
比べてるから全然OKじゃない

253 :名無しさん@編集中:03/10/19 17:58
>>251
伸張済みRGB読み込みだと補助線は意味ないな

254 :名無しさん@編集中:03/10/19 18:04
伸張済みのRGBなんて存在し無いじゃん
ありえないたとえだして人を惑わすなよ
DVDもキャプチャーも全てYUV
つうか素材は全て伸張前なんだよ素人さん
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない

255 :名無しさん@編集中:03/10/19 18:08
>>254
あのな、波形表示プラグインの話だぞ?
それにbt系なら伸張済み非圧縮RGBキャプできるよ。
つーか非圧縮にせよHuffyuvにせよRGBキャプするヤシは
ストレートRGBは使わないでしょ。
まぁ
DVDレコで録画しようがキャプチャーカードで録画しようが
同じ録画だ何も変わらない
なら波形表示プラグインなんていらないけどな。

256 :名無しさん@編集中:03/10/19 18:13
>>254
作者のGNB自身が、
16-235キャプだからまるもでストレートRGB読み込みしているわけだが
”0〜255を一杯に使うキャプチャカード・コーデックではOFFにしてください。”
とも書いてあるが

257 :名無しさん@編集中:03/10/19 18:14
>>254は前スレ読んでないのか?
伸張派を煽るようなことはやめれ
VFAPI経由で伸張RGB読み込みする人間だっておるよ。

258 :名無しさん@編集中:03/10/19 18:18
>>225にせよ>>254にせよ
自分の手順も晒さないで断言しすぎ
ある手順では正解だが
違う手順では不正解になる
そういう発言だとあってるも何もないわけよ

259 :名無しさん@編集中:03/10/19 18:20
YUY2読み込みでも補助線は意味ないような・・・。

260 :名無しさん@編集中:03/10/19 18:22
抜け殻sage忘れてるよ抜け殻

261 :名無しさん@編集中:03/10/19 20:13
PCとTVの見え方の違いは
0-100IREをRGBにどうマッピングするかという話か思ったら
本当にヒトの見た目で話してるのな。

262 :名無しさん@編集中:03/10/19 20:25
ある意味正解だと思うです
何の為にキャプチャして何の為にエンコしてるのか……
本来の目的を忘れて数字や手順とかに縛られてる奴多すぎ

263 :名無しさん@編集中:03/10/19 20:26
huffyuvのように(?)RGB変換時に伸長されるコーデックを、
ラデ系のグラボでオーバーレイ表示すると、
伸長&伸長になってしまうのですか?


264 :263:03/10/19 20:27
あと、前スレがdat落ちしたのはいつごろでしょう
html化を心待ちにしているのですが。


265 :名無しさん@編集中:03/10/19 20:32
>>263
それはないです。

266 :名無しさん@編集中:03/10/19 20:47
>>264
http://cham.dyndns.org/list/source/up642.zip
OpenJaneのdatだけどね

267 :名無しさん@編集中:03/10/19 20:49
>本来の目的を忘れて数字や手順とかに縛られてる奴多すぎ

こういう人たちがいるから
知識や知恵となって残って横着者や後の人が結果だけを得ることが出来るんではないかなあと思うんですが。

268 :名無しさん@編集中:03/10/19 20:58
>>267
これまた正論
でも金貰ってやってる仕事じゃないんだし、自分で見てOKならそれでいいってスタンスも有りなのかなとも思う

269 :263:03/10/19 20:58
>>265
ではどうなっているのでしょうか。
YUV→RGBをグラボ側でやってるとか?


270 :名無しさん@編集中:03/10/19 21:06
>>269
旧ビデオレンダラでメディアプレーヤ再生時にPrintscreen可能なことから
オーバーレイ表示ではないと思われ。
つまりTMPGEncのプレビュー画面がディスプレイに表示されるのと同じことだと思われ。


271 :名無しさん@編集中:03/10/19 21:06
>>269
そのとおり
ハードウェアオーバーレイ表示というのは
YUV>RGBをグラボがやること、だと思ってればいいよ

272 :名無しさん@編集中:03/10/19 21:08
>>270
Huffyuvはオーバーレイ表示できますよ
環境によってはBob再生も可能(XPSP1+DX9+RADE9500p+WMP)

273 :名無しさん@編集中:03/10/19 21:11
Huffyuvのオーバーレイ表示とGDI表示の区別はどこでつければ良いのでしょう?

274 :名無しさん@編集中:03/10/19 21:13
DVDを作成する時、メニュー画面もやはり16-235にしないとまずいんでしょうか?
ペイントで適当に作ったやつじゃ駄目なんですよね?

275 :名無しさん@編集中:03/10/19 21:16
>>273
Aviutlでオーバーレイ表示オンオフすればイヤでも切り替わると思うが
何をしたいの?

276 :263=269:03/10/19 21:21
>>270-271
なるほど、だいぶ分かってきました。
では、今試しに RGB24非圧縮 で作ったデータを
AviUtlで開いてオーバーレイON/OFFすると色合いが変化しました。
(i845GE内臓で確認)
グラボにはRGBでデータが渡ってると思うのですがなんで色合いが変わるのでしょう??


277 :名無しさん@編集中:03/10/19 21:22
今の時期、一言にハードウェアオーバーレイといっても
レンダラがVMR9かVideoRendererかで違うと思うんですが。


278 :名無しさん@編集中:03/10/19 21:27
>>276
前スレでもガイシュツだが
インテル系VGAのオーバーレイ表示は非BT.601
まぁどこも一緒だけど
メーカー独自の味付けが確実にあるよ
GDIもオーバーレイもキャリブレートしておくのが基本
デフォルトはダメダメよ(インテル系はまともにキャリブレートすらできないが)

>>277
詳しく


279 :277:03/10/19 21:32
自分で書いておいててなんですが
DX9にハードウェアで対応してないビデオチップで
レンダラをVMR9に指定してメディアを再生した場合
果たしてハードウェアオーバーレイなのかソフトウェア(?)オーバーレイなのか
どちらなんでしょうかね。

280 :名無しさん@編集中:03/10/19 21:35
VMR9かVideoRendererかで色かわるか?

281 :263=269=276:03/10/19 21:39
>>278
いやそれは分かっているのですが、
>>271氏がオーバーレイんときゃグラボがYUV>RGBをやるから
GDIのときと色が違うんだ、みたいな書き方をしてたので
じゃあはじめからRGB24で作ったデータはどういう処理になってんの?
YUV>RGB処理はないからオーバーレイとGDIが一致するのか?

・・・と思って実際にやってみたら色が違ってたのでこれはなぜだろうと。


282 :名無しさん@編集中:03/10/19 21:41
>>281
オーバーレイとGDIでは持ってる補正値が違うからでは?
合わせるのがキャリブレーションの一つじゃないの?

283 :名無しさん@編集中:03/10/19 21:46
伸張読み込み派はデータを破壊して何がしたいの?
0-255の範囲で保存したらどのプレイヤーで再生しても
白とび黒つぶれで苦しむのに

284 :名無しさん@編集中:03/10/19 21:50
AviUtlのオーバーレイ表示はYUVでグラボに渡してるんじゃないの?
それはともかく、うちのRADEON9000ではhuffyuv(YUY2)を
AviUtlのGDIとオーバーレイ表示で比べて色味の違いはほとんど分からないし
AviUtlのGDIとMediaPlayerの表示でも違いは分からない。

285 :名無しさん@編集中:03/10/19 21:52
>>283
0-255がRGBなのかYUVなのか分からん

286 :名無しさん@編集中:03/10/19 21:58
ストレート変換した動画を人に見せたら
「色が薄い」・「白っぽい」だのと散々突っ込まれて凹みますた。

287 :名無しさん@編集中:03/10/19 22:00
君の周りはゲフォ厨ばかりですね

288 :名無しさん@編集中:03/10/19 22:14
>>285
どっちでも同じ
あまり理解できてないな

289 :名無しさん@編集中:03/10/19 22:16
  ) ) )        おまいら、お茶のんどけ
 ( ( (    ∧_∧
┌───┐ ( ´・ω)  从/
│      ├ (つ旦と)──┐=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~
├───┤ `u―u' .   │−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~
│      ├──────┘=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~−=≡旦~
└───┘        W\
─────               ドドドドドドドド


290 :名無しさん@編集中:03/10/19 22:28
>>288
同じじゃないよ

291 :名無しさん@編集中:03/10/19 22:31
RGBもYUVも同じと言う香具師はもれなくゲフォ厨。

292 :名無しさん@編集中:03/10/19 23:38

16-235がフルスケールなのがYUV
0-255がフルスケールなのがRGB

ってのは判った。フルスケールってのは真っ黒から真っ白の事
であってる?
より細かく分解できるのがRGBなの?


293 :名無しさん@編集中:03/10/19 23:40
>>292
間違ってる
調べなおせ

294 :名無しさん@編集中:03/10/19 23:44
>>293
調べるつもりは無い。なぜならめんどくさいからだ。

http://pc.2ch.net/test/read.cgi/avi/1061527402/l50

これの定義に従って判りやすく教えろ。

295 :名無しさん@編集中:03/10/20 00:51
誰かLを救ってやれよ

296 :名無しさん@編集中:03/10/20 01:51
以下は 非オーバーレイ の話

あの〜メディアプレーヤー9って
CODECにかかわらず伸長表示するようになったんですか?

CanopusDV再生してたんですがなんかおかしいなと思って
システムディレクトリに残ってた mplay32.exe(Version5.1)で
再生するといわゆるストレート変換で再生されていて
MediaPlayer9のほうは伸長されてるようです。

気づくの遅すぎ?

ちなみにMP9でCODECにRGB変換させる(この場合ストレート変換)
にはどうすればいいのでしょうか?

297 :名無しさん@編集中:03/10/20 22:29
知ってるがお前の態度が気に食わない

298 :名無しさん@編集中:03/10/20 22:32
教えたいがお前の態度が気に食わない

299 :名無しさん@編集中:03/10/20 22:35
分からないがお前の態度が気に食わない

300 :名無しさん@編集中:03/10/20 23:12
そんなことより総括まだー?

301 :名無しさん@編集中:03/10/20 23:17
>>1-1000

302 :名無しさん@編集中:03/10/21 00:57
まるもmpeg2VFPAIプラグインなんかで伸張読み込みする意味はなんですか?

303 :名無しさん@編集中:03/10/21 02:17
>>302
まるものとこに書いてある

304 :名無しさん@編集中:03/10/21 12:02
まるもの所とここの主張が食い違って無いか?
まるもはストレート変換についてPCで作成した0-255範囲のCGを
破綻するのを防ぐ場合に使うとしてるからスケールをそのままRGBに変換するのがこれだよな
BT601伸張について文字通り伸張してPCディスプレイで表示したとき
実際テレビで見た画面に近くするためのあると書いてる
それで、一般的には伸張を選ぶべきとも書いてる
しかし、ここのスレではAVIUTLやメディアプレイヤーで再生した段階で
強制的に表示上は伸張すると書いてあるからまるもの表示上の見栄えを
テレビに近づけるという主張と矛盾してる
まるもVFPAIでBT601伸張して読み込むと16-235範囲のデータはVAFPI経由で
0-255に伸張されAVIUTLによって-16-275に伸張された色を見ていることになるんだよな?
それに、0-255に伸張したはいいけど、圧縮するとき0-255のままデータを
残したら再生時に-16-275で表示されることになるし
だからストレート変換が正しいと思うんだがどうか?

305 :名無しさん@編集中:03/10/21 12:06
そもそもYUV-RGB変換を行わなければ全て解決だな

306 :名無しさん@編集中:03/10/21 12:59
>>304
だいぶ混乱してるようだな
もうちょっとがんばれ

307 :名無しさん@編集中:03/10/21 13:11
>>305
うむ。YUV の光が見える我等超人には YUV-RGB 変換など不要だ

308 :名無しさん@編集中:03/10/21 14:10
結論を言うと
AVIUTLの画面表示は伸張表示してるは嘘








が正しいなら全てが丸く収まる

309 :名無しさん@編集中:03/10/21 14:21
伸張はあくまでYUV→RGB変換時に起こるもの
それを理解してるか?

310 :名無しさん@編集中:03/10/21 14:41
Lはまだ混乱しとるのか?

311 :名無しさん@編集中:03/10/21 15:14
まあここでも読め。
適当にAviUtlとかBT601伸張とかストレート変換に読み替えられるでしょ。
http://www.macdtv.com/Labo/Color/

312 :名無しさん@編集中:03/10/21 15:23
まるもVFAPIプラグインで伸張読み込みしたら
圧縮時に逆操作の縮小をしなければならない
しないとプレイヤーソフトで再生時やDVDに焼いてテレビで見た場合
-15-275に伸張された白飛び黒潰れ映像が再生されるんですよね?
まるも製作所で伸張読み込みを使えというのは編集時の色をテレビに近づけるためで
圧縮時に縮小することを前提で言ってる
で、まるも製作所で圧縮時に縮小しろと書いてないのが問題なんだな

313 :名無しさん@編集中:03/10/21 15:27
-15-275とか-16-275という数値はちゃんと変換式から出した数値なのか?
単純に16-235から0-255時の増分を、さらに0-255に加算しただけなら
そうはならないんじゃないの?
どっちにしろ白飛び・黒潰れという結果は同じだが

314 :名無しさん@編集中:03/10/21 16:05
前スレが資料価値高いと聴いたのだけど、どっかにミラーないかね。

315 :名無しさん@編集中:03/10/21 17:00
>>312
圧縮時に縮小しろと書いてないのは、普通のエンコーダは圧縮時に縮小するからだ

とりあえず試してみな
同じ設定で圧縮を繰り返せば色が保持できてるのか変化していってるのか分かるだろ?

316 :名無しさん@編集中:03/10/21 17:47
>>315
とりあえずDivX5.05で試してみたが全然縮小してなかったぞ

317 :名無しさん@編集中:03/10/21 17:48
そりゃ伸張してるからだろ

318 :名無しさん@編集中:03/10/21 17:54
またはRGB変換してないか

319 :名無しさん@編集中:03/10/21 18:18
>>317-318
AVIUTLを使ってDivXでスケールを縮小して圧縮する手順を教えてください
素材はmpeg1,2からdivx,xvid,wmv9,huffyuvまで多種そろえております

320 :名無しさん@編集中:03/10/21 18:26
>>319
何がしたいの?

321 :名無しさん@編集中:03/10/21 19:43
茂木さんが伸張したほうがいいって言うから伸張します

322 :名無しさん@編集中:03/10/21 19:44
>>316
YUY2圧縮にチェックいれてないか?
RGBで渡せば縮小するよ

323 :名無しさん@編集中:03/10/21 19:53
>>319
コーデックの設定でDivXをYUY2圧縮させない
そうすれば頭がなんでも縮小
伸張済みなら縮小の結果適正なYV12空間のファイルになり
伸張してなければ縮小の結果二重圧縮された不適正なYV12空間のファイルになる

324 :名無しさん@編集中:03/10/21 19:56
>>314
>>266

325 :名無しさん@編集中:03/10/22 00:56
まだ亜空間をさまよってますか?

326 :名無しさん@編集中:03/10/22 00:58
おいら、出口が見えません。

327 :名無しさん@編集中:03/10/22 01:41
>>323
コーデックのどこをいじればいいんでしょうか?

Mpeg2VFAPIプラグインをまるも推薦の伸張設定で使ってる人居るの?

328 :名無しさん@編集中:03/10/22 05:35
>>327
環境設定>コーデックの設定

MPEGソース->WMV9エンコードのためのフィルタリングにAviutl使う人は
伸張読み込みの人もいるでしょう

329 :名無しさん@編集中:03/10/22 10:45
>>328
できなかったよ
コーデックによる伸張縮小の話は全部ガセだな

330 :名無しさん@編集中:03/10/22 10:54
なんだがもーのすごーく疑い深い人が常駐しちゃってるな
何も信じないなら何も質問しなきゃいいのに

331 :名無しさん@編集中:03/10/22 11:06
信用して実験までしたのに全部裏切られたからだよ

332 :名無しさん@編集中:03/10/22 11:09
>>331
その実験の手順を書いてみな。
絶対どこか間違ってるからw

333 :名無しさん@編集中:03/10/22 11:41
>>332
DIVX5.05で圧縮した動画を一つ用意

AVIUTL側の設定
オーバーレイ表示と非オーバーレイ表示ともに試した
環境設定>コーデックの設定>DivX5.05>YUY2で展開する YUY2で圧縮する 設定を保持する
YUY2で展開する YUY2で圧縮する は共に○○、○X、X○、XXの4通りで試した
設定を保持するは常に○
この設定でQB95でエンコード
出来上がった動画をそれぞれ波形プラグイン、見た目で確認
見た目での変化はなし、波形プラグインでの変化は同じレベルでの変動程度で
とてもスケール圧縮した結果とは思えない

こんな感じでどうでしょうか?

334 :名無しさん@編集中:03/10/22 11:54
まあ予想通りの勘違いだな
DivXをRGB展開するときに伸張が起こってるんだよ
だからエンコード時にスケール圧縮して変動なしになる

どうしてもDivXをストレート展開したいならAvisynthのConvToでも使え

335 :名無しさん@編集中:03/10/22 12:50
>>334
DIVXをRGB展開するはオーバーレイ表示するってことですよね?
どちらかというとこの段階で縮小されていたが(どちらかというと)

336 :名無しさん@編集中:03/10/22 12:54
違う

337 :名無しさん@編集中:03/10/22 13:44
結論いうと

ふだんまるもVFAPIプラグインのBT601伸張を使ってる奴は馬鹿
それをデフォで奨めるまるもも馬鹿ってことでOK?

338 :名無しさん@編集中:03/10/22 13:55
簡単に言えば、YUVのまま処理しようよという事です。

339 :名無しさん@編集中:03/10/22 14:52
m2v.aui


340 :名無しさん@編集中:03/10/22 19:18
YUV16-235の映像をPCモニタに表示した段階で
伸張されて0-255に見えるんだよ。
波形プラグインの結果が本当の値では無い
と言う事に早く気付け!

341 :名無しさん@編集中:03/10/22 19:28
>>337
おまえが一番馬鹿なのは既出か

342 :名無しさん@編集中:03/10/22 20:23
>>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が行い、圧縮変換



343 :342:03/10/22 20:29
DivXが圧縮変換することをチェックしたいなら
ストレートRGBをソースにしないとわからない
MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする(DivXがRGB->YUV変換を行う)
こうするとストレートRGBを圧縮することになるので
二重圧縮YUVになる
で、なんでそんなことしたいの?

344 :342:03/10/22 21:28
あぁそうか
m2v.vfpを伸張設定で使うのがおかしいって言ってるのか
>>343試せばわかるよ
まぁ実際使うのはm2v.auiのがいいけどな

345 :名無しさん@編集中:03/10/22 22:18
>>340
それはオーバーレイ表示したときのはなしか?なら知らんが
非オーバーレイ表示時はファイルのデータと画面表示されるデータは同じだぞ
波形プラグインの結果と表示画面は同じということにここの書き込みに惑わされず
しっかり認識しろ

346 :名無しさん@編集中:03/10/22 22:22
>>345
ver 0.99 更新履歴
メインウィンドウのオーバーレイ時の挙動を非オーバーレイ時と同じになるようにした

347 :名無しさん@編集中:03/10/22 22:44
>>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として表示される


348 :340:03/10/22 23:58
>>345
YUV > RGB をストレート変換するならその通りだが
huffyuvやDivXは伸張している。
codecが伸張するのかAVIUtilが伸張するのかの違いだけ。

ふふああのヒストグラムとAVIUtilの波形プラグインを良く見比べてみ。

349 :名無しさん@編集中:03/10/23 02:01
カノプーDV codecが普通じゃないだけ。

350 :名無しさん@編集中:03/10/23 06:12
MorganのCODECも普通じゃないんじゃなかった?

351 :名無しさん@編集中:03/10/23 11:45
有益な情報ありがdです。>>all

厨な質問ですみませんが、皆様はエンコ後の動画の色を「妥当」と
判断するのため、どのようなツールを使っていらっしゃいますか?

352 :名無しさん@編集中:03/10/23 12:10
AviUtlの波形表示プラグイン
あとは(キャリブレーションされた環境での)見た目

353 :名無しさん@編集中:03/10/23 12:21
有益な情報に見えて全然間違ってたりするから侮れない

たとえば>>348とか確かめもしないで表示画面は伸張されてると思い込んでる
イタ房だし
自分の過ちを認められないのかねぇ〜

354 :名無しさん@編集中:03/10/23 13:17
ここは議論だけでソースや実験結果なんかはまったく出ないんだね

355 :名無しさん@編集中:03/10/23 13:25
そういう流れにしたければ別にそれでもいいと思うけど
今の流れではその必要がないからね

356 :340 348:03/10/23 13:30
>>353
なんか俺の反論を期待しているみたいだな。

357 :名無しさん@編集中:03/10/23 13:37
>>356
全く
永久に勘違いしていてください

358 :名無しさん@編集中:03/10/23 14:20
>>355
知識のない煽り合いが好きな人達には今の流れは楽しいだろうね

359 :名無しさん@編集中:03/10/23 14:23
今の流れ?
初心者が質問して知識のある人が答えるってのが今の流れじゃん
なんで君は突然煽り始めてるの?

360 :名無しさん@編集中:03/10/23 14:26
>>354
出ない ×
出せない ○

361 :名無しさん@編集中:03/10/23 14:30
>>359
この流れがそう見えるおまえはすごい
脳内知識の煽り合いじゃんただの

362 :名無しさん@編集中:03/10/23 14:33
この争いは地上デジタルになったら消えるの?

363 :名無しさん@編集中:03/10/23 14:36
>>361
ごめん
煽り合いは読んでないからどうでもよかった
確かに今争ってる人が二人いるみたいだね

364 :名無しさん@編集中:03/10/23 16:59
エンコされたものが、伸張されてるかされてないかって
もう一度編集ソフトに読み込ませて、ソースと見比べりゃわかりそうなもんだが?

365 :名無しさん@編集中:03/10/23 19:14
>>353
GDI表示のキャリブレートしてないのでは?
うちでも伸張されるのだが(Huffyuv,DivX)

366 :名無しさん@編集中:03/10/23 19:18
>>354
前スレで腐るほど出てる
前スレはこのスレのチョイ上のほうでageられてるから落としてごらん

367 :340=348:03/10/23 23:32
とりあえずですが、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の範囲に収めていないとおかしな階調になります。

368 :名無しさん@編集中:03/10/23 23:47
>>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とは区別してくれ

369 :368:03/10/23 23:51
要は
BT.601変換式のCodecはYUV->RGBでもRGB->YUVでもストレート
BASICCbCr変換式のCodecはYUV->RGBは伸張、RGB->YUVは圧縮
ってこと

370 :368:03/10/23 23:59
もうひとつ蛇足だが
以上のことから
Canopus>DivXの場合
CanopusDVCodecをYUY2展開(読み込み)させれば
なんの問題もなくエンコードできる
DivX->Canopus(こんなことしないけどw)の場合
CanopusDVCodecをYUY2圧縮させれば
なんの問題もない
BT.601系CodecとBASICYCbCr系Codecの相互変換は
途中でRGBにしないかぎり問題はおきない
なぜならYUV16-235有効なのは一緒だから

371 :340=348:03/10/23 23:59
>>368
フォローどうもです。

>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は使ってはいけない?


373 :名無しさん@編集中:03/10/24 00:30
テレビキャプチャでもDVDでもはみだしてるよ。


374 :名無しさん@編集中:03/10/24 01:04
>それからMPEG2変換 > DVDオーサリング とかやってる人はご存知だと思いますが、
>たとえばCCEでエンコする場合、CCEはYUY16-235なデータを要求します。
これ嘘だろ

375 :名無しさん@編集中:03/10/24 01:12
> 画面上RGB0-255 > codec内部によりYUY16-235に圧縮 > YUY16-235の範囲のデータを持つAVI

ここの「YUY16-235の範囲のデータを持つAVI」が16-235の範囲のデータを持つという証拠は?
確か前にAVIUTLの波形プラグインはAVIデータの値をそのまま反映してると誰かが発言していたはずだが
どうなってるんだ?
見てる側からすれば言い分が2転3転してるとしか思えない

376 :名無しさん@編集中:03/10/24 03:23
AviUtl099でYUVデータを扱ったとき
ヒストグラムのYCbCrと波形プラグインでは扱うスケールが違ったりするんだよねえ。
わざわざ書くこともないと思うけど
例えば、YUV16-235なデータをYUY2読み込みすると
ヒストグラムYCbCr:YUV16-235
ヒストグラムRGB:RGB0-255
波形表示プラグイン:YUV0-255
編集画面表示:RGB0-255

だから波形表示プラグインの表示は、
編集画面のために伸張された後のデータを反映している、と言ってもいいかもしれない。

377 :名無しさん@編集中:03/10/24 03:31
言ってもいいっていうかそういうものなんじゃないのかあれは

378 :名無しさん@編集中:03/10/24 05:37
>>372
>>368-370

379 :名無しさん@編集中:03/10/24 05:45
>>374
わかってないんだよ、>>340
YUVで渡せばスケール変換が起きないってことがな
例えばYUV0-255のソースをYUY2読み込みさせれば
CCEはそのままYUV0-255のMPEGを吐くだけなんだけどな
>>371で素直にミスを認めればいいものを・・・。

380 :名無しさん@編集中:03/10/24 05:47
つーか>>340は伸張派なんで有効範囲外データはゴミかなんかだと思ってるんだろうな

381 :名無しさん@編集中:03/10/24 06:09
範囲外はゴミでしょ

382 :名無しさん@編集中:03/10/24 08:11
ゴミだけど残そうよ。

383 :名無しさん@編集中:03/10/24 08:27
ゴミじゃねえっての

384 :名無しさん@編集中:03/10/24 08:59
でも、どーせ見えないんでしょ

385 :名無しさん@編集中:03/10/24 10:37
>>384
>>311

386 :名無しさん@編集中:03/10/24 10:56
>>376
>例えば、YUV16-235なデータをYUY2読み込みすると

そのファイルがYUV16-235であるとどうして言い切れるんだ
波形表示プラグインでさえ信頼できないのに、そのデータが本当に
YUV16-235の範囲にあると言い切れる根拠は何だ?

387 :名無しさん@編集中:03/10/24 11:14
ストレート変換で
RGB 1-254 あたりになるんならYUVで16-235ってのでいいんじゃねえの?
0-255になっちゃったら、YUVで16以下235以上の可能性があるけど。

388 :名無しさん@編集中:03/10/24 13:29
だから範囲外はいらねーんだってば

389 :名無しさん@編集中:03/10/24 13:44
範囲外にデータがあった場合、サチュレートすると当然ながら内部データは変わる
そのときPCでの表示、いわゆる伸張状態では色は変わらないが、
DVDプレイヤーなどでテレビに出力する場合は色が変わってくる
ものによってはかなり変わる

なのでテレビ出力を全く考えてないならサチュレートしてもなんの問題もない
テレビ出力を考えてるならサチュレートするしないで色が変わるから好みで使い分けろ

そういうことだから範囲外はゴミだとかいらねーだとか一言で片付けるな

390 :名無しさん@編集中:03/10/24 14:31
>>388
PCだけで見るのがDTVじゃないからね。

391 :名無しさん@編集中:03/10/24 14:31
だまされないぞ!

392 :名無しさん@編集中:03/10/24 15:06
TVってYUVの0-15までと、236以降ってどの変まで表示できるのが多いの?
規格上は、その範囲は規定無し なだけだから各社さまざまなんだろうけど・・・

色温度が規定なくてもなんとなく13000-16000とかくらいに各社そろえてる
(そろった?)みたいに傾向があったりするん?

393 :名無しさん@編集中:03/10/24 17:48
で、普段おまえらは何をキャプってるの?

394 :名無しさん@編集中:03/10/24 17:53


395 :名無しさん@編集中:03/10/24 18:53
>>392
設定によりけりだけど
能力的には-20〜300くらいまでいけるよ

396 :名無しさん@編集中:03/10/24 18:58
>>386
Avisynthでつくればいいだけでしょ
Avisynthならソースだって公開されてるんだから
ソースの工程が正しいかどうかは日欧米のエンコ厨がチェックしてるよ
納得できなければ自分でチェックすればいい
そのデータが厳密にYUV16-235であるクリップを作ればいいだけだよ
で、それをAviutlの検証用に使う、と

397 :名無しさん@編集中:03/10/24 19:06
>>387
それは伸張変換

398 :名無しさん@編集中:03/10/24 19:57
>>5とか>>62を引っ張り出してくるけど
つまりアナログキャプ厨は黒に関して
ソースの中で自分がいちばん黒くしたいところをY16にしとけばいいってことかい?

399 :名無しさん@編集中:03/10/24 20:52
>>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
(つまり最低輝度や最高輝度には色を付けてはいけない)

400 :名無しさん@編集中:03/10/24 21:52
>>399
UVとCbCrは違うのだが


401 :名無しさん@編集中:03/10/24 22:20
>>400
お前アホ!
本質じゃない部分に突っ込むバカ!

402 :名無しさん@編集中:03/10/24 22:43
波形表示プラグインの601補助線の意味を教えてください

403 :名無しさん@編集中:03/10/24 22:51
>>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にしてどうする?

404 :名無しさん@編集中:03/10/24 23:01
>>403はほっといて
>>399
そんなややこしい設定はできないだろ
サチュレートすればいいだけのことだよ

405 :名無しさん@編集中:03/10/24 23:12
>>404
最高輝度は兎も角
最低輝度はYUVともに16(RGB000)でいいんでなかったっけ?

406 :名無しさん@編集中:03/10/24 23:18
>>405
いやRGB=0やRGB=255が信号扱いになるのはストレートRGBの場合であって
伸張RGBには無関係
だからYUV(16-235)の範囲ではどっちにしろ関係ない


407 :名無しさん@編集中:03/10/24 23:43
404 はほっとけと言ってるが、一応掬っておきたい
>>403
BT.601/709 では、色差は負値も符号無しで扱うために +128 して 0=128 としてるんだ

408 :名無しさん@編集中:03/10/25 00:19
>>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になるだろう?


409 :名無しさん@編集中:03/10/25 00:29
>>404
サチュレートってどうやって?
Y=230,U=V=150
この場合どうやったらいいの?

410 :名無しさん@編集中:03/10/25 01:20
>>403
で、どこが本質だと思ってるの?
CbCrとUVの違い?

俺の思う本質は括弧の中
>(つまり最低輝度や最高輝度には色を付けてはいけない)
YとUVは関連性があり、独立して考えちゃダメって点だと思うが?

411 :名無しさん@編集中:03/10/25 05:49
>>408
>Yが大きく(小さく)なるに従って、UVは取りえる振幅を小さくしないといけない。
ということはないよ。
YUV16-235の間では元から振幅幅は充分に小さいし
PCモニタやテレビという自然と比較して圧倒的に表現の幅が狭い系では
人間は色を充分区別できる。
YUV(16,239,239)とYUV(16,240,240)は違う色として見えるよ。
YUVの値が2違ったらRGBで最大8違うわけだし。
それ以前にキャプやリップだとUVの幅は規定値より狭い(限界値付近を取らない)。
>つまり最低輝度や最高輝度には色を付けてはいけない
んじゃなくて
>YとUVは関連性があり、独立して考えちゃダメって点だと思うが?
つーのはその通りだけどね。


412 :名無しさん@編集中:03/10/25 15:18
ふぬああでYUY2無圧縮録画、RGB24bit無圧縮録画したものをAVIUTLに読み込む
YUY2はRGB24を伸張したデータになった
ここでYUY2はAVIUTLで読み込むときに強制伸張、RGB24はストレートだと考えて
ふぬああでHuffyuvにして録画すればどっちのケースでも強制伸張が起きて
RGB24録画した物が伸張されYUY2録画した物と同じになるはずだったが結果は変わらず
Huffyuvは可逆圧縮なので変わりにDIVXを使うも結果は同じ

413 :名無しさん@編集中:03/10/25 15:40
>>343
おっしゃるとおりに
ストレート変換でMpeg2を読み込ませDivXの圧縮設定をYUY2で圧縮するのチェックを
入れたものと外したもので試したが
圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ

414 :名無しさん@編集中:03/10/25 16:05
大成功ですね

415 :名無しさん@編集中:03/10/25 16:26
>>411
(Y,U,V)=(16,239,239)の場合、
(R,G,B)=(177,-133,224)
になるんだが、サチュレートされて(177,0,224)
こんなので良いと思ってるの、お前?

416 :名無しさん@編集中:03/10/25 16:50
>>414
ポイントはここ

MPEG2をm2v.vfpでストレート指定で読み込ませて
YUY2圧縮なしでDivXにする(DivXがRGB->YUV変換を行う)

このYUY2圧縮なし の部分
ということはYUY2圧縮するにチェックを入れれば2重スケール圧縮にならないと受け取れる
実際はどっちに設定しても2重スケール圧縮されましたよ

417 :名無しさん@編集中:03/10/25 17:02
ん?何か問題でも?

418 :名無しさん@編集中:03/10/25 18:05
あっちのスレが高度すぎて着いていけなくなってきているのですが、

MPEG2をm2v.aui使ってAvuUtlに読み込んでDivXで出力するとした場合、
コーデックの設定で「YUY2で圧縮する」のチェックを外す

ってことでよろしいでしょうか?
すでにYUY2になっているので、


419 :名無しさん@編集中:03/10/25 18:15
よろしくないです。

420 :名無しさん@編集中:03/10/25 18:52
>>416
あぁそういう意味じゃないよ
YUY2圧縮にチェックだとBT.601変換であるCanopusDVCodecだって圧縮されるんだから
無論この場合はチェックなしだと圧縮されない
YUY2圧縮にチェックを入れるとAviutlが圧縮変換するから
DivXがRGB->YUVをするかどうかの検証にならないでしょ
だから>>343のように書いただけ
で、二重圧縮になるでしょ?
DivXはRGB->YUVに圧縮変換を行うことが証明されたじゃん
と思ったら
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってなんだ?


421 :名無しさん@編集中:03/10/25 18:55
>>418
YUY2展開・圧縮の設定の意味は
チェックあり・・・Aviutlが伸張・圧縮をおこなう
チェックなし・・・CodecがそのCodecで規定された変換式でRGB<->YUV変換をおこなう

422 :名無しさん@編集中:03/10/25 18:58
>>419>>421
AviUtlのスレで質問しようとしたらこっちに書いちゃいまいた(w
違いはAviUtlが圧縮するかコーデック側がやるかの違いで、結局どちらも圧縮されるってことですね

ありがとうございました


423 :343=420:03/10/25 19:00
あぁわかった
>圧縮したができたファイルはMpeg2をストレート変換した物と同じでしたよ
ってのは
DivXが伸張変換してRGBになるが
作成手順 で二重圧縮してるから
結果的に一段圧縮されてストレートRGBと同じ色範囲を持つってことね
あってるじゃないの


424 :343=420:03/10/25 19:01
>>422
いやBASICbCr系CODECの場合がそうだって話ね


425 :名無しさん@編集中:03/10/25 19:05
>>422
せっかくm2v.auiで飽和させずに読み込んだのに
YUY2圧縮のチェックをはずしたら飽和してしまうよ。


426 :343=420:03/10/25 19:15
>>425
そこもかw
まぁ俺的には
せっかくm2v.auiで読み込んだのにチェックはずしたらRGB経由になるよ
と言いたいところだが、多分質問者にとってはどーでもいいだろうな

427 :名無しさん@編集中:03/10/25 20:40
>>421
YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
これは、Aviutlが伸張して表示していて
チェックなしだと、ビデオ展開形式がRGBになるけど、
これは、コーデックがYUV<->RGB変換して
表示させているということでいいでしょうか?

428 :名無しさん@編集中:03/10/25 21:07
>>427

出力するときのYUY2圧縮もおんなじ

429 :428:03/10/25 21:10
あぁちがうw
表示の話か
>>YUY2展開にチェックつけると、ビデオ展開形式がYUY2になりますが
>>これは、Aviutlが伸張して表示していて
>>チェックなしだと、ビデオ展開形式がRGBになるけど、
ここまではそのとおり
で、
RGB後内部YUV48にマッピングされ
内部YUV48->RGB24にAviutlが変換して表示する

430 :名無しさん@編集中:03/10/25 22:48
で、AVIUTLの波形表示プラグインでBT601線にあわせてエンコしたとある?

431 :名無しさん@編集中:03/10/25 23:07
>>430
だからそういう用途で使うものではない、という結論だったはずだが
あくまでもチェック用
基本的にRGB読み込みの時に使うものでしょうに

432 :名無しさん@編集中:03/10/25 23:17
基本的にRGB読み込みの時に使うものでしょうに

基本的にストレートRGB読み込みの時に使うものでしょうに

”0〜255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB

433 :名無しさん@編集中:03/10/26 01:12
>>431
何のチェックに使えるんだ?
>>432
ストレートRGB読み込みでも最終的に0−255ラインに合わせればいいから
601ラインは不必要では?

>”0〜255を一杯に使うキャプチャカード・コーデックではOFFにしてください。” by GNB

0−255を一杯に使うキャプチャーカードって何だよ
0−255を一杯に使うコーデックって何だよ
ちゃんとここを説明しておかないと混乱の元になるわな
だいたい0−255を一杯に使わないコーデックってあるのか?
コーデックのスケールの概念を持たないのが普通で、その知らない人たちに
たった一行でとても重要なことをあっさり済ませる態度が気にきらない
お陰で何ヶ月という時間を無駄にしたか分からん

434 :名無しさん@編集中:03/10/26 01:47
単にお前が理解していないだけだろ。

435 :名無しさん@編集中:03/10/26 01:47
んなのに引っかかるの一人ぐらいのものだろう

ストレート変換しなきゃ黒レベルが適切かどうか判定できない
(SMPTE カラーバーの -5% 領域が意味を持たない)から BT.601
チェックは一応意味があるし

436 :名無しさん@編集中:03/10/26 01:51
BT8x8とかCXとかだと、16〜253の範囲の値をとる。
0-15,254,255は存在しない。
こんなキャプチャボードの場合、16-235で調整するわけ。
別に他のキャプチャボードでも16-235で調整するのが混乱しない標準設定だと思うけど。

437 :名無しさん@編集中:03/10/26 02:10
>>435
伸張読み込みして0-255の範囲に入ってたら黒レベルは適切だと分かるんだがな
>>436
それはBT,CXチップがアナログ信号の16-253の範囲をサンプリングしてデジタル化するわけですか?
それで16-235に調整してもファイルの値は31-215なのですが、それに意味があるのか分からない

438 :名無しさん@編集中:03/10/26 02:16
そもそもアナログ信号を
16〜253の範囲の値をとる
ってICがどうやって判断してるの?(Pu

439 :名無しさん@編集中:03/10/26 02:28
>>438
誰に対するレスかしら無いけど信号の強度をICが理解できなくて
どうやってデジタルデータに変換するの?

440 :名無しさん@編集中:03/10/26 02:42
>>437
なにを勘違いしてるのか解らんが、アナログ信号のmVは相対的なものだよ。
信号的に0IREはXXmVて決まってるかも知れんが、
ICの場合、Gain調整で上下限を決めてるだけ。
だから、プロパティ設定で、Brightness,Contrast,Hue,Saturationの設定により
変化するわけ。
で、元のアナログ値じゃなくて取り込んだ後のデジタルデータが、16-253の範囲になっちゃうってこと。

441 :440:03/10/26 02:44
だから31-215なんかにはならない。あくまで16-253

442 :名無しさん@編集中:03/10/26 02:53
>>440
CX系は持って無いので知りませんが、明るさやコントラストを
どんなに上げ下げして真っ白真っ黒な画像をキャプチャーしても
波形表示プラグインでみれば16-253のラインでYの値が切れてるんですか?
SAA系はデータとしてなら-20〜270くらいまで取れてるようなんですけど

443 :名無しさん@編集中:03/10/26 03:28
>>442
いったいどうやって0-255を超えるデータを保持できるの?

444 :名無しさん@編集中:03/10/26 03:31
なんだか素人の猛者がうじゃうじゃ湧いて出る気がするな。

445 :名無しさん@編集中:03/10/26 03:41
>>442

>SAA系はデータとしてなら-20〜270くらいまで取れてるようなんですけど

Datasheetに "Sampling according ITU-R BT.601" と書いてあるぞ。
輝度やコントラストを弄れば波形は動くが、取り込みのスパンはあくまでも16-235の範囲内。

446 :名無しさん@編集中:03/10/26 04:04
>>445
SAA7133でYUY2で取り込んだデータなんだけど、コントラスト弄ると
0〜255のデータがちゃんと入ってるんだが、これは
SAA71xxで取り込んだ時点じゃ16-235だけど、その後スケール変換して0-255にされたってことですか?
(ちなみにバイナリエディタで覗いた16進数ダンプデータで確認)

447 :名無しさん@編集中:03/10/26 05:04
素人がこんな難しいスレに質問投げてすみません。

専門的な話をばっさり切ってしまって大雑把に言えば、TV放送開始前の
カラーパターンのなかの、黒0%のところがPC上で(R,G,B)=(0,0,0)に
なるように調整し、白100%の部分がPC上で(R,G,B)=(255,255,255)になる
ようにすればよいのでしょうか?

白100%の部分が(R,G,B)=(255,255,255)となるように調整すると、実際に
放送をキャプチャしたものが白飛びを起こすので何か違うような気もする
んですが・・・

#MTV2000

448 :名無しさん@編集中:03/10/26 05:13
放送されたカラーバーがそもそもそんな綺麗な数字ではないはず


449 :名無しさん@編集中:03/10/26 05:23
>>447
放送局のカラーバーはあまり信じないほうがいい
とくに明るさ・コントラストはカラーバーを使わなくても調整できるから必要ない
色合い・色の濃さは他に基準がないのでカラーバーを使うしかないけど
最終的には見た目を信じるしかないね

450 :447:03/10/26 05:25
>>448
えっと、画面下1/3に表示されているグレースケールの中の、「左から
2つ目の白い四角」が白100%で「一番左の黒い四角」が黒0%と言うつ
もりで書きました。

451 :名無しさん@編集中:03/10/26 05:28
SMPTEカラーバーなら一番左は黒じゃないし0じゃないよ

452 :447:03/10/26 05:46
>>451
一番左→一番右の間違いです。すみません。恥ずかしいのでsage


453 :名無しさん@編集中:03/10/26 09:09
>>447
カラーバー自体は信用していいんだけど、
それにあってない番組があるってことで。
厳密にあわせて来ない制作、編集側と、
信号管理がいい加減な局側の問題だな。

454 :445:03/10/26 09:09
>>446

codecにhuffyuvを使っているならね。




455 :名無しさん@編集中:03/10/26 11:41
>>443
ふぬああさんに聞いてください
>>445
広い範囲でとって後で色調調整してより厳密な色を取得したのは
ただの勘違いだったんですね

456 :名無しさん@編集中:03/10/26 15:27
>>447
MTV2000使ってる時点でそのへんは「機械任せ」になるんだけど。
望むと望まざるにかかわらず。
(G.I.ワークスのページでもそこら辺についての記述あり)
エンコ時に1フレームずつ手動で調整するわけにもいかないだろ?


457 :名無しさん@編集中:03/10/26 15:52
AVIキャプなら自分で調整できる

458 :名無しさん@編集中:03/10/26 16:45
難しい話は分からないのでもう見た目で調整することにしました。

459 :名無しさん@編集中:03/10/26 17:00
>>458
キャプチャレベルは多少控えめに設定しておくことがポイント。
その後、編集ソフトで拡張補正するのが吉。

460 :名無しさん@編集中:03/10/27 13:57
CS23881って、カノプのより100位色が薄い気がするんだけど…
aviutlで100位濃くするべき?

461 :名無しさん@編集中:03/10/27 17:34
>>460
CX23881のことだと思いますが、
カノプのと同じ色がいいと思ったらそうしてもいいかと。
ただ、カノプも独自の味付けを色に施しているはずです。

色の好みって結構個人差があるから、自分の納得いくようにしても
いいと思う。

一度カラーバーキャプしてAviutlの波形表示プラグインで見てみれば
参考になるかもしれません。

462 :名無しさん@編集中:03/10/27 23:05
>CS23881
CX23881の間違えでした

以前同じ設定でキャプしたカラーバーを使って、
Aviutlの波形表示プラグインで調べてみましたが、
やはり薄すぎる様でチョット鬱。

でも、色調整したところかなりいい感じになりました。
感謝。

463 :名無しさん@編集中:03/10/28 22:31
>>453は結構なバカ。まるで分かっていない。

464 :名無しさん@編集中:03/10/28 23:40
>>463
あまりにわかりきっていることなんで
スルーしとけばよろしい

465 :名無しさん@編集中:03/10/29 00:21
デジタル放送の話であり、局の友人から下のデータが正しいというのを
確認してあり、そのままコピーしたという前提なら彼は
正しい。
まちがってるのは463-464

466 :名無しさん@編集中:03/10/29 00:25
このスレでコンセンサスがとれた話題ってありますでしょうか?
おいら全然わかんないんで確実な所から理解していきたいです(;´Д`)

467 :名無しさん@編集中:03/10/29 00:41
>>466
一般論で話す奴、
自分の環境でだけで話す奴、
極端な場合や例外を取り上げて反論する奴、
現実を無視して理論的な話だけで反論する奴、
揚げ足とる奴、
なんか入れ混じっているけど、概ねコンセンサスは取れてる。
結論が出てる話に、特殊環境や極例を持ち出してきて話題にしてるだけ。

468 :466:03/10/29 01:12
>>467
なるほど、よくわかりました。
ガンガッテ学んでいきます。

469 :名無しさん@編集中:03/10/30 17:41
>>459
何でさ?
キャプ後の色補正は減色されるんだから、キャプ時に調整した方がいいじゃん。

470 :名無しさん@編集中:03/10/30 18:21
白とび防止でしょ

471 :名無しさん@編集中:03/11/03 00:49
Lが救われてから話題がないな

472 :名無しさん@編集中:03/11/08 18:01
本日は晴天なり 本日は晴天なり

473 :名無しさん@編集中:03/11/10 09:20
>>472
雨降ってるし
(・∀・)カエレ!!

474 :名無しさん@編集中:03/11/10 18:01
>>473
二日前の天気に文句言っても...

475 :名無しさん@編集中:03/11/10 18:08
ワラタw

476 :名無しさん@編集中:03/11/10 20:52
>>471
奴が帰ってきたぞ

477 :名無しさん@編集中:03/11/10 21:13
>>476
どのスレ?

478 :名無しさん@編集中:03/11/10 21:42
>>476
何時の間にか奴はバージョンアップされてるぞ(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経由で読み込み)

480 :名無しさん@編集中:03/11/13 00:02
質問が悪い
質問自体がすでに間違ってる
質問からして何も分かってないのが伝わってくる

ただ、何が聞きたいかは分かる
もしその質問に答えようと思ったら、30分ぐらいかけて長文を作成しなければならない
もちろんいろんなサイトへのリンクも貼りつつね

そんな面倒なことをする人はなかなかいない
とりあえず質問からしてちゃんと理解できてないみたいですよ?という意味で
( ゚Д゚)ハァ?
( ゚Д゚)ポカーン
( ´,_ゝ`)プッ
という優しい反応が返ってきたということだよ

481 :名無しさん@編集中:03/11/13 00:05
>>479
DivXのデコーダの設定ぐらいかけよ

482 :名無しさん@編集中:03/11/13 01:05
>>481
すみませんッ!
クオリティレベルを最低にした以外はデフォルトです


483 :名無しさん@編集中:03/11/13 05:36
>>480
非圧縮って非圧縮RGBか?
それはRGBオーバーレイになるんでDivXの再生のときとは無関係
DivXはYUVオーバーレイ
また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
といっているがYUY2展開はオンオフ?
作成するときもYUY2展開はオンオフ?
そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ?

484 :483:03/11/13 05:36
>>479だった・・・

485 :483:03/11/13 05:39
あとAviutlのプレビューじゃなくてオーバレイ表示オンと比較してくれ

486 :479:03/11/14 01:57
>>483
すみません返事が遅れてしまいました

> あとAviutlのプレビューじゃなくてオーバレイ表示オンと比較してくれ

まずこれですが、オーバーレイ表示をオンにすると暗くなります


> 非圧縮って非圧縮RGBか?
> それはRGBオーバーレイになるんでDivXの再生のときとは無関係
> DivXはYUVオーバーレイ

大変勉強になりました
オーバーレイには1種類しかないと思っていましたので


> また、”このDivXファイルをAviUtlで読み込んでみると、これもプレビューと同じ色です。”
> といっているがYUY2展開はオンオフ?
> 作成するときもYUY2展開はオンオフ?

よくわからないのですべてオンにしております


> そもそも元のMPEGをWMP再生させたときと比べるとどうなんだ?

元のMPEG2をメディアクルーズで再生している際は、元の色(暗くない)で再生されます

やはりオーバーレイがおかしいのでしょうか?
心配なのはDivXの作成方法が正しくないから暗くなってしまったのではないかということなのです
ビデオカードの設定でオーバーレイの色合いを変えられますが、単純に非オーバーレイと同じ色にするという項目はないようですね
目視で変更する以外に方法があるのでしょうか?
質問ばかりですみませんが、よろしくお願いいたします

487 :483:03/11/14 05:29
>>486
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もすべて色が直りました。
どうもありがとうございました

489 :名無しさん@編集中:03/11/21 02:14
ふぬああでRGB録画すると色が薄いんだけど何ででしょうか?

490 :名無しさん@編集中:03/11/21 03:13
それはたぶんストレート展開されてるからだね

491 :名無しさん@編集中:03/11/29 13:41
>>487が見たい…
同じようなことで悩んでるぽいです…。

492 :名無しさん@編集中:03/11/29 16:54
>>487
DAT落ち?

493 :名無しさん@編集中:03/11/29 19:31
>>491
DirectX9からくっついてくるVMR9の仕業
VMR9経由だと本来
ファイル>デコーダ(コーデック)がYUVへデコード>グラボがRGBへ変換>モニタ(ハードウェアYUVオーバーレイ)
ファイル>デコーダ(コーデック)がRGBへデコード>グラボ>モニタ(いままでのビデオレンダラーやGDI)
だったものが
ファイル>デコーダ(コーデック)がYUVへデコード>VMR9がRGBへ変換>モニタ
になる
プレイヤーがVMR9配下だとYUV->RGBはすべてVMR9が行う
デコーダによるRGB変換が起こらないため
デコーダ(コーデック)毎の色味の違いは起こらない
が、
VMR9の色調整をする方法が現状では、ない
また旧VMRと異なりいかなるWinでも動作する
自動ソフトウェアBob出力とか、いいとこもあるんだがな>VMR9

494 :名無しさん@編集中:03/11/29 19:37
>>493
ふむふむ。ありがとうございます。
でもDirectX9入れてないんですよね…。コレを機に入れるべきか。
現状再生でごまかしてるんで、もうちょっと悩んでみます。

495 :名無しさん@編集中:03/11/29 20:49
まあDX9ハードじゃなければ無理にVMR9を使う必要はないよ。
D3DがしょぼいビデオチップでVMR9再生したところで
ハードウェアOverlayに比べてパフォーマンスが(画質も?)低下するだけだから。

496 :名無しさん@編集中:03/11/29 21:09
>>495
DX9だとHuffyuのバグが直ってるんじゃなかったっけ?
メリットそれぐらいか?

497 :名無しさん@編集中:03/11/29 21:45
>>496
huffyuのバグじゃなくてmsyuv.dllの仕様。
それとDX9を入れてても旧オーバーレイは使えるからレンダラは好きなのにすればいい。
つまりDX9にする必要は無いということではなくて、レンダラをVMR9にする必要は無いと言うこと。

498 :名無しさん@編集中:03/11/29 22:20
結構常駐者はチェックしてるのね、このスレ
やっぱ質問者がいないとネタがないだけか

499 :名無しさん@編集中:03/12/02 03:57
このスレで勉強させてもらって Y をAVIUTLの波形プラグインで調整する方法は分かったのですが
Cb Crは基準線が無いため合わせ方が分かりません
みなさん、どんな風に調整してますか?

500 :名無しさん@編集中:03/12/02 16:11
>>499
ベクトル表示にて

501 :名無しさん@編集中:03/12/02 17:14
まず、信頼できるSMPTEカラーバーが手に入りにくい。
これが色で苦労する最大の原因だと思う。

502 :名無しさん@編集中:03/12/02 17:40
全然最大じゃないと思う。

503 :名無しさん@編集中:03/12/02 18:22
>>501
もれは夜中にCSで流れてたの使ってるが、これ自体絶対色調がおかしいと思う

504 :名無しさん@編集中:03/12/02 19:03
>>503
論外

505 :名無しさん@編集中:03/12/02 19:10
俺は自分で作ったよ
でも表示装置のキャリブレートぐらいにしか使わないし
なくても普通は大丈夫だと思うけど

506 :名無しさん@編集中:03/12/02 19:37
色を合わせるのが難しいね。
・まず表示装置を、自分でカラーバー作成して目視して合わせる。
・その後、キャプチャを通して放送電波のカラーバーをキャプチャ。
 これを作成したカラーバーに合わせるように調整。
ちゃんとした測定機械が無いから、波形表示プラグインとかColorYUY2とか使い、
最後は目視で微調整。結局全然いい加減なものになってしまう。
まあ最終的には「(調整を)やった」という自己満足だけか。
・その後、各番組をキャプチャしても、番組ごとにレベルが違ってて
 結局またまた色補正することになっちゃうし。

507 :名無しさん@編集中:03/12/02 19:46
ペイントツールでカラーバーをbitmapで作成(これは自分で作らなくてもWeb探せば簡単に見つかる)

AVIにする

MPEG2にする

DVDに焼く

キャプ(以下略

このDVD、一枚千円ぐらいでヤフオクに出したら売れるかな

508 :名無しさん@編集中:03/12/02 20:01
>>507
普通、DVDプレーヤーの再生画像は綺麗に見えるようにメーカーの調整がされている。
なのでそれじゃ全然リファレンスにならない。

509 :名無しさん@編集中:03/12/02 20:35
>>507
なんだよ、>>507の「MPEG2にする」まで実行したのにw

510 :名無しさん@編集中:03/12/02 23:26
VideoGateでがんばる。、

511 :名無しさん@編集中:03/12/08 08:36
SAAチップは緑を下げた方がいいのかな?
下げたら下げたで赤っぽくなるのが悩みなのだが

512 :名無しさん@編集中:03/12/08 09:41
赤くならない程度に下げるとグッ

513 :名無しさん@編集中:03/12/08 19:29
ほんと糞の役にも立たないレスだな

514 :名無しさん@編集中:03/12/08 19:59
緑を下げるって何をする気だ?

515 :名無しさん@編集中:03/12/08 22:56
>>514
小川を後列に回すということだ

516 :名無しさん@編集中:03/12/09 00:15
なるほど

517 :名無しさん@編集中:03/12/09 08:39
>>514-516

>>513

518 :名無しさん@編集中:03/12/10 09:03
彩度を上げたいんだけど、avisynthのColorYUY2だとどう記述すればいいのかよくわからない

Y、U、V どれをどういじれば彩度が上がるのか教えて下さい


519 :名無しさん@編集中:03/12/10 09:38
Yは輝度、UとVは色差
cont_uとcont_vを同じ数値ずつプラスすれば彩度が上がる

520 :名無しさん@編集中:03/12/10 09:58
>>519
即レスthx
早速試してみるよ

521 :520:03/12/10 10:13
ありがとう
上手くいきました

彩度を上げると見栄えが良くなるね
そのぶん縮まなくなるけど


522 :名無しさん@編集中:03/12/11 12:07
わらひもある日突然WMP9の主にDivXあたりが妙な色合いになって
>>479と一緒です。オーバーレイ全オフでましになったけど
Media Player ClassicでVMR9オフで更にましに。
ただなんつうか好きな色味がWMCだけになってもうた。まあテレビアウトもするからいいっすけど

523 :名無しさん@編集中:03/12/12 01:10
なんつうかそれはちょっと違うような オーバーレイしなきゃそもそもテレビに出ないんじゃ・・・
プレイヤいじるんじゃなしに画面のオーバーレイをいぢれ
明るさいぢるだけで希望の近づける事は出来るから
要はAviUtlで見れる色味じゃないのは何故?と思ってるわけでしょう。
そこで見れる色味はオーバーレイ無視されてるはずだから

524 :名無しさん@編集中:03/12/12 01:12
もちろんオーバーレイ表示にしてみる方法も知ってるよな? 479
知らないみたいだから

525 :名無しさん@編集中:03/12/13 05:58
Aviutl上でGDIとオーバーレイの色味が同じになるように調整しても
VMR9再生だと色が変わるが・・・

526 :名無しさん@編集中:03/12/16 09:22
>>523
VMR9でオーバーレイの調整って出来るの?

527 :名無しさん@編集中:03/12/16 09:35
VMR9は、GDI表示とも、オーバーレイ表示とも違うと思うが?
これは、Videoチップの3D表示機能を使って表示させることだよ。

528 :名無しさん@編集中:03/12/16 12:35
無知でスマソ。どうも有り難う。

529 :名無しさん@編集中:03/12/16 13:54
まあ今のところオーバーレイ表示の方が、画質(10bitだし)も良いし、帯域も使わないし良いよね。
でも今後のビデオチップ如何によってはVMR表示の方が良くなるかも。

530 :名無しさん@編集中:03/12/21 14:51
ソフト何もインストしてないのに色が濃い 
と思ったらディスプレイのコントラスト設定を大幅に下げてただけだった

531 :名無しさん@編集中:03/12/21 19:10
以前XviDは伸張・圧縮を行うと書いているレスを見たが、伸張・圧縮は行わないよ。
バイナリによって違うのか?
当方 Koepi's Stable を使用している。
MS-MPEGやDivX4.12も同様。

532 :名無しさん@編集中:03/12/21 19:24
>>531
以前も現在もXviDもDivXも圧縮伸張しているけど?
まあ俺はRGBで処理することも見ることもないからストレートでも圧縮伸張でも関係ないんだが。

533 :名無しさん@編集中:03/12/21 19:31
>>532

2行目の意味が分からない???


534 :名無しさん@編集中:03/12/21 20:12
>>532
してないよ。
勘違いしているんじゃないの?

535 :名無しさん@編集中:03/12/21 20:35
突然わけの分からんことを言い出す奴が現れたな
詳細を確認するのも面倒だからほっとくか

536 :名無しさん@編集中:03/12/21 20:57
>>535
そこまで言ったら、取り敢えず指摘だけでもしておくべし。


537 :名無しさん@編集中:03/12/21 22:21
してるよ
YUY入力してしてないとかいってんじゃないの?

538 :名無しさん@編集中:03/12/22 01:21
>>533
RGBで見ることもないってのが判らなかったんだろう?
確かに表示はRGBだけど、表示の仕方がYUVオーバーレイだから、XviDはYV12データを渡すだけ。
あとはビデオカードの仕様によるってだけ。
XviDの変換方法とは無関係だということを言いたかった。

539 :名無しさん@編集中:03/12/22 18:22
してるとか、してないとか言ったって環境を書かないと分からない。
参考にもならない。


540 :名無しさん@編集中:03/12/22 19:21
CODECが圧縮・伸張しているかどうか?だろ?
それは
そのCODECにRGBを渡したときに圧縮するか?
そのCODECにRGB展開させたときに伸張するか?
って意味だよな
YUVで入力させたときや再生・表示させたときにどうなるか、は
CODECの圧縮・伸張とは無関係(というか環境、手段に依存)
MPEG4系CODEC(クローン含む)はみんな圧縮・伸張型だよ
というより圧縮・伸張型じゃないのって
MotionJPEGの一部とCanopusDV以外あるのか?
HuffyuvSは独自型だし

541 :名無しさん@編集中:03/12/22 22:15
DVは圧縮するだろ

542 :名無しさん@編集中:03/12/22 23:26
>>541
CanopusDVはしないよ
RGB食わすとストレートでYUVになる

543 :名無しさん@編集中:03/12/22 23:32
まさか・・・
伸張の対義語で使う”圧縮”と
可逆圧縮などで使う”圧縮”の
区別がついてないわけじゃないよな?

544 :名無しさん@編集中:03/12/22 23:56
>>543
もしそんな勘違いしてたら、MotionJPEGも全部が圧縮って書いていそうなもんだが。

545 :名無しさん@編集中:03/12/23 00:08
>>544
反DV・Huffyuvマンセー厨のなかには
MotionJPEGを知らないヤシもおろう

546 :名無しさん@編集中:03/12/23 00:50
>>542
YUVっつったって4:1:1だろ?

547 :名無しさん@編集中:03/12/23 01:10
DVって1/5圧縮ではないのですか?

548 :名無しさん@編集中:03/12/23 15:24
コーデックの伸縮の可否をどうのようにして検証しているんだ?
ファイルのスケールが違っても、表示上は見分けがつかないと思うんだけど?


549 :名無しさん@編集中:03/12/23 15:27
みんな英語読んでるんだよ

550 :名無しさん@編集中:03/12/23 15:50
まじれすすると、ソースコード読んだりメモリ上に展開されたデータ読んだり圧縮されたデータ読んだり

551 :名無しさん@編集中:03/12/23 15:54
>>550
マジレスではないな。

552 :名無しさん@編集中:03/12/23 17:12
「コーデックが伸縮しない場合」

ソース(MPEG2)を準備する。
(a)
AVIUTLでYUY2圧縮オンにしてAVI出力する。−1
それをAVIUTLでYUY2展開オンで読み込む。+1 ∴±0 -> 表示:1
(b)
AVIUTLでYUY2圧縮オフにしてAVI出力する。0
それをAVIUTLでYUY2展開オフで読み込む。0 ∴±0 -> 表示:0


「コーデックが伸縮する場合」

ソース(MPEG2)を準備する。
(a)
AVIUTLでYUY2圧縮オンにしてAVI出力する。−1
それをAVIUTLでYUY2展開オンで読み込む。+1 ∴±0 -> 表示:1
(b)
AVIUTLでYUY2圧縮オフにしてAVI出力する。−1
それをAVIUTLでYUY2展開オフで読み込む。+1 ∴±0 -> 表示:1

※(a)と(b)が一致しているのでコーデックは伸縮する。

こういう理解をしているんだが?


553 :名無しさん@編集中:03/12/23 17:14
ぺぐ2をソースにしてる時点で問題外

554 :名無しさん@編集中:03/12/23 17:22
>>553

的外れなレスだな。
コーデックのスケール圧縮・伸張を判断する例なんだが。

555 :名無しさん@編集中:03/12/23 17:30
553は映像を見てコーデックの区別が付くようだ。(w

556 :名無しさん@編集中:03/12/23 17:55
どうでもいい話が展開してるな
相手をするのも面倒だしほっとくか

557 :名無しさん@編集中:03/12/23 18:05
>>556
それならいちいち書き込むな。

558 :名無しさん@編集中:03/12/23 18:26
>>555
アニメならすぐにわかるよ
汚いのは間違いなくMPEG2ソース

559 :名無しさん@編集中:03/12/23 18:57
>>552
正解

560 :名無しさん@編集中:03/12/25 23:22
2. 汎用性・拡張性に優れた動画編集エンジン “VME(Video Mastering Engine)” 新規搭載
TMPGEnc 3.0 XPress の動画制御エンジンとして新たにVMEを開発し、搭載しました。
VMEは動画の入力から加工、出力までを総合的に扱う専用エンジンとして動画を扱う上で優れたパフォーマンスを発揮します。 RGB色空間に加えYUV色空間にも対応し、さらなる高速化を実現しました。
(※一部フィルターはYUV色空間に対応しておりませんので、RGB色空間での処理となります)

ついにきたか

561 :名無しさん@編集中:03/12/25 23:26
それでもCCEのがいいと思うヤシ↓

562 :名無しさん@編集中:03/12/25 23:28
エンコーダは使ってみないことにはなんとも・・・

563 :名無しさん@編集中:03/12/27 01:12
>>540
独自ってなんだよ

564 :445:03/12/27 13:39
独自じゃなくて ストレート(伸張、圧縮しない)だと思うが。

565 :名無しさん@編集中:03/12/27 20:31
>>564
伸張しないが圧縮する。
そのためHuffyuvS(YUY2)>RGB>HuffyuvS(YUY2)を繰り返すと
どんどんYUV範囲がシュリンクしていく。

566 :565:03/12/27 20:33
勿論Conv.YUVを使えば圧縮しない。
というかそのためのオプション。

567 :名無しさん@編集中:03/12/27 21:07
YUV使ってる分にはSも無印も同じということでよいか


568 :565:03/12/27 21:11
>>567
そ。

569 :445:03/12/27 23:21
なるほど!

570 :名無しさん@編集中:03/12/29 20:34
で、色は再生時にいじるのがベストなんですか?

571 :名無しさん@編集中:03/12/29 21:04
>>570
まあ、やりたいようにやればいいんだけど、自分なりのルールを
決めておいた方がいいね。


572 :名無しさん@編集中:03/12/30 09:00
俺はいつもYC伸張してるよ。TV出力できる環境のほうが少ないしな。
手軽にPCで見れるってことがいい。

573 :名無しさん@編集中:03/12/30 11:49
未だにTV出力云々でYC伸張するのしないの言ってる人がいるのか。

574 :名無しさん@編集中:03/12/30 13:30
>>572
DTV板住人とは思えんな

575 :名無しさん@編集中:03/12/30 13:54
1、画像の調整の明るさ、コントラストを調整
2、Huffyuvでカラーバーをキャプ
3、aviutlでコーデックの設定でHuffyuv v2.1.1のYUY2で展開する、YUY2圧縮する、圧縮の設定を保持するにチェック
波形表示の補助線をCCIR601用にするにチェック入れて確認

1、2、3の繰り返しでチャンネル毎に調整したのを基本に、エンコ時にYC拡張してた
今まで間違てたか?


576 :名無しさん@編集中:03/12/30 14:02
ビデオカードが勝手に伸張してしまうのですがどうすればいいですか?

577 :名無しさん@編集中:03/12/30 14:08
>>572はウンコスレ住人

578 :名無しさん@編集中:03/12/30 14:28
>>575
コントラスト薄いと感じない?


579 :名無しさん@編集中:03/12/30 14:59
http://pc.2ch.net/test/read.cgi/avi/1072604425/144

580 :名無しさん@編集中:03/12/30 15:42
>>575
間違ってはいないが普通じゃない
キャプボの能力を使い切ってない
とはいえ大した差はないとは思うけど

581 :名無しさん@編集中:03/12/30 17:09
>>575
http://pc.2ch.net/test/read.cgi/avi/1072604425/180


582 :名無しさん@編集中:03/12/30 17:49
YUY2展開圧縮しといて、なんでYC拡張するのやら

583 :名無しさん@編集中:03/12/30 20:01
坊やだからさ

584 :名無しさん@編集中:03/12/30 20:07
坊やでもマナー違反は如何なものか。


585 :名無しさん@編集中:03/12/31 00:27
VFAPIConvでaviにした場合って、YUY2のデータでも強制的に
RGBに変換されるってどこかで見た気がするんだけど、ホント?

586 :名無しさん@編集中:03/12/31 00:37
>>585
本当もなにもVFAPI(Conv .d2v .aup .tbr)って全部RGBだよ

587 :名無しさん@編集中:03/12/31 00:51
>>585
ttp://jumper-x.hp.infoseek.co.jp/begin/column/1/
プログラム読めるなら↓見てもわかる
ttp://www.yks.ne.jp/~hori/data/VFAPI.zip

588 :名無しさん@編集中:03/12/31 03:11
しかしこのスレは同じ話題が何度もループするよね。

589 :名無しさん@編集中:03/12/31 03:59
そういうスレだからな
新しいことなんてほとんどない
分からなくなった人や誘導された人が聞きに来るだけ

590 :名無しさん@編集中:03/12/31 09:04
インタレスレ、アスペクトスレもそうだからな。
勇者がHPにまとめてくれれば三つともいらないんだよね。

591 :名無しさん@編集中:03/12/31 09:55
でも似非勇者がまとめたHPは結構あるよな。内容はアレだが・・・。

592 :名無しさん@編集中:03/12/31 11:48
YUY2 と YUV422 の違いについて教えてください。
どっちも16bitで同じような気がするのですが…。

593 :名無しさん@編集中:03/12/31 12:19
ttp://www.fourcc.org/yuv.php

ここが詳しい

594 :名無しさん@編集中:03/12/31 17:42
ttp://vision.kuee.kyoto-u.ac.jp/~hiroaki/firewire/yuv.html
日本語キボンヌならこちら

595 :名無しさん@編集中:04/01/01 02:48
うんちくはどーでもいいから君望を正しい色に補正してみろ
できねーから

596 :名無しさん@編集中:04/01/01 05:14
その>>594のヒロアキって奴は、なにか勘違いしてるな。
京大のくせに頭悪い!

597 :名無しさん@編集中:04/01/01 08:47
年明けそうそう”正しい色”厨か
”正しい色”再現は不可能ってことでとっくに決着ついてるのに

598 :名無しさん@編集中:04/01/01 13:10
>>596は本当は何も分かってない中卒です



599 :名無しさん@編集中:04/01/01 13:19
>>596
学歴とアタマの良し悪しは、必ずしも一致しないのだよ。
君も自信を持ちなさい。


600 :名無しさん@編集中:04/01/01 23:18
お、やっとヒロアキが登場したな。
あんたの書いてる式、間違ってるよ。
叶社員よりバカだね

601 :名無しさん@編集中:04/01/01 23:37
このサイト、2002.2で更新とまってる廃墟だし
本人がこんなとこ書くとは思えないがな
突っ込みだったらメールやれば?
メアドも死んでるような気もするが

602 :名無しさん@編集中:04/01/02 00:52
Last Modified 2001/07/17
って書いてある。廃墟。
リンクをたどっていくと、現在は京大の助手をやってるみたいだな
専門は
マルチメディア統合
時系列パターン認識
マン・マシン・インタラクション
>>600は論戦を挑んで来いよ


603 :名無しさん@編集中:04/01/02 01:17
助手になれるってことは成績も上位だな。
一流大の一流と戦争。

604 :名無しさん@編集中:04/01/02 01:23
勝ったらなにくれる?

605 :名無しさん@編集中:04/01/02 01:38
フーン

606 :名無しさん@編集中:04/01/02 01:44
糞〜

607 :名無しさん@編集中:04/01/02 05:01
>>595

学歴コンプレックスは首吊って死ね


608 :名無しさん@編集中:04/01/02 07:16
インテリって煽りに弱いなぁ(藁
ちょっと小馬鹿にされるとすぐヒステリーだよ>ヒロアキ

609 :名無しさん@編集中:04/01/02 11:26
また低レベルに荒れとるな

610 :名無しさん@編集中:04/01/02 18:20
でもさ、一週間位してHPが修正されてたら結構笑えるよね。

611 :601:04/01/02 21:16
どうだろ?
一応ここのURL貼ってメール送ってみたけどな

612 :名無しさん@編集中:04/01/03 00:42
更新するほどヒマじゃないだろ
あっさり削除されるに1票。
>>601のせいだな

613 :名無しさん@編集中:04/01/03 01:05
だいじょうび。漏れは既に保存したから。

614 :601:04/01/03 01:37
オレも保存したけどねw

615 :名無しさん@編集中:04/01/03 13:24
>>600

>>602
に対する書き込みが
>>608
ということでよいか。


616 :名無しさん@編集中:04/01/04 03:32
Mpeg4系のコーデックは大体が伸張、縮小するのは分かったのですが
Mpeg2系のコーデックはどうなるんですか?
DVDにオーサリングするときの基準になるようにAVIUTLで調整するには
ITU601に合わせるのか、0、255ラインに合わせるのか分かりません

617 :名無しさん@編集中:04/01/04 07:23
>Mpeg2系のコーデックはどうなるんですか?

TMPGEnc内蔵デコーダーは伸張。
DVD2AVIやMPEG2 VIDEO VFAPI Plug-inならデコードオプションで好きな方にすればいい。


618 :名無しさん@編集中:04/01/04 11:51
>DVDにオーサリングするときの基準になるように

こんなこと言ってる時点で全く理解してないな

619 :名無しさん@編集中:04/01/04 15:45
>>617
ありがとうございます
VFAIPの挙動が分かったのでMpeg2エンコソフトを使うたびに地道に調査したいと思います
>>618
DVDにオーサリングする段階で元のファイルを16-235近辺に納める事が基準になると思うのだが

620 :名無しさん@編集中:04/01/04 20:24
>>619
少なくともCCE系やTMPGEnc3.0ならRGB入力する必要はないんだが
というか伸張も縮小も意識しない

それと
DVDにオーサリングもなにも関係ないんだよ
どんな場合でもYUV16-235近辺に収めないでどうする?


621 :名無しさん@編集中:04/01/05 00:25
>>620
だからこそ16-235に納める方法を知っておく必要がある
AVIUTLと波形表示フィルターをはじめて使った頃は
誰もが波形表示フィルターの16-235ラインに納めるんだと勘違いしていたはずだ
そして、DIVX化
もちろんできたファイルは16-235を更に縮小した動画になるから糞ファイル
AVIUTLやDivXが強制的に伸張、圧縮することを知ってないと間違った動画を作る
Mpeg2でもコーデックや使用するソフトの特徴をつかまないと同じ間違えする

622 :名無しさん@編集中:04/01/06 08:29
Σ(*゜ェ゜*)ハッ 今までDVD2AVIでRGBで出して
VfapiConvでAviUtl→VirtualDubでDivX作ってたけど大間違いか?だめなのか??w
別にどっちにしても大して変わんないし・・・(DVDソースの実写多し)

TV出力はやったりやらなかったり

623 :名無しさん@編集中:04/01/06 09:16
それだけではダメかどうかは一概には言えないが、アホくさとは思うね

624 :622:04/01/06 15:50
しかたねーColorSpaceをちゃんとYUV4.2.2選ぶわ

AviUtl→VirtualDub アホくさいのは多分ここだろうがw Bふれ使う時仕方ねーのだ

625 :名無しさん@編集中:04/01/06 15:54
>>622
VfapiConv使わなくてもDVD2AVIのプロジェクト食うよ > AVIUtl

626 :名無しさん@編集中:04/01/06 17:56
mpeg2やvobもまるもでいけるし>aviutl

627 :名無しさん@編集中:04/01/06 20:51
VFAPIとは
VFAPIConv.は勿論.d2v.aup.tbrやm2v.vfpなどを含む
堀氏作成のフレームセーバー・ローダープラグインであり
全て入出力はRGB24で行う

つまり
VFAPIConv.使おーが
.d2v経由にしようが
ColorSpaceを何にしようが
m2v.vfpにしようが
ぜーんぶRGB

m2v.auiを使いましょう

628 :名無しさん@編集中:04/01/06 22:35
うむ
DVD2AVI側でColorSpaceを何にしようが、それはd2vを開くソフトが決めることなんで
d2vファイルを他のソフトで開くときはそこの設定には意味がない

629 :名無しさん@編集中:04/01/07 00:59
まるも使えばYUVで出てくれるというわけですか?そしたらAviUtlだけで出してみよう
短編多いからBふれ使わないでもいいし
一応まるもでvob、mpeg2読めるようになってる
どうせ音声分けなきゃ駄目かもしれんけど。

630 :名無しさん@編集中:04/01/07 01:14


631 :名無しさん@編集中:04/01/07 01:17
うむm2vconf.exe熟読した

(´∀`) 元のYUVデータを維持するんですね、そうですね こーやって使うツールだったんか。。
どうせ音声のためDVD2AVIしそうだけどやってみるでし

632 :名無しさん@編集中:04/01/07 04:00
音声分けツールなど他にも沢山あるべな まあYUV反映させたければまるも使うこと(設定もな

633 :名無しさん@編集中:04/01/07 05:36
>>631
わかってないのでは?
m2v.vfpをm2v.auiにリネームしてる?

634 :名無しさん@編集中:04/01/07 05:39
”元のYUVデータを維持する”と
出力がRGBかYUVかは無関係

635 :名無しさん@編集中:04/01/07 07:48
ところでaviutlのフィルタはRGBでしか使えないので、結局RGBに変換されてしまうのでは?

636 :名無しさん@編集中:04/01/07 09:09
YUVのまま処理したければAvisynth使う
こんなの基本だろ

637 :名無しさん@編集中:04/01/07 20:01
>>635
いつの時代の話だ?
Aviutlの内部処理はとっくにYUV化されてる
将、まるも、GNB、標準のフィルタはYUVで動いてるよ

638 :名無しさん@編集中:04/01/07 22:55
このすれみてm2v.vfpからm2v.auiに変えたらエンコ時間が早くなりました。どうも

639 :名無しさん@編集中:04/01/08 20:47
(´・ω・`)ショボーン m2v.auiってなんですか・・・??
ソフトでもなし・・・
そんな拡張子を出すソフトも・・・うううググりまくっても、わかりまへんでー!

もしかしてキャプチャしなきゃ分からない?w
YUVでエンコするならまあまるもでやれるからいーんですが

640 :名無しさん@編集中:04/01/08 20:51
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=m2v%2Eaui

|・ω・`) コソコソ だって検索結果これだけなんでしw

641 :名無しさん@編集中:04/01/08 21:20
>>640
普通にヒットしてるのに気付かないとは・・・
MPEG-2 VIDEO VFAPI Plug-Inに同梱されてるreadmeを読め

642 :名無しさん@編集中:04/01/09 09:10
そんなことよりおまいら
ttp://jp.nvidia.com/page/home
nVidiaの日本公式サイトなのだが
真中のカオスレギオンの広告をクリックしてみてくれ

643 :640:04/01/09 10:34
|゚∀゚)
でキタ━━━(゚∀゚≡(゚∀゚≡゚∀゚)≡゚∀゚)━━━━!!!!

エンコも速くなる・・・かも
|∀゚)っω お礼に置いてくね
|≡ サッ ω

644 :名無しさん@編集中:04/01/09 16:22
>>637
公式サイトにおいてあるゴースト(縦線)除去が
YUY2モードだと利用できない…(´・ω・`)

645 :名無しさん@編集中:04/01/09 17:33
>>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モード時、現状では内蔵フィルタしか動作は保障されない

あとは過去ログ読め


646 :名無しさん@編集中:04/01/12 22:13
哀王のLinkPlayerとかで見る用のaviは16-235で作った方がいいんすか?

647 :名無しさん@編集中:04/01/12 22:33
>>646
そのAVIはYUVであろう?
YUVフォーマットなら有効範囲YUV16-235
まぁRGBフォーマットのAVIは読めないだろうがな

648 :647:04/01/12 22:33

Y16-235ね

649 :名無しさん@編集中:04/01/14 17:43
隔離スレ浮上age

650 :名無しさん@編集中:04/01/14 17:45
sageてたw

651 :名無しさん@編集中:04/01/14 22:28
なんかAvisynthスレが荒れてんな。

652 :名無しさん@編集中:04/01/14 22:33
あれは荒れてるとは言わない

653 :名無しさん@編集中:04/01/14 23:10
すいません
荒らしてましたw
何度もこっちでやろう、と書いたんだが

654 :名無しさん@編集中:04/01/18 01:33
BCTV9スレでお前さん方の出番ですよ。
http://pc.2ch.net/test/read.cgi/avi/1074046153/247-

655 :名無しさん@編集中:04/01/18 01:38
出張サービスは行っておりません。

656 :名無しさん@編集中:04/01/18 01:41
ここは釣り氏が釣られるバカどもを見て、笑うスレですか??(・∀・)ニヤニヤ

657 :名無しさん@編集中:04/01/18 09:30
Dubスレでもやっとるな
みんなここでやれっての
あっちゃこっちゃで釣り糸垂れるなよ・・・

658 :名無しさん@編集中:04/01/25 21:50
AviUtlのYUY2展開にバグが発見されました。ご臨終。

659 :名無しさん@編集中:04/01/26 06:28
YUY2で読み込んでもゴーストなんかでないのですが。DubとAviUtl0.99でエンコしたファイルをを比べたら同じだったのですが。

660 :名無しさん@編集中:04/01/26 21:14
>>659
DivXコーデックで出るよ

661 :名無しさん@編集中:04/01/26 21:26
>>660
YUY2展開は
YUY2デコードはCodecが行い
YUY2->YUV48変換をAviutlが行う
このときYC補間が入るため
モスキートノイズやリンギングなどが発生しているソースは
ゴーストが出ているように見える
これをそのままYUY2圧縮しても
ゴーストのようなものは出ない
なぜならYUV48->YUY2はleft originだからだ

YUV48による擬似ゴーストは
ソースの動画再生時にはみえにくいノイズが表示されてるにすぎない
無論、これをフィルタリングで消せば
より綺麗な動画が作れる
素晴らしい仕様ですな

662 :名無しさん@編集中:04/01/26 21:31
前半は分かるけど、後半の意味が分からない
なんでより綺麗な動画になるんだ?

663 :名無しさん@編集中:04/01/26 22:53
>>662
モスキートノイズやリンギングが消えるからでは?

664 :名無しさん@編集中:04/01/27 00:08
見えにくいノイズが見えやすくなることで補正しやすくなり、
きっちり補正すれば綺麗になる と言いたいのでは?

665 :名無しさん@編集中:04/01/27 00:30
>>661
何いってんのかさっぱり分からん
大体YC補間ってなんだよ

666 :名無しさん@編集中:04/01/27 01:25
YUY2->YUV48変換でゴーストが出るって言うのはなに?
新手のプラシーボ?

667 :名無しさん@編集中:04/01/27 05:12
>>665
【最強】VirtualDub情報局 Part4【世界標準】
http://pc.2ch.net/test/read.cgi/avi/1065508229/606-613

668 :名無しさん@編集中:04/01/27 08:32
つまり、バグではないのですね。

669 :名無しさん@編集中:04/01/27 14:07
そうみたい
で、ノイズが見えるというより補完からはみ出た要素がゴーストになって現れるとかではないと?

670 :名無しさん@編集中:04/01/27 19:10
今までどうやらそうらしいとは言われてきてましたが。
NVIDIAの関係者が、NVIDIAのグラフィックチップの色空間変換はYUVとRGBを1:1でマッピングする、
つまり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もこれの一種



672 :名無しさん@編集中:04/01/27 20:52
色スレにはやさしい人が多いですね〜

673 :名無しさん@編集中:04/01/27 21:17
>>671
とりあえず、あんたの言う補間処理でゴースト?が出る理屈を教えてくれ
色が甘くなるだけで輪郭が目に見えて変化するのか?

674 :名無しさん@編集中:04/01/27 22:34
>>673
UV成分は色ではないし
単純に差分をとっただけならボケるだけ
それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意

今回のはjumperの手順に問題がある
RGB24->Huffyuvのとき
HuffyuvによるYC補間と逆の操作がおこる
単純に間引くのではなく差分をとって間引いている
データ的には輪郭外周ににじみがでる
これを今度はAviutl内部で->RGB
このときはleft originで補間される
滲み成分が2ピクセルごと1ピクセル外にずれて補間される
left originであるために対象物の右側に発生する



675 :名無しさん@編集中:04/01/27 23:19
>>674
何か話が見えにくいな。Huffyuvなんか俺にはどうでもイイ

>それ以前にYC補間そのものが”輪郭が目に見えて変化する”操作であることに注意
色差にローパス掛けたらゴーストでるのか?
彩度を思いっきり上げない限りは大したエッジ誤差になるはずがない
色ゴーストなんてよほど強く出てないと気付かないと思うが・・

676 :名無しさん@編集中:04/01/27 23:25
>>675
いやアルゴリズムの異なるローパスが二重にかかるからこうなる

なんだか説明しづらいので図式
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が擬似ゴースト

678 :名無しさん@編集中:04/01/27 23:31
0.98ではjumperが言うような問題は見えないんだけどな。

679 :名無しさん@編集中:04/01/27 23:43
というか問題点そのものが理解できない。
出力に影響がないのに何が問題なんだろ?
表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。

680 :名無しさん@編集中:04/01/27 23:59
結局、内部処理的には問題ないんでしょ?
でもプレビューがあの調子だと、色タイミング補正とかがし難い。

681 :675:04/01/28 00:10
>>676
図まで書いてもらってすまんのだが
さっぱり分からん(図が)

>アルゴリズムの異なるローパスが二重にかかるからこうなる
っていうのはそれが事実なら当たり前だろうが
その影響がどの程度のものなのかこの例えから読み取れない
(そもそも何故縦方向に平均化するのか・・)

まぁ暇な時にでも自分で調べてみるよ

>>679
>表示ったてAviutlの表示はアテにならないのはさんざんガイシュツなのに。
まじで?少なくともVFAPIで渡した時は表示通りじゃないとおかしくないか?

682 :名無しさん@編集中:04/01/28 00:32
久しぶりに一般人には到底理解出来ない話題で盛り上がってるな

683 :名無しさん@編集中:04/01/28 16:09
散々迷惑をかけて申し訳ないです。
また変な事いいだしますが聞いてください。

>>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」ですね。

684 :名無しさん@編集中:04/01/28 16:10
つづき

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」ではないのでしょうか?


685 :名無しさん@編集中:04/01/28 17:45
0.99は他ツールとの連携がしにくいってことか。

686 :名無しさん@編集中:04/01/28 20:21
>>683
根本的にわかっていない部分があり過ぎ
展開と圧縮は違うって何度もここに書いてあるだろ?
せっかちすぎる
検証向きではないな
内部データと表示されてるものと出力データは異なるってことも理解できない?
しかもkeep originとleft originの意味もわかっていない
読んでないだろ?
keep originのうち左端ピクセルを維持するのがleft originなんだってわからない?
TMPGEncのYUY2展開ってなに?
3.0か?
流石、横のみリサイズだとインターレースが壊れないと
自サイトに書くだけのことはある
もう一回情報収集と自分の検証方法を全てにおいて見直せ
まずはこのスレを全部読み直せ
次にまるもの戯言を全部読み直せ
基本的なアプリの動作がわかってないとどうにもならない
そして他の人間にもどういう手順でなにをやったかきっちり書いてくれ

個人的にはこの件は表示バグではないかと思っているけどな

687 :名無しさん@編集中:04/01/28 23:05
>>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%の理解には至っていません。
この板とグーグルとまるもで勉強させていただきます。
わかってから使えるように努力します。

688 :名無しさん@編集中:04/01/28 23:06
つづき

>流石、横のみリサイズだとインターレースが壊れないと
>自サイトに書くだけのことはある
Σ(゚Д゚;エーッ!
リサイズアルゴリズムによる色変化と関係してますか?
ピクセル座標連続性と関係してますか?
質問ばかりだと悪いのでこちらで考えます。

せっかちでごめんなさい_| ̄|○
ちょっとでも理解できたと思うと、うれしくて先走ってしまいます。
少々お時間を下さい。

>>672
良スレじゃないと私は書き込みませんよ。
他のDTVスレッドは良くないインターネットですからね。
私みたいに正確性に欠けた人が板を汚すのも悪いですが。

689 :名無しさん@編集中:04/01/28 23:32
>他のDTVスレッドは良くないインターネットですからね。

てめぇ、AviUtlスレ馬鹿にしてんのか!?

690 :名無しさん@編集中:04/01/29 00:14
>横のみリサイズだとインターレースが壊れない
拡大縮小のアルゴリズムによっては、上下のピクセルからも補間するからねぇ。


691 :名無しさん@編集中:04/01/29 00:20
>>689
AviUtlスレの事を指して私が言ってることだと
理解されたあなたはすごい。正解です。

692 :名無しさん@編集中:04/01/29 04:29
>>686
おまいすごいのはわかるけど
友達すくねーだろ?

693 :名無しさん@編集中:04/01/29 09:38
純粋に研究を志す椰子にとってあのスレはって気持ちはワカランでもないが
でも一言よけいは大人げない、黙ってればいい

694 :名無しさん@編集中:04/01/29 09:43
悪いけど
上に色々書かれていることは、ここに書かれた文章から理解しようとするよりも
この分野の入門書や仕様書を読んだ方がわかりやすいしそんなに難しい話ではない。

695 :名無しさん@編集中:04/01/29 18:46
huffyuvで16-235キャプ

AVIは0-255に伸張してavisynth+Dubエンコ
mpeg2は16-235でエンコしてたんだが、これだとTV出力の際に具合悪い

よってmpeg2も伸張して0-255でCCEエンコすることにした

AVIを16-235エンコしてるやつってほとんど居ないだろうなぁ
いったいmpeg2エンコするときどうしてるんだろ

696 :名無しさん@編集中:04/01/29 19:05
また別のあほがきた

697 :名無しさん@編集中:04/01/29 19:17
どこで勉強したらこんな意味不明なことをしゃべるようになるのか・・・

698 :名無しさん@編集中:04/01/29 19:57
>>695
ttp://cwaweb.bai.ne.jp/~icchan/Data/hard/saa7130b.htm

ここを見て参考にした厨か?w
そのサイトはデタラメで全く当てにならないぞ。

699 :名無しさん@編集中:04/01/29 20:17
32-215キャプかよ

700 :名無しさん@編集中:04/01/29 21:00
>これはAviUtlのPCスケール補正での演算誤差なのか、
>CCIR601用チェックでの誤差なのか、
>ReelTimeが信用できないのか、
>huffyuvの圧縮が信用できないのか、
>huffyuv.dllのYUY2展開精度が信用できないのか、
>SAA7130のA/D精度がそういうものなのか、不明です。

明らかなのは、信用できないのは ICZ だってことだな。


701 :名無しさん@編集中:04/01/30 00:18
動画仲間は誰も突っ込まないのかな?

702 :名無しさん@編集中:04/01/30 00:43
ふつうのOPEDエンコ人はインタレ解除したらとりあえずRGBで保存しちゃうからあんまり関係ない。
ICZ氏もそうだろうと思う

703 :名無しさん@編集中:04/01/30 00:57
>>702

SAA7130+huffyuv(YUY2)をAviUtl0.98d+波形表示といった環境で
Y16-235に調整してる時点で入力時のダイナミックレンジを損してるっつうか・・・
RGBでキャプチャすんなら分かるけど

704 :名無しさん@編集中:04/01/30 01:44
俺はAviUtlのほうは古いの使ってるから98dだか99の展開(展開表示)の挙動はシラネ-ですが
あんなマメなら2重伸長のことも知ってるんじゃないかなと、メンドイから更新してないぽいし
まあ想像ですが。

705 :名無しさん@編集中:04/01/30 01:52
YUY2で記録したHuffyuvはRGBで展開してもスケールを伸張するんだから
AviUtlが古かろうと新しかろうと関係ないし、
ICZのやってることは2重伸張どころかその逆の行為なんだから
704の想像も明後日を向いてるな。

706 :名無しさん@編集中:04/01/30 02:01
ふつうhuffyuv(YUY2)なんか使わないから分からんつーの
まあ俺はCCIR601やスケールにうるさい連中が
YUY2をhuffyuv(YUY2)でキャプチャしろなんてアホなこと言い出したんだと思ってるが

707 :名無しさん@編集中:04/01/30 02:23
>>697

708 :名無しさん@編集中:04/01/30 02:26
ふつうhuffyuvはYUY2で使うと思っていたが…

709 :名無しさん@編集中:04/01/30 04:38
ICZは、暗い絵が好きなんだって。
ただ、それだけ。

710 :名無しさん@編集中:04/01/30 05:16
アニペグコミュニティにはアニペグコミュニティの文化があるんだよ。

711 :名無しさん@編集中:04/01/30 11:41
中間ファイルにyuy2を使うなよ低脳

712 :名無しさん@編集中:04/01/30 11:52
中間ファイルにRGBを使えというのか

713 :名無しさん@編集中:04/01/30 11:55
全工程においてRGBには一度も変換しません

714 :名無しさん@編集中:04/01/30 11:58
それはAviUtlを使うなってこと?

715 :名無しさん@編集中:04/01/30 12:05
2002/5/3 ver 0.98 YUY2入出力に対応。

716 :名無しさん@編集中:04/01/30 13:00
>>706>>711は同じ人だよな?
こんな人が何人もいるなんて考えたくないんだが

717 :名無しさん@編集中:04/01/30 13:37
2.2.0やhuffyuvsのYUY2は伸長展開しないよね?

718 :名無しさん@編集中:04/01/30 14:00
yes and no

719 :名無しさん@編集中:04/01/30 14:08
質問よろしいでしょうか?
YUY2の共有UV2ピクセルには、上下方向の
補完は入るのでしょうか?
どう考えても、横方向の色しか丸め込みも
補完も働いていない気がします。

>>711
YUY2を知れば知るほど理解できます。
ソースがRGBなんですね。

720 :名無しさん@編集中:04/01/30 14:15
>>719
普通はやりません

ソフトによっては斜め方向も考慮した補間を使うかもしれないけど、
計算量が増えるので、補間を行う場合でも隣しか見ないのが普通です

あと、最近の MPEG-2 VIDEO VFAPI Plug-In は 422 -> 444 への色差
補間はやってません (420 -> 422 はインタレース対応で必須だから
やってるけど)

422 の色差をそのまま使って RGB に変換しています

721 :名無しさん@編集中:04/01/30 15:36
>>720 さん
ご回答サンクスです。

>>676-677 図のゴースト理論が嘘という事と、
4:2:2補完がされていない映像がゴーストの正体とわかりました。
YC伸張フィルタ(AviUtlプラグイン)の4:2:2→4:4:4補完を使ってみたら
AviUtl0.99のプレビューのゴースト消えました。

お騒がせしました。
私があること無い事言ってかき乱してしまいました。申し訳ないです。

輝度で悩んでる方々もがんばってください。

722 :名無しさん@編集中:04/01/30 20:09
>>721
AviUtl掲示板のあのスレッドはあの結論のままにしておくのでしょうか。

723 :名無しさん@編集中:04/01/30 23:17
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/

724 :名無しさん@編集中:04/01/30 23:18
huffyuv(YUY2)でキャプ、ここからMPEG2にしたいんだけど、
avisynth挟んでyuv411->422補間するのって意味あるかな?


やってもやらなくても一緒のような気がした、といかむしろチラついておかしくなった気がする。

725 :名無しさん@編集中:04/01/30 23:22
>>724
YUY2というのはyuv422の事なんだからyuv411->422補間など無駄。

726 :名無しさん@編集中:04/01/30 23:23
キャプった時点で422だったね。吊ってくる

727 :名無しさん@編集中:04/01/30 23:25
>>725
すまん、725読み込まずに書き込んでもうた。

無駄ならいいけど、デメリットがあるかな・・・
もう50本ほどこの設定でエンコしちゃったよ

728 :名無しさん@編集中:04/01/31 02:12
420を補完すると何かいいことあるの?

729 :名無しさん@編集中:04/02/02 13:04
>>722 さん
AviUtl掲示板のものは謝罪と解説付きで
しっかり謝罪しますm( __ __ )m

>>728 さん
AviSynthとYV12の関係を調べたサイトがありますよ。
ttp://members.at.infoseek.co.jp/kiraru2002/
意味合いは少し違いますが(汗

730 :名無しさん@編集中:04/02/02 23:20
jumperさんは誠実な人ですね。

731 :名無しさん@編集中:04/02/03 03:30
一応ぼくも見てます(謎)

732 :名無しさん@編集中:04/02/03 03:30
723?

733 :名無しさん@編集中:04/02/03 11:34


734 :名無しさん@編集中:04/02/03 19:10
AviUtlのRGBの色ゴーストね・・・
クロマアップサンプリングバグとでも言った方が格好いいな。

735 :名無しさん@編集中:04/02/03 20:42
>>733
図星?

736 :slave:04/02/03 20:53
723さん(>>723ではありません)は読んでても理解できてないと思います

737 :名無しさん@編集中:04/02/03 22:34
オマイが指導してヤレ


と言いたいとこだけど破門したんだよね

738 :名無しさん@編集中:04/02/04 00:01
>>735


739 :名無しさん@編集中:04/02/05 15:22
radeonのオーバーレイってどう弄べばyc伸張に匹敵するのですか?

740 :名無しさん@編集中:04/02/07 10:27
明るさ      -10
コントラスト   30
ガンマ       0
輝度        20
色の濃さ     10
色合い       0

741 :名無しさん@編集中:04/02/11 13:58
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 に見えるような
デフォルト値が内部で設定されてるってことかな?


742 :名無しさん@編集中:04/02/11 20:05
その辺の調整が各社腕の見せ所

743 :名無しさん@編集中:04/02/11 20:45
"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


744 :名無しさん@編集中:04/02/15 21:44
NTSC基準の色ぐらいポンと設定できないものでつかね。
キャリブレーションなんか。。。

745 :名無しさん@編集中:04/02/15 22:20
国内向けに作られてる民生AV機器ですら
「メーカー色付け」がなされてるのに
開発国がNTSC-JですらないPC機器にそんなこと期待しても・・・

746 :名無しさん@編集中:04/02/18 10:34
WindowsXP、DirectX9.0b、RADEON9700です。

なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
正直困っています。だから、MPCのVMR9モード使いたくても使えません。

どうしたらいいでしょうか?



747 :名無しさん@編集中:04/02/18 10:34
あげます。

748 :名無しさん@編集中:04/02/18 11:49
>>746
RADEONはオーバーレイで伸張。
VMR9にYV12接続で非伸張。

例えば、DivXをVMR9で再生するなら
デコーダオプションのYuv Extended Modeを外すと
YUY2で出力されるのでVMR9で伸張される。

ffdshowを使うならoutput coloerspaceのYV12のチェックを外しておけばいい。

749 :名無しさん@編集中:04/02/18 13:52
>>748
ありがとうございます。
しかし、それは実はもう試していて、今改めてデコーダーの設定を変えてみましたがやっぱりだめでした。
VMR9に限らず、オーバーレイじゃない場合は色がくすんでしまいます。
また、DivXだけでなく、WMV9、VP6、RV9・10でもだめです。
また、huffyuvでは伸長された色になります。

ffdshowは使っていません。

750 :名無しさん@編集中:04/02/18 15:24
>>749
MPC使ってみました。
うちではVMR9(windowed) と VMR9(renderless)では色が違って見えるんですが
それは確認されてますか?
VMR9(renderless)だとOverlayMixerと同じに見えます。

751 :名無しさん@編集中:04/02/18 15:28
>VMR9(renderless)だとOverlayMixerと同じに見えます。

ああ、これは "こうなるべき" と言う意味ではなくて
うちではそう見えますがどうですか?と言う意味です。

752 :名無しさん@編集中:04/02/18 21:54
>>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&オーバーレイ&伸長


753 :名無しさん@編集中:04/02/18 21:56
DivXでうまく行ったファイルと行かなかったファイルの違いは良くわかりません。

>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
皆さんは、VMR9(renderless)以外のオーバーレイ無しで伸長されるんですか? 

>>754
RADEONのドライバですか?

756 :名無しさん@編集中:04/02/19 13:45
BSPlayerでオーバーレイの時の色がForceRGBで表示した時の色が同じなら
伸張しているってことでいいの?

757 :名無しさん@編集中:04/02/19 19:39
>>755
なんか勘違いしてるような?
Radeonはオーバレイのとき伸張するよ。
ただし
BT.601通りの伸張にならない
じゃぁBT.601伸張と同等にするには?
が、現在の話題。
つまり
>なんか上のレス見ていると、オーバーレイは伸長しなくて、通常は伸長するようですが、
逆。GDIはソフト依存、オーバーレイは 伸張。
>おれの環境では逆で、オーバーレイしないと、伸長が行われていないみたいです。
みんなそうです。ただし正確じゃない。

758 :名無しさん@編集中:04/02/19 20:34
>じゃぁBT.601伸張と同等にするには?
>が、現在の話題。

そんなの誰も話題にしてないぞ。

759 :名無しさん@編集中:04/02/19 20:42
まあ伸張が正確ではないというのが分かるぐらいなら
正確な伸張との差を取って補正値を見つければ良いだけですな。
その答えを757さんは知ってるんでしょう。

760 :名無しさん@編集中:04/02/19 20:47
>>739-742を受けて
>>755は質問してるんではないのか?

761 :名無しさん@編集中:04/02/20 06:22
DOS/V magazine No.247 2/15号

オーバーレイの明るさ、色調を
(*)非オーバーレイ描写と同一に調節する方法
(*)マイクロソフトが推称しているDirectDrawでの
   動画再生描写結果と近い画質になります

@GeforceFX5600(Forceドライバ)・・・デトネーターは設定値が違うので注意
色相2%
彩度98%
明るさ122%
コントラスト107%

※デトネタは
明るさ120
コントラスト98
色相+4
彩度104

ARADEON9600XT(恐らく純正ドライバ)
明るさ20%
コントラスト90%
彩度95%
*ラデは動画を再生中でなければ
 オーバーレイ画質の調節はできない

762 :名無しさん@編集中:04/02/20 23:37
こーゆーのは色スレだと言われたので同じ事聞きますがすみません。
AviUtlでまるもでm2v.auiで直接読んで色空間は「元のYUVデータ維持」
はまずいっすか? 実写が主です
PCもテレビもどっちも見れる事を前提に一応作ってまつ
使用グラボはGeForce4 MX420
RGBより色くっきり、AviUtlにしてはエンコも早い気がしていいと思いましたが。

763 :名無しさん@編集中:04/02/20 23:51
>>762
BSDや地上Dじゃないならそれでいいでしょう。

764 :名無しさん@編集中:04/02/21 02:43
>>762まずいというよりそれが推奨

765 :名無しさん@編集中:04/02/21 08:02
PCでの鑑賞前提ならYC伸張した方がいい

766 :名無しさん@編集中:04/02/21 08:29
>>765
おまえこのスレの内容理解してないだろ

767 :名無しさん@編集中:04/02/21 09:03
アフォジャンパもそんなこと書いてるしな。
こういう初心者は減らないよ。

768 :名無しさん@編集中:04/02/21 10:03
>>765
びっくりするほど典型的なミスだな
このスレが生まれたきっかけそのものだ

769 :名無しさん@編集中:04/02/21 18:02
>>765
http://pc.2ch.net/test/read.cgi/avi/1076669197/133-


770 :762:04/02/21 20:15
さんきゅらちょ まるもで直接が楽だし好きなほう選んでやりまふ
そうです、地上Dエンコするわけでもありませんので
YC伸張フィルタてのは使ったことありません

771 :名無しさん@編集中:04/02/22 11:25
>>767
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の人とかじゃなくて初心者に誤解されないようにしろよ。
初心者のためのページなんだろ?

773 :名無しさん@編集中:04/02/22 14:58
初心者はaupを別のフロントエンドに突っ込んだりしません

774 :名無しさん@編集中:04/02/22 15:09
それはあなたの判断。
初心者が何したいかはわからないだろ?
だいたいジャンパのとこにやり方書いてあるでしょう?
もっとおかしいのは、
・ジャンパはm2v.auiを推奨している。
・ジャンパはPC動画は伸張しろと書いてある。
・AviutlではデフォルトでYUV展開・圧縮はON。

m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力

↑こうやることになるぞ?
本当にこれでいいと思ってる?

775 :名無しさん@編集中:04/02/22 15:09
>>767
アフォなのは否定しません。よく間違えますし。

ということで、
ttp://jumper-x.hp.infoseek.co.jp/study/6/index.html
どうぞ。
YC伸張が必要なのは、「目で見る時」の
YUV→RGBにする時であって、
前スレの真意はそこに集約されると
おっしゃってる人の通りであって・・・
(このスレの真意はYUV→RGB小数点切捨て回避ですが)
AviUtlのYCbCrのヒストグラム範囲が
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の打ち間違いですな。
まったくせっかちなんだから・・・。

777 :名無しさん@編集中:04/02/22 15:24
うお。書き込み中に新レスが。
>>772 さん
>>774 さん
そういうことなのね・・・CCE持って無いので
わかりませんが。

>・ジャンパはm2v.auiを推奨している。
してるように見えますか_| ̄|○
>・ジャンパはPC動画は伸張しろと書いてある。
書いてますね。でも、何でもかんでも伸張しろとは
言ってない希ガス。
>m2v.aui->AviutlでYC伸張->YUV圧縮ON状態でDivX出力
プレビュー見たら、初心者だったら余計に
できないと思いますよ。

伸張無しRGB読み込み→
AviUtlのプレビューが薄いけどいいや→YUY2出力
伸張ミスでシュリンクアボーン(´・ェ・`)
をしてほしく無いから書いたのですが。

778 :謎の645:04/02/22 15:29
やはりジャンパはアニヲタって感じがするな。
実写だと二重伸張・二重圧縮でも気が付かないヤシはいるでしょう。
モーヲタとかモーヲタとかモーヲタとか。
ぶっちゃけ照明のせいで真っ白・真っ黒がわかりにくいからね。
ソースと比べりゃわかるんだけどな。

779 :名無しさん@編集中:04/02/22 15:47
謎の645さんへ

その通りです。アニヲタ寄りです。
ドラマとかも漫画原作のドラマばかりキャプしています。
私自身が、めざせ!あにぺぐの常連ですし。

>実写だと二重伸張・二重圧縮でも気が付かないヤシはいるでしょう。
気付いて( ゚д゚)ホスィ…

打ち間違えのところを直しました(`・ω・´)シャキーン
ご指摘ありがとうございます。

780 :名無しさん@編集中:04/02/22 19:04
どうせならAviUtl内部フォーマットの詳細な解説を作れば?
どう読み込むとどうなって、表示はどうなり、出力される時にどうなるのかとか。

781 :名無しさん@編集中:04/02/22 19:26
AviutlのYUYフィルタモードでやる場合は、ヒストグラムの左右の線より内側になるようにしておけば安心?

782 :名無しさん@編集中:04/02/22 21:20
>>780
もうできてるよ

783 :名無しさん@編集中:04/02/22 21:58
>>782
消えただろ

784 :名無しさん@編集中:04/02/23 00:09
jumperさん、YC伸張のコンテンツ乙です。
初心者の私にはとても分かりやすくためになる内容でした。


785 :名無しさん@編集中:04/02/23 13:04
BS デジタルの場合、m2v.auiの設定はどうするのが正しいの?

786 :名無しさん@編集中:04/02/23 18:27
正しいの「ですか?」だろ
人に物を尋ねるときは口の利き方に気をつけろや、ヴォケ

787 :名無しさん@編集中:04/02/23 21:40
で、どうするのが正しいの?

788 :名無しさん@編集中:04/02/23 22:37
どうしようが大してかわらんだろ
好きなのえらんどけ

789 :名無しさん@編集中:04/02/24 00:35
カラーバーをDVDにしたいのですが
このzipファイル内にあるA,Bどちらのファイルを使うのが正しいですか?
http://my.reset.jp/~abon/download/NO_20040224002943.zip.html


790 :名無しさん@編集中:04/02/24 23:36
両方ともおかくないか?
デザインも微妙に変。

791 :790:04/02/24 23:43
スマソ。Aだな。

792 :789:04/02/25 00:35
>>790さん
ありがとうございます。


793 :名無しさん@編集中:04/02/25 01:02
この度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圧縮されたため)
なのでしょうか?
なんとなく色が薄くなっているような気がするのですが、この設定で正しいのでしょうか?

よろしくお願いします。


794 :名無しさん@編集中:04/02/25 01:20
ああ、コピペがキタ

795 :名無しさん@編集中:04/02/25 08:16
薄くなってると思うなら調整すればいいだろ
コピペ師ね

796 :名無しさん@編集中:04/02/25 11:12
その方法だと薄くならないだろうに

797 :名無しさん@編集中:04/02/25 11:22
薄くなるのはやりすぎの証拠。
騙されたと思って3日間ガマンしてみ。濃くなるから

798 :名無しさん@編集中:04/02/26 12:54
>>797
そんなことしてたら、また3日我慢しないと濃くならないだろうがよ。

799 :名無しさん@編集中:04/02/26 13:19
三日も我慢できないよぉ

800 :名無しさん@編集中:04/02/28 01:02
M2Kitの画像を私なりに、補正してみました。
補正の内訳

1.オリジナルのJPEGデータ50.4KBを、AdobeFhotoDeluxeにてBMP1013KBに変換。
2.BMPをAviutlにロードして、YC伸張フィルタと拡張色調補正フィルタをかける。
  YC伸張フィルタの設定・・・Y(lower)=16、Y(Upper)=235、Cb=64,Cr=64、YCbCr補間法=Yuv4:1:1→Yuv4:2:2
  クリッピング・・・右2(補間基準点左側、右側2をクリップし、元サイズに拡大)
拡張色調補正フィルタの設定・・・Cb(gain),+32、R(offs)+32、G(offs)+32B(offs)+40,B(gain)+8,B(gamm)+8
3.未圧縮のYUY2のAVIに保存。680KB
4.Videostudio7にYUY2のビデオファイルをロードして、JPEG(品質70)にて静止画として取り出す。48.9KB

http://www.geocities.co.jp/SilkRoad-Desert/3853/Home1/newpage1.htm

801 :名無しさん@編集中:04/02/28 01:36
これはデジカメを加工するツールじゃない
YUY色空間等の変換ロスとかどうなるんでしょうね
ちゃんと理解してツールを利用した方がよいと思う
微妙にフィルタかけた後の画像の取り出しもぎこちないし
あー、これたぶん誤爆なんだろうな

802 :名無しさん@編集中:04/02/28 23:28
>>800の続編
http://www.geocities.co.jp/SilkRoad-Desert/3853/Home3/newpage3.htm


803 :名無しさん@編集中:04/03/12 00:05
age

804 :名無しさん@編集中:04/03/13 08:56
http://www.extremetech.com/article2/0,1558,1544889,00.asp
糞とWMV9だけ色が薄い

805 :名無しさん@編集中:04/03/14 18:18
RGBはデータの値のまま編集ソフトに読み込めるのに
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表示も可能。




807 :名無しさん@編集中:04/03/15 18:03
>>806
ありがとうございます
ほんとによくわかりました
デコーダーの-5%輝度を取り込むのはアナログ0-255スケーリングのものなんでしょうが
仕様としてはアナログ16-240範囲をスケーリングしてくれた方が精度がよさそうですね
-5%もテレビで確認できるんだからばっさり切ってしまうのは、また反発もありそうですが

808 :名無しさん@編集中:04/03/17 00:55
YUV<>RGB変換誤差って小数点の丸め込みなの?
jumperさんがそう書いてるんだけど…。

809 :名無しさん@編集中:04/03/17 10:37
回りくどい尋ね方で申し訳ない
このヒストグラムはありえますか?
http://with2ch.net/cgi-bin/pict/image-box/img20040317103514.jpg

ビデオデッキチューナーS端子→DVメディアコンバータi-Link→
ふぬああ(コンプレッサなし)DVType2にチェック

DVコーデックとしてirisベータ6.3が入っています。MSDVとの置き換えもしています。
iris設定はストレート変換を行うにチェックが入っています。

メディアプレイヤでオーバーレイを先に占有して
ふぬああでアナログBS1をプレビューした時の画です。
本来ならヒストグラムはもっと中央寄りになっているべき物と
考えているのですが、どうなのでしょう?

この状態だと何かが伸張しているとしか考えられないのですが。



810 :名無しさん@編集中:04/03/17 11:04
>>808
どこに書いてある?
そんなこと書いてあるかなぁ・・・
一応答えるが「小数点丸め込み」よりもっと誤差はでかいよ

>>809
全然ありえます
「全ての民生AV機器は顧客がより綺麗に感じるように表示・信号生成を行うよう設計される」
から
つまり
>>ビデオデッキチューナーS端子
>>DVメディアコンバータi-Link
どちらもBT.601有効範囲を保障するものではありません
またDVだろうがDVDだろうがキャプボだろうが
使用者が、BT.601の有効範囲でA/D変換されるように設定する
のは大前提
もちろんそれができない機器は多いけどなー
つまり>>809がやってることは
”BT.601に準拠してない信号をBT.601の有効範囲を守るかどうかわからない方法でキャプって
ヒストグラムみたらYがBT.601の有効範囲を大きく逸脱した”
に過ぎない
伸張云々以前の問題

811 :809:04/03/17 12:06
>>810レスポンスありがとうございます。
で、ここからが回りくどさの真骨頂なのですが。
以前は同様の環境でBT.601の有効範囲と思われる範囲で
キャプチャできていたのです。逆にキャプチャ段で縮小されていた
可能性も否定できませんが。

キャプチャしたものをaviutl0.98dで編集するのですが
現在の>>809のような状態だと、YUY2で展開すると
さらに伸張された様なヒストグラムに、RGBで開くと
プレビューとほぼ同じ範囲になります。>>809の通りirisコーデックの
デコードはストレートです。当然フィルタは全てOFFです。
それでも、明るい部分が以前ではありえないほど飛んでしまいます。

以前キャプチャしたものはRGBで展開していましたがaviutlのヒストグラムは
中央よりの狭い範囲によった形でした。
その当時キャプチャ時にはふぬああでのヒストグラムは確認していません。

当然何かきっかけがあってこの様になっているわけですが
はずかしながらいつのまにかこんな状態になっていてわかりません。
ソフトウェアやコーデックの出し入れはしていません。

いくつかの要素からたどってくると結局キャプチャ段階で
変化が起きてしまっていると考え、その段階で伸張(または縮小)
してしまうような要素を探しているのですが、自分ではお手上げ
状態です。


812 :名無しさん@編集中:04/03/17 12:48
>>811
Aviutl98d上で以前キャプチャされたものをRGB展開でみたヒストグラムと
最近キャプチャしたものが違うってこと?
ちなみにRGB展開でYUVヒストグラムみても
有効範囲かどうかはわからないんだけどね

813 :名無しさん@編集中:04/03/17 13:06
あと基本的な事項を確認したいんだけど
Y値が0-255をとってるから伸張されてる、ってことにならないのはわかってるんだよね
ヒストグラムを見る限りでは伸張されてるというより
家電にありがちなトビ気味になってるYUVにしか見えないんだが

814 :名無しさん@編集中:04/03/17 13:51
>>775
見逃してた

815 :名無しさん@編集中:04/03/17 14:24
>>812
以前と現在のキャプチャ結果がいつのまにか変わっている、そういうことです。
小数点以下の話が出るような厳密なスレの流れのなか、かなりあいまいな話で
申し訳なく、腰が引けてしまうのですが。正直よくわかってません。

以前は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

817 :名無しさん@編集中:04/03/17 14:39
>>816
Irisもストレート指定してるってのはCanopusと同じことになるんじゃないの?

818 :名無しさん@編集中:04/03/17 18:31
>>815
以前も今も”オレスケール”キャプチャしてるだけでしょ
だったら”オレスケール”補正すればいいじゃん
所詮色なんて自分が満足ならそれで構わないんだから
”以前のオレスケールと今のオレスケールが違うのはなぜ?”
といわれても困ってしまうわけだが

819 :809、815:04/03/17 18:56
いじってる自分でもわからないもの
こういう場面にあったことのある人じゃなきゃわからないですね。
いろいろとありがとうございました。

>>818
現状では勝手に伸張されたような状態なので
クリップして飛んでいってしまった部分はどうしたって
帰ってこないわけですよ。だから困っているわけで・・・。

キャプチャする時点でDVなのでコンプレッサも何も使っていないのに
というか、使っていないからスケールがどんなスケールなのか
わからないわけですよ。前の状態が正しいのか今の状態が
ただしいのか。
DV+ふぬああ環境、コンプレッサ無しで任意のスケールで
キャプチャできるものなのか、できないのか。

で、現状は伸張されたような状態なので元に戻すには
どうしたらいいのかを探してます。

820 :名無しさん@編集中:04/03/17 19:31
>>819
iLINK転送なんだからPCにくる以前にデジタルになってるんだよ?
デジタルになってる時には既にクリップされてるんだよ?
デッキかコンバータ-つまりアナログレベルでダイナミックレンジいじらなきゃどうにもならないでしょ
ただ、あのヒストグラムでクリップされてるとは思わないけどね

821 :名無しさん@編集中:04/03/17 19:38
使っていないからスケールがどんなスケールなのか
わからないわけですよ

これがそもそも認識不足
アナログYUV->デジタルYUVでスケール変換なんてないんだから
デッキ->コンバータorコンバータ内部のA/D変換のときに
メーカー独自の味付けがされてるってだけ
それはキャプボだって同じなんだよ


822 :名無しさん@編集中:04/03/23 21:05
このスレには魔物が住んでるってこの板では評判ですね。でまともな
職人は寄り付かないと。

823 :名無しさん@編集中:04/03/23 21:09
コピペか

824 :名無しさん@編集中:04/03/27 01:58
保守

825 :名無しさん@編集中:04/03/27 02:15
わしも似たパターンかな。DR7スルーでふぬああでDVキャプチャ。
TV東京の番組のファイルをColorYUY2のAutoYUVに通してログファイルを
見たらYが0-255になっとる。

826 :名無しさん@編集中:04/03/27 05:36
サチュレートしなけりゃY0-255は当たり前

827 :名無しさん@編集中:04/03/27 11:14
>>825
そうなんですよ、テレ東が一番健著。
日テレはYUV16-235範囲で収まってるけど、テレ東はYUV5-255overみたいな。
同じCMみても全然違う。

テレ東も3月の頭まではこんなじゃなかった様な気がするんですけど



828 :名無しさん@編集中:04/03/27 11:17
テレ東全部ってなら受信状態の問題でしょ
ちゃんとチャンネルごとに設定しなよ
または後で補正できるようにキャプしな

829 :名無しさん@編集中:04/03/27 11:39
テレ東全部ですね。
もちろん、他チャンネルと比べて尋常じゃない状態なので
受信状態うたがいましたよ。
微調整で受信調整しながらキャプチャしてもY255まで
使い切ってるのは変わりませんでしたが。

参考までにDVで後に補正ができるような方法教えてもらえませんか?
全く方法を変えなければ無理ですか?

830 :名無しさん@編集中:04/03/27 12:33
コントラストを低めにキャプすればいいじゃん

831 :名無しさん@編集中:04/03/27 20:52
だからDVはキャプじゃないんだって・・・
DVHS=MPEG2TSと一緒でストリーム転送
アナログ>DVコンバータかなんかで補正できるものはあるけどな
どっちにしろPCへは転送されてるだけなんだって

832 :名無しさん@編集中:04/03/27 21:25
何言ってんだか
PCで扱うDVは単なるコーデックだぞ

833 :名無しさん@編集中:04/03/27 22:50
>>832
DVコーデックがやってるのはYUV<>RGB変換だよ
質問者はDVデッキからIEEE1394でPCにもってきてる
データ的にはストリームだよ
CanopusだろうがIrisだろうがこのときコーデックはデコーダになるだけ
MPEG2TSのデコーダがWinDVDだろうがまるもプラグインだろうが
動画データ的には一緒だろ?
DVの場合ヘッダとFourCCは変わるがPC側でエンコードはしてない
キャプチャキャリブレートはA/Dの前に行わないと意味がない
後で行うなうなら色調補正と一緒
ストリーム転送はデジタルデータ貰ってるだけなんだから
キャプチャキャリブレートはPC内でできない

834 :名無しさん@編集中:04/03/27 22:53
訂正
色調補正と=>Aviutlなどのアプリ上で色調補正するのと

835 :名無しさん@編集中:04/03/27 22:56
質問者がDVデッキつかってストリームキャプしてるなんてどこにも書いてないんだが?

836 :名無しさん@編集中:04/03/27 22:56
ってレス遡ったら書いてたスマン
忘れてくれ

837 :名無しさん@編集中:04/03/27 22:59
罰としてスクワット50回!

838 :名無しさん@編集中:04/03/27 23:02
なので、わざと質問してみたわけですが。

机上の理論ももちろん重要ですが
皆さんのテレ東受信環境ってどうです?実際。
他のチャンネルと比べて輝度が高くありません?

839 :名無しさん@編集中:04/03/27 23:10
そうでもない・・・たぶん
GRTやAGCの影響もあるのかもしれないけど

840 :833:04/03/27 23:14
>>838
実はGCT500+WVDR7+DVSTorm2だったりw
はっきり言ってメロメロ
でも前からテレトってそうだけどなぁ
横浜在住

841 :名無しさん@編集中:04/03/28 06:17
AviutlのFrameloaderはどうなんでしょ。
ソースをYUV読み込みしたらYUV16-235で中継できるんかな?
それともRGB16-235出力?

842 :名無しさん@編集中:04/03/28 07:34
>>841
やってみれば?

843 :名無しさん@編集中:04/03/28 17:03
>>839>>840
レスポンスありがとうございます

まちまちっぽいですね。ただ、今まで自分の所有した事のある
GRチューナーだとちょっと暗めの画になる感じがするので
それで適度になってるって可能性もあるような。
今使用してるチューナーはGRないんですけど。

833さんと近いと言えば近いですけど、実はUの中継送信
拾って受信してるんで電波は違うかな。

844 :名無しさん@編集中:04/03/28 19:09
>>841
フレームセーバー・ローダーはメモリに展開されたビットマップデータをやりとりするだけ。
RGBですな。

845 :名無しさん@編集中:04/03/28 19:10
>>843
Uの中継ということはアナアナ変換にひっかかったんでない?

846 :名無しさん@編集中:04/03/28 19:20
俺多摩付近に住んでるけど最近は受信状態が不安定で困る

847 :名無しさん@編集中:04/03/28 21:26
>>846
受信料払ってるなら、NHKに訴えるとよい。

848 :名無しさん@編集中:04/03/28 21:38
そんなことでいちいち訴えてられるかよ
映らないわけじゃないんだから

849 :名無しさん@編集中:04/03/28 22:24
>>848
意外に結構対応してくれるぞ
民放の受信状態が悪くてもNHKが対応する
しかも調査費用ただ
ま、オチが「ケーブルになされては?」だったりもするがw

850 :名無しさん@編集中:04/03/28 22:25
あぁそうかw
NHK" を "じゃなくて
NHK" に "ね

851 :名無しさん@編集中:04/03/28 23:19
NHKは受信障害に対応する義務がある

852 :名無しさん@編集中:04/03/29 00:57
そんな義務いらないから一月の受信料を250円にして欲しい
デジタル放送のタカリテロップうぜぇよ

853 :名無しさん@編集中:04/04/01 09:33
>>838
北九州在住ですが、テレ東系のTVQは白飛びしがちです。


854 :名無しさん@編集中:04/04/29 17:16
sage

855 :名無しさん@編集中:04/04/29 21:29
age

856 :名無しさん@編集中:04/04/29 22:19
つーかついに存在価値がなくなったのか?
このスレ

857 :名無しさん@編集中:04/05/02 14:17
DivXやXviDのような16-235の範囲しか扱えないコーデックを使うならTVスケールで。
VP6やWMV9VCMのような0-255迄扱えるコーデックならお好みでいいんじゃね?

858 :名無しさん@編集中:04/05/02 14:32
馬鹿がきた

859 :名無しさん@編集中:04/05/02 14:39
( ´д)ヒソ(´д`)ヒソ(д` )

860 :名無しさん@編集中:04/05/02 14:44
全部読んだ挙げ句にあのレスなのかな・・・

861 :名無しさん@編集中:04/05/02 17:03
全くとんちんかんなこと言ってるんだが、それは無視することにして、
そんなことより間違ったことは言うな。
信じるバカが出るだろが。
>DivXやXviDのような16-235の範囲しか扱えないコーデック

862 :名無しさん@編集中:04/05/02 21:29
まだこのスレには存在意義があることがよーくわかったよ・・・

863 :名無しさん@編集中:04/05/02 21:38
>>861
857じゃないけどDivXは16-235しか受け付けないようだが
0-15、236-255は真っ白及び真っ黒になる・・・

864 :名無しさん@編集中:04/05/02 21:45
>>863
イヤ、もう一回YC伸張スレから読み直してくれ


865 :名無しさん@編集中:04/05/02 22:10
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なので
上記に準ずる

866 :名無しさん@編集中:04/05/02 23:02
ややこしいが、YUV(16-235・240)でコーデックに送るのが正解なのか。
PCで再生する場合はグラボまでYUVで逝って、グラボがRGBに変換(この時に伸張)して表示するそうだし。

DivXでもYUV(0-255)ソースからYUV(0-255)で作れるの?
おかしいな・・

867 :名無しさん@編集中:04/05/02 23:03
そのYUV収納コーデックなんだけど、オーバーレイ再生じゃないと伸長されないみたいで不便です。
色が汚くておかしいなって思ってたりするとなにか起動しっぱなしのウィンドウ忘れてたりするんですよ。
何とかならないでしょうか

868 :名無しさん@編集中:04/05/02 23:29
>>866
なるよ
ただしYUV入力・処理するようにアプリを設定しなければならない
AviutlだとYUV展開やm2v.auiで読み込んでYUV圧縮でcodecに渡す
飽和はoff
Dub系ならfast
TMPGEncやDub系のfullはRGB入力になるので不可

>>867
なんとかもかんとかもおまいがそういう使い方をしてるだけ
本来再生環境と編集環境を一致させるため
オーバーレイ表示とGDI表示は同一になるようにキャリブレートしておくもの
テレビでもPCでもデフォルトで正しい色味になってるわけではない
勿論環境によってはキャリブレートがまともにできないものもある
IntelVGAとかね

869 :名無しさん@編集中:04/05/03 00:12
i815EのVGAだと、オーバーレイとGDIの差は判らない程度だよ。
i845以降は傾向が変わったみたいだが。

870 :名無しさん@編集中:04/05/04 11:31
>>869
そういや前スレでもそんな報告あったな
845G以降はしろトビしまくりでキャリブレートしても諧調が戻らないスーパーコントラストになっちったけどね
あと意外とラデもキャリブレートしづらいね
設定が煮詰めきれない
デルタクロームでないかなぁ
雑誌評価はすごかったが>キャリブレート
昔からs3の2D色再現性は高かったんだがな
でないことには

871 :名無しさん@編集中:04/05/04 18:00
845Gは白が飛ぶだけじゃなくて黒もグレーになっちゃう
買うまで知らなかったからそれに気がついて愕然。
当初考えてなかったグラボ買っちゃったよ


872 :名無しさん@編集中:04/05/04 22:17
自作板ではキャリブレートの話題なんかでないし
振ってもレスつかないしね
エソコ、エソコばっか書くくせにさ

873 :名無しさん@編集中:04/05/05 08:02
対抗意識バリバリだな

208 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)