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

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

YC伸張する?しない?総合スレッド

1 :slave:03/04/14 14:53
YC伸張はどんなとき必要か?
多数のアプリを経由したときのスケールはどうなるか?
などなど
codecどころかVGAチップまでもがYC伸張する昨今
混乱を極めたスケール変換についての総合スレです
参考資料

http://vmaker.tripod.co.jp/huffyuvs/convlist.html

2 :名無しさん@編集中:03/04/14 14:57
総合?

3 :名無しさん@編集中:03/04/14 14:57
>>1
@MPEG2→DVD2AVI→AVIUTL→VFAPI→CCE→DVD化
AMPEG2→DVD2AVI→VFAPI→CCE→DVD化
この場合はどーしたら良いん?

4 :名無しさん@編集中:03/04/14 14:59
1じゃないが
DVDにするならしなくていいだろう

5 :名無しさん@編集中:03/04/14 15:01
全部TVスケールにしとけばいいの?

6 :slave:03/04/14 15:04
@DVD2AVI(TVスケール)→AVIutl(YC伸張せず)→VFAPI→CCE(RGB0-255)
A@に同じ

7 :名無しさん@編集中:03/04/14 15:10
>>4 >>6 Thunks!
もう一個質問。
DVD2AVIで、「ColorSpace」で、「RGB 24bit」、「YUV 4:2:2」とあるけど、
これはどーするの?


8 :slave:03/04/14 15:14
>>7
その項目はDVD2AVIでAVI出力したときのみ反映される
プロジェクトファイル経由だとVFAPI経由と同等になる(VFAPIプラグインだから)
そしてVFAPIはRGB入出力しかもたない

9 :名無しさん@編集中:03/04/14 16:30
MPEG2→CCE→DVD化

これじゃだめなの?
わざわざアプリ通して画質悪化させる理由とはいかに?

10 :名無しさん@編集中:03/04/14 17:08
>>9 MPEG2>CCEは不可能です。
ノバック販売CCEのFAQでは、AviSynth経由「ごっちぇ」とかいうの経由で、
MPEG2エンコしろってことになってます。

11 :slave:03/04/14 17:23
まぁ回答しといてアレだが
>>3のAは意味不明といえば意味不明
でも本人のデフォがそういう手順なんでしょう


12 :名無しさん@編集中:03/04/14 17:28
AviUtlが勝手にYC伸張するとかしないとかいう話と関係あるんじゃねえ?

13 :slave:03/04/14 18:01
>>12
VFAPI経由で入力してVFAPI経由で他のアプリに渡すならAVIutlのYUY2展開・圧縮は無関係
それ以前にAVIutlの設定でYUY2展開・圧縮させるかどうかは変更できる

14 :名無しさん@編集中:03/04/14 18:51
いつもやっているのは
Huffyuv→AviUtilでYC伸張(0-255、4:2:2)→VFAPI経由でmpeg2


15 :slave:03/04/14 19:03
>>14
情報不足で回答不能
1、ソースHuffyuvはRGBかYUY2か?
2、AVIutlにおけるYC伸張はなにか?外部フィルタか本体フィルタか?
3、VFAPI経由で渡されたエンコーダはなにか?またエンコーダ側の設定は?
4、視聴環境はPCかTVか?またオーサリングは?

16 :slave:03/04/14 19:05
訂正
2、AVIutlにおけるYC伸張はなにか?外部フィルタか本体フィルタか?

2、AVIutlにおけるYC伸張はなにか?外部フィルタか本体のYUY2設定か?

17 :名無しさん@編集中:03/04/14 19:13
>>1
( ^▽^)<しないよ

18 :名無しさん@編集中:03/04/14 19:48
>>1のHPの作者ってDQNなの?

19 :名無しさん@編集中:03/04/14 19:50
>4、視聴環境はPCかTVか?またオーサリングは?

これは関係ないでしょ。

20 :名無しさん@編集中:03/04/14 19:57
>>18
いい人だよ

21 :slave:03/04/14 20:35
>>19
視聴環境をPC限定としており
YC伸張を行わないVGA、プレイヤー、MPEG2codecを使用するため
最終出力はPCスケール(YC伸張済み)にこだわりたい方もいるか、と
ほんの2年前は↑が多数勢力だったので確認です

22 :slave:03/04/14 20:37
>>18
なお、私はvmaker氏とは関係ありませんので

23 :名無しさん@編集中:03/04/14 21:00
CCESPのトライアルやTMPGEncのフリー使って能書き書いてるあたりでDQN度が分か(ry

24 :名無しさん@編集中:03/04/14 21:24
CCESPのトライアルやTMPGEncのフリー版が製品と色が違ったら大問題だが

25 :名無しさん@編集中:03/04/14 21:51
>>23のDQN度がよくわかるな(w

26 :名無しさん@編集中:03/04/14 22:31
HuffyuvSってHuffyuvを改造した物らしいけど信頼できるのかい?
ソースコードも公開されてないけど。

27 :名無しさん@編集中:03/04/14 22:34
>>26
本当?
Huffyuvって、GPLじゃなかったっけ?
それじゃ、HuffyuvSってライセンス違反の極悪ソフトってことか。

28 :名無しさん@編集中:03/04/14 22:35
>>26
RGB<->YUVの変換のときのYC伸張を除いただけ。無問題。
&ソースは公開されてる。→http://vmaker.tripod.co.jp/files/huffyuvs_0.6_-_left_origin_-_base2.1.1_src.zip

29 :名無しさん@編集中:03/04/14 22:36
>>13
YUY2展開・圧縮するかどうかは設定出来るが、YUY2展開して
読み込んだ場合強制的に伸張されるんだよな・・・

30 :28:03/04/14 22:36
なんか直アドレスだけ書いておくと公開してないように見えるから本ページも付記。
http://vmaker.tripod.co.jp/huffyuvs/index.html

(なんだかなぁ…

31 :名無しさん@編集中:03/04/14 22:40
漏れはPC限定の動画はYC伸張しないで代わりに色補正やってる。
PCのモニターでTVで見てるような色にしたいもんで。

32 :名無しさん@編集中:03/04/14 23:15
だから、PC限定とかっていう言い方には意味がないんだってば。
YUV16-235になってればTVに出すのは問題ではないし
PCなら再生時にビデオチップで伸張されるの。
YUVデータを伸張しないビデオカードで視聴してるんなら買い換えなさいってこった。

33 :名無しさん@編集中:03/04/14 23:17
>>32
i845GでCyberLinkcodec使うと二重伸張されるので
非常に困るわけだが

34 :名無しさん@編集中:03/04/14 23:19
伸張するビデオカードって具体的には何?

35 :名無しさん@編集中:03/04/14 23:23
>>32
それだとせっかく伸張済みで残しておいたライブラリを捨てることにならない?
伸張か伸張しないか選べるビデオカードってあるならなに?

36 :名無しさん@編集中:03/04/14 23:32
>>35
それはビデオオーバーレイの問題では?
使いたいプレイヤー以外で見る気のないファイル再生させて
一時停止しといて最小化してから
見たいのを使いたいプレイヤーで再生すれば
ビデオオーバーレイじゃなくなって伸張せずに済むんじゃなかろうか?
試してないけど

37 :slave:03/04/14 23:41
>>29
それはその通りなんですが
VFAPI入力時にはYUY2展開できませんし、
VFAPI出力時にはYUY2圧縮できませんから、
>>3の場合には問題にならないと思います
ですから>>13のように書きました。

38 :名無しさん@編集中:03/04/14 23:44
>>34
伸張しないのって nVidia 以外であるの?

39 :名無しさん@編集中:03/04/14 23:49
>>38
古いものは全て
古いと言っても3年前くらいだがな

40 :名無しさん@編集中:03/04/14 23:50
G400はしない?

41 :名無しさん@編集中:03/04/14 23:50
TMPGEncもCCEもデフォルトでは16-235になるようになってる。
だからなにも考えない人がRGB0-255に伸張された状態、
つまり編集アプリ上でTVの見た目に近くなるように編集してエンコードしても
Y16-235のデータになるようになってる。
それでいい。
このY16-235のデータを再生するとき、RGB16-235の変換で表示するか、RGB0-255で表示するかは
ビデオドライバに依存する。(まともにハードウェアが働いていれば)
言うまでもなく後者は編集時やTVで見るのに近い表示になる。

変に色気を出すと、二重に伸張したり圧縮したりすることになるのさ。

42 :名無しさん@編集中:03/04/14 23:52
>>39
RagePro、Savage3D、Savage4は伸張してたけど。
KYRO1はしなかった。

43 :名無しさん@編集中:03/04/14 23:55
>>40
しない
G450もしないな

44 :名無しさん@編集中:03/04/14 23:59
>>43
オーバーレイでも変わらないと思ったらやっぱりそうですか?
今ビデオカード買い換えるとしたら何がいいんでしょう?

45 :名無しさん@編集中:03/04/15 00:01
>>41
色気もなにも最大勢力のnVidiaは伸張しないのだが?
ひょっとしてラデ厨?

46 :43:03/04/15 00:02
>>44
>>45


47 :名無しさん@編集中:03/04/15 00:17
伸張する : ATi, S3
伸張しない : nVidia, Matrox

結局伸張させないほうがいいのかな
伸張させたければプレイヤー側で調整しろってこと?

48 :名無しさん@編集中:03/04/15 00:46
>>47
Matrox(Parhelia) - 伸張する

確認方法
DVD2AVI (1.77.3) で m2p 読み込み

「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい

G400/G450 でも伸張してた気がする。今はもう手放してるので確認できないけど

49 :名無しさん@編集中:03/04/15 01:17
MTVとかでTVを生で見るとき
伸張してくれないVGAだとマズーになるの?

50 :名無しさん@編集中:03/04/15 01:35
>>48
全然わかってないな(プ

51 :名無しさん@編集中:03/04/15 02:17
>>48
今ここで伸張するしないビデオカードって言っているのは、
『YUVオーバーレイ』再生時のビデオカードの挙動について謂っているのだよ。
(Display表示するには、RGBデータに変換しないといけないわけだが、
 YUVデータをビデオカードがどのようにRGB変換するかが問題なの)

つまり具体的には、AVIファイルを例えばWMPで再生させてみて(オーバーレイであることを確認)
その動画とTMPGEncやAviUtl、Dubなどの通常のGDI経由の表示画面が同じ輝度・色合いだったら
伸張されている。(WMP再生の方が暗かったら伸張されてない。Geforceなどが相当)

52 :51:03/04/15 02:40
>>48,>>49
MTV1000 レビュアーズガイド
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

ここのオーバーレイについての記述を参考にしてみてね。

53 :名無しさん@編集中:03/04/15 07:39
>>51
DVD2AVI のソース読んでくれ
「映像 -> 色空間 -> YUV」が指定されてるときは DirectDrow で YUV
オーバレイを使って描画してる

54 : ◆S/VMAKER3c :03/04/15 10:24
>1
直接にすると、行方不明者がでるので、できれば、Topから案内してあげて
くださいね(^^;。convlist.html を見て、huffyuvs って何? って人が結構
いたので、レイアウト変えたんだったりするんで。
# convlistはExcel だからリンクの管理がめんどい(ぉぃ)。

>18
ある意味正解(をぃ

>23
なぜトライアルやフリーを使ってテストをしたかと言うと、同じことを誰で
も試せる状況を作って置きたかったからなんですよ。ここで、正式版を持っ
ているもののみで動作を確認して表にしても、「そんなん持ってないから試
せないし〜」「あのページみても参考にならんし〜」って結果になりがちだ
と思います。
幸い、CCE や TMPGEncは比較的よく使われていて、かつ、トライアルおよび
フリーが用意されていて、かつ動作結果が違わないのでサンプルにするには
丁度良かったと言うのが理由なんです。

>26
これこれ、公開してるって(^^;
huffyuvs を Download できるなら、ソースも一緒に見つかるはずのページ
構成にしてあるつもりなんですが、どうして公開されてないって思ったんで
しょう? 今後のページ構成変更の参考にしたいので、ぜひ教えてください。


55 :名無しさん@編集中:03/04/15 12:16
>>54
huffyuvs作者さんですか?
ちょっと聞きたいのですがなんでCCESP用と二種類あるんですか?

56 :名無しさん@編集中:03/04/15 12:25
◆キャプチャ&エンコード 質問、情報交換スレ◆4
ここの400ぐらいから読めばわかる

57 :名無しさん@編集中:03/04/15 15:55
>>53
面白いことを言うね。もう一度自分で、>>48の発言を読んでごらん。
全くのトンチンカンなこと言ってるって分かるはず。

58 :名無しさん@編集中:03/04/15 16:23
>>53
>48ではYUV->RGB変換のことを書いておいて、>>53ではColorspaceがRGBかYUVかを取り上げるのか?

>>53の言うように、色空間がYUVの時は、確かにYUVオーバレイで表示されているよ。
(YUV->RGBの指定が、PC ScaleだろうとTV Scaleだろうと無関係に)

59 :名無しさん@編集中:03/04/15 16:30
@伸張されている場合
  YUVオーバーレイと通常表示は同じ明るさ
A伸張されてない場合
  YUVオーバーレイの方が通常表示より暗くなる

少なくとも、YUVオーバーレイの方が明るくなることは有りえない

60 :名無しさん@編集中:03/04/15 16:47
DVD2AVIのYUV→RGB変換はColor SpaceがRGBの時しか機能しないみたいだし、
YUV→RGB変換がTV ScaleのままでColor Spaceを変えてみたら
RGB TV ScaleよりYUVのほうが明るくなったということを>>48は言いたいのでは。
試してみたらG400も>>48と同じ結果になったのでG400も伸張してるのでしょうか?

61 :名無しさん@編集中:03/04/15 17:22
>>60
色空間がRGBの場合は、YUV->RGB変換をDVD2AVIが、YUV->RGB変換の指定に従って変換後、
当然の結果としてRGBで表示している。
このときの表示はオーバーレイではない。
ビデオカードが伸張するしないに関わらず、すべからず同じ結果になるであろう。

だから、>>48=53は見当ハズレのトンチンカンなことを言っている。

62 :61:03/04/15 17:33
>>60
そのとおりだね。
考え直してみたら、>>48の結果からも伸張しているということは言えるね。
>>48には悪いことを言ったかな。ごめん。

63 :名無しさん@編集中:03/04/15 18:49
つかぬ事を伺いますが、ソフトDVDプレイヤーなんかだと再生の際にプレイヤー側で
0〜255に伸張してるって事でいいのでしょうか?

64 :名無しさん@編集中:03/04/15 19:12
>>63
CyberLinkは伸張し
Ligosは伸張しない

65 :名無しさん@編集中:03/04/15 19:28
>>48
>>60
>>61
いやなんかおかしいぞ?
GeForcemx400でも↓のようになるよ??
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい
純粋にハードウェアオーバーレイになってないんじゃないの?
他のnVidiaユーザーも試してみてよ

66 :slave:03/04/15 19:46
>>54
ご、ごめんなさい・・・・

>>65
検証してみました
>>48と同様になるもの
G450,GeForce2
>>48と異なるもの
i845GE
「色空間」を RGB と YUV で変更 - 「映像 -> YUV RGB 変換 」が パソコン色調テレビ色調に関わらずYUVだと明るくなる
インテルチップセット内臓VGAはYUVを伸張する(というか伸張しかできない)ので有名ですから
DVD2AVIの実装がどうなってるのかはわかりませんが、
パソコン色調時に変化するかどうかで調べるのが正しいのでは?
できればATiの方の実験結果もでてきてほしいですね。



67 :48=53:03/04/15 20:09
言いたいことが伝わったようなので安心した。
判りやすく書けなくて申し訳ない。

ついでに、伸張しない VGA の場合

「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - RGB が明るい
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - 変化無し

になる。

デコーダがオーバレイを確実に使うかどうか不明な MediaPlayer よりも、ソースも
公開されてて、同じフレームで検証できる DVD2AVI の方が確実に判定できると思って
確認方法書いたのだけど、邪魔だったかな。

>>60
40&44 かな?
そういうわけで、G400 と同じ見え方を維持したいなら ATI/Intel/Matrox がおすすめ
G400 からなら Parhelia なんてどうでしょ?

68 :名無しさん@編集中:03/04/15 20:18
>>67
え?

69 :slave:03/04/15 20:20
>>67
ちょっと確認したいんですが
DirectXのバージョンはなんでしょうか?
うちは8aで統一なんですが・・・。

70 :63:03/04/15 20:24
>>64
どもです。要はプレーヤー毎にバラバラなんですな

71 :名無しさん@編集中:03/04/15 20:27
Radeon9000だけど、

DVD2AVIのYUV(PC/TVスケールとも)とRGBのPCスケールは VFAPI Plug-Inで伸張してmme.exeに表示したのと同じ。
DVD2AVIのRGBのTVスケールはVFAPI Plug-Inでストレート変換してmme.exeに表示したのと同じ。

CyberLinkのDirectShowFilter(build 4.00.2417)を使ってMediaPlayerでの表示は
上記伸張した方と同じ。
RavisentのDirectShowFilter(ATi DVD Player)で再生しても伸張された方と同じ。

そしてCyberLinkのデコーダーを使うと2重に伸張されるということは個人的には信じ難い。

72 :48=53=67:03/04/15 20:37
>>69
Parhelia の環境は DirectX 9.0

で、67 書いたあとで nVidia Quadra2 (43.45) で試してみたんだけど……
# こちらは DirectX 8.0a

48 とも 67 とも違う結果が出たので戸惑ってる。
TV スケールの RGB よりも、YUV が暗い。

ドライバ設定でオーバーレイの色調補正ができるけど TV スケールにも PC スケールにも
合いそうにない。

ストレート変換よりも、さらに圧縮してるような感じ。

73 :名無しさん@編集中:03/04/15 20:47
>>55
作者さんの見解ではCCESPがよく使われているからじゃない?
でもなんかダーティーな匂いがするよね

74 :slave:03/04/15 20:51
>>72
とりあえず追試してみました
G450&GeForce2
パソコン色調(YUV,RGBとも)テレビ色調YUV > テレビ色調RGB
i845GE
テレビ色調YUVおよびパソコン色調YUV > パソコン色調RGB > テレビ色調RGB
なにがなにやら???

75 :名無しさん@編集中:03/04/15 20:52
i845GEは伸張しすぎということ?

76 :名無しさん@編集中:03/04/15 21:03
>>55
>>73
http://pc.2ch.net/test/read.cgi/avi/1035744504/962

キャプ質スレ漁ればわかるがユーザーの希望によってつくられたもんだよ>パッチ対応版
ぶっちゃけCCESPTrialをクラックしちまうと
Huffyuv2.11は読み込み不良やエンコードエラーがでる
で、海の向こうではHuffyuv2.11を改造してクラックパッチ対応版Huffyuvが作られた
このクラックパッチ対応版をS化したものがbase2.11-CCESP版なのだよ

77 :名無しさん@編集中:03/04/15 21:17
>>76
クラックパッチ対応版とbase2.11-CCESP版のDLLのサイズがかなり違うんですが
こんな物なんでしょうか?無対応版の差はそれ程ないので。

78 :76:03/04/15 21:22
それはオレに訊いても・・・・・・
vmaker氏の降臨を待て
つーかスレ違いだからキャプ質スレに逝け

79 :名無しさん@編集中:03/04/15 21:32
>>76
じゃあvmaker氏もクラックしてるんですか?
じゃないと動作確認できないですよね?

80 :76:03/04/15 21:33
つーかTOPはってねーな
スレ違いだがな(w
http://vmaker.tripod.co.jp/

81 :76:03/04/15 21:39
>>79
http://pc.2ch.net/test/read.cgi/avi/1042666068/417-427


82 :名無しさん@編集中:03/04/15 21:49
i815Eの場合です。
Win2K-SP3, DVD2AVI(1.76+), DirectX 8.1(4.08.01.0881)

YUV(TV Scale/PC Scale) = RGB(PC Scale) > RGB(TV Scale)

83 :82:03/04/15 21:56
なお、YUVの場合オーバーレイ表示、RGBの場合通常表示であることは確認した結果です。
Alt+PrintScreenでコピーし、ペイントでペーストしたときに
画像が取り込まれているか(通常表示)、真っ暗(オーバーレイ)かで確認済み。

84 :82:03/04/15 22:03
AviUtlの再生ウインドウで、オーバーレイ表示にチェックを入れても外しても
同じ表示であったことも付け加えておきます。
(ここでもオーバーレイ表示の場合、Alt+PrintScreenで画像をキャッチできなかったことを確認)

以上のことから、i815Eのビデオ機能はYUVオーバーレイは伸張『あり』です。

85 :82:03/04/15 22:10
理論上、RGB(TV Scale)がRGB(PC Scale)より明るい分けはないと思うんだが。
(ピクセルの数値はPC Scaleの方がTV Scaleよりレンジが大きいんだから)

86 :82:03/04/15 22:15
画像によっては、明るい暗いという見方より色がくっきりか淡いかで見分けた方が良いみたい。

87 :名無しさん@編集中:03/04/15 22:18
おいおい、0.2.2がクラックパッチ対応とぶっちゃけるとは恐れ入った。

添付のドキュメント読んでないでしょ。
HuffyuvとCCEはYUY2の扱いに食い違いがあったため
RGB Outputをしてやらないとならなかった。
これだとパフォーマンスのロスになるのでHuffyuvをhackしたのさ。
CCEにクラックパッチを当てるからHuffyuvのYUY2で問題が出てたわけではないよ。

またその他、CCEの問題とは別に
Field ThresholdがオリジナルではPAL圏用に288になってるのだが、
0.2.2ではNTSC圏用に240にできるのさ。

88 :76:03/04/15 22:23
>>82
>RGB(TV Scale)がRGB(PC Scale)より明るい分けはないと思うんだが。
あの、RGB(TV Scale)がRGB(PC Scale)より明るい例はでてないと思うが?

89 :76:03/04/15 22:24
>>87
スマソ
家蔵でそう読んだものでね(w

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

どっちもYUV系の出力をするのであればYC伸張しないよ。


動画再生はVGAがYUY2オーバーレイを行い、その際のYUY2>RGB変換の
際にYC伸張するのが一般的な作法。

#オーバーレイがうまく効かない、調整値がいじってあるとか言った状態を勘違いする香具師もいるみたいだが・・・

というか明示的に設定する場合を除き、基本的にはPCで扱うディジタルな色空間はすべて

RGB:PCスケール
YUV系:TVスケール

になってると言うことが理解できれば、この話題は特に混乱することもないと思うのだが・・・

91 :名無しさん@編集中:03/04/16 00:48
わけわかめです。


92 :名無しさん@編集中:03/04/16 05:32
バカにも判るように言えヽ(`Д´)ノ ウワァァン

93 :名無しさん@編集中:03/04/16 07:06
動画見て判断すればいいんじゃね?
違いがわからないならどっちの設定でもよさそうだし。

94 : ◆S/VMAKER3c :03/04/16 08:53
>77
そもそも、huffyuv / huffyuvs / huffyuvs-cce のサイズを比べてもらうと、
「おいこら何か仕込んでないか?」 って思えるほどサイズが違うので、その
辺の理由をば。

最初、まったく動作しないとの報告があり、プログラムの不具合などを疑っ
てたのですが、よくよ聞いてみると、外部 DLLが無いためだった…と言う事
が数例ありました。そのため、huffyuvs は、その DLLを必要しない状態で
コンパイル/リンクされています。これは、外部にあったプログラムを取り
込んでしまっている状態であるため、サイズが大きくなってしまいます。

また、CCEパッチの方は、ToolTip Help のコードとかが増えているために大
きくなっているだけで、プログラム的にはそれほど差がありません。

なので、コンパイルできる環境があるかたは、自前で動的リンクした方が、
HDD に優しいのですが、今時、しかも、ビデオ関連をやろうとしているのに
100K単位以下の差を気にしてもね(^^;


ところで、このスレ。YC伸張関連の話と、ビデオオーバーレイの話が混ざっ
てて混乱してるようにも見えますね。とりあえず、ビデオオーバーレイをし
てるかどうかを確認する方法と、データとして伸張されるのかどうかを確認
する方法に分けて話すってのが良いのではないかと。


95 :名無しさん@編集中:03/04/16 13:19
おまえが話を複雑にしてるんじゃねーかよ

96 :名無しさん@編集中:03/04/16 13:24
YC伸張はしない方が良い。
huffyuvよりhuffyuvsの方が良い。
って事ですか?

97 :名無しさん@編集中:03/04/16 14:10
>>94


>>95
氏ね

>>96
自分がいいと思ったほうにすればいいんじゃない?
漏れはそうしてる。自分しかみないからね。

98 :名無しさん@編集中:03/04/16 16:42
前提なしで「良いか、悪いか」の結論を付けたがる奴って必ずいるよな。


99 :名無しさん@編集中:03/04/16 16:47
>>96
ヴぉけすれあげんなヴぉけ

100 :名無しさん@編集中:03/04/16 19:21
100げっつ

101 :名無しさん@編集中:03/04/17 01:34
>>97
いやだ おまえもしちゃ駄目

102 :名無しさん@編集中:03/04/17 02:49
意味不明

103 :山崎渉:03/04/17 12:00
(^^)

104 :名無しさん@編集中:03/04/17 13:36
俺の身長も伸ばしたい 

105 :名無しさん@編集中:03/04/17 16:31
sageんなヴォケ

106 :ラデ厨:03/04/17 20:07
TV出力するからYC伸張しない、PCだけでしか見ないからYC伸張するという
出力方法や見た目で場合分けする奴はゲフォ厨。

YUVデータを伸張しないゲフォで
Y(16-235)のデータをテレビと同じ輝度でPCでモニタするには
ソースそのものをY(0-255)に伸張しないといけないからな。
こいつをTVで見れば当たり前のように色飛びするわな。
だからTVで見るから、とかPCでしか見ないからという言い方をする。

一方、ラデやインテルのように伸張するチップだと
データそのものを伸張しなくても
PCのモニタとTVとで同じ輝度で見えるから
PCで見るのこととTVで見ることに区別をつける必要がないし、
余計な伸張処理をしてればおかしいことに気付くことが出来るのさ。

趣味でDTVやってる人はゲフォ厨の言うことに惑わされないように注意しよう。

107 :名無しさん@編集中:03/04/17 20:20
つっても乗ってるカードがゲフォだからなぁ。
ラデが乗ってるならそれでいいんだろうけど。
自分の環境に合った設定でエンコする、では不満ですか?

108 :名無しさん@編集中:03/04/17 21:08
>>107
プレイヤーで伸張できるものなぞいくらでもある。
伸張してエンコするヤシがヴァカなだけだよ。
伸張してエンコするとビットレート的にも不利なんだからさぁ。


109 :名無しさん@編集中:03/04/17 21:10
>>107
それじゃあ、ビデオカードを買い換えたときに後悔するかも。
Geforceであっても、BT.601準拠で作成するほうがいいぞ。
GeforceのYUVオーバーレイに合わせると、TV出力する場合や友人にやる場合とかに困るだろ。
それでPCで再生する場合、ffdshowとかで伸張しながら再生すると万事解決だね。

110 :名無しさん@編集中:03/04/17 21:19
仲間外れはゲフォ厨だけでよろしいか?

111 :名無しさん@編集中:03/04/17 21:25
>>110
kyro厨も入れておいてくれ

112 :名無しさん@編集中:03/04/17 21:30
gefo使ってるけどTV出力はVG1000使ってる俺もナカマ外れですか?

113 :107:03/04/17 21:35
基本的に俺はYC伸張しない派なんだが。

114 :名無しさん@編集中:03/04/17 21:39
>>112
君は、ゲフォの見た目に合わせる不具合を実感してるだろうから、
人にあげる場合は注意しているだろうし、自分の範囲内で切り分けしてるなら問題はないよ。
ナカマニイレタゲルヨ

115 :名無しさん@編集中:03/04/17 23:11
>113
YC伸張する派しない派なんていうのが見当違いなんだよ。

最終的なデータをBT.601に準拠させるために
伸張したりその逆をしたりという処理が必要な場合があるんだよ。

よくあるのがRGB(16-235)のデータ(例えばMPEGキャプチャのソースをTV出力するからと言ってDVD2AVIでRGB TV色調にして)を
TMPGEncで「BasicYCbCrで出力〜」にチェックを入れない状態でエンコードするやつ。

116 :名無しさん@編集中:03/04/17 23:44
Geforceのオーバーレイはだろ、Canopusさん。
>オーバーレイを行う場合には、デジタルコンポーネントビデオをグラフィックスボードがRGBに変換しますが、デフォルトの変換では、Y=235の白は(R,G,B)=(235,235,235)に変換され、Y=16の黒は(R,G,B)=(16,16,16)に変換されます(*1)。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

さてATIのチップでグラフィックボードをリリースすることになったら今度はどう書くのかね。
http://www.zdnet.co.jp/news/0304/17/nj00_canop2.html


117 :名無しさん@編集中:03/04/17 23:48
>>115
途中でするかどうかなんて話しとらんじゃん!?
最終出力の話してるだけやん

118 :名無しさん@編集中:03/04/18 00:30
>>115
他人が作った動画を自分がもらうことを前提に話してる?

119 :名無しさん@編集中:03/04/18 00:39
>>118
動画自体じゃなくても、そういうちょっと間違った情報を初心者に吹聴する人を前提にしてる。

120 :名無しさん@編集中:03/04/18 00:43
DVD2AVIなんか使わなければよい

121 :名無しさん@編集中:03/04/19 10:29
良スレだね…

122 :名無しさん@編集中:03/04/19 23:12
ageられてもダレもレスできないくらい良スレですな

123 :名無しさん@編集中:03/04/20 04:46
考えるのが面倒だから伸張なしでエンコ

124 :山崎渉:03/04/20 05:52
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

125 :大田遺産:03/04/20 15:38
MPEG2(カノプMTV2000)からWMV9に変換の場合(簡潔に)
DVD2AVI(TV Scale・d2v保存)→TMPGEnc(音ずれ補正のみ使用・DVD2AVIで
音声出力時の-66msとかを修正)→aviutl(拡張色調補正でTV→PCスケール
補正・ここでYC伸張される・aup保存)→VFAPIConv(aupから参照aviへ
変換・音声含む)→WME9(WMV9エンコ)
の順でやっている。これでMPEG2とほぼ同じ輝度だった(CRTで確認)。
YC伸張はaviutlで1回やっている。これを無効にすると少しMPEG2より
すこし輝度が落ちかつ色が少し薄い?感じになった。俺の場合はオリジナル
に一番近いかどうかで判断しているため、YC伸張してる。まちがいがあったら
指摘ください(グラボはマトG550使用)。


126 :大田遺産:03/04/20 15:59
修正
×少しMPEG2→○MPEG2


127 :名無しさん@編集中:03/04/20 18:43
>>125
>aviutl(拡張色調補正でTV→PCスケール補正・ここでYC伸張される・aup保存)
>→VFAPIConv(aupから参照aviへ変換・音声含む)
VFAPIConv通すってのは無圧縮RGB出力してんのと同じだから
WME9がRGB>YV12変換時にYC圧縮→再生時にYC伸長してるだけでないの?
YUVエンコーダがRGBで入力されたときは「伸長されてるもの」として扱うのは極一般的
YUVで受け取ったときはどうなる?
VFAPI使えないけど・・・

あと
音声出力時が-66msだったら音ズレ補正などせんで
まるもプラグインで直にAVIutlつっこんだほうがいいでしょうな
まぁ音声.m2pじゃないとあかんけど

128 :名無しさん@編集中:03/04/20 19:15
http://vmaker.tripod.co.jp/huffyuvs/convlist.html
↑の表を見ると

HuffyuvS(YUY2)→AviUtl (YUY2チェック無)→VFAPI→Codec
だとストレートって読めるけど

この場合YC伸張or圧縮はされてないと判断していいの?
それともやはりVFAPIの時点で伸張されてしまうの?

129 :名無しさん@編集中:03/04/20 19:19
>>127

>WME9がRGB>YV12変換時にYC圧縮

そうされるのを見越してAviUtlの時にYC伸張(RGBフルスケール化)してるんでしょ。
そこで伸張しないとTVスケールから更に圧縮されることになる。

結果として前後でYUVオーバーレイの色調が同じになってるんだから
なにもマズいところはないはずだけど。

130 :127:03/04/20 20:19
>>129
マズイって書いてないんだが?
本人が理解してるのかどうか自信がないようなんで解説つけて
なおかつあえて質問つけてるだけよん

>>128
>HuffyuvS(YUY2)→AviUtl (YUY2チェック無)
この段階ではストレート・・・というかYUY2
YUY2はデータ的には(0-255)を持つが表示されるときには(RGB変換されるので)
(0-255)のうち(16-235)の領域を(0-255)に伸長してRGBにする
これがYUVオーバーレイ表示における常識的なビデオカードの伸長動作(つーかBT.601準拠の動作)

>→VFAPI→Codec
ところがここでは表示してるわけではないので(データとして渡してるだけなので)
YUY2の(0-255)がストレートでRGBになってる
YUY2(0)=RGB(0)になってるのね
つまりVFAPIに通った時に(RGBになったときに)BT.601準拠のデータではなくなっている
BT.601に準拠するならYUY2(0)=RGB(16)にならないかんわけよ
だから最終出力時にエンコーダに対して「このデータは伸長されてませんよ」と明示してやらなければならない

ということであって
>この場合YC伸張or圧縮はされてないと判断していいの?
はあっている
>それともやはりVFAPIの時点で伸張されてしまうの?
何度も出てる話だがVFAPIは伸長しない(なんでもかんでもRGBストレート=BT.601に準拠しない)

131 :大田遺産:03/04/20 20:38
>>127
まるもさんのMPEGデコーダでaviutlでaupやってみたらWME9で画面が出力
されなかったので(原因不明)125のやり方でWMV作ってる。それから音ずれ
チェックはまるもさん(aviutl2つ起動して音波形確認)のと比べて-66msで
ほぼ合っていることを確認した。
YC圧縮→再生時にYC伸長してるだけでないの?>>メディアプレーヤー9は
再生時はYC伸長していないと思う(確信なし)

>>129
>WME9がRGB>YV12変換時にYC圧縮
なるほどWME9でYC圧縮してるからaviutlでTV→PCスケール(YC伸張)しない
とWMVの色が薄くなった感じになるわけだ。勉強になります(CRTでオーバー
レイの画像比較でのみ判断してたもんで)


132 :名無しさん@編集中:03/04/20 20:41
好きなようにやれよ。

133 :127:03/04/20 20:44
>>131
>メディアプレーヤー9は
>再生時はYC伸長していないと思う(確信なし)
YUVオーバーレイはビデオカードの仕事なんだが
WMP9はGDI表示するのか?


134 :127:03/04/20 20:51
大体オレと>>129は同じこと言ってるんだが・・・
>WME9がRGB>YV12変換時にYC圧縮
してるなら
>再生時はYC伸長していない
わけないんだけどなぁ

135 :大田遺産:03/04/20 20:55
>>133
>>134
そうだったのか、素人ですまん。アドバイスありがとう


136 :名無しさん@編集中:03/04/20 21:50
>(0-255)のうち(16-235)の領域を(0-255)に伸長してRGBにする
>これがYUVオーバーレイ表示における常識的なビデオカードの伸長動作(つーかBT.601準拠の動作)

カノープスではビデオチップでは伸張されないことが常識とされていて、
伸張するビデオチップは異端であるかのような扱いだ。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

#127に突っかかってるわけじゃないからよろしく。

137 :127:03/04/20 21:56
>>137
つっかかれてると思ってるわけではないが
あくまでも「BT.601準拠の動作」を基本に解説しただけ
質問者のビデオカードはゲフォちゃうしな
それにカノープスはラデに乗り換えるようだから
そこの表記も変わるんでない?

138 :127:03/04/20 21:56
>>136でした(w

139 :名無しさん@編集中:03/04/20 22:02
カノープス独自ドライバで伸張させないようにしたりして

140 :127:03/04/20 22:07
ありえる(w

141 :大田遺産:03/04/20 22:34
もひとつ聞きたいのですが
>>47 48の人が伸張する : ATi, S3、伸張しない : nVidia, Matrox
Matrox(Parhelia) - 伸張すると書いてるが俺の作ったWMV9はYC伸張したもの
ばかり。ということはラデオンとかにグラボ換えたときオーバーレイ表示で
2重にYC伸張されちゃうのか?だとしたらマズー(ON・OFF切替あるか?)
その辺どうなんでしょ。


142 :名無しさん@編集中:03/04/20 22:41
>>141
その後の調査でMatroxも伸張してるということになりました。

伸張する : ATI, S3, Matrox, Intel
伸張しない : nVidia, ST Microelectronics(KYRO)

143 :名無しさん@編集中:03/04/20 22:58
>大田遺産

>>125の手順で作成してるなら問題ないですね。


144 :大田遺産:03/04/20 23:02
>>142 ゲゲーー。ということは俺はG550ユーザー(Ti4600もサブ機に付けて
いるが)だからYC伸張してるグラボにさらにYC伸張かけたWMVで2重伸張
されたものをみてたわけか?どうりでDVDMAXでのTV出力でやけに画像が
明るいとおもった。でもCRTのオーバーレイではオリジナルMPEG2(MTV2000)
と俺の作ったWMV9の輝度と色調が同じなんだよな(エロアニメでの肌色の
確認にて・けっこうはっきりわかる)。結局どのやり方が正しいんでしょか?
(Ti4600ではオーバーレイが汚いかつTV出力オーバースキャンせずの2重苦で
見る気がせん。)


145 :名無しさん@編集中:03/04/20 23:04
>大田遺産

そもそも、どうして最初にDVD2AVIでTVスケールにしているの?
あなたの使い方の場合、ここでPCスケールにするのが普通だと思うけどなあ。

146 :名無しさん@編集中:03/04/20 23:05
>>144
いや、WMV9 がエンコード時に圧縮してるから、気にしなくて良い

147 :名無しさん@編集中:03/04/20 23:08
DVD2AVIのやつはAVI出力時のみ反映されるんじゃなかったっけ

148 :名無しさん@編集中:03/04/20 23:08
>>137
マジでカノプラデにのりかえるの?

149 :名無しさん@編集中:03/04/20 23:09
>>145
>>147

150 :名無しさん@編集中:03/04/20 23:13
>>145
プロジェクト保存でも反映されたとしても
微調整出来ないから白とび黒つぶれする可能性がある

151 :名無しさん@編集中:03/04/20 23:20
>>145のいうように、できるだけ伸張・圧縮の回数を減らすようにした方がよい。
大多数の人間は、RGBではPCスケールで処理するとおもう。

DVD2AVI :YUV(YV12)->RGB(RGB24)  ここでPCスケールにする
TMPGEnc :RGB24
AviUtl  :RGB??
VFAPI  :RGB24
WME   :YUV(YV12) BT.601準拠の標準YUVに変換してくれる

こうすればAviUtlで伸張しないで良い。
大体、情報量はできるだけ無くさないように処理することを心がける。
圧縮->伸張するとデータの詳細な点が無くなる

最初にTVスケールにする特殊な場合を使う人は、特定の目的のために
メリット・デメリットをしっかり把握してその上でやってるわけ。

152 :こうもいえるんだけどね:03/04/20 23:23
>>136

カノープスでは動画はBT.601準拠に準拠したレベルで作られているということが常識とされていて
エンコードの段階でYC伸張して調整してある動画は異端であるかのような扱いだ。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

136にに突っかかってるわけじゃないからよろしく。

153 :152:03/04/20 23:26
誤字多すぎ、漏れ・・・・。



154 :名無しさん@編集中:03/04/20 23:34
>>152

いやいや、
BT.601準拠に準拠したレベルの動画を、オーバーレイの調整で伸張するのは
カノープスにとっては普通ではないという書き方がされてるんであって、
(「●オーバーレイ領域の映像調整でコントラストを上げても、あまり良くならない」の部分)
エンコードの段階でYC伸張して調整してある動画のことなんてどこにも出てこないよ。

155 :名無しさん@編集中:03/04/20 23:38
>>150
今TMPGEncで確認してみた。プロジェクト経由でもしっかりPC/TV Scale指定は反映されてた。
色空間をYUVに指定しても、DVD2AVIのプロジェクトVFAPIプラグインで必ずRGB24に変換されるみたい。

あと、変換時に範囲オーバーの値がカットされるのを心配しているようだが、
カノプのMTVだったらその点は問題ないと思う。
圧縮->伸張すると色分布に隙間が開くデメリットがある。
(つまり隣り合わせの似た色の差が同じになるデメリットがある。色情報が潰れる)

156 :名無しさん@編集中:03/04/20 23:47
カノプーのページで書かれてることはbt.601準拠の映像データがオーバーレイでどう表示されるのかが書かれてるだけだね。
エンコードするのにYC伸張するのが正しいのか誤りなのかは書かれていないね。

157 :名無しさん@編集中:03/04/20 23:53
あちらこちらのスレで、エンコの仕方について
偉そうに能書きたれている人を見かけるけれど
世間に出回っている動画を見ると
しょぼいペグ1ばかりが目につく。
はやりのアプロダなんかをチェックしてても
高画質な動画なんかどこにもない。
ということは、えらそうな口をきいているやつらも
実力のないアホばかりということらしい。


158 :127:03/04/20 23:55
>>144
しょーがないから詳細に説明
>DVD2AVI(TV Scale・d2v保存)→
ここでYV12(ちなみにYUVなのでオーバーレイ再生時伸長される)がストレートでRGBになる
つまりYUV(0)>RGB(0)
.d2vで送られる場合はRGBになるのと同等(なぜならVFAPIだから)
余談だがPC Scaleにすると伸長される(VFAPI経由で無視されるのはColorSpace(色空間指定)であってスケーリングは無視されない)
>TMPGEnc(音ずれ補正のみ使用・DVD2AVIで音声出力時の-66msとかを修正)→
VFAPI>VFAPIであり、伸長処理してないのでそのまま
つまりソースから見ればYUV(0)>RGB(0)
>aviutl(拡張色調補正でTV→PCスケール補正・ここでYC伸張される・aup保存)→
まったく大田遺産の言うとおりで「ここでYC伸張され」てるんだよ
ソースから見ればYUV(16)>RGB(0)(BT.601準拠)
>VFAPIConv(aupから参照aviへ変換・音声含む)→
VFAPIだからストレート
しかし前段で伸長されてるので
ソースから見ればYUV(16)>RGB(0)(BT.601準拠)
>WME9(WMV9エンコ)
RGB入力なのでYC圧縮してエンコードされる
ソースから見るとYUV(16)>YUV(16)
>グラボはマトG550使用
なので再生時伸張される
つまりソースとエンコ後でデータのスケーリングも再生時の動作も一緒
あってるじゃん


159 :127:03/04/21 00:04
>>150
>>155
まぁどっちにしろ伸張してRGBになる作業がはいると白トビ黒つぶれはさけられない
ただその問題はTV出力した場合にかぎるし
避けようとするといかなる段階でも伸張せずに
YUVのままでエンコーダまでもってかなきゃならんのでスキルがいる
ぶっちゃけAVIsynthか、どうしてもAVIutl使うならHuffyuvSで中間ファイルを出すしかない
つーか、だからHuffyuvSがつくられたんでしょう
勿論RGBになる段で伸張しないという手もあるが
その場合はエンコーダの設定で伸張されてないことをはっきりさせる必要がある
TMPGEncやCCEはその設定があるんだが他のエンコーダはシラソ

160 :名無しさん@編集中:03/04/21 00:14
>>158
>ソースから見るとYUV...
分かりにくい。
単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。

ところで、微妙な表現に関して。(説明の省略だってことは分かってる)
YUV(0)->RGB(0)になるわけじゃない。(普通はならない YUV(0,128,128)->(0,0,0)にはなるけど)

独り言
●PCスケール、TVスケールって、YUVの場合で言うのはなんかしっくりこない
●RGB(TVスケール)にしてたって、その後、伸張しちゃったら意味は無い。
 (この場合は伸張せずに最後まで処理しないとTVスケールにした意味は無い)
 (または、手動色補正で伸張作業を行いPCスケールにまでもっていくこと)

161 :名無しさん@編集中:03/04/21 00:19
>>159
>ただその問題はTV出力した場合にかぎるし
何言ってんの?

中間ファイル出力なんて誰も言ってないし、
そこまで気を配る人は詳細情報の欠損を気にして、HuffyuvでもRGBで保存するはず。

162 :127:03/04/21 00:25
>>160
>単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。
それも思ったんだが受け渡しはRGBなんだが内部処理が違うもんが入ってるんで
こっちのがわかりいいか、と
ちなみにそれはAVIutl
内部YUV24ビット(なんと4:4:4YUV)処理で色調補正系フィルタとモニタ表示はRGB24ビット変換(あたりまえ)というキテレツ仕様
しかもYUV<>RGBは古い計算式で誤差盛りだくさん
いや、色調補正はRGB32ビットたったかも・・・

163 :127:03/04/21 00:32
>>161
オレがいったのはRGB(PC Scale)に途中でするとクロップされる情報があるよ、ってことだけ
またソースか途中段で伸張せずにHuffyuv RGB(TV Scaleなら)にするなら確かに問題はないね
ぶっちゃけTMPGEncなら伸張せずにHuffyuv RGB
CCEならHuffyuvS YUY2が一番なんだが
途中段で処理間違ったらどーもこーもだがな

164 :名無しさん@編集中:03/04/21 00:39
>>162
aviutl の内部処理詳細仕様

内部処理フォーマット YUV 48bit (4:4:4 YUV, 各色 16 bit, 有効範囲 12 bit, マージン 4 bit)
オーバーレイ時は YUY2 形式(8 bit Y, U, Y, V 形式)
プレビュー時は RGB24 形式 (8 bit RGB 形式)
コーデックで YUY2 オプション付けたときは YUY2 形式で入出力、それ以外は RGB24
入出力プラグインの場合はプラグイン側で RGB24 か YUY2 を選べる

昔は変換誤差が大きかったけど、最近(0.98 系から)まともになった

相互変換は

YUY2 -(伸張)-> 内部形式 -(ストレート)-> RGB24
RGB24 -(ストレート)-> 内部形式 -(圧縮)-> YUY2

という扱い

普通のフィルタプラグインは全て内部形式で処理してて、AviUtl 組み込みの色調補正
フィルタとかにのみ RGB で処理するものがある


165 :名無しさん@編集中:03/04/21 00:41
GF4使っててffdshowで伸張する場合レベルのインプットを16-235でいいの?


166 :名無しさん@編集中:03/04/21 00:41
>>154

んじゃ、カノプの言うままに調整した環境で「エンコードの段階でYC伸張して調整してある動画」を
再生するとどうなるよ?

普通の動画(BT601準拠)と「エンコードの段階でYC伸張して調整してある動画」を再生するたびに調整しなおす?

167 :大田遺産:03/04/21 00:47
>>127様他の皆様方、さまざまな意見、アドバイスをどうもありがとう。自分
のエンコのやり方がマチガっていなくて安心しました。理論的なことがよく
わからんかったのでCRTでのみ(色々なスレをみながら)確認していたので
自信がもてなかった(以前にDixXでエンコしてたときはDVD2AVIでTV Scale
そしてAviUtlでそのまま(拡張色調補正OFF)でやってて出来上がりの動画・
エロAVがどうしても肌色が薄いというか暗いというかそんな感じであれー
なんかちがうなーと思ってた)。そこでたまたまYC伸張スレを見て思い切
ってみんなはどーやっているのか聞いてみたわけです。どーもありがとー、
でわまたあうひまで(といいつつすぐ書くかもしれんが)。


168 :名無しさん@編集中:03/04/21 00:51
>>166
そういうこと。
フルスケールのYUVデータを作ってしまってた人はご愁傷様。
だから、>>109の言うようにBT.601準拠のデータを作りましょうという話なのさ。

そもそも伸張しないチップのユーザーがカノプの言うようにちゃんと調整してれば
「エンコードの段階でYC伸張して調整してしまった動画」なんて作りようがない。


169 :名無しさん@編集中:03/04/21 00:51
>>166
カノプは別に、Geforceに合わせて伸張しろとは言ってない。
言っていることは、
『オーバーレイにすると暗くなるけど、そのために伸張して明るくするのはダメ、
むしろ伸張せずにオーバーレイの方をなんとか調整して普通に見えるようにしたほうが良い』
って良いこと言っていると思うけど。

170 :名無しさん@編集中:03/04/21 00:53
>>166
「エンコードの段階でYC伸張して調整してある動画」なんて存在
するのか?

BT.601 形式の YUV を、YUV でフルスケールに拡大するとしたら
TMPGEnc でフルスケール RGB を BasicYCbCr でエンコードする
ぐらいの方法しかないと思うのだが。

エンコーダ(CODEC)が RGB -> YUV の際に、RGB フルスケール
から BT.601 スケール YUV に変更するから、YUV から RGB に変
換するときには BT.601 スケール YUV からフルスケール RGB に
変換するって、それだけのことしかやってないぞ。


171 :169:03/04/21 00:54
読み違えた。メンゴ

172 :名無しさん@編集中:03/04/21 00:57
>>170
そういうもっともな事じゃなくて、
巷には何と!色補正でYC伸張(別にTMPGEncでもAviUtlでもなんでも良い)してから
エンコした動画が出回ってるわけ。
(当然カノプのいうように、白飛び、黒潰れのクソ動画になってるわけ)

173 :名無しさん@編集中 :03/04/21 00:59
>>170
GeforceはYUV→RGB変換がストレート変換なので
エンコード後のデータをフルスケールYUVになるようにしておかないと
BT.601 スケール YUV → フルスケール RGB と同じに見えないらしい。


174 :名無しさん@編集中:03/04/21 01:06
>>170
DivXでもXviDでもRGB->YUV変換時、サチュレーチョンなぞしてない。
つまり、通常は色バランスが崩れているから、RGB(PC Scale)->YUV(TV Scale)に変換後でも
YUVで、16-235(240)を外れたデータが出来てしまう。
(極端なことをいったら、YUV=(255,128,128)はBT.601準拠で変換しても範囲内に収まる)

TMPGEncで普通にエンコしたら、必ず16-235(240)にサチュレーションされるみたいだから
さらに情報が欠損するけど。

175 :名無しさん@編集中:03/04/21 01:25
DVソース→Avisynth→HuffyuvS→CCE
の場合はColorYUY2で411->422にしておくのが適当かな。
オーサリング前提です。

176 :名無しさん@編集中:03/04/21 01:50
>>172
エロDVDでたまにそういうのあるね。
マイナーなレーベルのやつとか。

177 :名無しさん@編集中:03/04/21 06:18
>>175
それはYC補完
微妙にスレ違いだが正解

178 :名無しさん@編集中:03/04/21 08:08
えーとつまり・・・huffyuvS(YUY2)の0-16,235-255部分を
犠牲にしたくないならAviutil使ってる時点でもうアウト?

どうしてもAviutilを使いたいならhuffyuvSの
Convert YUY2形式で中間を吐けばOK?

179 :名無しさん@編集中:03/04/21 08:40
>>178
意味わからん。
huffyuvS(YUY2)だったら、YUY2なんでしょ。AviUtl使っても大丈夫だよ。
AviUtlのYUV444(12bit)なら、オーバーフローなんてしないし。
どうしてConvertYUY2なんて出てくるの?そのままYUY2で出力すれば?

180 :名無しさん@編集中:03/04/21 11:16
知恵熱出てきた(つд`)

181 :名無しさん@編集中:03/04/21 19:52
0-16,235-255部分を持つHuffyuvS(YUY2)をAviUtlで扱うときは
YUY2オプションを外し
RGB展開してRGB圧縮でHuffyuvS(RGB)か、ConvertYUY2によるHuffyuvS(YUY2)出力をすると
レンジが保存される。
編集中はTV→PCスケール変換をチェックしておくと、TV表示や(伸張する)オーバーレイ表示に近い状態で編集できる。
もちろん出力時にはTV→PCスケール変換のチェックを外しておくこと。
さらにこのデータのレンジをMPEGエンコードでも保存するなら
HuffyuvS(RGB)はTMPGEncでBasicYCbCr出力、CCEで0-255のオプションを付けること
HuffyuvS(YUY2)はTMPGEncでBasicYCbCr出力、CCEはYUY2デコードを試みるのオプションを付けること

AviUtlはYUY2ソースをYUY2展開するときは伸張する。
伸張前の0-16,235-255部分は0-255の範囲を超えるが
編集中においてはオーバーフローはしない。
ただこのときYUY2オプションにチェックしてYUY2出力すると
0-255の範囲を超えてたデータは切り捨てられた上で16-235に圧縮される。
つまりソースの0-16,235-255部分は切り捨てられる。

ただ178の言う0-16,235-255部分が
ちょびひげ程度なのか、フルレンジびったりなのか、
犠牲の意味が、切り捨てされることなのか、スケールを圧縮しなくちゃならんことなのか
それが分からないと第三者にはどうするのが良いかは分からないよ。


182 :178:03/04/21 20:45
>>179
AviutilからhuffyuvS(YUY2)で出力するとYC圧縮かかっちゃうので。

>>181
「犠牲」は切り捨ての意味で使いました。
やはりConvertYUY2で中間ファイル吐いた方がいいみたいですね。

メインで使ってるWMV9がRGB(0-255)→YUY2(0-255)変換できれば
わざわざ中間ファイルいらないのになぁ

183 :名無しさん@編集中:03/04/21 20:59
>>172
それは茂木とあにぺぐのせいのような・・・
書かれた当時と状況が違うとはいえ
ネットってヤシはずっとそのときの情報がグルグル回ってたりするからな
今は変更されたが茂木なんか「CanopusDVをストレートで扱うのはおかしい」みたいなこと書いてたでしょ


184 :名無しさん@編集中:03/04/21 21:20
>>181
色補正は、TV→PCスケール変換 後の値に補正値が掛けられるの?
もしそうだったらチェックを外すと補正値じゃ若干大きくなるから
補正時にはその分小さく(0.7倍程度にする?)設定しないといけない?

185 :名無しさん@編集中:03/04/21 21:56
PCでしか見ないなら伸張する、TV出力するなら伸張しない
なんてわめいてる奴の方がよっぽど罪が重いと思うがな。


186 :名無しさん@編集中:03/04/22 00:00
PCのみに限定してても伸張するとコントラストがえぐくなりすぎてダメだ。

187 :名無しさん@編集中:03/04/22 00:04
どんどん訳わかめになっていく。
huffyuvでUYVYキャプしてそのままCCEで縁故するのはだめなんですか?

188 :名無しさん@編集中:03/04/22 00:17
>>187

ダメじゃないよ。まともなスケールでキャプチャしてればね。

189 :名無しさん@編集中:03/04/22 01:06
YC 伸張 (わいしーしんちょう)

YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
行う一部 CODEC (Canopus DV など)の仕様をユーザレベルで回避するた
めの緊急回避的処理。

通常は CODEC の YUV -> RGB 変換の際に同時に伸張処理が行われるので
使用してはいけない。また YUV データのまま、RGB に変換せずに処理す
るばあいも、使用してはいけない。

常識だと思ってたのだけど、不安になったので書いとく。

190 :名無しさん@編集中:03/04/22 02:11
>>189
確かに常識だ。
ただし、HuffyuvSでもYUY2で入出力せずに、RGBでの入出力する場合は、
>YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
>行う一部 CODEC
に該当するってだけ。

191 :名無しさん@編集中:03/04/22 10:52
huffyuvSでキャプ(0-255)、そのままTMPGEncで伸張せずにBT601にてエンコしたものは
PCで見ると(16-235)だが、マト様でTV出力すれば問題なし、ってことでOK?

192 :名無しさん@編集中:03/04/22 13:09
>>191
YUV -(ストレート)-> RGB -(圧縮)-> YUV になるけど
キャプチャ時に YUV で (0-255) まできっちり広がるように
設定を詰めてるんなら問題なし

>PCで見ると(16-235)だが
ハードウェアオーバレイで伸張しない VGA で見ればなら問題なし
パソコン色調のDVD2AVIで見ても(16-235)なら問題あり

>マト様でTV出力
DVDMax はデフォルトだと BT.601 からさらに伸張かけるので基準に
使わない方がいい (自分で調整済みなら別)

193 :名無しさん@編集中:03/04/23 15:59
>>180
同じく…

で、質問なんでスが、2Passエンコしたいがために今まで

1. Huffyuv(YUY2)でキャプって、
2. AviUtlで処理してHuffyuv(YUY2で展開・圧縮・圧縮設定保持)で出力
3. VDub使って2Passエンコ

ってしてたんだけど、これだと2の段階で余計な伸張・圧縮が起きてるってこと?
>>1 の表を見るとモロにそういうことになるみたいなんだけど…
どうしたら回避できるんですか?

194 :名無しさん@編集中:03/04/23 18:50
>>193
AviUtlは処理ビット数が大きいため変換誤差は気にすることはないと思われ。

195 :名無しさん@編集中:03/04/23 18:54
Canopus MTVシリーズ
------------------------------------------------------------------------------------
Q: 録画したファイルを再生すると色が薄い。
A: PCのディスプレイとテレビでは仕組みが違うので、そういうもん。テレビで見るときれいに映る。
------------------------------------------------------------------------------------
先日MTV2000を購入して初のキャプチャをしまして、出来たm2pファイルを
メディアプレーヤで見ようとしたのですが、何か画面がとても暗いんです。
G-Specで見ると普通なんですが、メディアプレーヤ(6.4と7と9で確認)では
明らかに暗いです。

これはテンプレにある、「録画したファイルを再生すると色が薄い。 」って
やつのことでしょうか?
だとしたら、皆さんどうやって見てますか?
------------------------------------------------------------------------------------
MTVのキャプチャはTV出力したときに普通の色になるようにキャプチャされるから、
当然PCのモニタで見た場合には暗い感じになる。
G-Specは使ったことないが、それを考慮して再生時に調節されるんだろうな。


196 :名無しさん@編集中:03/04/23 19:24
>>193
せっかく中間ファイル吐くんなら

1.HuffyuvS(YUY2)でキャプ
2.AviutilでYUY2展開・圧縮ノーチェックで読み込んで
 HuffyuvS(Convert YUY2)で中間ファイル出力
3.VDubの再圧縮(高速)でエンコ

がいいかと(手間も一緒だし)。
途中でYC伸張・圧縮されないから
0-15,236-255の範囲も保持される。

197 :名無しさん@編集中:03/04/23 20:15
・・・ん?
伸長しない方が良いってなってるけど、AVIUTLでYUVで保存するなら
(つーかDirectXの規定ではRGBはフルスケールで扱いYUVは16-235
で扱うことになってるから)画面に表示された状態では伸長しとかな
いとまずいんでは?
YUVに再変換されるときにYC圧縮かかる訳だし。
YUV読み込みで既に伸長されている物を更に伸長するのはあれだが。
YUV出力しないなら話は別な。
もっとも伸長圧縮しないでYUVのまま回せれれば一番いいんだが。

198 :名無しさん@編集中:03/04/23 20:52
>>197
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html

↑を見る限りでは>>196の通りにすれば
YUVに再変換する際にYC圧縮されないんじゃ?

確かにAviutilで編集するとき(PCモニタ上で)
一時的にPCスケールにしておいた方が
フィルタの調整はやりやすいと思うけどね。

199 :名無しさん@編集中:03/04/23 21:19
0-15,236-255を無駄にしたくないって人いるけど、
その範囲って、画面の何割も占めたり重要なピクセルなの?

自分は16-235に収めて、その範囲外はノイズだったりシュートしてオーバーした部分程度だったりするんだけど。

200 :名無しさん@編集中:03/04/23 21:37
>DirectXの規定ではRGBはフルスケールで扱いYUVは16-235
で扱うことになってるから
それはオーバーレイの話ですな
AVIutlのデフォルト表示はGDIですがな

201 :名無しさん@編集中:03/04/23 21:40
>>199
普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね

202 :197:03/04/23 22:20
>200
いや、そういう意味で言ってる訳じゃなくて、動画の格納形式の意味
で言っているんだけど、RGB格納だと0-255でYUVだと16-235で収まって
いないといけないって意味で
YUVで格納するときは16-235で納めるのは前提としてこのスケールで
格納するためには画面表示は0-255にしておかなきゃいけないんじゃ
ないかなってこと。
VFAPIで他のソフトに渡すなら伸長する必要はないんだけど。
保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしまうと思うんですが。
98系と97以前で動作が違うからややこしいね^^;;;
DirectXってYUV-RGBの時VGA側で伸長するのかCODEC側で伸長するの
か定義してないんだよな。
だからこんなややこしいことになるんじゃないかと。

203 :名無しさん@編集中:03/04/23 22:35
>>197
ひょっとするとHuffyuvSを知らないのでは?
Huffyuvの話じゃないよ
つーか
>>1なり>>198なりのリンク先みてる?
>保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしま
いません
逆にAVIutlに伸張させてYUVで保存すると15以下や236以上はクリップされる
実際に伸張させてYUV保存したモノを読み込んでヒストグラムみてごらん
見事にクリップされちゃうから

204 :203:03/04/23 22:37
ぶっちゃけAVIutlのYUV展開・圧縮の動作がおかしいだけなんだけどね

205 :名無しさん@編集中:03/04/23 22:41
一般化して話をするのは難しいよね。
だから単純にYC伸張するのしないのというんではアテにならない。

こういう話をするときは、アプリとCODEC、そのオプションなど前提をハッキリさせておかないとおかしいことになりますね。


206 :名無しさん@編集中:03/04/23 22:46
HuffyuvSソースではないキャプったmpeg2ソースの場合、
m2v.vfp (ストレート)でAviUtlに渡せば 0-15,236-255 の範囲は保持されるの?

207 :203:03/04/23 22:46
あとGDI表示アプリは画面表示にDirectX通さないと思うが?
実際AVIutlもcodecの展開した値(無論ここでDirectShowはよびだされることもある)を内部で自前でRGBにして表示するんだけど
だからYUV展開するときはAVIutlが伸張し
圧縮するときはAVIutl自身が圧縮するわけだ
で、その動作がDirectX上の動作ともBT.601の動作とも違う、と
だからAVIutlで展開、圧縮せずにcodecでやろう、と
そういう話なんだけど?

208 :名無しさん@編集中:03/04/23 22:52
>>206
保持されるけど
保存時にも注意しないとスケールが圧縮されるからね。

209 :名無しさん@編集中:03/04/23 22:53
>>206
ひすとぐらむってしってるかい
じぶんでみればわかるだろ?

210 :名無しさん@編集中:03/04/23 22:55
>>206
される
なぜなら
ソースはYUV(のうちこの場合はYV12)ということは
データ上は(0-255)を持ち、オーバーレイ表示するときは伸張される(のが正しい)データ形式を持つ
そしてm2v.vfp はVFAPIなのでAVIutlからはRGBとしてみえる
しかもストレートを選んでいるのでこのRGB(0-255)はソースのYUV(0-255)を持つ(厳密には”ほぼ”だけどね)
伸張、圧縮をおこなってないので伸張、圧縮によるデータ欠損はない

211 :名無しさん@編集中:03/04/23 22:59
HuffyuvSをAvisynthを通してReadAVS.dllでTMPGEncに読ましたら
伸張されるような気がするんだけど、こういう場合はどうしたらいいの?

212 :206:03/04/23 23:09
>>208>>210
即レスどうも有り難う。

あと一つ疑問(;´Д`)
m2v.aui→AviUtl だとYUV2で渡される?ので伸張されるから
>>196の方法使えば一度も伸張・圧縮されないの?


213 :210:03/04/23 23:23
.aui登録するとAVIutlのcodecの設定のとこにm2vでるの?
出るならそのとおりだが
でなけりゃ・・・
あ!?
出ないときはストレートRGB読み込みだからどっちにしろ伸張されないな

214 :名無しさん@編集中:03/04/23 23:24
>>212
YUVとRGBは表現できる範囲が違うから、相互変換は質を落とすことには変わりがない。
(ストレート変換YUV->RGBの時に大きく質を落とす。BT.601 YUV->RGBの方が質はマシだけど範囲外がカットされる。)

AviUtlは、誰かが言ってたけど YUY2を内部YUV444に変換するとき、16倍拡大とYC伸張を行う。でも有効12bitなので範囲外になることない。
問題なのは、YUY2出力時、YC圧縮と1/16倍に変換するけど、おまけとして16-235(240)にカットされる点。
(このおまけがなければ、AviUtlを通しても全く劣化しないのに。)
(ちなみに、YC拡張->YC圧縮はほぼ劣化しないが、YC圧縮->YC拡張ははっきり劣化する。
 HuffyuvSでストレート変換するというのは、このYC圧縮->YC拡張に相当する作業)

で、m2v.auiでYUY2で渡されるかどうかは自分で確認すること。(「ファイルの情報」で見れる)

215 :210:03/04/23 23:35
>HuffyuvSでストレート変換するというのは、このYC圧縮->YC拡張に相当する作業)
というのがわからんなぁ
>>196でやってるのは
YUV444->RGB24->YUY2であって
YC圧縮->YC拡張に相当しないと思うが?
>ストレート変換YUV->RGBの時に大きく質を落とす
のは同意だが、AVIutlを使いたいとなると・・・
しかもそのあとVirtualDUBやCCEに突っ込むとなると・・・


216 :206:03/04/23 23:48
>>210
コーデックのトコには全く出ませんでした(;´Д`)

ってカキコした後から試してみましたが、
1:キャプソースmpeg2→m2v.vfp(ストレート)→AviUtl
2:キャプソースmpeg2→m2v.aui→AviUtl(PC -> TV スケール補正)
これらはヒストグラム上で全く同じでした。

>>214
こちらもレス有り難うございます。
AviUtlにYUY2で扱うと、
>おまけとして16-235(240)にカットされる
よって劣化が生じると、、、

ちなみにファイル情報では「ビデオ圧縮」「ビデオ展開形式」ともに
YUY2と確認出来ました。

217 :206:03/04/24 00:04
あと、
>YUY2出力時、YC圧縮と1/16倍に変換するけど

ってことは、上記216で(PC -> TV スケール補正)をかけた値が
ヒストグラム上同じでも、AVI出力時にはチェックを外さないと、
2度YC圧縮されているって事なんですね、、、

うーんイマイチ理解出来ない。

218 :名無しさん@編集中:03/04/24 01:17
>>217
AviUtlでは、
  YUY2->(YC拡張)->YUV444->(ストレート)->RGB24
通常(TMPGEnc,VirtualDub)
  YUY2->RGB24(YC拡張)
この両者は、RGb24でみるとほぼ同じに見えるし、RGBヒストグラムも誤差程度の差。

逆も同様
  RGB24->(ストレート)->YUV444->(YC圧縮)->YUY2 : AviUtl
  RGB24->YUY2(YC圧縮)              : VirtualDub,TMPGEnc

つまり、AviUtlでRGBヒストグラムを見てればそれがそのまま出力される(RGB24でもYUY2でも)ということ。

>>215
RGB24をHuffyuvSでConv.YUY2するとYC拡張されたことに相当する。
逆にHuffyuvSでRGB24入力するとYC圧縮されたことに相当する。

あれ、AviUtlの内部形式は、16倍じゃなくて、4倍だったかも。(通常範囲 0〜1023で最大0〜4095?)

219 :名無しさん@編集中:03/04/24 01:35
>>217
AviUtlは使わずに、ずっとYUY2のままで処理すると、フォーマット変換誤差が生じる余地はない。

ストレート YUY2->RGB24変換は、当然BT.601 YUY2->RGB24変換より、取り得る値の範囲が小さい。
どういうことかというと、微妙な階調情報が失われるということ。
これをより多く劣化すると表現した。

具体例をあげると、(わかり易く説明しているだけで実際にこうなるというわけではない)
隣り合うピクセルの値が、110,111,112,111,110,111,112,113,114とあったとする。
BT.601変換だと、これが110,110,112,110,110,110,,112,112,114となるとする
ストレート変換だと、109,111,111,111,109,111,111,114,114とより詳細が潰れるということ。

220 :名無しさん@編集中:03/04/24 01:42
つまり、わかり易く言うと、

HuffyuvSで YUY2->RGB24->YUY2 するのは、
YC圧縮して、0-255の範囲を飛び出さないようにRGBに変換して、YC拡張してYUY2に戻すということ。

221 :名無しさん@編集中:03/04/24 01:45
>>220
追記しておくと、

HuffyuvSで YUY2->RGB24 変換しても、0-255の範囲に納まるというわけではない。
それでも、範囲外の値になってカットされるものも出てくる。
ただし、実際面でいうとカットされるのは、BT.601と比べれば断然少ないので
目に見える影響は小さい(無視できる?といえるか)ということ。

222 :名無しさん@編集中:03/04/24 01:53
おまけ

以上のことは、視点を何処に置くかで表現は変わる。

HuffyuvSが、そのまま変換で、BT.601が拡張・圧縮すると言い換えることもできる。
(世の中の常識、世界的にみても、BT.601の方がノーマル変換という見方だけど)

言い方を変えたとしても、HuffyuvSの方が変換誤差が大きく出ることに違いはない。

223 :名無しさん@編集中:03/04/24 02:06
ここまで言っててなんだけど、HuffyuvSを使う方が普通の人には悪影響が少ないだろう。


【推奨】
●YUY2のまま処理する。
 (ただしNR等はフォーマットの弱点が出てYUV444,RGB24で処理するよりは劣化度は大きい。
  でも最終的にMPEG圧縮するならあまり気にしないで良い程度)

どうしても、RGB変換が必要な場合
●色バランスが崩れていて、キャプチャの入力レベルが大きく、BT.601変換すると
 範囲オーバーする場合は、HuffyuvSを使う
●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。
●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して、
 色補正等でバランス、レベルを整えてからYUY2で出力する方がベター

224 :名無しさん@編集中:03/04/24 03:04
すばらしい

225 :名無しさん@編集中:03/04/24 03:51
ちょっと訂正
>【推奨】
>●YUY2のまま処理する。
> (ただしNR等はフォーマットの弱点が出てYUV444,RGB24で処理するよりは劣化度は大きい。
>  でも最終的にMPEG圧縮するならあまり気にしないで良い程度)

>どうしても、RGB変換が必要な場合
>●色バランスが崩れていて、キャプチャの入力レベルが大きく、BT.601変換すると
> 範囲オーバーする場合は、HuffyuvSを使う
>●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。
>●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して、
> 色補正等でバランス、レベルを整えてからYUY2で出力する方がベター

これは正常な映像を作る(または人に貸与するとか)場合であり、
TV出力して見る人とかでは、また違った観点があり若干範囲オーバー気味の方が良い。
もっとも、PCでみる場合でも多少オーバー気味に上下が切れたとしても、その方が見た目には綺麗。

●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して、
 色補正等でバランス、レベルを整えて、若干上下がオーバーするように作成する。
 その後、YC縮小にチェックして、HuffyuvSでRGB24で(Conv.YUY2しても良い)出力するのがベスト。

補足:HuffyuvSは、RGB24->YUY2時、色差を左ピクセル値で変換する。
   これは、単純にYUY2->RGB24,RGB24->YUY2の相互変換するには誤差が少ない手法。
   但し、AviUtlでNRとか掛けると話は違ってきて左右のピクセル値をブレンドした方が良くなる。

226 :225:03/04/24 04:17
【AviUtlへの要望】
BT.601も、16-235(240)が絶対じゃなくて、推奨であり 1〜254までなら
存在しても良いことになってるんだから、

AviUtlも、サチュレートするかどうかチェックボタンを追加してくれないかな。
DivXもXviDも別にサチュレートしないわけだし。

227 :名無しさん@編集中:03/04/24 10:40
>○も
あなたが来ると盛りあがります

228 :名無しさん@編集中:03/04/24 11:19
1. PIC(4/2/2)でキャプ
2. AviUtl(YUY2で展開するチェック無し)で読みこみ
  YC伸張してHuffyuvで出力
3. VDubでFast recompressエンコ

としているのですが、この場合2のところを

2. AviUtl(YUY2で展開するチェック無し)で読みこみYC伸張せず
  YUY2で圧縮するチェック無しでHuffyuvS(Convert to YUY2)で出力

とした方がよいのでしょうか?

229 :名無しさん@編集中:03/04/24 11:20
ストレート変換時にYC圧縮→拡大されてるってのが
イマイチ信じられん。ソースを提示してほしい。

>●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して
このYUY2のコーデックは何?Huffyuv?
ひょっとして色空間とCodecを混同してないか?

230 :名無しさん@編集中:03/04/24 11:31
>>229
YUY2で入力するとき、CODECなんか関係あるのか?
Huffyuv = HuffyuvS (YUY2->YUY2の場合)
それとも、YUY2->YUY2時に色変換するバカなCODECが存在するとでも。

もっとちゃんと読んだら。
BT.601と比較したら、ストレート変換は圧縮・拡張するように見えるって書かれているじゃん。
見方を変えたら、BT.601の方が拡張・圧縮すると言い換えることもできると。

231 :230:03/04/24 11:37
>>229
まあ、その文は確かにおかしいね。
でも元の訂正前の文をコピーペーストして削除し忘れただけじゃないかな。
その文節自体意味がないもの。

232 :名無しさん@編集中:03/04/24 11:46
>>231
別におかしくないよ。

>どうしても、RGB変換が必要な場合
>HuffyuvSを使うよりは、
って意味は、「HuffyuvSでRGB24入力するよりは、」ってことだろ。

233 :名無しさん@編集中:03/04/24 11:57
>YUY2で入力するとき、CODECなんか関係あるのか?

ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html
↑の表だとHuffyuv(YUY2)とHuffyuvS(YUY2)の
Aviutilでの読み込み&出力動作が全然違うじゃん。
入力ソースのCodecはきちんと記載しておくべきだと思う。

>BT.601と比較したら、ストレート変換は圧縮・拡張するように見える

ひょっとしてYUY2→RGB(ストレート変換)すると
BT.601準拠変換した場合よりもPCモニタ上で
コントラストが低く表示されることが根拠?

もしそうなら通常ストレート変換ではYUY2(16-235)が
そのままRGB(16-235)になるからPCモニタ上では
コントラストが低く見えるのはあたりまえでしょ。
YC圧縮されて階調がつぶれてしまうことにはならないと思うんだけど・・・

まぁ仰るとおりYUY2⇔RGB変換する時点で
劣化は避けられないのには同意だけど。

234 :名無しさん@編集中:03/04/24 12:25
なんかストレート変換って言葉に騙されてないか?
YUV->RGB変換するのに、情報を落とさずに変換するためには
RGBは、-100〜+400程度はないとダメなんだぞ。

結局、YUV<->RGBは、見方によって片方が拡張->圧縮する、もう片方が圧縮->拡張する
としか言えないのでは。

235 :名無しさん@編集中:03/04/24 12:30
>>233
ごめん、多分オレの目が節穴なんだろうけど「huffyuv(YUY2) の aviutl (YUY2 チェック)」 と
「huffyuv2 (YUY2) の aviutl (YUY2 チェック) 」の違いが何処にあるのか見つけられないんだ。

違いが何処にあるのか教えてくれないか?

236 :名無しさん@編集中:03/04/24 12:38
>>233,>>235
「huffyuv(YUY2) の aviutl (YUY2 チェック)」 に注意書きで、
一旦RGBにしているようで精度が悪いとある。
でも、普通考えてそんな処理しているはずが無いではないか。
AviUtlがRGBとしてHuffyuvから貰っていたら入力は「YUY2」とはならないし、
Huffyuvの中で一旦RGBに変換するはずはない。そのことはHuffyuvを元にHuffyuvS
を作った本人が一番良くしってるだろう。

別の疑問として、
「huffyuvS(YUY2) の Avisynth」が伸張で、
「huffyuv(YUY2) の Avisynth」がYUY2
というのはどういう意味?

237 :名無しさん@編集中:03/04/24 12:42
>>233
Yは置いとくとして、通常映像でUVの取り得る範囲は意外な程小さい。
俺の経験から、-50〜+50も振れれば上出来。
(カラーバーのようなフルレンジをとるものもあるけど)
これを、より変換レンジの小さいストレート変換で変換すると、
情報が潰れちゃいそうな気がしない??

238 :名無しさん@編集中:03/04/24 12:55
>>233
頭かたいなあ

HuffyuvSがストレートで伸張も圧縮もしない、という視点しか持ってないんだろうな。

視点の中心をBT.601に置き変えてみるということが出来ないもんかねえ。
(BT.601の変換方法が、「ストレート」だとしてみるってことだよ。
 何のためにBT.601がYUV->RGBのそういう変換式を採用したのかってことを考えてごらんよ。)

239 :名無しさん@編集中:03/04/24 12:56
>>234
> YUV->RGB変換するのに、情報を落とさずに変換するためには
> RGBは、-100〜+400程度はないとダメなんだぞ。

その通りなんだけど、自然光から直接 YUV データは作れないんだ。

一度、RGB で(フィルタ・プリズム等で)分光したのを 0〜255 に
量子化(8bit CCD/CMOS センサの場合)し、そこから YUV データを
作るので、問題は発生しない。

RGB -> YUV (RGB よりも範囲が広い) -> RGB

としてる限りは、レンジオーバーはまず発生しないから。

あと、素の YUV を表示できるデバイスというのは存在しないので
実際の表示の際は必ず RGB に変換されてからになる。

その変換を CODEC が行うか、VGA が HW で行うか、あるいは TV が
中で行うかの違いしかない。

YC 伸張とは関係ない話ですまない。

240 :名無しさん@編集中:03/04/24 13:02
それより8チャンネルの高すぎる輝度をどうにかしてくれ

241 :名無しさん@編集中:03/04/24 13:07
>>240
メーカーサービス呼んでチューナ調整してもらえ

「8ch だけ受信感度が異常に高いので、調整してもらえないでしょうか」

と低姿勢で頼めば、ユーザサポートを重視する企業ならやってくれるだろう。

242 :名無しさん@編集中:03/04/24 13:08
>>199が結論ということで

〜〜〜〜〜〜終了〜〜〜〜〜〜

243 :名無しさん@編集中:03/04/24 13:10
>>239
きみは、キャプチャってもんを知らん。
カラーバランスや色レベルはキャプチャ時に大きく影響される。

アナログキャプチャは、作成元のコンポーネント信号とは違うって
前提があるだろが。

244 :名無しさん@編集中:03/04/24 13:13
>>243
キャプチャカードの調整も出来てない状態で YC 伸張云々してても仕方ないじゃん。
そこをクリアして、それ以降の話をするスレッドじゃないの?

245 :名無しさん@編集中:03/04/24 13:15
>>242
そうそう。

放送信号自体に100%以上が許されているっていうのを、
235以上も必要な情報があたかもあるかのように言っているけど、
作成元のコンポーネントマスターには、BT.601の範囲外は無いと思うぞ。

246 :名無しさん@編集中:03/04/24 13:17
>>244
キャプチャ時に適正に入力できてれば、
HuffyuvでBT.601を使った方がベターだろうが。
何を言っているんだ。

247 :名無しさん@編集中:03/04/24 13:19
HuffyuvS使って対して重要じゃない部分を残そうとやっきになってるヤシは負け組

248 :名無しさん@編集中:03/04/24 13:21
>>245
それが Y=235〜240 程度ならば普通にコンポーネントマスターにも使われてる
情報だったりするのよ。
# カメラ撮影限定の話で、フルデジタルアニメの場合は別

249 :名無しさん@編集中:03/04/24 13:25
俺なんか、
BT.601で変換しても範囲オーバーになる情報は、元々要らない情報だよ。
BT.601で変換したものっていうのは、元々、直にRGB24でキャプチャしたのと同様ってことだぜ。

色補正で、有効な情報だって多少はオーバーさせてカットしてるってのに。
>>199が言ってるように、リンギングやシュートした部分なんて不要だぜ)

250 :名無しさん@編集中:03/04/24 13:26
>>246
判りやすくかけなくて申し訳ない。

RGB で -100 だの 400 だのになるような YUV データは、よっぽど腐った設定の
キャプチャ環境でないかぎりありえない。

# なので、そんなもんを考慮すんのは無駄だ。

239 では 234 個人にそう伝えたかっただけなんだ

251 :名無しさん@編集中:03/04/24 13:27
>>248
そんな御託は、デジタルキャプチャできるようになってから言ってくれ!!!

252 :名無しさん@編集中:03/04/24 13:30
>>250
>>234はそんなことを問題にしてないだろが。
頭の固い野郎がいて、そいつが、YUV->RGBストレート変換は、伸張も圧縮もしてない
って思っていることに対する反論のために言っただけじゃん。

253 :名無しさん@編集中:03/04/24 13:32
>243
おいおい、キャプチャ時に16-235に収まるように調整してないのかYO!
まず調整すれ、話はそれからだ。
それでも飛び出た信号が時たま来るけどそれぞれに余裕あるからオーバ
ーするこたない。

254 :名無しさん@編集中:03/04/24 13:37
>>253
おいおい、色バランスってことを知らんのか。
16-235に納まってても、RGB変換時にオーバーするってのはそれじゃん。

だって、元々RGBをYUVにして送出してるってことは、
色バランスが送出元と同じだったら、変換してオーバーになることは無いってことなんだから。

お前だって、言っただろ。
>RGB -> YUV (RGB よりも範囲が広い) -> RGB
>としてる限りは、レンジオーバーはまず発生しないから
ここで、まず、なんて言わずに絶対って言ったって良かったぞ。

255 :名無しさん@編集中:03/04/24 13:49
>>253
お前は、その時たま飛び出た信号が必要なのか? 本当に?

256 :名無しさん@編集中:03/04/24 13:58
そりゃコンポーネントマスターと同じ色範囲と輝度範囲なら
>RGB -> YUV (RGB よりも範囲が広い) -> RGB
>としてる限りは、レンジオーバーはまず発生しないから
これは成り立つけど、キャプチャ時に狂っていたら意味無い
じゃん。
カラーバーで調整してそれでも飛び出る信号は無視してもいい
って話なんだが。
調整しても0以下の信号や255を越える信号が入って来てもそれ
はいらない信号だと思うが

>お前は、その時たま飛び出た信号が必要なのか? 本当に?
調整してても飛び出すなら、多分いらない信号だと判断してますが

257 :名無しさん@編集中:03/04/24 14:00
>RGB -> YUV (RGB よりも範囲が広い) -> RGB
>としてる限りは、レンジオーバーはまず(絶対)発生しないから。

これは言えるけど。誤解を生みやすいぞ
BT.601変換で見える範囲に限れば、YUVがRGBより必ず範囲が広いわけじゃない。
RGB->YUV変換でも、範囲を超えてオーバーすることはある。

まあ、問題にしているストレート変換の場合だと、
YUVがRGBより必ず広いって言えるけど、ここでいっているのは放送現場だからBT.601の事だよな。

258 :名無しさん@編集中:03/04/24 14:35
>>お前は、その時たま飛び出た信号が必要なのか? 本当に?
>調整してても飛び出すなら、多分いらない信号だと判断してますが

なんだ。
結局喧嘩してるように見えただけか。
お前だって、BT.601で変換して十分だって意見なのか。
最初は、16-235を超えるデータも必要だから(100%以上の信号もコンポーネントマスタにも存在するから)
って言ってたから、ストレート変換じゃないと許せないって言ってるもんだと思ったよ。

259 :名無しさん@編集中:03/04/24 14:40
●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。

結論は、これに相当するわけだね

260 :名無しさん@編集中:03/04/24 15:51
結局huffyuv(YUY2)でBT.601準拠キャプした場合
Aviutilに読ませるときはYUY2チェックするの?しないの?

261 :名無しさん@編集中:03/04/24 17:11
>>260
自分で決められなきゃどっちでも同じ。
決められるだけの材料は出尽くしているだろが。

262 :名無しさん@編集中:03/04/24 20:10
ttp://www.marumo.ne.jp/bt601/
↑より抜粋

<ストレート変換の場合>

○利点
・ITU-R BT.601 の輝度スケール 16 〜 235 を超えた信号も作れる
・YUV→RGB→YUV→RGB と変換を繰り返した場合の画質の変化が
 最小限に抑えられる
○欠点
・PC のディスプレイ上での画質調整が困難になる


<YC 伸張・圧縮する場合>

○利点
・TV に出力されるイメージに近い画質が、PC ディスプレイの段階で手に入る
○欠点
・規格外のデータを入れられなくなる
・YUV <-> RGB 変換時のロスが大きくなる

263 :名無しさん@編集中:03/04/24 22:54
DVキャプのときもYC伸張はいりませんか?
補間だけでいいのですかね?

264 :名無しさん@編集中:03/04/24 23:16
>>263
DVはYUV
あとはスレ見て考えろ

265 :名無しさん@編集中:03/04/25 00:00
ffdshowってYC伸張してるの?

266 :名無しさん@編集中:03/04/25 07:43
>>265
選択可能

267 :名無しさん@編集中:03/04/25 12:35
>>266
えっ、そんな項目ないような…
輝度とかイジれってこと?

268 :名無しさん@編集中:03/04/25 19:20
ふと思ったんだが
VirtualDubとAVIsynthの環境でLoadAviUtlFilterPlugin(aufilters.avs)使えば
AVIutlのフィルタ使用でサチュレーションも中途RGB化もないHuffyuv出力ができるんでなかろうか?

269 :名無しさん@編集中:03/04/25 22:26
>>268
手順は?

270 :267:03/04/25 22:32
>>268
ConvertYUY2ToAviUtlYC()
RGB化しないAVIutlのプラグイン
ConvertAviUtlYCToYUY2()
でDubはFastComp.

271 :267:03/04/25 22:37
ひょっとして・・・
AVIutlのコマンドライン入出力ってRGB?
それとも選択制?
選択制にしてもaufilters.avs使用時に
どうやってYUY2展開になるんだろ?
aufilters.avsがAVIutlコマンドラインをYUY2展開で開かないと意味ないんだが

272 :名無しさん@編集中:03/04/25 22:57
半角カナだと読みにくい

273 :265:03/04/26 11:58
う〜んffdshowの設定に伸張に関する項目が見当たらない。
ゲフォ房なんでもうこれっきゃないな〜と思ったんだけど・・・

274 :名無しさん@編集中:03/04/26 12:46
>>273
Levelsにチェック -> Input(16-235) , Output(0-255) に設定

275 :名無しさん@編集中:03/04/26 13:24
>>273
それ、あったら最強ッス (´・ω・`)

エンコ時に伸張いらんし
ファイルサイズがめちゃ縮むのに…


276 :274:03/04/26 13:40
>>275
シカトかよゴルア!!

277 :275:03/04/26 13:57
>>276
スマソ
投稿してから274読んだ

278 :名無しさん@編集中:03/04/26 14:48
ワラタ

279 :265:03/04/26 14:58
>>274
サンクス!!
こりゃ〜使えるよ

280 :名無しさん@編集中:03/04/26 15:44
ここまで読んだけど、高度すぎてほとんど理解できませんでした。


MTV2000でMPEG2でキャプチャ

AVIutlで読み込み(MPEG-2 VIDEO VFAPI Plug-In 使用)(ストレート変換)

DivXに出力

としてるのですが、AVIutlの出力でYC伸張が必要でしょうか?
DivXのコーデックが伸張すると聞いて、今は伸張していないのですが……。

それと微妙な諧調が失われてしまっているのか心配です。
よろしくお願いします。

281 :名無しさん@編集中:03/04/26 20:33
>>280
DivXごときにエンコードするのに
”微妙な諧調が失われてしまっているのか心配”する
おまいのことが心配だよ・・・

282 :名無しさん@編集中:03/04/26 20:37
>>280
もし、書かれているようにAviUtlで色補正せずエンコだけやってるなら、
最初にm2v.vfpではストレート変換は止めたほうがいいでしょう。
(AviUtlでYC伸張してもいいけど、m2v.vfpで伸張したほうが手間いらず)
今のストレート変換、YC伸張なしだと、結局YC圧縮したままなので暗く淡くなってるでしょう。

283 :名無しさん@編集中:03/04/26 21:09
>>280
そりゃ釣られてるわ
DivXでは伸張されへんよ

284 :名無しさん@編集中:03/04/26 21:10
>>282
つーかもしYC伸張してなければ、気づくと思うのだが
ビデオカードが伸張しちゃってるんで気づかないってやつ??

285 :名無しさん@編集中:03/04/26 21:51
>>284
おまい、バカ?
伸張するビデオカードでもそういう風に見えるので普通は気づく。
いわんや伸張しないビデオカードの場合は...

286 :名無しさん@編集中:03/04/26 21:56
>>284
YC伸張するビデオカードでも
280の操作だと一段YC圧縮されて見えるのには変わりない。

287 :名無しさん@編集中:03/04/26 22:03
ゲフォだと2段圧縮か...見られたもんじゃないな。

288 :名無しさん@編集中:03/04/26 22:04
>>286
うちだと伸張するビデオカードですが、AVIutlで伸張してDivXに出力、
再生時はビデオカードでさらに伸張で良いのですか?

289 :名無しさん@編集中:03/04/26 22:10
>>288
お前は、>>282の言うとおりにしとけ。
このスレに来る意味なし。

>DivXに出力、
ここでDivXがBT.601に従ってYC圧縮するのを忘れてない?

ここで議論してるのは、編集途中で伸張するかしないかであって、
最終エンコを伸張するしないじゃない。

290 :名無しさん@編集中:03/04/26 22:24
伸張したのと、しないのと、圧縮したのと、しないのと、
見分けがつかないはずが無いんだがなぁ。
何で質問してくるんだろうか?わからん?

291 :名無しさん@編集中:03/04/26 22:25
誰か分かってる奴これまでのまとめ書けよ。
>>286みたいなのはいつまでも理解できずに現れるよって...

292 :名無しさん@編集中:03/04/26 22:29
>>291
リンク先ミス??
もし間違いじゃなければ、分かってない君はキミの方だよ。

293 :名無しさん@編集中:03/04/26 22:36
訂正>>288...

294 :名無しさん@編集中:03/04/26 22:40
ここまで読みましたが、低知能には話が高度すぎて難儀であります
mpeg2 -> DVD2AVI(VFAPI) -> Aviutl(YC伸張) -> LCL(RGB) -> WMV9
でエンコしてるんですけど、自分のPCで見るにはいい感じなのですが、
人様のPCで見ると化けるのでしょうか
ちなみにラデ8500.

295 :名無しさん@編集中:03/04/26 22:49
>>294
もう一度読み返せ。分かるまで何度でも読み返せ。
試験勉強を思い返せ。
ヒントをやろう。ラデ8500は「ATI」だ。

296 :名無しさん@編集中:03/04/26 23:00
>>294
同一環境(例えばラデ)でソースとエンコード後の再生画面を見比べて
同じになってればスケール変換に誤りはないということ。

その同じデータを違う環境(ラデとゲフォ)で再生比較したときに色が違って見えるかどうかはまた別の話です。


297 :名無しさん@編集中:03/04/26 23:03
>>291
まとめが>>1のリンク先だと思うんだが

298 :名無しさん@編集中:03/04/26 23:04
mpeg2 → d2v(TV scale) → avs → AviUtl → DivX を
DVDMaxでテレビ出力する場合、YC伸張は必要?


299 :名無しさん@編集中:03/04/26 23:07
>>294
本当に分かってないね。
その手順には、ある重要な情報が提示されてない。
読んだ人にとっては正しいことにも間違っていることにもどっちにでも受け取れる。
結果として、>>296の言うように自分の目でみて正しかったか間違ってたか判断してくれ。

300 :名無しさん@編集中:03/04/26 23:09
>avs → AviUtl → DivX
このへんでナニしてんだか全然わからんし
そもそもDVDMaxは(ry

301 :名無しさん@編集中:03/04/26 23:12
さて、今日はERなワケだが(´ー`)

302 :名無しさん@編集中:03/04/26 23:12
>>297
一見公平そうだけど、あるベクトルを感じるリストではあるな。

303 :268:03/04/26 23:43
http://niiyan.s8.xrea.com/avisynth/color_test.html
なんでHuffyuvじゃダメなんだろ???

304 :名無しさん@編集中:03/04/26 23:58
にーやんに聞いてみな。

305 :268:03/04/27 00:26
>>304
メール発射してみました

306 :名無しさん@編集中:03/04/27 01:36
誰?

307 :名無しさん@編集中:03/04/27 05:43
readavs.dll通す時点でだめだめ

308 :名無しさん@編集中:03/04/27 05:54
つかフツーavsinp.auiを使うだろ

309 :名無しさん@編集中:03/04/27 05:56
avsinp.aui通すと伸張されるん?

310 :名無しさん@編集中:03/04/27 07:42
慎重に扱えよ

311 :名無しさん@編集中:03/04/27 09:37
YUY2で入力できるわけ

312 :大田遺産:03/04/27 11:12
>>280さんへ 282さんもおっしゃるとおり
以前にその方法でやってたけどまるもさんのMPEG-2 VIDEO VFAPI Plug-In
で伸張をかけないとソースMPEG2(MTV2000)とエンコ後DivX(Ver5.02)で色調
や輝度が少し落ちた(薄い・淡い)感じだったので伸張したほうがいいと
思う。何通りか作ってみてCRTでオーバーレイ2つ立ち上げて(MediaPlayer
あたりで)ソースとエンコ後を比較するとわかると思います。

>>それと微妙な諧調が失われてしまっているのか心配です
その件はDivXにした時点であきらめましょう(暗部でのブロックノイズ化・
モスキートノイズの嵐)。WMV9でも同様だが、あまり目立たないので良い
と思う。

>>298 DVDMaxでテレビ出力する場合、YC伸張は必要?
DVDMAXで比較しないほうがいいかと(デフォルトでかなり輝度高し)
CRTオーバーレイ比較がいいと思います。それとavsの事はよくわかり
ませんがDVD2AVIかAviUtlのどちらかで伸張をかけたほうが(AviUtl
のほうが元ソースに近い感じとの報告あり(DVD2AVIスレにて・俺には
よくわからんかった))良いと思う。


313 :名無しさん@編集中:03/04/27 11:36
ええと・・・
なんて言えばいいのかな・・・
うんとね。
伸長しても元のスケールが正しいなら問題ないんだ、0-255になるだけだから。
最近はYUY2だと伸長するボードが出てきてるから、再生するときに伸長したデ
ーターだと2重に伸長してしまうから問題になってる訳で。
勿論データーレベルでは正しく伸長されていれば損なわれることはないんだけ
ど。
だから、伸長しないボードの場合にはプレイヤーで伸長して伸長するボードの
場合にはボードに任せると、でデーター自体は伸長しないほうが良いんじゃな
いかなぁ。ってなってる話なんですよ。
AVUTLが正しく伸長圧縮をしてくれるならYUY2読み込み→伸長 YUY2書き出
し→圧縮で全く問題ないんだけど。どうも伸長はともかく圧縮がおかしいと・・
だったら最初から伸長圧縮しないでなんとかしましょうってのが趣旨なんだけ
ど・・・・
ってこの話の流れで合ってます?>ALL

314 :名無しさん@編集中:03/04/27 12:18
>>313
大体あってる
とりあえず>>196のやり方で伸張圧縮なしエンコできるんだが
このやり方だとYUV>ストレートでRGB>YUV変換がはいってるんじゃないのか?
それはYUV>BT601準拠RGB>YUV変換より変換誤差がでかいんじゃないか?
じゃぁどーすんだよ、ボケが!!
という流れ

315 :名無しさん@編集中:03/04/27 12:21
PICMJPEGキャプではどうすりゃいいの

316 :294:03/04/27 14:43
YUV形式をPCのディスプレイに表示するには、RGB形式に変換する必要がある
でも、そうすると元の色と変わってしまうので、元の色を再現する為にYC伸張をする(?)
そうするとPCのディスプレイでYUVの色味が再現できる
でいいのかな。

となると >>294
VFAPIを使用するとRGB形式に変換してしまうので、元の色を再現する為にYC伸張する
そうするとPCのディスプレイに表示するときに元の色が再現できる(?)
と言っていいのかな

>>151さんの発言からすると、私の作ったファイルは
mpeg2 -> DVD2AVI(VFAPI) -> Aviutl(YC伸張) -> LCL(RGB) -> WMV9
YUV -> RGB -> RGB(YUVにみえるRGB) -> RGB -> YUV
となって、ATIなので作成したWMV9を再生するとYC伸張されて表示される
ということなのか?
ちなみにDVD2AVIはテレビ色調です

ん。
>>299さんの言っている「ある重要な情報」って言うのはDVD2AVIの色調のことなのかな
だとしたらすみません分かってませんでした

317 :名無しさん@編集中:03/04/27 15:23
伸張を+1、圧縮を−1として完成ファイルが0になってればいい
って感じに置き換えて考えてますが正しいでしょうか?

318 :名無しさん@編集中:03/04/27 16:31
>>317
そんなかんじ。
ファイル自体のデータの話と自分の環境での見え方の話を分けて考えないから
ごちゃごちゃするんだよ。
用は>>317の言うように完成ファイルが0(TV出力時が0、PC出力で+1)に作るだけ
ここでビデオカードの仕様でPC出力=0だからってYC伸張で補完するのはダメ
あとは個別のコーデックと加工ソフトの入力、出力の+、−を知ればいいだけ

319 :名無しさん@編集中:03/04/27 19:53
>317
キャプチャ時に 0 になっていることが大前提ね

320 :268:03/04/27 21:17
にーやん氏から返事がきました
メールの内容貼るのはアレなんでアドバイスを元に実験しました
まずはYUV(254.1.158)のカラークリップをDV-Stormにて作成
これをソースに
1.AVIutlにてYC展開・圧縮を一切せずにHuffyuvS(conv.YUY2)出力(>>196に倣った
方法)
>>YUV(229.15.147)←YC<>RGB変換誤差発生
2.AVIutlにてYC展開・圧縮してHuffyuv(YUY2)出力(>>214-の○もっぽい方の方法の
ひとつ)
>>YUV(235.16.158)←サチュレート発生
3.AVIsynthにてConvertYUY2ToAviUtlYC(),ConvertAviUtlYCToYUY2()使用で
HuffyuvS(YUY2)出力(にーやん氏の方法)
>>YUV(254.1.158)←ソース同等
4.AVIsynthにてConvertYUY2ToAviUtlYC(),ConvertAviUtlYCToYUY2()使用で
Huffyuv(YUY2)出力(>>268に書いた思いつき)
>>YUV(254.1.158)←ソース同等

つーことですな
でもこんなことはプロの方はわかりきってるでしょうし
趣味でやるときはそれ以前に大事なことがあるんだけどね
どーしてもこだわりたい人向けです
ぶっちゃけ
http://pc.2ch.net/test/read.cgi/avi/1048392387/834


321 :268:03/04/27 21:26
変なとこで改行してスマソ

322 :名無しさん@編集中:03/04/27 21:45
>>320
そんな大幅な範囲外の値じゃ実質、意味が無いと思う。
誰かが言ってたけど、ストレート変換でも、-100〜400程度の値をとる。
変換誤差はこれが0〜255にサチュレートされたものを再YUV変換するので発生。

もっと、ボーダーラインの近傍でテストしてみれば、
どれだけ問題があるのかないのかが判ると思う。

もちろん、3,4の方法は値を保持するけどそれが果たしてよい結果を生むのか疑問。
むしろ、1の結果の誤差変換の方が結果的に良いと言えるかも知れない。

323 :268:03/04/27 21:48
あと書き忘れたけど
YUV(254.1.158)なんてキャプデータは普通ないから
初心者は慌ててAvisynth勉強し始めたりしないように

324 :268:03/04/27 22:00
>>322
CCEやDUB系なんかのYUV入力・YUVネイティブ環境なら3.4.のがいいんでない?
RGB入力・RGBネイティブだとHuffyuv(S)とフロントエンドのどっちが伸張処理は優秀かって話にはなるけど
ぶっちゃけ1.3.4.はどれでもいいと思ってるけどな
2.に関してはやはり奨められない
RGBストレート変換時の0-15,235-255はいらないデータだと語るものも多いようだけど
家電のチューナーが軒並みRGBストレート変換時の0-15,235-255をチューニングやデジタイザで生み出し
家庭用テレビがそれを平気で映し
しかも市販DVDビデオすらサチュレートされてない実勢で
BT.601が絶対というのは甚だ疑問
こういうこと書くとまたアレだが
PC再生のみならサチュレートしてもいいけどね

325 :名無しさん@編集中:03/04/27 22:04
初心者はハイブリットレコ買った方がいいみたいですね

326 :名無しさん@編集中:03/04/27 22:06
大抵の市販DVDは、範囲外の値を含んでいるといっても、別にそんなに問題じゃない。
YUVで、1-15,235-254を含んでいても、RGBに変換(BT.601で)したら0-255に納まる
か又は0.xx%というような極僅かのピクセルが僅かに範囲外になるか程度。

327 :名無しさん@編集中:03/04/27 22:54
>>312
>何通りか作ってみてCRTでオーバーレイ2つ立ち上げて(MediaPlayer
>あたりで)ソースとエンコ後を比較するとわかると思います。

DirectX9とVMR9を使う環境だと
複数のオーバーレイがサポートされてるから単純に比較できなかったり。
とくにWMP9あたりでやると。
なんて書くとまた混乱させちゃうかなあ…

328 :名無しさん@編集中:03/04/27 23:05
・・・・つーか白より白い白や黒より黒い色のデーターって必要なの?
サチュレートされても別に良いと思うけどなぁ。
そりゃYC展開圧縮の計算式が間違っていたりしたら困るけどさ。
ちゃんと調整してもはみ出すデーターなんていらないYO!
4:3映像で705以上のピクセルのデーターを残すか残さないかの議論に
似てないか?この問題

329 :名無しさん@編集中:03/04/27 23:09
でもテレビを完全にキャリブレートすることなんて実質ムリ
テレビ視聴とキャプの入力チューナーを同一にしてる環境なら
やっぱサチュレートするのはイヤだよ

330 :大田遺産:03/04/27 23:42
>>327
>>何通りか作ってみてCRTでオーバーレイ2つ立ち上げて(MediaPlayer
>>あたりで)ソースとエンコ後を比較するとわかると思います。

簡潔に言い過ぎた、失礼。
俺の場合は、元ソース(MPEG2・MTV2000)はMediaPlayer6.4(デコーダー
はinterVideoになってる)でエンコ後WMV9はカノプVG1000用の付属ソフト
VideoGatePlayer(デコーダーはWMVideoDecoderDMOと書いてあった)を
同時に立ち上げてCRT比較している。たぶん問題ないと思う(どっちも
シンプルだし)。

331 :名無しさん@編集中:03/04/28 06:00
オーバーレイ表示と比べるなんて間違いのもと。
同じ編集ツールでGDI表示同士でソースとエンコ結果を比べるほうが確実。
これだと、RGBになるけどピクセル単位でRGBの各数値で比較可能になるから。
(虫眼鏡ツールでRGBを確認できる)

332 :名無しさん@編集中:03/04/28 07:29
まるもさんの日記読みました。
正直感心しています。
人間的に成熟している部分に目を見晴らせさせました。
私は小心者のくせに我を張るタイプなので、正直とてもかないません。
(小心者なので、これも自分のwebページではなく、ここに書いてます)
まるもさんとは、他スレでもどうやら色々と何度もぶつかっているようです。
(ドット妨害、GPL事件等、私の書き込みへのレスが今回以外にも何度か日記に登場してます。
 私は深夜にナチュラルハイになりすぎます。後で反省しきりです。)

私はAvisynth中心なので、正直AviUtlは縁がありません。
YUY2出力のサチュレートも先人の発表の受け売りです。(事実確認はしましたけど)
まるもさん(の成果物、とくに日記)には今までかなりお世話になっています。
これからも精力的に魅力的な活動を期待しています。

以上
Best Regards.

333 :大田遺産:03/04/28 10:16
>>331
それがいちばんいいけど、aviutlでwmv9が出力出来かったんでやむをえず・・・・


334 :名無しさん@編集中:03/04/28 10:51
>○も氏
192と235の間にもあなたの書きこみは相当あるんじゃないの?

335 :名無しさん@編集中:03/04/28 11:17
そんなことはどうでもいいよ。

336 :名無しさん@編集中:03/04/28 15:52
大事なのは誰が言ったかじゃなくて何を言ったかだろ

337 :名無しさん@編集中:03/04/28 21:03
しかしホントなんで「まるもさん」なんだろ?
茂木さんでしょうに
それは置いとくとしてAVIutlが茂木氏やこのスレの何人かが言うように
圧縮時にサチュレートしない(飽和処理しない)ようになったら
HuffyuvSって何に使えるんだ?

338 :名無しさん@編集中:03/04/28 21:04
やっぱりHuffyuvSは無意味だったってことか・・・

339 :名無しさん@編集中:03/04/28 21:41
>>337-338
AviUtlがサチュレートするからその対策としてHuffyuvSが出てきたんだろ。
未来の人間にとっては必要なくなるかもしれないが、今の人間は必要とされてるならそれでいいんだよ。

天然痘ウイルスが絶滅したらワクチンってなんに使うんだ?と言ってるようなもんだ。

340 :名無しさん@編集中:03/04/28 21:55
(・∀・)ナルホド!

341 :名無しさん@編集中:03/04/28 22:09
Vmaker氏が現れやすそうな雰囲気になったんでちと書くが
>AviSynth で YUY2のみ処理を行うと、
>YUY2 <-> RGB の変換誤差から開放される…筈だったんだけど、
> 調べた結果は、一度 RGB にストレート変換を行い、
>その結果を huffyuvs の Convert YUY2 で変換 しないことには、元データを保持することができない
とかいうことが
ttp://vmaker.tripod.co.jp/other/graphedit.html
にあるんだが、これってにーやん氏や>>320の結果と異なるんでは?

342 :名無しさん@編集中:03/04/28 22:54
何とかHuffyuvSを使ってもらおうと、あの手この手で勧誘しているんじゃないの?

343 :名無しさん@編集中:03/04/28 23:04
>>338
主なターゲットはAviUtlじゃなくてCCEだと思うが。

344 :名無しさん@編集中:03/04/28 23:10
>>343
ありえない
それならHuffyuvで充分だし
そもそも初期HuffyuvSにはCCEパッチ版が存在しなかった

345 :名無しさん@編集中:03/04/28 23:47
>>341
http://pc.2ch.net/test/read.cgi/avi/1042666068/523

346 :341:03/04/28 23:51
>>345
utlがそうなるのはわかるが
synthのことを訊いているのだが?

347 :名無しさん@編集中:03/04/29 00:01
>>346
http://vmaker.tripod.co.jp/other/graphedit.html
でも、↑ってAvisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)の話じゃないの?
AviUtlの部分は想像だけど。

ちなみに、vmakerさんはVirtualDubModに乗り換えたって話を読んだ気がする。

348 : ◆S/VMAKER3c :03/04/29 00:04
huffyuvSは、当初 ConvertYUY の為だけに存在してたんだったりします。
つまり、TMPGEnc の出力を YUY2で保存して中間ファイルにする時に、
何度でも通せるようにしたかったのです(ぉぃ

# って事で、選択肢を増やして混乱させてしまったのは私なので、 >95 に
# 言い返せなかったり (^^;;;

349 :名無しさん@編集中:03/04/29 06:18
>AviSynth で YUY2のみ処理を行うと、
>YUY2 <-> RGB の変換誤差から開放される
をどう読み解けば
>でも、↑ってAvisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)の話じゃないの?
なるんだ?
本人スルーだし・・・

350 :名無しさん@編集中:03/04/29 06:57
>>341
読んで見た。俺にも真意は分からんが、最後にこんなこと書いてあった。

>■ 蛇足
>読込み・出力の対応表を見て頂くと判ることですが、 TMPGEnc/AviUtl ともに RGBストレートスケールでのみ
元の YUV空間のデータ範囲をなんとか 保持できます。同様に VirtualDubでも RGB 処理です
(とは言うものの、fastでスルーも可能ですね。しかし、それは Dubを使っているのかと(笑))。

これ読んで、俺はこう思った。
Dubで Fast recompressやDirect stream copy(無圧縮YUY2で中間吐くには最適)を使えば
大丈夫だが、これはDubを使ったことにはならん。
う〜ん、やっぱり分からん。何処にAvisynthの問題があるというのだろう?
これ、単なる『俺って、GraphEdit使えるんだぜ!スゴイだろ!』って自慢を披露したかっただけじゃないかな?
例の比較表にも訳分からん部分がいくつかあるし。
(どうやって確認したか、またその比較結果データを別に置いておいて欲しい。
 実験レポートってのは、結果だけじゃなくて、ときにはその何百倍もの実験データが添付資料として付くもんだぞ)

351 :名無しさん@編集中:03/04/29 07:04
ほんと都合が悪いのはあからさまにスルーするよね
アメリカ軍の司令官みたいだ

352 :名無しさん@編集中:03/04/29 13:15
>>349
AviSynth→avsinp.aui(YUY2)→AviUtl(出力のみ)→Huffyuvs(YUY2)という
> 処理を行うと、YUY2 <-> RGB の変換誤差から開放される…筈だったんだけど、
> 調べた結果は、
Avisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)
> で変換 しないことには、元データを保持することができない
と読み解く。

そこで、GraphEditを使うことにした。以下、その方法。
http://vmaker.tripod.co.jp/other/graphedit.html
と読み解く。
※その後、VirtualDubModを知り、使い始めた。

でも、実際には、
http://pc.2ch.net/test/read.cgi/avi/1042666068/523
だった。
http://vmaker.tripod.co.jp/other/graphedit.html
は、その投稿以前のもので、更新していないから、保持できるように書いたままになっている。
と読み解く。

もちろん、私はvmakerさんではないので、vmakerさんのHPとかキャプチャ&エンコスレのvmakerさんらしき投稿を参考に推測したもの。


353 :名無しさん@編集中:03/04/29 13:25
あと、↓とか。
http://pc.2ch.net/test/read.cgi/avi/1042666068/518
「YUY2を〜」というのは、旧ページでの
「YUY2 を一度 RGB に変換しないと、期待する結果を得ることができないなんて…。」

354 :名無しさん@編集中:03/04/29 22:56
age

355 :名無しさん@編集中:03/04/29 23:14
必死な奴がいるな

356 :名無しさん@編集中:03/04/29 23:20
使いたくなければ使わなければいいだけのこと
ソース公開までしてるのに、何が気に入らないのだ?
現状でHuffyuvSは便利だけどなー

357 :名無しさん@編集中:03/04/29 23:56
>>355
質問に答えただけなのだが・・・。

358 :名無しさん@編集中:03/04/30 00:22
>ソース公開までしてるのに

公開しないとそっちの方が問題になるんじゃないの?

359 :名無しさん@編集中:03/04/30 00:41
>>356
ソース公開は義務だろ
アホか

360 :名無しさん@編集中:03/04/30 01:09
あーあ、また墓穴ほっちゃったよ

361 :名無しさん@編集中:03/04/30 01:32
>>356
ソース読んでみたからと言って、Avisynthの何処に問題があるのか
俺にはわからんのだが、お前にはわかるというのなら教えて欲しい。

362 :名無しさん@編集中:03/04/30 02:20
>>361
Avisynthに問題があるって誰が言ったの?

363 :名無しさん@編集中:03/04/30 02:37
>>362
ああ、悪かった。俺の勘違いだわ。
>341 :名無しさん@編集中 :03/04/28 22:09
>Vmaker氏が現れやすそうな雰囲気になったんでちと書くが
>>AviSynth で YUY2のみ処理を行うと、
>>YUY2 <-> RGB の変換誤差から開放される…筈だったんだけど、
>> 調べた結果は、一度 RGB にストレート変換を行い、
>>その結果を huffyuvs の Convert YUY2 で変換 しないことには、元データを保持することができない
>とかいうことが
>ttp://vmaker.tripod.co.jp/other/graphedit.html
>にあるんだが、これってにーやん氏や>>320の結果と異なるんでは?
これ読んで、Avisynthに問題有りと言っていると思った。
問題はその後だったんだね。AviUtl,TMPGEnc,VirtualDubどれでもダメで
HuffyuvSとGraphEditを使うことでしか解決しない。と言っている訳だったんだ。

364 :名無しさん@編集中:03/04/30 02:40
でも、やっぱりソース読んでも意味がないな。
問題なのは、DirectShow FilterのPinの接続の仕方だと言っているわけだから。

365 : ◆S/VMAKER3c :03/04/30 10:18
え〜と、何から答えたら良いでしょう(^^;;
とりあえず

>364
> 問題なのは、DirectShow FilterのPinの接続の仕方だと言っているわけだから。
これは、どの部分のことでしょうか? 2G超えのあたり?
そとれも、Avisynth で RGB だと…って部分ですか?

>363
えっと、実は Convlistを作成した時は、VirtualDubの Fast の動作を知らなかっ
たんです。で、知らなかったなんて恥ずかしいから、いつだったかGraphEditの蛇
足にコソーリと追加したんじゃなかったかな(^^;;。で結局混乱の元。すみません。

>352
ありがとうございます。私もよく覚えてませんが。そんな感じかと思います。
ちゃんと全部メンテしないとダメですね。

>350
> 単なる『俺って、GraphEdit使えるんだぜ!スゴイだろ!』って自慢を披露したかった
流石に、こんな風に言われると悲しいものがあるんですが、そういう風に見えちゃ
いますかねぇ〜。GraphEdit関連の情報は意外に少ないので、実は簡単で、結構便利
ってな意味もあって残してあるんですが、削除しよかっな(^^;

> 実験レポートってのは、結果だけじゃなくて、ときにはその何百倍もの実験データ
> が添付資料として付くもんだぞ
その通りかもしれません。ただ、今回の場合必要でしょうか?
FREE版や、Trial版を使った理由と共通しているのですが。誰でも試すことのできる
データやプログラムをベースにテストしているので、試したデータを添付する必要は
無いと踏んだのです。


366 :350です:03/04/30 13:49
このときは別にそんなに本気で書いたわけじゃなく、チラッとそう思ったってことで、
そんなに落ち込まないでください。

ではどうしてそう思ったかは、>>350で参照している『蛇足』からです。
ここで、あなたはDubのfastで同じことができる。と書いてあるように読める。
だったら、上で大層なことを書いているのはいったい何だったのか?
という思いから、もしかしたら心のどっか片隅にこんな思いが潜んでいるのでは?
と勘ぐったわけです。GraphEditはDirectX SDKをDownしようと思う人なら使えて当たり前
という考えもあって......
まあ、ゲスの考えって奴です。俺のことなんか軽蔑して無視しちゃってください。
でも、俺が思うに、書き換えるなら、蛇足じゃなくて、冒頭を書き換えて、
『DubでDirect stream copy, fast recompressを使えばよいが、
 GraphEditを使ってもできる』
とするけどね。いらざる誤解を与えるし。
あと、書き換えたんなら、版数と更新日を表示することも普通にやるかな。

ちょっと前の
「huffyuvS (YUY2) の aviutl (YUY2 チェック) 」が伸張 で
「huffyuv (YUY2) の aviutl (YUY2 チェック) 」が伸張 ※9 だったりして
ちょっと色めがねをかけていただけなんで。

で、この※9についてどうやって確認して、その誤差ってどの程度?
ってところからレポート云々が出てきたわけですが?
これが、『誰でも試すことのできる』からデータは不必要と言われてはしかたありません。
たしかに俺は『試すことのできる人』ではありますから。面倒だけど。
あと、誤差の程度がデータがあれば見えるのにな、って思っただけです。
(確かに、変換誤差は、AviUtl,TMPGEnc,VirtualDubで若干違っていてVirtualDubが一番大きいかな』
 っていう思いもありますけど、俺には関係ないことだしいまさら確かめる気力は出ませんが、
 この表を作ったあなたならやってくれるんではないのかな、と思って。
 excelの表かなんかに、最大、平均、最小2乗誤差とかいろいろまとめてくれないかな?)

367 :名無しさん@編集中:03/04/30 14:04
なんか違うなあ、って思って読み返したら....
>ゲスの考えって
『下衆の勘ぐり』の間違いです。どうしてこんなの間違えたんだろう?
こんな主文的な重要な部分に間違いがあって申し訳ない。

俺って、やっぱりこの程度の奴です。

368 : ◆S/VMAKER3c :03/04/30 15:05
>366
どうもありがとうございます。気分的に少し復活できました。でと

>「huffyuvS (YUY2) の aviutl (YUY2 チェック) 」が伸張 で
>「huffyuv (YUY2) の aviutl (YUY2 チェック) 」が伸張 ※9 だったりして

これって? どういう意味でしょうか? 私がアップロードしている convlistを
参照して頂く限りは

> HuffyuvS (YUY2) AviUtl (YUY2チェック有) 伸張 ※9
> Huffyuv (YUY2) AviUtl (YUY2チェック有) 伸張 ※9

となっている筈です。ちょっと前ということは、抜けてたことがある…のかな?
# Application列で見て、11行目と、29行目のことですよね? 違うのかな。

版数や日付などは確かにそうですね。入れるよう気をつけて行きたいと思いま
す。プログラムの更新日には気をつけているんですけどね(^^;;


369 :名無しさん@編集中:03/04/30 15:38
蛇足ってのは余計な付け足しって意味で、
今回のように重要な訂正を書くもんじゃないでっせ!

370 :名無しさん@編集中:03/04/30 15:44
>>350
別に下衆の勘ぐりとは思わないけどなあ。
普通の語学力のある奴なら皆そう考えると思うぞ。

371 :370:03/04/30 15:53
と言っても、今回はそう誤解されても仕様が無かったようにした、
◆S/VMAKER3cさんの所為だと言っただけ。
>>350さんは、>>214さんですね。きっと。

◆S/VMAKER3cさんにお願い
>>214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
調査して報告しようとは思いません?

372 :名無しさん@編集中:03/04/30 16:18
>>337
確かに茂木さんだけど、本人自身の書き込みで、まるも(マルモ、○モだったかも)
と自分のことを表現したことが何度かあり、まるもでも間違いじゃないだろうと思う。

373 :名無しさん@編集中:03/04/30 20:56
確かトリップがmarumoじゃないっけ?
2chでの

374 :名無しさん@編集中:03/04/30 21:25
MPEG2(D-VHS)→MPEG-2 VIDEO VFAPI Plug-In→TMPGEnc→DVD の場合はどうすればいいですか?
m2v_vfpでストレート変換にして、
TMPGEncでYUV データをCCIR601 ではなく、BasicYCbCr で出力するにチェック有りであってます?
今まではITU-R BT.601から伸張、TMPGEncでチェックなしでMPEG2を作ってました。

375 :名無しさん@編集中:03/04/30 21:42
MPEG2(D-VHS)→MPEG-2 VIDEO VFAPI Plug-In
ここで伸張
→TMPGEnc
でチェックなしのが精度は高いでしょう
ただ、その差が果たしてわかるかどうか・・・

376 : ◆S/VMAKER3c :03/05/01 10:10
>371
> 214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
> 調査して報告しようとは思いません?
言わんとしている事はなんとなく解る気がするのですが、それを調べて把握
して置くメリットって何でしょう?


377 :名無しさん@編集中:03/05/01 16:44
>>376
つまりやる気はないわけですね。
そうですか、とても残念です。

378 :名無しさん@編集中:03/05/01 17:02
>>376

>それを調べて把握して置くメリットって何でしょう?
自作ソフトを使って貰おうという人間の言葉とも思えません

このソフトには、これこれこういう特徴(メリット)があります
でも、こういうリスク(デメリット)もあります
両者を天秤にかけて使用するかどうかご判断ください

ってのが正直者の態度だと思う
まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね

“そんなものがもしあったとしても俺が調べる謂れはないだろっ”
って態度はいかがなものかと
中傷なら無視するのも当然だけど、中傷だと思っているわけ?

379 :名無しさん@編集中:03/05/01 17:18
>>373
>確かトリップがmarumoじゃないっけ?
トリップって何?

trip /trp/→→
名詞
 1 旅行 〔to〕《★【類語】 ⇒→travel》.→
 2 (用向きの)外出,ひと走り; 通勤,往復 〔to〕.→
 3 a 踏みはずし,つまずき; つまずかせること.→
  b 過失; 言いそこない.→
 4 《口語》
  a (主に LSD による)幻覚(の経験,期間).
  b 刺激的経験.
 5 【機】 始動装置,掛けはずし子(こ); スイッチ.
動詞
(tripped; trip・ping)
 1 動(+前+(代)名)〔…に〕つまずく,つまずいて倒れる; よろける 〔on,over〕.→
 2a 間違える.→
  b +up (+on+(代)名)〔…で〕過ちを犯す,間違える.→
 3 +副(句)軽快な足どりで歩く[走る,踊る].→
 4 +out《口語》 (主に LSD による)幻覚症状に陥る.
他動詞
 1 +目(+up)
  a 〈人を〉つまずかせる,ころばせる; (レスリングなどで)〈人の〉足をすくってひっくり返す.→
  b 〈人を〉失敗させる.→
  c 〈人に〉つじつまの合わないことを言わせる.→
 2 〈機械・装置を〉始動させる.
  古期英語「踏む」の意

380 :名無しさん@編集中:03/05/01 17:26
>>378
またキツイことを...
正論に聞こえるから仕方ないかもしれんけど。

でも、どうせなら指摘した>>214さんに報告してもらったら?

381 : ◆XPRMtj3vAA :03/05/01 17:38
>>375
http://www.marumo.ne.jp/bt601/yuvcheck.lzh
ストレートでの YUV->RGB->YUV の誤差とか RGB->YUV->RGB の誤差とか
圧縮・伸張での YUV->RGB->YUV の誤差とか RGB->YUV->RGB の誤差とか

RGB 変換後オーバーフローしない範囲内ならば、ストレートも圧縮・伸張も
YUV->RGB->YUV 共に誤差 0。オーバーフローするケースだと、ストレートが
有利。

とまあ、そんな結果になります。

アーカイブの中のプログラムは浮動小数点で精度を最大限取れるように計算
してるから、Huffyuv/HuffyuvS の MMX 実装でどうなるかは不明です。
多分傾向は変わらないんじゃないかと思いますけど。

YUV 絶対主義の方(多分居ないと思うけど)はそもそも 234 の言うように
RGB になんて変換してはいけません。どっちでもオーバーフローしますから。

382 :381 ◆47o/marumo :03/05/01 17:41
トリップミスかっこ悪ぃ。

383 : ◆S/VMAKER3c :03/05/01 18:18
>377
なぜそういう事になるのやら…。少なくとも、>214 に書かれた事は、特性ですから、
それを比較すること自体には意味を感じてません。ですから、とてもよい目的がある
のであれば聞きたいと思ったのでけど。

>378
>まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
>おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね
えっ? 不具合があったんですか? どこに書いてあるんでしょう? すみませんが、どうも
見落としているようですので、ポインタを示して頂けないでしょうか。


384 :名無しさん@編集中:03/05/01 18:22
>>381
Avisynth + VirtualDub (fast recompress) な人だと、既に RGB なにそれ? と
なっているよん。んまぁ、1394 で HD キャプでもやる人だと、いったん
BT.709 に従って YUV -> RGB 変換しないとまずいことになるから、しょうがなく
RGB に変換かけているだろうけど。

385 :名無しさん@編集中:03/05/01 20:27
>>383
脊髄反応せずに、もう少し冷却期間を置いたらどう?
あんまりみっとも良い態度じゃないよ。

386 :名無しさん@編集中:03/05/01 21:37
>Avisynth + VirtualDub (fast recompress) な人だと、既に RGB なにそれ? と
>なっているよん。

そういう人はそもそもこのスレの話題は関係ないのに、なにしに来てんの?


387 :名無しさん@編集中:03/05/01 21:46
>>386
俺もAvisynth + VirtualDub (fast recompress) な人だけど、ここに見に来てるよ。
だって面白いんだもん。iyahonntoni

マジな話、そういう俺でもRGBは無視できないね。
だって、YUVで色補正するとき、RGBベースでやっぱり調整しなきゃならないもん。
表示がRGBなんだから、あんまりRGBの範囲をはみ出すわけにはいかん。

388 :名無しさん@編集中:03/05/01 22:37
ピクセラ厨とMTV厨がYC伸張してるだのしてないだの騒いでます。

389 :名無しさん@編集中:03/05/01 22:44
あいつ等は放置した方がいいと思います

390 :名無しさん@編集中:03/05/01 22:45
HuffyuvSマンセーのスレになる筈だった公算がすこしくるってきました

391 :名無しさん@編集中:03/05/01 23:08
MEDIACRUSEってビデオ入力を表示するときって
ソフトウェアでYUV→RGB(伸張)変換してからオーバーレイに転送してるんですかね?

392 :名無しさん@編集中:03/05/01 23:29
>>388
PCスケールとかTVスケールという言葉が一人歩きしているようだ

393 :名無しさん@編集中:03/05/02 00:59
>>392
へへん、知ったようなことを

394 :名無しさん@編集中:03/05/02 02:09
ここまで読んでて思ったこと。
プログラミングの技術うんぬんはおいて置いてVMAKERさんって人間的にはまったくの子供なんだね。
まあ今後社会に出てもまれて立派な社会人になることを期待しとります。

395 :名無しさん@編集中:03/05/02 02:17
>>394
へへん、(ry

396 :名無しさん@編集中:03/05/02 05:59
>>394
とっくに社会に出てるわけだが
ああいうタイプの人間は社会に出ればいくらでもいるわけだが
そんなこともわからない>>394は明らかに社会に出てないわけだが
おまいは、脛かじりもいい加減にしる!

397 :名無しさん@編集中:03/05/02 06:39
もういいよ・・・これ以上恥の上塗りをしないでくれ(つД`)

398 :名無し募集中。。。:03/05/02 17:51
HuffyuvSとHuffyuv

399 :名無しさん@編集中:03/05/02 18:38
HuffyuvR の登場が待たれます

400 :名無しさん@編集中:03/05/02 18:48
保守

401 :名無しさん@編集中:03/05/08 18:42
Huffyuv(あるいはHuffyuvS)でカラーバーをキャプチャーして
AviUtlの波形表示プラグインで調整する場合、
読み込み時のコーデックの環境設定は展開圧縮ノーチェック
にしなければならないのでしょうか?

402 :401:03/05/08 18:45
波形表示プラグインの補助線はCCIR601用で調整してます。

403 :名無しさん@編集中:03/05/08 19:28
波形表示プラグインの解説にあるように
カラーバーで調整するときはストレート変換が前提。

なのでHuffyuvSで展開ノーチェックがよろしいかと

404 :401:03/05/08 20:38
ご回答ありがとうございました。

何かこのスレ、コーデックとハードとソフト、
それぞれの問題がごっちゃになっていてわかりづらいですね。

405 :名無しさん@編集中:03/05/08 21:17
>>404
動画再生時はハードウェアオーバーレイが前提になるんでしょうがない。

406 :名無しさん@編集中:03/05/08 22:39
伸張する?とか、しない?とか、
最初に言い出したのは誰なのかしら?

407 :名無しさん@編集中:03/05/08 22:50
>>406
あにぺぐであろうな

408 :名無しさん@編集中:03/05/09 03:54
ここってバカが転がり込んで来るスレですか?

409 :名無しさん@編集中:03/05/09 17:40
イマイチ古いネタだけど。このスレッドの方々にとって

ttp://www.canopus.co.jp/catalog/dvstorm/dvstorm_comparison2.htm
ttp://www.matrox.com/video/jp/products/pdf/canopus_got_it_wrong.pdf
ttp://www.canopus.co.jp/catalog/dvstorm/objection.pdf

ってどんな感じなのかしらん。特に YUV - RGB の辺りについて。

410 :名無しさん@編集中:03/05/10 01:08
どっちの言い分が正しいかは分からないけど、
このメーカーにしてあのユーザーありって感じ<カノプ

411 :名無しさん@編集中:03/05/10 01:11
age

412 :動画直リン:03/05/10 01:12
http://homepage.mac.com/hitomi18/

413 :名無しさん@編集中:03/05/10 01:46
>>409
まさにこのスレでの議論と似たようなことをメーカ間でやっている感じ。
スゲー面白い。

YUVとRGBのどっちが大きいかは、BT.601で比較すると
・全体的にはYUVの方が大きい
・でもRGBの方が大きい部分もある

元々カメラ撮影がRGBでそれをYUV変換したものをソースにした場合、
・YUV->RGBでのロスは少ない
・RGB->YUVのロスは無い

でも、RGB空間でトランジション処理したら、
・RGB->YUVでもロスが出る

matroxの言い分もある程度聞けるけど、
ことYUV->RGB変換に関してはやっぱり変換ロスはどうしても出るだろうね。

414 : :03/05/10 02:04
こんちゅのあちゅきよで
とどほかんしてじゃねど

415 :名無しさん@編集中:03/05/15 14:52
ずっと読んできたんだけど確信が持てないので
自分はcanopusのDVキャプなんですが
DV→AviUtl (YUY2 チェック無)で読み込み→Huffyuv S(Conv YUY2) で出力
CCE(0-255)でエンコードでいいんでしょうかね?

DVDにしてTVで見るのを前提としています



416 :名無しさん@編集中:03/05/15 17:26
>>415

YUY2 チェック有であるならば0-255は関係ないのでは?
ほかの部分はよくわからんのでわかる人サポートよろしく

417 :名無しさん@編集中:03/05/15 17:47
>>416
そのとーり。

418 :名無しさん@編集中:03/05/15 17:57
>>415 
AviutlのcanopusのYUY2で展開するをはずし
Huffyuv SのYUY2で圧縮するもはずしておいてConv YUY2
CCEはYUY2チェックでいいと思うんだが

頭のいい人俺も正解知りたいから教えてくれ

419 :名無しさん@編集中:03/05/15 18:07
canopus DV → CCE → DVD
これだと16-235なの??

420 :名無しさん@編集中:03/05/15 20:00
>>419
ちがう。
スケール変換というものは、ある色空間をRGBにするときの変換式を言う
そしてYUV色空間は画面表示時に伸張するのが基本
だから
>これだと16-235なの??
というのは意味がわからん
canopus DV はDVなのでYUV4:1:1
よってネイティブ色空間はYUV
CCEでYUY2読みこみ。無論YUV4:1:1をYUY2変換して読み込ませることが可能
しかもCCEはTMPGEncと異なりネイティブ色空間はYUV
DVDは内部色空間YUV(YV12 or YUY2。ただしYUY2の市販DVDはない)
つまり
canopus DV → CCE → DVD
はずっとYUV処理になる
RGBにはならない

421 :名無しさん@編集中:03/05/15 21:28
↓このスレ痛杉(^A^)ケラケラ

〓〓〓〓〓飯田里穂11歳ぱーと12〓〓〓〓〓
http://tv3.2ch.net/test/read.cgi/geino/1051133784/


422 :419:03/05/15 21:35
>>420
ありがとうございます。
勉強になりました。

423 :名無しさん@編集中:03/05/16 08:16
canopus DV → CCE → DVD
って4:1:1→4:2:2補完せんのかよw

424 :419:03/05/16 14:55
>>423

>>415のようにやるといいんでしょうか??

425 :名無しさん@編集中:03/05/16 18:35
>>423
うむ。Avisynth挟んでColorYUY2でinterpolation使ったほうがよさげ。

426 :名無しさん@編集中:03/05/16 18:36
>>424
お前、415がなにをしているのかも、YUV422補完とはなきかもまるで
理解できないのかよ…

427 :名無しさん@編集中:03/05/16 21:05
初心者にそこまでいわんでも・・・
とりあえずYUV422補完しないでやって
気に入らなかったら補完するようにすればいいんでない?
多分このスレの常駐者でも、動画をひと目見て
「む?DVソースだな。補完しないとは愚かなヤシだ。」
なんてわかるのは、皆無か極少数だよ

428 :名無しさん@編集中:03/05/16 22:59
これを見て、識者の皆さんはどう思われますか?
http://pc.2ch.net/test/read.cgi/avi/1052654576/733-734n

429 :名無しさん@編集中:03/05/16 23:23
上手く調整されてると思いますが。

430 :419:03/05/17 15:26
>>425
これで合ってますか?
__________________________
#--- プラグイン ---
PluginDir = "C:\Program Files\avisynth\plugin"
LoadPlugin( PluginDir + "ColorYUY2.dll" )

#--- ソース ---
SourceDir = "D:"
FileName = "source"
AVISource( SourceDir + FileName + ".avi" )

#--- YUV411->YUV422 ---
ColorYUY2(interpolation="411->422")

return last
_________________________

431 :名無しさん@編集中:03/05/18 17:26
>>430
一瞬で試せることを訊くな

432 :名無しさん@編集中:03/05/19 21:23
たまには

433 :名無しさん@編集中:03/05/20 23:20
最終的にCODECが受け取った時の処理なんですが

ソース YUV時
CCE
YUV(16-235)からYV12(16-235)
TMPGEnc
YUV(16-235)から内部RGBに変換(ストレート?)出力時YV12(0-255),YV12(16-235)選択可
DivX
YUV(16-235)からYV12(16-235)
XviD
YUV(16-235)からYV12(16-235)
WMV
YUV(16-235)からYV12?(16-235)

ソース RGB時
CCE
RGB(0-255)から出力時YV12(0-255),YV12(16-235)選択可
TMPGEnc
RGB(0-255)から出力時YV12(0-255),YV12(16-235)選択可
DivX
RGB(0-255)からYV12(16-235)
XviD
RGB(0-255)からYV12(16-235)
WMV
RGB(0-255)からYV12?(16-235)

こんな感じでよいのでしょうか?
CCE/TMPGEncは選択可能ですが、DivX/XviD/WMVはYUV入力時とRGB入力時の挙動がはっきりしないので。


434 :名無しさん@編集中:03/05/20 23:48
YUVにもYV12にも(X-Y)という概念はありません
(X-Y)という表記はYUV>RGB変換時の値です
大体YUVの範囲は0〜255じゃないですよ
それにYV12はあくまでもYUVの一種です


435 :名無しさん@編集中:03/05/20 23:57
もうひとつ言えばCCEやTMPGEncはエンコーダ
DivXやXviDはコーデックです
コーデックに色情報を受け渡すのはエンコーダですから
コーデックが直にソースを受け取ることはできません
つまりエンコーダ(正確にはフロントエンド)に依存します

436 :名無しさん@編集中:03/05/21 00:58
>>434
>>435
ども、やっぱ書き方まずかったですね。
過去ログにあった「DivXはRGBで渡すとコーデックが圧縮(0-255>16-235)する」ってのが発端で疑問に思ったので
最終的にCODECに渡した場合に(CCE,TMPGEncはエンコーダーですが、MPEG(YV12)に変換する部分の話ということで)
RGB、YUVで渡した時の処理の差が知りたかったということです。


437 :名無しさん@編集中:03/05/21 01:26
>>436
XviD はソースがあるから、それを確認するのが確実(確か伸張・圧縮してたはず)
後、YUY2/YV12 で渡した場合にスケール変換するコーデックは存在しないはずだから
AviUtl で YUY2 チェックを圧縮・復号で ON/OFF して比較を推奨

438 :山崎渉:03/05/22 01:53
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

439 :名無しさん@編集中:03/05/22 17:25
(・∀・)hosyu

440 :名無しさん@編集中:03/05/25 22:58
http://homepage1.nifty.com/straylight/bbs/docs/20030523223511.html
元々、DVDなどはビデオ信号に載せてNTSCなどのビデオモニタで見る事を
前提として作られているので、色もその場合に最適になるように調整してあるのです。
なので、RGB信号で出力した際の色は、制作者の意図した色と違います。
具体的には、色が薄く、コントラストが弱くなります。

#私はPCでCG映像などを制作する仕事をしていますが、
#色調整は必ずNTSCモニタ上で行います。映像業界では常識です。
#色調整をNTSCモニタで行うための専用のソフトやハードまであります。
#NTSCモニタとPCでは色が全然変わってきてしまうので、
#PCモニタ上の色はあくまでもプレビュー程度という認識です。


441 :名無しさん@編集中:03/05/25 23:18
>>440
リンク先も読んだがちと事実誤謬があるな

「制作者の意図した色と違います」のはモニタ色温度の問題であって(もしくはスケール変換やグラボのオーバーレイの問題)
「RGB信号で出力」することには起因しない
NTSCビデオモニタだって内部RGB変換して表示してるんだからね
実際表示するさいの出力形式はNTSCだろうがPALだろうが、マスターモニタだろうが民生テレビだろうが
RGB信号なんだよ


442 :名無しさん@編集中:03/05/26 02:18
とうとうスネちゃったのかな
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html

443 :名無し募集中。。。:03/05/26 06:32
まあいいんでない?

444 :名無しさん@編集中:03/05/26 07:44
>>442
事故であることを祈る。
もしスネて削除したんであれば、彼はそれだけの人間だったってことか。

445 :名無しさん@編集中:03/05/26 07:59
あらら・・・

446 :名無しさん@編集中:03/05/26 12:46
それじゃthejamのボケと同じだな

447 :名無しさん@編集中:03/05/26 13:50
thejam氏は復活した

448 :名無しさん@編集中:03/05/27 03:24
thejam以外はみんなうんこ

449 :名無しさん@編集中:03/05/27 12:43
またMXやってんのか?

450 :名無しさん@編集中:03/05/27 12:48
これからはMXだよ

451 :名無しさん@編集中:03/05/27 15:07
これからはHDDで直接交換

452 :名無しさん@編集中:03/05/27 15:46
映像制作のプロっつったってこんなもんだ。(((( ;゚Д゚)))ガクガクブルブル

>漏れも映像CG屋なんだけど、NTSCで納品する場合の色の補正って、
>(中略)
>こういうこと恥ずかしいからあまり会社で聞けない(汗

http://pc.2ch.net/test/read.cgi/cg/1041868484/388-390


453 :名無しさん@編集中:03/05/27 23:02
言いたいことがあるならこっちで書けよ>>1
http://pc.2ch.net/test/read.cgi/avi/1051598630/854-862



454 :名無しさん@編集中:03/05/28 15:51
>>452
ところでセーフカラーに入らなかった時にどういう問題になるか知ってて書いてる?

455 :名無しさん@編集中:03/05/28 16:18
>>454
知りません。教えてください。

456 :山崎渉:03/05/28 16:47
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

457 :名無しさん@編集中:03/05/28 20:47
AEだったら
http://www.flashbackj.com/SA/EchoFire/forwin.html
こんなのあるね

458 :名無しさん@編集中:03/05/29 02:20
もぐったら事故

459 :名無しさん@編集中:03/05/29 12:00
あ、もう正解が書いてある(w

460 :名無しさん@編集中:03/06/04 12:42

おまえらのせいでvmakerさんが公開止めちゃったじゃないか
しねしねしね

461 :名無しさん@編集中:03/06/04 12:46
>>460
vmakerさん久しぶり。元気?

462 :名無しさん@編集中:03/06/04 14:16
vmakerさーーーーーーん

463 :名無しさん@編集中:03/06/04 18:15
vmaker=slave=1だったってことで

464 :slave:03/06/04 20:30
>>463
違いますよ
vmaker氏には「スレがあんな状況になってスイマセソ」
というメールを出したんですが返事は来ませんでした
そしてしばらくしてサイトが・・・
listやHuffyuvSは兎も角、他のプラグイソまで・・・
キャプエソ質スレでも以前からやりとりしており
気さくな方だと認識しておりましたから
サイト永続アボーソはないと信じたいんですけど・・・

465 :名無しさん@編集中:03/06/05 01:42
サイトが消えたのはその話題の直後じゃなくて、
誰も振り向きもしなくなって数週間後のことだから、
ちょっとこのスレとは関連があるとは思えないけど。

466 :名無しさん@編集中:03/06/05 04:41
パッチがまずかったんだろうか、、

467 :名無しさん@編集中:03/06/05 19:28
パッチってなんのパッチ?

468 :名無しさん@編集中:03/06/05 19:45
みなしご

469 :名無しさん@編集中:03/06/06 15:53
上から読んだけどサパーリ。
キャプボじゃなくてDVDレコーダーでキャプってるんですが、
どういう処理をすればいいんでしょう?
DVD2AVIでプロジェクトファイルとWAVを作成後、
Aviutlで各種フィルタをかけて(色はいじらない)Huffyuvに変換。
そして特に余計なフィルタをかけずにTMPGEncでMPEG1やSVCDやに変換してます。
特にHuffyuvに変換にする時の設定がサパーリ。

470 :名無しさん@編集中:03/06/06 16:26
>>469
エンコード前後で色調が同じになってれば良いだけだよ。

471 :名無しさん@編集中:03/06/06 18:37
>>464
つまり、おやぶんのために作ったスレが逆に足を引っ張るハメになって
詫びを入れたがへそを曲げちゃったってことですか?

472 :名無しさん@編集中:03/06/06 20:13
>>469
DVD2AVI→RGB TV色調
AviUtl→コーデックの設定でYUY2で出力のチェックを外す
huffyuv→RGB compression methodをConvert to YUV以外にする
TMPGEnc→BasicYCbCrで出力にチェックを入れる

473 :469:03/06/07 02:41
>TMPGEnc→BasicYCbCrで出力にチェックを入れる

Σ(゚д゚lll)ガーン
今までエンコした動画、全部チェック入れてなかった。
DVではONにした方がいいとか書いてありますが、DVDレコも同じようなものなんですか。

474 :名無しさん@編集中:03/06/07 02:50
>>473
チェックを入れてなかったからって問題があるとは限らない
ストレート変換(>>472の言うDVD2AVI→RGB TV色調)をしたときのみチェックを入れる

475 :469:03/06/07 09:58
>>474
今までずっとこういう設定でやってきたんですが・・。(ていうか知らずにそのままにしてた)

DVD2AVI
Color Space = YUV 4:2:2
YUV -> RGB = PC Scale

AviUtl コーデックの設定
YUY2で展開する・YUY2で圧縮する・圧縮の設定を保持する の全てにチェック

Huffyuv
YUY2 compression method = Predict left [fastest]
RGB compression method = Predict gradient [best]
その他の項目にはチェックなし

TMPGEnc
BasicYCbCr = チェックなし

上のほうで、テレビで見るかPCで見るかは関係ないというような書き込みがありますが、
やはりPCで観るためのMPEG1でもテレビで観るためのVCD・SVCD・DVD-Videoでもこれらは変わらないんでしょうか?
キャプを始めて早一年・・。かなりの腕になったと思ってたんですが、先は長そうです。

476 :名無しさん@編集中:03/06/07 22:50
>上のほうで、テレビで見るかPCで見るかは関係ないというような書き込みがありますが、
>やはりPCで観るためのMPEG1でもテレビで観るためのVCD・SVCD・DVD-Videoでもこれらは変わらないんでしょうか?

それはBT.601厨のたわ言なので気にすることはありません。
自分の使う機器にベストなセッティングで動画を作りましょう。


477 :名無しさん@編集中:03/06/07 23:25
でもまあ、BT601に準拠させとくのが無難かと。

478 :名無しさん@編集中:03/06/07 23:36
>>475でもBT.601に準拠するわけだが

479 :名無しさん@編集中:03/06/07 23:38
コントかこのスレは

480 :名無しさん@編集中:03/06/07 23:41
むしろ>>472はBT.601準拠してないわけだが
でもできたファイルは大差ないけど

481 :469:03/06/07 23:54
誰の言う事が本当なのかわかんねぇよもう・゚・(ノД`)・゚・。

482 :名無しさん@編集中:03/06/08 00:02
>>480
472を書いたのは私ですが、BT.601に準拠させるつもりでああ書いたのではなくて
DVDレコーダーがどういうように記録してるのか分からないので
16-235外のデータも保持できるように配慮した設定を書きました。

483 :名無しさん@編集中:03/06/08 00:04
>>481
>>470が正しい
ちなみに>>472でも>>475でも結果は>>470になる
>>472だと途中経過がBT.601に準拠せずかつ
色調補正がしづらく、またYUY2<>RGB変換誤差の不安が残る
>>475だとAviutlによってサチュレートされてしまう問題が残る
それぞれの欠点が逆では利点になる
だから>>480
”でもできたファイルは大差ないけど”も正しい

484 :名無しさん@編集中:03/06/08 00:06
地上波もDVDもBT.601の推奨範囲を守らないのに、
なんで地上波やDVDリップしてるアマが推奨範囲を金科玉条にするんだろ?
どんなチューナーもシュートするし、
NTSCビデオモニタは勿論民生テレビだってBT.601オーバーを表示できるのに、
ほんとうにBT.601の推奨範囲を守ることが正しいの?


485 :名無しさん@編集中:03/06/08 00:09
>>484
むこうのスレが生きてるのにコピペすることもないんだが
一応コピペレスしてやろう

白トビ黒つぶれも映像表現だと言われればそれまでなんだよ
だけどキャプるとき(もしくは色調補正するとき)の指標は必要でしょ?
PC環境が変わっても破綻のない絵柄を選ぶ、という目的のためには
推奨範囲を守るのが一番正しいんじゃないかなぁ?
実際キャリブレーションというのは
推奨範囲内でのダイナミックレンジを有効に利用する設定なわけだし・・・。
まぁ俺スケールでもかまわないとは思うけどね。
AV機器ヲタなんてキャリブレートなんかより俺色合い重視だしな。

486 :名無しさん@編集中:03/06/08 00:16
>>484-485のやりとりは
キャプチャ時に補正がかけられるボードに関する話題
YC伸張とはちょっと違う話なので
>>469は混乱しないように

487 :名無しさん@編集中:03/06/08 00:19
オーバーも許容されるんだからBT601にしと毛

488 :名無しさん@編集中:03/06/08 00:25
やっぱ、テストパターンを極めるところから始めないと。

489 :名無しさん@編集中:03/06/08 00:29
テストパターンを極めたところで
テレビ放送を録画してそれが正しい色調で録画できると言えるか?

490 :名無しさん@編集中:03/06/08 00:34
テストパターンさえ綺麗になれば満足です

491 :名無しさん@編集中:03/06/08 00:35
調整しないよりいいんじゃネーノ?

492 :名無しさん@編集中:03/06/08 00:35
少なくとも、色調に対する感受性というか、
判断力を養う訓練にはなるんでない?

493 :名無しさん@編集中:03/06/08 00:36
>>489
いえない
カラーバー送出機をキャプってもキャプボのデジタイザ特性がわかるだけ
チューナー特性はわからない
テストパターンDVDを使ってもいったん送信させてからキャプることになるため
送信側の特性に埋もれてしまう
局から送信されたものをキャプってもそのときの受信状況の特性しかわからない
わからないどころかSMPTEカラーバーですらない
でも他に方法が・・・・俺スケール??

494 :名無しさん@編集中:03/06/08 00:37
>493
えらそうに薀蓄たれてるが
キャプじゃなくて録画の話じゃねーのか?

495 :名無しさん@編集中:03/06/08 00:38
>>475
DVDレコーダーの人はメーカーさんが自信を持ってコンフィギュレーションしてんだから
PC用とかTV用とか考えないでそれを維持するように努めれば良いんじゃないの?
Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。

496 :名無しさん@編集中:03/06/08 00:41
カラーバーで調整したキャプボでTV放送をキャプチャしたものと
DVDになったもので色を比べたら全然ちがくてあせった
こんな場合でも何処に問題があるのか特定できないんだよな
DVDの色は間違ってないと思いたいんだが…

497 :名無しさん@編集中:03/06/08 00:41
半角カナ=slave=1

498 :名無しさん@編集中:03/06/08 00:42
チャンネルごとのカラーバーキャプって調整すれば
完璧と言っていいんじゃないの?
しょせんエアチェックなんだし、それ以上は無理。
受信状況なんかそんなに変化するもんじゃないよ。

499 :名無しさん@編集中:03/06/08 00:42
>>495
それはキャプボもいえますな
これからMTV厨も苦労徒廃人も補正してはイカン!
メーカーの人を信じなさい
受信環境による相違?
ハァ?
安心しろ、地上波デジタルはもうすぐだ

500 :名無しさん@編集中:03/06/08 00:45
もはや嗜好の問題でしかないような・・・・・

501 :名無しさん@編集中:03/06/08 00:46
>>499
玄人は日本で調整してないからダメだよ

502 :名無しさん@編集中:03/06/08 00:49
>>501
日本以外でNTSC-Jって送信してるのか?
煽りじゃないんでマジレスキボンヌ

503 :469:03/06/08 01:05
みなさんありがとうございます。
とりあえず、問題ないなら今までの方法でやります。

>Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。

ただこれが気になります。
Geforce以外のやつなのにテレビより暗くなるんです。
DVDレコで録画したものを、何もいじらずそのままWMPで再生してもそうなります。
グラフィックカードはIntelのi810かi815のどちらかです。
再生時の設定がおかしいということでしょうか?

504 :名無しさん@編集中:03/06/08 01:06
最近フジ(東京8ch)の色が赤くなってない?
こないだカラーバーで調整したらフジだけ色相が回ってた
実際通常放送時の見た目も赤っぽくなってる
前は大丈夫だったんだけどな
まあうちの受信環境の問題かも知れんが

505 :名無しさん@編集中:03/06/08 01:07
>>503
モニタ+グラボ、もしくはテレビ、或いは両方がキャリブレートされてないから
まぁキャリブレートしたところで色温度が違いすぎるんで
PCモニタとテレビは一緒にならないよ

506 :469:03/06/08 01:07
>>502
このスレとは関係ないですが、家のテレビで一台だけPALを白黒表示できるやつがあります。
90年前後のパナのテレビです。
それ以外はPALを表示させようとすると、カラーですが画面が乱れます。
謎。

507 :名無しさん@編集中:03/06/08 01:10
>>503
DVD2AVI上で
YUV422とRGB PCスケールで表示を比べるとどうなりますか。


508 :505:03/06/08 01:10
あぁi815か
チップがそもそも糞

509 :名無しさん@編集中:03/06/08 01:12
>>503
>Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。

これはラデ厨のたわ言ですから気にしないように。

510 :469:03/06/08 01:13
>>507
市販DVDだと明るさが変わります。
DVDレコのやつとか拾ったMPEG2だとあまり変わりません。
ただ市販DVDとレコを見比べる途中に、一度MPEG2コーデックを変えてるんですよ。
関係ないかもしれませんが。

511 :469:03/06/08 01:14
>>508
Σ(゚д゚lll)

512 :505:03/06/08 01:15
>>510
物凄く関係あるよ
MPEG2decoderってメーカー毎の色づけが違うよ


513 :名無しさん@編集中:03/06/08 02:51
>>504
周波数がズレてきてるんじゃない?
微調整すれば。

514 :名無しさん@編集中:03/06/08 22:32
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=huffyuvs+cinema+craft+encoder&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

どうするんだろうね


515 :名無しさん@編集中:03/06/08 22:36
http://pc.2ch.net/test/read.cgi/avi/1049354328/964
これも困っちゃうんだよな
復活してくれ・・・

516 :名無しさん@編集中:03/06/08 22:39
もぐったら事故

517 :名無しさん@編集中:03/06/09 02:52
ConvTo持ってるぞ?

ConvTo_0.4-IF1_dll
ConvTo_0.4-IF2_dll

518 :名無しさん@編集中:03/06/09 16:57
YUY2で0-255で取り込むとまずいの?

519 :名無しさん@編集中:03/06/09 18:17
>>518
PCが爆発する

520 :名無しさん@編集中:03/06/09 18:21
>>519
もっと早く言ってくれよ。爆発しちゃったじゃん!!

521 :名無しさん@編集中:03/06/09 19:26
>>518
もぐったら事故

522 :名無しさん@編集中:03/06/09 19:59
まず全裸になり、自分の尻を両手でバンバン叩きながら白目をむき
「びっくりするほどユートピア!びっくりするほどユートピア!」
とハイトーンで連呼しながらベットを昇り降りする
これを10分程続けるばOK




すると妙な脱力感に襲われ、解脱気分に一日中浸れる


523 :名無しさん@編集中:03/06/14 19:40
TMPGEncの RGB to YUV 変換の問題点
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic10951

524 :名無しさん@編集中:03/06/15 16:10
このスレを読めば読むほど訳分からなくなってきてしまったのでお助け下さい。

GeForce2MXを使っているのですが、AviUtlでオーバーレイ表示すると、しないときに比べ確かに画面が暗いです。
しかしDivXを出力して、これをWMP(オーバーレイ)で再生させるとAviUtlのプレビュー画面(非オーバーレイ)と色味は一致してしまいます。
AviUtlとWMPでオーバーレイの色味が変わることなんであるんでしょうか?
ここまでスレを読んできまして、GeForceではWMP再生時に画像が暗くなると理解してしまったのですが・・・・。


以下の点は確認してみました。
・デコーダの方では色設定を変更していません。
 ・ffdshowでは伸張していません。
 ・DivXデコーダの YUV Extended mode はOFFです。
・DirectXは8.0aです。オーバーレイの設定はデフォルトのままです。
・GeForceのプロパティはすべてデフォルトのままです。
・WMPの画像をPrint Screenしてペイントに貼り付けると真っ黒になりました。

よろしくお願いします。

525 :名無しさん@編集中:03/06/15 17:52
>>524
ソースがなんだかわからんけど
ソース読み込み時にYUY2展開にチェック入ってて
DivX出力時にYUY2圧縮にチェック入ってないんじゃない?

526 :名無しさん@編集中:03/06/15 22:24
>>523
本家はなんやおもろいことしてまんなぁ。


527 :名無しさん@編集中:03/06/16 01:39
あんなテストじゃ判らんよ。
YV12->YUY2補間があって、当然データはコントラストが縮小方向に向かうからね。
何回も繰り返せば元とどんどん違ってきて当然。
補間なしでできるものは現在存在しないから、プログラムできる人じゃないと
テスト自体出来ない。

528 :名無しさん@編集中:03/06/16 01:51
なんだ、GeforceのハードウェアオーバーレイってYC伸張してるのかよ。

529 :524:03/06/16 02:07
>>525
バッチエンコ中だったのでレス遅れましたです。

設定確認してみました。
<コーデックの設定>
・圧縮プログラム DivX Pro 5.0.5 Codec
・YUY2で展開する     ON
・YUY2で圧縮する     ON
・圧縮の設定を保持する ON


ソースは、MPEG2(MTV2000)→AviUtl(m2v_vfp)(BT.601 から伸張)→DivXに出力です。
#「ソース読み込み時にYUY2展開にチェック」ってどこで確認すれば良いんでしたっけ?


こんなんで何かわかりますでしょうか?

530 :名無しさん@編集中:03/06/16 02:27
m2v.vfpをm2v.auiにリネームしてAviUtlフォルダに置きなさい。
入力プラグイン優先度の設定で「MPEG-2 VIDEO File Reader」の優先度を上げておくように。

531 :名無しさん@編集中:03/06/16 05:31
>>524
YUY2ハードウェアオーバーレイだと伸張せずに
YV12ハードウェアオーバーレイだと伸張するとか??

532 :名無しさん@編集中:03/06/16 23:30
>>527=XXX
おまいイイ!ヤシだなぁ

533 :名無しさん@編集中:03/06/16 23:46
>>532
多分皮肉で言ってるのだと思うが……
YV12 と YUY2 では Y の補間なんて発生しないぞ

補間が発生するとしたら U/V (Cb/Cr) だけだし、補間でコントラストが
下がるなんてことは、よっぽど変なコードでない限りありえない

534 :名無しさん@編集中:03/06/17 00:03
>>533
確かに、YV12->YUY2補間では、UVのみだけど、コントラストは下がるよ。
Avisynthで確認済み。

それにTMPGEncだと、一旦RGBに変換するから、
UVの変化がRGB全てに関係してくる。
その後、エンコすれば、Yにも当然影響することは自明。

535 :名無しさん@編集中:03/06/17 02:03
ゲフォ厨のやつ>>524に答えてよ

536 :532:03/06/17 08:28
いややっぱ>>527はイイ!ヤシだって
オレも検証続行しよっと

537 :名無しさん@編集中:03/06/17 16:26
>>524
画面のプロパティの詳細に入ってオーバーレイの色調整しろ

538 :名無しさん@編集中:03/06/17 16:33
ゲフォだけどやっぱり伸張しないよ

539 :名無しさん@編集中:03/06/17 16:44
うちもしない
>>524の環境か目か頭がおかしいんじゃないの?
まぁそもそもDivXの色再現性は低いんだが

540 :名無しさん@編集中:03/06/17 20:04
CCEはRGB->YCbCr変換式を公開してるね。
実際のコードじゃないからその情報に価値があるかは分からんけど。

541 :名無しさん@編集中:03/06/17 21:34
>>540
公開も何もITU-R BT.601-5まんまの変換式だよ
まるもと一緒

542 :541:03/06/17 21:42
TMPGEncも一緒ξ

堀 さん 01/08 (火) 02:45 ( ID:TMPGEnc Net ) [ 編集 / 削除 / 引用して返信 ]
その場合、後者が正しいです。

「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」のオプションは
RGB->YCbCr 変換するときの変換式を切り替えています。

ソースがCCIR601に準拠していない一般的なRGBデータの場合、
  チェックしない:RGB(0-255) を YCbCr(16-235) に変換する式が使われます。
  チェックする :RGB(0-255) を YCbCr(0-255) に変換する式が使われます。

ソースがCCIR601に準拠している場合、
  チェックしない:RGB(16-235) を YCbCr(30-218) に変換する式が使われます。
  チェックする :RGB(16-235) を YCbCr(16-235) に変換する式が使われます。

となります。



543 :名無しさん@編集中:03/06/17 21:53
ソースがCCIR601に準拠しているかどうか、
いったいどうやって判断しているんだ?

544 :名無しさん@編集中:03/06/17 22:19
>>543
堀は日本語が不自由なんだよ
行間を読み取ってやれば
「ソースがCCIR601に準拠しているかどうか」など
チェックしてないことがわかる

545 :CCE:03/06/17 22:23
RGBからYCbCr への変換式は以下の通りです。

“16 から235” を指定した場合
R' = 219R + 16 * 256
G' = 219G + 16 * 256
B' = 219B + 16 * 256
Y = (77R' + 150G' + 29B') / 216
Cr = (131R' - 110G' - 21B') / 216 + 128
Cb = (-44R' - 87G' + 131B') / 216 + 128

“0 から255” を指定した場合
Y = (77R + 150G + 29B) / 256
Cr = (131R - 110G - 21B) / 258 + 128
Cb = (-44R - 87G + 131B) / 256 + 128

いずれの場合も,割り算の結果の小数点以下は切り捨てられます。

546 :名無しさん@編集中:03/06/17 22:53
.pdfって無断転載禁止なはずだが・・・・

547 :名無しさん@編集中:03/06/17 23:53
うーん
うちもゲフォだけどどうも伸張してるっぽい...
ffdshowで伸張すると伸張されすぎてる
こんなこと言ったらここでは村八分ですか?

548 :名無しさん@編集中:03/06/18 00:26
>>547
んじゃ、BSPlayerでハードウェアオーバレイ使ったときと使わないときとで
比較してみたら?

549 :名無しさん@編集中:03/06/18 01:32
ゲフォはゲフォでもチップの型とドライババージョンをはっきりさせたらどうでしょうかね。
VPEで動画機能を強化したコアもあることですし。

550 :名無しさん@編集中:03/06/18 23:09
最新のデトネイターにしてみた
が、
オーバレイ表示だとコントラストがあがったような画になりました
伸張って感じじゃないな
輝度自体は圧縮されたかのように暗くなってる
ゲフォ2MX200・WinXPSP3

551 :名無しさん@編集中:03/06/19 00:32
デジタルバイブランスってやつか?

552 :名無しさん@編集中:03/06/19 00:39
う〜ん、ドライバのバージョンの違いでそんなに挙動が違うとなると、
GeForce はちと恐くて使えんな。この辺、nVIDIAはいったいなにを
どう考えているんだろう…。

553 :名無しさん@編集中:03/06/19 00:47
(カラープロファイル…

554 :名無しさん@編集中:03/06/19 03:28
4月28日(月) 2ch DTV 板 YC 伸張総合スレッド

大体想像がついてる人もいるかもしれませんが、48, 53, 67, 72, 164, 170, 189, 192, 235, 239, 244, 248, 250 は私の書き込みだったりします。それ以外では書いてません。

私は AviUtl の YUY2 出力での飽和処理に気づいてなかった人間だったりするので、214 さんを私扱いすると失礼ですよと。こちらでも確認しましたが、この処理は弁護
の余地がないですね。ここだけでも直して GW 中に 0.98e をリリースして欲しい(SSE2 対応/内部 YUY2 化は後回しでいいから)ところです。

555 :名無しさん@編集中:03/06/19 11:20
そろそろKENくん死亡説がまた流れるころかな

556 :名無しさん@編集中:03/06/19 12:57
以前と違ってAvisynthやVirtualDubのプラグインが進歩してきてしっかりと
使えてきているんで、AviUtlがあのままでもかまわないや。

557 :名無しさん@編集中:03/06/23 04:29
全部読んだ。
キャプ厨ってのはどうしようもない人種だなと思った。
趣味でやってるはずのことを何故もっとハッピーに進められないんだろう?
こういう↓スレを立てる奴の感性は正しいと思う。
http://pc.2ch.net/test/read.cgi/avi/1050071901/l50

558 :名無しさん@編集中:03/06/23 05:49
物事を突き詰めるのに趣味もくそもないでしょ。

559 :名無しさん@編集中:03/06/23 05:55
相手にすんなって

560 :名無しさん@編集中:03/06/23 06:14
趣味はともかく、くそは無いな、確かに

561 :名無しさん@編集中:03/06/23 15:34
>>550
今更だが
WinXPsp3使ってるなんてすごいな!

562 :名無しさん@編集中:03/06/23 21:15
>>561
未来からきたのであろう
ということは未来においてもゲフォはメーカー独自変換なんだな
もう、ラデ厨になっちまおうかな?

563 :名無しさん@編集中:03/06/23 22:34
msyuv.dllのYUV→RGBは伸張処理するようになってるね。

564 :名無しさん@編集中:03/06/23 22:47
>>563
それが普通。
なぜなら基本的にRGB変換というものは再生時、表示時のためのオプションだからだ。
趣味のDTV人口の拡大に伴う複数ソフトへの動画の受け渡しや、
中間ファイルの一般化なんぞ考慮してないからな。

565 :名無しさん@編集中:03/06/24 00:29
つまりゲフォは異端ってことだ

566 :名無しさん@編集中:03/06/24 01:04
DirectX 8.1 YUV Color Space Fix

567 :名無しさん@編集中:03/06/26 23:22
>>566
どこの情報?
つーかなんの??

568 :名無しさん@編集中:03/06/26 23:32
msyuv.dll

569 :名無しさん@編集中:03/06/26 23:37
fixということはそれ以前は伸張しないか俺スケールかだったのか・・・

570 :名無しさん@編集中:03/06/26 23:46
つまりはAviUtlでTV→PCスケール補正で最終保存するとまずいって事?

ノーチェックで保存が当たり前?

571 :名無しさん@編集中:03/06/27 00:33
だから、ソースによるって言ってるだろ。あほんだら

572 :名無しさん@編集中:03/06/27 01:37
>>569
DirectX8のmsyuv.dllは YUV→RGBをRGB16に変換する。
いわゆる msyuvの減色バグと言われてたやつだ。それのfix。

573 :名無しさん@編集中:03/06/27 13:05
>>571
TV→S端子経由→玄人志向SAA-7130→MJPEG
このソースの場合は?

574 :名無しさん@編集中:03/06/27 14:39
>>573
キャプチャする時、どの様に輝度等を調整してるか分からない。
取り込み方がRGB24かYUY2か分からない。
どのMJPEG codecを使ってるのか分からない。
AviutlのMJPEGのcodec設定がRGB24かYUY2か分からない。

575 :名無しさん@編集中:03/06/27 21:25
自作板の自作HTPCスレでBT.601厨が火種をまいてますね。

576 :名無しさん@編集中:03/06/27 21:31
>>575
論破されたバカ?

577 :名無しさん@編集中:03/06/27 21:40
huffyuvで圧縮されたファイルが、yuvで記録されてるか、rgbで記録されてるか、
判別する方法無いですかね。
あとで、エンコードしようとして放置してたら、どんな設定で圧縮したか分からなく
なってしまいまして。

578 :名無しさん@編集中:03/06/27 22:03
AviUtl(0.86d)で読み込んで[その他]->[ファイルの情報]->ビデオ展開形式
でどを?

579 :名無しさん@編集中:03/06/27 22:04
ああそういうことあるね
でもhuffyuvならYUV→RGB時には伸張するから区別できるんじゃ?

580 :名無しさん@編集中:03/06/27 22:05
0.86dって何だよヽ(`Д´)ノ 0.98dだよ

581 :名無しさん@編集中:03/06/27 22:36
>>579
伸張するから同じ画になって区別つかないんじゃ?
伸張しなけりゃぱっと見た目で区別できるよ。

582 :名無しさん@編集中:03/06/27 22:45
>>581

ストレート変換したものと見た目に違いがあるならYUVってそういう意味だったんだけど。
違わないならRGB

583 :名無しさん@編集中:03/06/27 22:55
>>566
ttp://www.doom9.org/Soft21/SupportUtils/dx81-yuv-fix.exe
これでそ?

584 :名無しさん@編集中:03/06/28 00:05
>>582
ストレート変換って?

Huffyuvでは、YUVとRGBで見た目に違いは無い(BT.601伸張変換されるから同じに見えて当然)
(レンジオーバーしてればサチュレートされるから違いは出るけどそれが見てわかるかどうか?)
>>578の言うようにAviUtlかAvisynthでチェックするか

585 :名無しさん@編集中:03/06/28 00:18
>>584
RGBはストレート展開じゃないの?

586 :名無しさん@編集中:03/06/28 00:30
>>585
試してみな。見て分かるか?

>>577
Huffyuvの設定ダイアログの一番下のチェックボックス "Enable console-window logging [use debugging]"
にチェックして、一旦終了。
再度起動して、問題のAVIを読み込めば、コンソールウィンドウが現れて、
 "DecompressQuery: input = HFYU, 16 bits, method 2, output = (null)"
みたいなのが表示される。
この場合は、入力 = Huffyuv 16bit(YUV) method=predict medianを示す。
RGBだったら、24bitになるはず。

587 :名無しさん@編集中:03/06/28 00:43
>>586
試してみたよ。見て分かったよ。
たぶん俺の言いたいことがちゃんと伝わってないだけ

1.動画編集ソフト(たとえばTMPGEnc)にそのままそのAVIを読み込ませてみる
2.そのAVIをConvTo.dllでストレートRGB展開するようにしたAVSを読み込ませてみる
3.1と2を見比べてみて変化があればYUV、なければRGB

588 :名無しさん@編集中:03/06/28 00:51
>>587
あほ。
それじゃAvisynth使えって言ってるじゃんか。
Avisynth使うなら、そんなことしなくたって簡単に判別つくわい。
Dubでavs読み込んで、file information見たって良いし、
ColorYUY2でdebug=3,5で見たって、YUY2のみしか使えないフィルタを追加したって分かる。
方法なんて他にもまだまだ幾つもあるぞ。

589 :名無しさん@編集中:03/06/28 01:03
あほって言われてもなあ
Avisynth使うなって言われてないし
一番簡単な判別の仕方を教えろとか言われてないし…
普段やってることだから全然手間じゃないんだよな俺の場合
TMPG使うから必ずストレート変換するのよ

590 :名無しさん@編集中:03/06/28 20:24
教えてください。現在、LDからDVD-VIDEOへの変換を行っているのですが、
CANOPUS DigitalVideoRecorder+ふぬああにて、

UYVY&huffyuvS->Aviutl(YUY2展開無)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮無)->huffyuvS(ConvertYUY2)->CCEと、してるんですが、これで
あってるでしょうか。

591 :名無しさん@編集中:03/06/28 20:38
>>590
ふぬああの設定が不明
まぁUYVYならレンジは普通のYUVにしていると考えればあってることはあってる
勿論CCEはYUY2読み込みでしょ?
でもhuffyuv(S)キャプでCCEならAvisynthのほうが利口だよ

592 :590:03/06/29 06:28
ふぬああでのレンジ設定って、UYVY以外にいじるところって有りますか?
色調整項目は、MTV系なので、基本的に自動で放置してますです。
あと、CCEはYUY2読み込みさせてます。

以前は、UYVY&huffyuvS->Aviutl(YUY2展開有)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮有)->huffyuvS(YUY2圧縮?)->CCE(YUY2読込?)と、していましたが、
こちらのスレでAviutlで展開圧縮すると、0-15,236-255が切り捨てられるってな話をみて、
590のやり方に変えてみました。

593 :名無しさん@編集中:03/06/29 07:46
せっかくAVIキャプ時は手動で調整できるんだから
できるなら手動で調整したほうがいいと思うけど

594 :名無しさん@編集中:03/06/29 11:39
>>590
このスレをくまなく見れば,そのやりかたではYUV->RGB->YUV処理が入ることがわかるはず
そしてYUV->RGB->YUVには色変換誤差が生じることも・・・
Avisynthにしなはれ

595 :名無しさん@編集中:03/06/29 14:31
>>592
LDからの取り込みで、ノイズリダクションって必要なの?


596 :名無しさん@編集中:03/06/29 15:04
>>595
アナログなんだから当然かけてもいいでしょ

597 :名無しさん@編集中:03/06/29 15:42
アナログだからって意味分かんね

598 :名無しさん@編集中:03/06/29 15:53
>>597
どんなに設備・環境を整えてもアナログ波には必ずS/Nの問題が生じる
ノイズからけっして逃げられないんだよ

599 :名無しさん@編集中:03/06/29 15:58
デジタルならいらないのか?
ああアニメの話か

600 :いんやモーヲタ:03/06/29 16:53
>>599
デジタルならば最終出力形式と好みの問題もあるが

デジタルストリーム記録の場合ソースにあるノイズは送信側に既に存在するノイズ
ソース至上主義ならばデジタル記録はノイズレスということになる
つまりノイズリダクションはいらない
最終出力時にデータを圧縮しやすくするための画像処理はノイズリダクションではなくフィルタリングでしょ


601 :名無しさん@編集中:03/06/29 17:21
>>600
ソース至上主義ならばアナログでもLDからじゃノイズリダクションするべきじゃないと思うが

602 :名無しさん@編集中:03/06/29 17:26
スレ違い。

603 :名無しさん@編集中:03/06/29 17:52
>>601
LDがないならVHSデッキでもいいから同じソースを何度もキャプってみればわかる
ドット妨害の出現パターンは毎回かわる
>>602
無理やりスレの趣旨に近くしようとしてみるテスト
LDキャプチャー(正確にはアナログキャプチャー全般)時に載るノイズをリダクションする一番いい方法は
何度もキャプチャーし、それぞれをブレンドし、逆鼠算的にブレンドを繰り返すこと
この、内容は同一だがノイズの出現パターンの異なる動画のブレンドを繰り返すというフィルタは
Vmakerが作ってて公開してたんだがな
当人もLD->DVD時に有効と書いてたが、
いい加減サラっとフカーツしねーかな
Huffyuvsはどーでもいいから<スレ違い

604 :名無しさん@編集中:03/06/29 18:25
毎回かわるから何

605 :名無しさん@編集中:03/06/29 18:58
馬鹿はレスしなくていいよ。

606 :名無しさん@編集中:03/06/29 19:03
>>603
slave乙

607 :slave:03/06/29 19:04
>>606
どういたしまして

608 :名無しさん@編集中:03/06/29 19:26
何か語り口調が見たことあると思ったら、slaveってあの師匠だったのね

609 :名無しさん@編集中:03/06/29 21:25
>>603
2.52標準のMergeChroma / MergeLumaがその用途のためにある。

610 :名無しさん@編集中:03/06/29 23:20
>>609
お、クスコ!

611 :名無しさん@編集中:03/06/29 23:20
>>601
同じ意見。正直、ノイズリダクションしたら、映像が元ソースと
ちがってしまうのは嫌だ。
綺麗なソースがあるならそのままやったほうがいい。
安いLDプレイヤーなら仕方ないかもしれないけど。

612 :AV機器ヲタ:03/06/29 23:29
>>611
綺麗なソースの定義は人それぞれ。
好きなようにやればよし。
画像も見ずに「LDソースだから綺麗」というのはおかしい。
それにLDプレイヤー(DVDも準ずる)は高ければソースにピュアなわけでもなく。
勿論安いLDプレイヤーがピュアなわけでもなし。
画像なしでは判断できないが、ひとついえることは、
LDプレイヤーのYC分離は総じて糞であり、
それどころかその多くはコンポジット出力しかもたない。
LDソースが綺麗なソースだとはとても思えない。
画像を見なければわからないけどね。
スレ違いなんでsage。

613 :名無しさん@編集中:03/06/30 02:50
>>609
他の使い道

mergechroma(c,blur(c,1.3))
mergechroma(c,fluxsmooth(c,7,7))

614 :名無しさん@編集中:03/06/30 11:59
>>612
LDプレイヤーがコンポジット出力しか持たないのが多いのはその機器の特性上別に問題でもなんでもない。
LDソースが綺麗だと思わないとは・・・・貴公はどんなソースが綺麗だと思うんだ?
あくまで、一般家庭の話ですよ。

615 :名無しさん@編集中:03/06/30 15:58
LD って、コンポジット信号(Y/C混合)で記録されているって
当然知ってて書いてるんだよねぇ?ちみたちは。

>>612
ソースにピュアって話するなら、コンポジット出力だと思うが?

616 :名無しさん@編集中:03/06/30 18:51
LDPによってはコンポジット出力がY/C分離したあと再混合した信号を出力
していたりするけどな。

617 :名無しさん@編集中:03/06/30 19:45
>>615
すまん、LDにS出力があるんだとばかり思ってた。
ごめんなさい。

618 :名無しさん@編集中:03/07/02 04:31
何かどんどんスレ違いに・・。>590に一つ助言すると、LDプレイヤーの
S-端子は確かにあんま性能が良くないことが多い。これは>612の言っている
通りだ。だから、コンポジット出力をS-VIDEOデッキの3次元Y/C分離を
通してS出力すると綺麗になる場合もある。ただしこれは、>616の言う機能を
有したLDプレイヤーの場合、効果は薄い。

619 :名無しさん@編集中:03/07/02 11:49
>>592
Avisynth使えって言ってるだろが ヽ(`Д´)ノ


LDをキャプチャーするスレ
http://pc.2ch.net/test/read.cgi/avi/1051885045/

こちらもよろしく

620 :590:03/07/02 20:19
どうも皆さん助言を頂きありがとうございました。
えと、うちのプレイヤーですが、コンポジット出力は再混合したものが出力される
タイプなんで、S端子で繋いでいます。

で、16-235 <-> 0-255間違ってたら、あからさまなんで確認したかった訳なんですが、
0-15,236-255のためにAvisynthに乗り替えるのもめんどいんで、Aviutlでまったりと
逝きます。

621 :名無しさん@編集中:03/07/02 23:04
本当に、Aviutlもいい加減サチュレートしないバージョンださないかなぁ
Avisynth使うの面倒くさくなってきた

622 :名無しさん@編集中:03/07/03 01:02
つーかこのスレに来たのってAvisynth使うの面倒だからだったんだけど
今やこっちの方がメンドイな

623 :名無しさん@編集中:03/07/03 06:55
AviUtlを貶しているけど、
AviUtlがRGBだったころ(0.97まで)、または、0.98でサチュレートしていることを
知る前までならみんな文句言わずに使ってたよな。
高画質で綺麗綺麗と言って。
サチュレートしているって聞いたとたん、AviUtl使うのは問題だよな、
っていうのはどういうものなのか。

624 :名無しさん@編集中:03/07/03 08:51
そうですね。痛いハイエンドオーディオに現を抜かしてるヤシみたいで
アフォくさいですよね。洩れは綺麗に見えるように自分が納得した
設定にしています。それに、苦労して何時間もかけてエンコードした
ファイルって、HDD の肥やしにしかなってないのが現状だしね〜。

625 :名無しさん@編集中:03/07/03 08:53
後で鑑賞するのが目的なはずなのに、いかに理論に沿って
ソースに忠実にエンコードするかが目的になっちゃってる自分に
ふと気付くと、本当に無駄な時間の過ごし方してる。

626 :名無しさん@編集中:03/07/03 11:38
エンコードそのものに試行錯誤することが快感になってることに早く気付けよ
この板にはそんな人間がいくらでもいるから安心しろって

627 :名無しさん@編集中:03/07/03 12:06
自己満足オナヌィ板(;´Д`)ハァハァ…

628 :名無しさん@編集中:03/07/03 18:29
>>624-625
slaveうぜえ

629 :名無しさん@編集中:03/07/03 20:56
Aviutlの98以降がサチュレートするのは本家BBSでもここのAviutlスレでも
98発表当時問題になってる
「TVスケールとPCスケールつけるからいいでしょ」ってな返答をKENがして
「ちげーよ、色がクロップされるって言ってるんだよ」って突っ込まれてたんだが
「ハァ?BT.601だとこれが正規ですよ、と。おまいの環境のキャリブレートがオカシイカモナー」
みてーな返答でスルーされておった。
意地でも直さないだろうな・・・KEN。

630 :名無しさん@編集中:03/07/03 23:02
>>629
slaveは恐ろしい釣り氏だな。

「そこまでAviutlをおとしめたいのか?」

と思ってAviutlスレ3から6まで読んじゃったじゃねーか。
完全に釣られました。
そんな話はでてきておりません。
途中音ずれの話題でレスが埋め尽くされてたのはワラタが,
あの頃は結構まともに機能してたんだな >Aviutlスレ。

631 :名無しさん@編集中:03/07/04 00:57
似たようなので、YUY2入力するとスケール伸張されるって騒いでたな。
そしたら内部は12bit有効なので伸張されてもクロップされないってマルモがしゃしゃり出たんじゃなかったっけ?

632 :名無しさん@編集中:03/07/04 01:29
aviutlは途中でクリップされないのがいいとこなんだがな
YCCは各12ビット表現だけど出力フレームが確定するまでは16ビットフルに有効だから
(プラグイン作者が想定してるのは13ビット以内のデータだけだろうけど)
YUY2読みしてもYゲインを下げれば範囲外の階調もちゃんと残ってることに気付くよ

avisynthの場合、データは8ビットでしか扱えないから
何かのフィルタで一度飽和させてしまうともう元に戻せないしね
まぁ速いし、YUY2読みしたものをそのままCCEに渡せるから愛用してるけど。。

633 :名無しさん@編集中:03/07/04 01:52
>>632
飽和させるフィルターって何?
ちょっとそれは考えられないけどな。縮小されるフィルターばっかし。
もちろん、色補正関係のフィルターを除いての話。

634 :名無しさん@編集中:03/07/04 03:07
>>632
m2v.vfpでYC伸長してAviUtlに渡すよりm2v.auiでYUY読み込みしたほうが
AviUtlでYUY2のソースをYUY2で展開してYUY2で圧縮する設定なら
RGBのヒストグラムを0-255まで使ってYUY2に圧縮するときに
BT.601の範囲内に収まるYUY2データを残せて良いと理解していいですか?

635 :名無しさん@編集中:03/07/04 05:33
>>634
小一時間悩んだが、俺はお前の言いたいことが理解できない。
日本語勉強しなおしてくれ。

”m2v.auiでYUY読み込みしたほう”
       と
”YUY2のソースをYUY2で展開して”
は同じ意味。
どっちも
"YUY2読み込み”
m2v.vfpだと”RGB読み込み”だからな。

”RGBのヒストグラムを0-255まで使ってYUY2に圧縮するとき”
微妙に意味が通らない。
YUV->RGB変換がストレートだろうが伸張だろうが
”RGBの”のデータは”0-255”。

m2v.auiはMPEGソースを”YUY2展開”する手段。
.d2vやm2v.vfpでは”YUY2展開”できない。
できないということはYUV->RGB変換がはいる。
つまりm2v.auiの利点は
「YUV->RGB変換しないこと」
であり、
m2v.vfpの欠点は
「YUV->RGB変換すること」

YUV->RGB変換の欠点・利点は↑のほうでガヤガヤやっとるんで、
ログ参照。





636 :名無しさん@編集中:03/07/04 22:57
radeonは規格準拠なのがはっきりしたわけだが

> ちなみにRADEONはDTVについてのPDFで
> >RADEON supports any of the color spaces defined by the MPEG-2 standard,
> としている。
> http://mirror.ati.com/developer/atirdv.pdf


637 :名無しさん@編集中:03/07/04 23:12
>>636
はっきりしてないわけだがw

638 :名無しさん@編集中:03/07/05 12:51
こういう言い方はあいまいにするための常套手段だねw。
つか、準拠という言葉自体が。。。

639 :名無しさん@編集中:03/07/05 21:27
MPEG2規格のいかなる色空間もサポートするよ、と。
それはYV12,YUY2,IYU2をサポートするよ、と言ってるだけだろ。
大体このスレで誰も突っ込みが入らないのが不思議なんだが、
BT.601規格にはストレート変換も入っているのだよ。
”BT.601準拠=伸張変換”みたいなレスが多いが
それは間違い。

640 :名無しさん@編集中:03/07/05 22:32
>>639
IYU2ってなに?

641 :名無しさん@編集中:03/07/05 23:44
>>640
24bitYUV4:4:4
ググレよ、これくらい

642 :名無しさん@編集中:03/07/06 00:21
>>639
そんなにムキになるなよ。
ここにいる奴はまるものページぐらいは読んでるって。
BT.601とストレートで十分に通じるぞ。

643 :名無しさん@編集中:03/07/06 00:34
ここって常駐者しかいないのに
新情報なんてロクにないから
初心者がくだらないカキコしないとレスが進まないね
まぁその初心者も常駐はしないだろうし

644 :名無しさん@編集中:03/07/06 00:45
>>643
slave氏ね

645 :名無しさん@編集中:03/07/06 14:31
>>633
実際にはゴーストリダクション系くらいだろうな。
設定値によってはシャープ系でも飽和させれるけど、
そんな設定値使わないだろうし。

646 :名無しさん@編集中:03/07/11 01:19
90さんの書いてることが真実なんだろ。悩むことないよな。

YUV形式の動画 → RGB形式の動画 YC伸張する
RGB形式の動画 → YUV形式の動画 YC圧縮する

で良いんだろ?

あとは使うソフトによって精度が変わるくらいで大した問題じゃないな。

647 :名無しさん@編集中:03/07/11 05:56
>>646
残念ながら>>90に書いてあることは真実ではない
でも、二重伸張や二重圧縮に比べたら
YUV<->RGB変換誤差やサチュレートなんてたいした問題ではない

648 :名無しさん@編集中:03/07/11 10:31
>>647
> 残念ながら>>90に書いてあることは真実ではない

真実ではないのはどういう点なんだい?

俺がひとつ疑問かなぁと思ったのはキャプチャーで出来るMPEGはTVスケール
(16-235)で間違いないと思うんだけど、hunuaaなんかでhuffyuv圧縮(yuv形式)
で取り込んだAVIもTVスケール(16-235)なのかなぁっていう点。個人的には
RGBをYC圧縮なしにRGB>YUV変換してるような気がするのでPCスケール(0-255)
のような気がする。

とすれば、90さんの言うYUV系:TVスケールっていうのもあながちそうでもない
ということになる。


649 :名無しさん@編集中:03/07/11 10:54
お前ら、どっちでもいいんだよ。綺麗に見える方。これ最強。理屈などいらぬ!

650 :名無しさん@編集中:03/07/11 10:55
またあふぉがきた

651 :名無しさん@編集中:03/07/11 11:33
TVスケールとかPCスケールとかいう言葉に納得がいかない

652 :名無しさん@編集中:03/07/11 11:36
>>650
DTV なんか究極の自己満足じゃねーかよ。
自分が良ければ、それでOKだろう。

653 :名無しさん@編集中:03/07/11 12:32
650は648へのレス


654 :名無しさん@編集中:03/07/11 13:10
>>653
了解

655 :名無しさん@編集中:03/07/11 16:27
結局あれだろ?各動画フォーマットが

full-range RGB [0,255]
compressed-range RGB [16,235]
full-range YUV [0,255]
compressed-range YUV [16,235]

のうちどれを使ってるか把握出来てれば問題ないんだろ?あとは些細な精度の問題で。

656 :名無しさん@編集中:03/07/11 20:49
>>655
動画フォーマットがどっちのスケールを使うかということより
動画系アプリがどういう設定のときどっちのスケールを使うか?が問題。
それによって出力された動画のスケールが決定されるから。

657 :名無しさん@編集中:03/07/11 20:54
わけわからん

658 :名無しさん@編集中:03/07/11 21:09
>>655
>>317が正解
ただYUV<->RGB変換誤差が些細な問題かどうかは
>>381を御覧あれ


659 :名無しさん@編集中:03/07/11 21:43
そもそもMSがちゃんと動画フォーマットの仕様決めないからこんなことに
なるんだな。

WIN上で扱うRGBはすべてfull rangeに汁!YUVはすべてcompressed rangeに汁!
Video Cardはオーバーレイ使う時はHWでYC伸張汁!ってすれば無問題なのにな。

660 :名無しさん@編集中:03/07/11 21:48
>>659
基本的にはそうなっているっしょ。問題はそれを無視する腐れアプリ・codec・
グラフィックカードがあるってこと。

661 :名無しさん@編集中:03/07/11 21:52
>>658
まぁね。些細な問題じゃない人もいるわな。そのへんは個人の価値観ってことで。
俺はYC伸張や圧縮を二重にかけたりしさえしなけりゃそれでOKって思える人間
だからなぁ。

ノイズやアルゴリズムの計算上の誤差なんてのはこだわりだしたらきりがない
からな。それこそ最終的にはソース見せろや、ごるぁってところまでいかないと
ほんとの信用なんて出来ない訳だしな。w

662 :名無しさん@編集中:03/07/11 21:55
>>660
腐れグラフィックカード;ゲフォ

腐れアプリと腐れCodecって何がある?

663 :名無しさん@編集中:03/07/11 22:04
腐れアプリ:Avisynth厨が言うところのAviUtl

664 :名無しさん@編集中:03/07/11 22:36
腐れCodec:HuffyuvS厨が言うところのHuffyuv


665 :名無しさん@編集中:03/07/11 22:38
腐れアプリ:内部RGBのTMPGEnc
腐れコーデック:いわずもがなのHuffyuvSとHuffyuvのconv->yuy2
腐れ仕様:VFAPI


666 :名無しさん@編集中:03/07/11 22:45
>>661がどうやってるのかは知らない
ただよくやる以下の手法は
正直どう見ても色がかわる
DVD2AVI->.d2vでAviutl->Huffyuv(YUY2)中間ファイル->TMPGEnc
↑こんなことしといて
「エンコードって色が変わるねぇ」
いわれてもさぁ・・・
いや、エンコードによる色変わりは当然あるけど
それ以上の問題があるだろ?
まぁ手順の問題というか
目の問題というか

667 :名無しさん@編集中:03/07/11 22:49
腐れcodec:WMV9のインターレース

668 :661:03/07/12 01:07
>>666

俺の手順は

hunuaa(huffyuvキャプ、YUY2)→AVIUTLで編集(フィルタ類は一切使わず、
カット&ペーストのみで再圧縮なしで保存)→WME9でインタレエンコ

VGAはG450、AVIUTLも再圧縮なしだと高速だし、TV出力してもモニタで見ても
同じように見えるし、俺的には画質も無問題。

669 :名無しさん@編集中:03/07/12 02:08
>>668
ある意味理想かも知れないね。
キャプチャ時の設定がジャストミートしてればさ。
でもNRぐらい掛けたら?(インタレを壊さないNRってことだけど)

670 :名無しさん@編集中:03/07/12 02:10
インタレを壊すNRって何?

671 :名無しさん@編集中:03/07/12 02:30
>>669

時間以外はそれなりに満足してるんだけどね。いろいろ試行錯誤して結局
こうなったんだよな。

220GBほどHD用意してるけど3時間ちょっとしかキャプ出来ないんで
録りだめは出来ないね。w

672 :名無しさん@編集中:03/07/12 02:36
こっちでももめてる
http://pc.2ch.net/test/read.cgi/avi/1044370473/909-

673 :名無しさん@編集中:03/07/12 02:40
>>670
上下に隣接している点を考慮するNRはインタレ構造を壊すことが分からんか?
たとえば、P(x,y)=( P(x,y) + P(x,y-1) + P(x,y+1) + P(x-1,y) + P(x+1,y) ) / 5
なんてのなら、ライン間でブレンドされるだろが。

674 :名無しさん@編集中:03/07/12 02:44
>>672
RGBで253ってのはまあ妥当じゃないの?
べつにこんなのじゃもめないよ。

675 :名無しさん@編集中:03/07/12 09:32
>>659
PCで完結してもダメなのよ

676 :名無しさん@編集中:03/07/12 11:59
またアフォが一人現れたな >675

677 :名無しさん@編集中:03/07/12 12:04
やっと理解できた。みなさんありがとう。

678 :名無しさん@編集中:03/07/12 12:26
>>675
この人言ってる意味不明、恐らく何も分かってないと思われ。

659で触れてる規格はむしろ映像業界のフォーマットに後発のPC側が
合わせた結果であって別にPCで完結しようとしてる訳ではない。

679 :名無しさん@編集中:03/07/12 13:45
678必死だな(藁

680 :名無しさん@編集中:03/07/12 13:52
679 名前:名無しさん@編集中[sage] 投稿日:03/07/12 13:45
678必死だな(藁

681 :名無しさん@編集中:03/07/12 16:02

◆◇◆◇ 海外サイトだから安心無修正 ◇◆◇◆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html

 ↑ 
ココは丸見え! 今ならまだ消されてないよ。たぶん・・・

682 :名無しさん@編集中:03/07/13 20:52
242 :名無しさん@編集中 :03/07/13 16:52
>>240
本当は可逆圧縮より圧縮しないで良いならそのほうが良いが、
MPEGからなら普通Huffyuv を使うという事。
元の情報よりHuffyuvにした時点で少し劣化する。



243 :名無しさん@編集中 :03/07/13 17:21
>>242
若干わかりにくい文章かも。


244 :名無しさん@編集中 :03/07/13 17:30
>>242
Huffyuvってハフマン符号化だけじゃないの?だとしたら劣化しないはずだけど。




683 :名無しさん@編集中:03/07/13 20:52
245 :名無しさん@編集中 :03/07/13 17:36
>>242
中間ファイルなんだろ?
”圧縮しないで”ってなんだ?
MPEGソースなら非圧縮YUY2か?
MPEGソースの非圧縮YUY2とHuffyuv(YUY2)は同等だよ。
MPEGソースを非圧縮RGBにしたりHuffyuv(RGB)にしたら
どっちも劣化するけどな。


246 :名無しさん@編集中 :03/07/13 17:52
可逆圧縮の意味もわからんヤシが回答するのか

(回答者も)初心者質問スレッド 27 だな



247 :名無しさん@編集中 :03/07/13 18:03
わからんやつや246を見習って傍観


248 :名無しさん@編集中 :03/07/13 18:08
そのソースMPEGがYUV4:4:4の場合にかぎり
何選んでもHuffyuv化するときに少し劣化する。
でもYUV4:4:4のMPEGって仕様書にはあるけど、
作れないし見たこともない。


249 :名無しさん@編集中 :03/07/13 18:31
MPEGソースは非圧縮じゃない。


684 :名無しさん@編集中:03/07/13 20:53
251 :名無しさん@編集中 :03/07/13 18:40
AVI(YUY2)を編集後に中間ファイルを出して
その後DIVX化する場合にHuffyuv(YUY2)でやると
元のAVI(YUY2)よりサイズが小さくて明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。


252 :名無しさん@編集中 :03/07/13 18:47
???


253 :251 :03/07/13 18:48
修正。AVI(UYVY)


685 :名無しさん@編集中:03/07/13 20:54
255 :名無しさん@編集中 :03/07/13 19:35
>>251
カラーフォーマットの変換による色(色差)情報の劣化と、圧縮形式による情報の欠落を
ごっちゃになっているような。
通常、圧縮による劣化の有無は、カラーフォーマットの変換を含めないで話した方が
いいんじゃないだろうか?



256 :名無しさん@編集中 :03/07/13 19:40
>>251
もとのAVI(UYVY)はどうやって生成した?
その編集とやらはVirtualDub系のFastRecompresなのか?



257 :名無しさん@編集中 :03/07/13 19:42
>>255
同意。
ハフマン符号化して劣化するなら、世のプログラムは圧縮した段階で
正常に動作しなくなりなります。


686 :名無しさん@編集中:03/07/13 20:54
259 :名無しさん@編集中 :03/07/13 19:44
釣りだろ
”元のAVI(YUY2)よりサイズが小さくて明らかに劣化がわかる”
とかほざいてるし
”.zipは元の.exeよりサイズが小さくて明らかに情報欠落がわかる”
と言ってるようなものだ


260 :名無しさん@編集中 :03/07/13 19:51
UYVYであってもAvisynthでマクロピクセルパックをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。
Huffyuvに渡される以前で変換誤差がでるようなやり方をしてると勿論ダメ。
DUBのFullやAviutl,TMPGEncのAVI出力などは
Huffyuvに渡される前に情報劣化がおきる。


261 :名無しさん@編集中 :03/07/13 20:02
環境が不明だが、
>>251のやり方では以下のような減少がおこる

AVI(UYVY)を編集後に中間ファイルを出して
その後DIVX化する場合にAVI(UYVY)でやると明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。

687 :名無しさん@編集中:03/07/14 20:13
また、やってる・・・

688 :名無しさん@編集中:03/07/14 20:26
358 :名無しさん@編集中 :03/07/14 19:32
>>261
AVI(UYVY)で撮ったならhufにしないほうが結果はいい。
自分の環境ではAVI(YUY2)でも撮れるが、その場合はhufにしても劣化はない。
要するにYUY2よりUYVYのほうがはっきりわかるほど綺麗なんですよ。UYVYで
プレミア編集後無圧縮で書き出してdubでDIVX化するのでhufにする必要はない。

364 :名無しさん@編集中 :03/07/14 20:08
>>358
YUY2とUYVYデータ順列以外の違いはない
ただしキャプチャーボード上のチップや編集ソフトなどがネイティブUYVYの場合
YUY2キャプチャーやYUY2吐き出しを行うとソフトウェア処理による
UYUV->RGB->YUY2変換が行われる
結果的にYUV<->RGB変換誤差がおこる

似たような現象にYUY2ネイティブキャプチャーボードによるRGBキャプチャーがある
大概ふぬああ+Huffyuv(RGB)でおこなうことになるが
これはキャプボがYUY2でキャプチャーし、ソフトウェアでYUY2->Huffyuv(RGB)にリアルタイムでしてるだけ
RGBネイティブキャプチャーとは画質が全然異なるばかりか
そのキャプボのネイティブYUY2より劣化したRGBになる

キャプチャーボード、編集ソフト、エンコーダ、フロントエンド、codecなどの
ネイティブ色空間を把握しておくことが大切である


365 :名無しさん@編集中 :03/07/14 20:23
>>358 >>364
ウザい。↓でやれ。

YC伸張する?しない?総合スレッド
http://pc.2ch.net/test/read.cgi/avi/1050299614/


689 :251:03/07/14 20:44
ネイティブUYVYです。

690 :名無しさん@編集中:03/07/14 20:46
>>689
omaedareda?

691 :名無しさん@編集中:03/07/14 20:50
ネイティブUYVYだからRGB変換誤差がおこる だから
hufにしない。で間違ってないじゃん。

692 :x:03/07/14 20:52
◎無修正画像をご覧下さい◎2日間無料です◎
http://yahooo.s2.x-beat.com/linkvp/linkvp.html

693 :名無しさん@編集中:03/07/14 21:14
>>691
ネイティブUYVYでも
”UYVYであってもAvisynthでマクロピクセルパックをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。”
ってのはどうよ。
つーか
”AvisynthでマクロピクセルパックをYUY2に正常化”
ってなんじゃ?

694 :山崎 渉:03/07/15 11:08

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

695 :名無しさん@編集中:03/07/15 18:36
Huffyuvの対応色空間
YUY2、UYVY、RGB24、RGB32(RGBA)

UYVYもそのまま圧縮可能だよ。

696 :名無しさん@編集中:03/07/15 19:50
>>695
じゃぁAvisynthがUYVYに対応しないってことか?


697 :名無しさん@編集中:03/07/15 20:12
>>696
AvisynthはYV12かYUY2かRGB32にしか対応しとらんやん

698 :名無しさん@編集中:03/07/15 20:35
>>697
それはフィルタの話でしょ?
I420でもswapUVでYUY2にできるわけだから。
でも”AvisynthでマクロピクセルパックをYUY2に正常化”は不可能?
Directshowで読めるならYUY2に変更して展開するんかな?
UYVYの動画がないんでよくわからないんだが。

699 :名無しさん@編集中:03/07/15 21:30
>>698
それは見た目がYUY2だからだろ。Avisynthは基本的にコーデックがYUY2に展開して
くれないと話にならん。


700 :名無しさん@編集中:03/07/15 21:46
Avisynth2.52でUYVY試してみた。
無圧縮UYVYの場合、RGB32にdecompressされた。(vidc.UYVY=msyuv.dll、huffyuv.dllとも)
Huffyuv(UYVY)の場合、YUY2にdecompressされた。
どうやら、Huffyuv(msyuvも同様)は、UYVYでdecompressQueryすると、RGB32/24を返すようだ。

701 :名無しさん@編集中:03/07/15 21:51
>>699
UYUVの見た目はYUY2なんだが

702 :名無しさん@編集中:03/07/15 22:03
>>700
おお!クスコ。


703 :700:03/07/15 23:34
Huffyuvのソースをちょっくら覗いてみた。
DecompressQueryで、
intype=-1(HFYU)の場合、outtype=1(YUY2),3(RGB24),4(RGB32)の時、ICERR_OKを返す。
intype=-2(RGB24),1(YUY2),2(UYVY)の場合、outtype=3(RGB24),4(RGB32)の時、ICERR_OKを返す。
intype=-3(RGB32)の場合、outtype=4(RGB32)の時、ICERR_OKを返す。
それ以外はICERR_BADFORMATを返す。

つまり、UYVYはHuffyuv圧縮すると、-1(HFYU)になり、decompressはYUY2、RGB24,RGB32のいずれかのみ。
UYVUが何時YUY2になるのかみると、既にcompress時にswapされてYUY2となってHuffyuv圧縮されちゃってるよ。
Avisynthは、DecompressQueryを、YV12,YUY2,RGB32,RGB24と発行してOKが帰ってきた色空間でDecompressBeginを発行している。

以上のことから、Huffyuv(UYVY)はHuffyuv(YUY2)と同じと思って良い。
無圧縮UYVYは、この色空間を取り扱えるソフトが無く、RGB24/32に変換されるので使用しない方が良い。
ということになる。

704 :700:03/07/15 23:37
間違い訂正
intype=-2(RGB24) -> intype=-2(HFYU(RGB24))
intype=-3(RGB32) -> intype=-3(HFYU(RGB32))

705 :名無しさん@編集中:03/07/16 23:19
>>703
VirtualDubでもダメかな?
Dubに非圧縮UYVY読ましてFastでHuffyuvにしちゃえば
あとはやりたい砲台なのでは?

706 :名無しさん@編集中:03/07/17 20:59
落ちるには惜しいスレ

707 :名無しさん@編集中:03/07/17 21:37
VirtualDubで非圧縮UYVY読ましてからDivxにしてる。
間にHuffyuv入れる事はない。というかVirtualDubで
取り扱えるんじゃないの。自分はHuffyuvにすると
容量3パーセントほど減って重くなるし、コーデックHuffyuvのAVIで
撮ってもそう。

708 :名無しさん@編集中:03/07/17 21:44
UYVYを展開するのはmsyuv.dllじゃないの?


709 :名無しさん@編集中:03/07/17 21:45
VirtualDubはfast recompressでもYUY2/RGBじゃないと入力できないはずだけど。

710 :名無しさん@編集中:03/07/17 22:11
YUY2で撮るとさらに汚いけど…

711 :名無しさん@編集中:03/07/17 22:34
>>710
>>688

712 :名無しさん@編集中:03/07/18 00:43
>>710
http://pc.2ch.net/test/read.cgi/avi/1050299614/566-

713 :名無しさん@編集中:03/07/19 03:06
ゲフォ厨発見

622 :名無しさん@編集中 :03/07/17 03:59
>>619
PCのモニタで見てない?
TVに出力すればちゃんとしたメリハリの効いた画になってるはず。
PCモニタでTVと同じ画を表示しようってのは絶対無理。


714 :名無しさん@編集中:03/07/19 03:40
>>713
いやあ、どんなビデオボードでだってTVと同じには表示できんよ。
TVとPC画面を2つ並べて見比べてごらんよ。

715 :名無しさん@編集中:03/07/19 10:23
蛍光体の違いはあるからTVと同じように表示するのは難しいことは確か。
でも、蛍光体の違い以前にTVのキャリブレーションがまったくされていない
ため、見栄えが違ってくる場合がほとんど。TVはRed Pushしたりガンマ補正
したりと、原信号を思いっきり歪めて表示していることが非常に多い。

716 :名無しさん@編集中:03/07/19 10:35
民生用TVで動画見てるやつは知障

717 :名無しさん@編集中:03/07/20 21:39
スレ読んでたら混乱してきたのでちょっと質問。
canopus DV codecのソースを最終的にDVD化するという話です。

1. キャプってcanopus DV codecのソースを用意する。
2. Aviutlで「YU2展開」のチェックボックスを外して開く。
3. 波形表示フィルタで16-235の範囲になるように色・輝度調整。
4. ノイズ除去とかしたかったら各フィルタ設定。
5. 「YUV2圧縮」のチェックボックスを外した状態でcanopsu DV codecで中間ファイルを作る。
6. Avisynth挟んでColorYUY2でinterpolationtion使って4:2:2補完してCCEに渡す。
7. CCEは16-235でMPEG2ファイルを作る。後、オーサリング&焼き

こういう手順で良いのですかね? 
近々カノプDVを使ったキャプに乗り換える予定なのです。
何か間違いがあれば指摘してください。


718 :名無しさん@編集中:03/07/20 22:51
なんか難しいことやってるなぁ。

YUY2で展開/圧縮をオフるとRGBになっちゃうからオンの方がいいと思うぞ。
それから、YC伸張プラグインを使ってAviUtl上でyuv411>422補完、とか
Avisynth上でフィールド別処理のcolorYUY2で411>422補完→avsinp.auiを使ってAviUtlにわたす、とか
すれば処理が少なくてすむかな。
あとは中間吐くなりVFAPI Reader CodecつかうなりでCCEに渡すと。
最後までyuvでいきたいなら中間つくった方がいいのかな。
中間出力するならDVよりHuffyuvかLCLのほうがいいよ。

俺もあんまり詳しくないんで間違ってるかもしれんけど。

719 :名無しさん@編集中:03/07/20 23:11
>>717
ちょっとその方法はひどすぎ
大体ソフトウェアでCanopusDv化しようとすると9分くらいしかできないよ
参照CanopusDvCodecはハード専用
それ以上にフィルタ>DVcodecっじゃひっでぇ画になる

オレもDV厨だが
1,canopus dv codecのソース用意
2,AviutlでYUY2読み込み
3,YC伸長フィルタで補完
4,各種フィルタ
5,Aviutlでは出力しない
6,ソースをAvisynth+VirtualDubで読み込み
7,Convert411to422使用
8,AviutlFilterPluginで4,の結果をスクリプト化
9,VirtualDub(Fast)にてHuffyuv(YUY2)出力
10,CCEにyuy2読み込みさせてエンコード

まどろっこしいけど
色調をフローさせず
なおかつ自分好みの色合いにして
しかもYUV<->RGB変換せずに
Aviutlのフィルタを使う方法です。


720 :名無しさん@編集中:03/07/20 23:20
>>718
なるほど、今YC伸張フィルタ落としてきたところです。
中間ファイル作るのもいいけど、HDDに余裕あるわけでもないので、
最後だけVFAPI経由でCCEに渡して16-235でエンコすることにします。

何にしても、波形表示フィルタでヒストグラム見ながら、
おかしなことにならないように確認していこうと思います。
ありがとうございました。

721 :名無しさん@編集中:03/07/20 23:31
>>720
Avisynth2,0系なら.avsそのままCCEにもってけるよ
VFAPIになんぞせんでもよろしい

722 :名無しさん@編集中:03/07/21 00:13
>>719
YC伸張フィルタを使用したのに、Avisynthでも伸張?補完?するのは何故ですか?
あと、AVIUTLからAvisynthへの持っていき方がわからないです。ソースを読み込むとか....

というか、Avisynth使ったことないのでさっぱりな自分があかんのですけど。
もうすこし解かりやすい説明をして頂けないでしょうか。

723 :名無しさん@編集中:03/07/21 00:47
>>722
AvisynthのAviutlFilterPluginは
Avisynth上でAviutlのフィルタを使うプラグインなんだけど
なんせスクリプトだから数値を変化させても動的に画質をチェックしにくい
だからAviutl上でいっかいフィルタの各設定値を煮詰めておいて
その数値をAvisynthのスクリプトに書き写してるんだよ
だから”5,Aviutlでは出力しない”
Aviutlは設定を決めるために使ってるだけ

724 :名無しさん@編集中:03/07/21 00:47
>>722
説明求めるまえに自分で調べるようにしろよ…。そんなんじゃ、いつまでたっても
厨のまんまだぞ。

725 :名無しさん@編集中:03/07/21 00:48
>>722
とりあえずAvisynthスレからにーやんのページにいってみな
くれぐれもAvisynthスレでそんな質問せんほうがいいぞ

726 :名無しさん@編集中:03/07/21 00:51
いや、すんません。頑張ってきます。

727 :名無しさん@編集中:03/07/21 01:03
>>723
具体的にどのフィルターをAviutlFilterPluginで読み込んでる?
できればAvisynthだけで完結したいんだけどwavelet系が弱いからまだAviUtlフィルター手放せないんだよなぁ。

728 :名無しさん@編集中:03/07/21 01:18
>>727
WaveletTYPEG,3DNR2,リンギング低減,視聴覚感度ぼかし
あとはAvisynthのフィルタを使ってる
てか、スレ違いでない?

729 :名無しさん@編集中:03/07/21 19:17
>>717
430見れ

730 :名無しさん@編集中:03/07/28 23:51
1から読んだけど全然わからん。

結論を書いては貰えませんか?
普通にキャプって、普通にエンコする場合どうすればいいんです?
ふぬああとかHuffyuvとかややこしい物は使いません。

731 :名無しさん@編集中:03/07/29 01:16
>>730
結論?
自分の環境と目的と同じ物を探せばいいだろうが

732 :名無しさん@編集中:03/07/29 05:55
>>730
お前がキャプしてる方法が世界標準とでも思ってるの?
何だよ普通にキャプって・・・。

733 :名無しさん@編集中:03/07/29 07:37
そもそもふぬああやHuffyuvを使わない普通じゃない方法ってあるのか?
思いつくのはDVDレコやDVやD-VHS使う方法くらいだが。
何も考えずMPEG2→MPEG1みたいなことじゃないのか?

734 :名無しさん@編集中:03/07/29 08:58
何も考えないにしてもどーゆー手順でどーゆーソフト使ったか
わからんとどーにもならないわけで

735 :名無しさん@編集中:03/07/29 15:20
730じゃないですけど、松下のDMR-E80Hで録画したものを、
DVD2AVIとTMPGEncでVCD・MPEG2・Divx等にエンコードする時はどうすればいいんでしょう?

736 :名無しさん@編集中:03/07/29 15:41
>>735
エンコの仕方勉強して出直してこい

737 :名無しさん@編集中:03/07/29 17:25
MPEG2-TS → DVD2AVI → Avisynth → CCE → DVD
この場合ですが、AvisynthにColorYUY2(levels="709->601")と入れておくと良いんでしょうか?

DVD2AVI1.77.3、Avisynth2.52、MPEG2Dec3を使ってます。

738 :735:03/07/29 21:12
>>736
あ、エンコの仕方は知ってます。
YC伸張のことです。

739 :名無しさん@編集中:03/07/29 21:28
色が薄いと思ったら伸張すれ
ちょうどいいと思ったらしない
それだけだ


740 :名無しさん@編集中:03/07/30 00:00
イジワル

741 :名無しさん@編集中:03/07/30 05:02
>>737
MPEG2-TSだからといって、必ずしもBT.709とは限らないよ。SDならBT.601だし。

742 :名無しさん@編集中:03/07/30 12:33
>>741
HDの時だけですか?

743 :名無しさん@編集中:03/07/30 14:25
HDってプログレだけだっけ?

744 :名無しさん@編集中:03/07/30 20:50
DOS/V magazine で 動画の表示比較記事があったが
nVIDIAはGeforceFXになっても、ATIやMatroxやS3とは明らかにスケールの取り方が違うことが分かったよ。

745 :名無しさん@編集中:03/07/30 20:57
nVIDIAもうだめぽ

746 :名無しさん@編集中:03/07/30 20:57
>>742
そ。

>>743
普通1080iだからインターレース。

747 :名無しさん@編集中:03/07/30 23:35
>>746
じゃYV12の色空間だったら
ColorYUY2(levels="709->601",interlaced=true)
が良いのだろうな。

748 :名無しさん@編集中:03/07/31 00:01
マジで??

749 :名無しさん@編集中:03/07/31 09:20
720p

750 :名無しさん@編集中:03/07/31 14:56
720pの時にfalseなんでつね

751 :名無しさん@編集中:03/07/31 15:27
Interlaced指定は、YUY2なら気にしなくてよいぞ。

752 :名無しさん@編集中:03/07/31 15:59
720pってBS朝日で1回放送しただけなんだっけ。以前、地上デジタルでは720pなんて
話があったけど、結局1080iになったみたいだし。

753 :ぼるじょあ ◆yBEncckFOU :03/08/02 05:04
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

754 :名無しさん@編集中:03/08/03 22:43
これで見たらSDのおね2はBT.709だったが。
TS>PS変換しただけなら変わらないよね?
http://www.sakurachan.org/soft/mediatools/index.html


755 :名無しさん@編集中:03/08/03 22:45
直リンしてしまった。ごめんなさい。

756 :名無しさん@編集中:03/08/03 23:36
>>754
webでも情報が錯綜していてよくわからないんだよ
BSDハイビジョン(1080i)はBT.709は確定なんだが
他の解像度についてはマチマチで


757 :名無しさん@編集中:03/08/04 06:19
美少女コスプレイヤーのパンチラと
パイパンおまんこが見れるサイトを発見でつ!!!
http://plaza16.mbn.or.jp/~satchel/idolno_omanko/

パイパンおま○こは本当に美しい… (*´∀`*)ハァハァ


758 :_:03/08/04 06:30
http://homepage.mac.com/hiroyuki44/

759 :名無しさん@編集中:03/08/05 06:32
NHKに問い合わせりゃいいじゃん。

760 :名無しさん@編集中:03/08/05 10:33
>>759
そんなことしたらデジタルコピーしてることがバレるじゃんか。
犯罪者は犯罪を犯しているという自覚を持ってないとボロがでるぞ。

761 :名無しさん@編集中:03/08/05 12:50
おかしな知障が何か言っております

762 :名無しさん@編集中:03/08/05 13:23
高ビットレートMPEG2からDVDサイズのMPEG2への変換における
カラースケールの設定について詳しく、しかしなるべく簡単に
説明をお願いします。
過去ログ嫁とかはなしで。
次からテンプレにできますしね。

763 :名無しさん@編集中:03/08/05 13:27
おかしな知障が何か言っております

764 :名無しさん@編集中:03/08/05 13:49
夏真っ盛り

765 :名無しさん@編集中:03/08/05 14:04
>>762
1から嫁
答えはすぐそこにある

766 :名無しさん@編集中:03/08/05 15:05
>>765
自分でレスしてるんだから気付けよ。

テンプレ化しないから、
>>762 → >>765 のようなやり取りが繰り返されることになる。
(テンプレ化しても質問するアホはたまにいるけど)

767 :名無しさん@編集中:03/08/05 15:12
     ///////
    ///////____________
    ///////  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| ̄ ̄
   ///////              (~) チリンチリン
   ///////              ノ,,
  ///////     ∧_∧         / ̄ ̄ ̄ ̄ ̄ ̄
  ///////     ( ´∀`)( 厨 ) )) <  夏だなあ〜
 ///////      (つ へへ つ      \______
///////   //△ ヽλ  ) ) 旦
//////  l ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄l
/////    ̄| .| ̄ ̄ ̄ ̄ ̄ ̄ ̄| .| ̄
////     ^^^          ^^^

         2chの夏。厨房の夏。

768 :名無しさん@編集中:03/08/05 15:26
>>766
じゃおまえがやれば

769 :名無しさん@編集中:03/08/05 19:18
というわけで最強のテンプレ案↓

770 :master:03/08/05 19:31
YC伸張はどんなとき必要か?
多数のアプリを経由したときのスケールはどうなるか?
などなど
codecどころかVGAチップまでもがYC伸張する昨今
混乱を極めたスケール変換についての総合スレです
参考資料

http://www.studiomilk.com/ichigomilk/diary/orenatsu2opdemo.swf

771 :名無しさん@編集中:03/08/05 19:43
>>770
お前、楽しい?

772 :名無しさん@編集中:03/08/05 20:29
>>762
すべてYUVで処理する。
そうすればカラースケールなど無関係。
君もAvisynth+CCEの世界にきなさい

773 :名無しさん@編集中:03/08/05 23:50
slaveがスネちゃったからテンプレ化は無理だろうな

774 :名無しさん@編集中:03/08/06 03:53
ビデオカードでGEフォースを使ってるのですが、
そのためにWMPで再生したときオーバーレイを切らないと
暗くなってしまいます。
オーバーレイを切らずに暗くしない方法ってありますか?

あと、今、WIN2kを使ってるのでわからないのですが、
将来WINXPで60fps再生したとき、オーバーレイを有効にしないと
できないと思うのですが、そのときも暗くなってしまうのでしょうか?

775 :名無しさん@編集中:03/08/06 04:29
>>774
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

これ読んでモニタとデスクトップガンマを調整する、か
ffdshowをRAW ModeにしてLevalsで調節するか、か
Radeonを買うか。

776 :775:03/08/06 05:24
Levelsね

777 :slave:03/08/06 05:41
HTTPの知識もないし
自分が使わないパターソはよくわからないし
大体あの実験をやる気が・・・
Vmaker氏のページをファイル化しとくべきでしたね
誰か保存してないんでしょうか?

778 :名無しさん@編集中:03/08/06 11:55
ttp://www.archive.org/にもなかったな。。。

779 :名無しさん@編集中:03/08/06 12:01
持ってるけど、どうしよう。いる?

780 :名無しさん@編集中:03/08/06 14:15
>>779
おながいします

781 :名無しさん@編集中:03/08/06 16:54
>>779
頼む

782 :名無しさん@編集中:03/08/06 18:25
>>779
よきにはからえ

783 :名無しさん@編集中:03/08/06 18:38
>>779
BlendClips (Avisynth plugin)
CutOff (Avisynth plugin)
もありますか?

784 :名無しさん@編集中:03/08/06 19:20
>>779
兄貴って呼んで良いですか?

785 :slave:03/08/06 21:21
>>779
是非!是非!!

786 :779:03/08/06 21:46
すいません、しばらくPCの前から離れてたもんで、、、

ていうか、本当にconvlist.htmlでいいんですよね?
なんかとんでもないボケをかましているような気がしてきました。。。

>>783 残念ながら見あたりません。
自分が持っているのは、ブラウザの履歴によると、2003年4月28日にアクセスしたときの
もののようです。チョット古い?

787 :slave:03/08/06 22:07
>>786
個人的にはconvlist.htmlだけで結構です

788 :名無しさん@編集中:03/08/06 22:08
できればwakamelist.htmlもお願いしたいのだが。

789 :名無しさん@編集中:03/08/06 22:12
convlist.htmlはすぐにでもうpします。

>>788
探してみます。履歴にはアクセスした形跡があるんだけど、ものが見つからない。。

790 :名無しさん@編集中:03/08/06 22:17
勝手にうpしてもいいの?

791 :名無しさん@編集中:03/08/06 22:24
うpしました。

http://up.isp.2ch.net/up/921f8fd5d0ef.zip

2chうpろーだなのでお早めに。。

792 :slave:03/08/06 22:36
>>791
いただきました
ありがとうございました

793 :名無しさん@編集中:03/08/06 22:41
>>788

ブラウザはネットスケープを使っているのですが、
ブラウザがクラッシュした時に、キャッシュも吹っ飛んでしまったみたいです。
保存しておけばよかった。。すいません(T T)

794 :名無しさん@編集中:03/08/06 22:43
>>793
すいません。
コンブとワカメをかけた、ただのダジャレで
そんなファイル自体存在するかどうかすら知りませんでした。
本当にあったのかな…?
なかったなら…申し訳ない…

795 :名無しさん@編集中:03/08/06 22:46
>>794
もちろん無いですw
お気になさらずにw

ただ、ホントに探していたgraphedit.htmlはネタじゃなくありません。。。

796 :名無しさん@編集中:03/08/06 23:08
著作権を侵してる奴らがいるな

797 :名無しさん@編集中:03/08/07 20:17
>>796
この板の多くの連中がそうだな。

798 :名無しさん@編集中:03/08/11 18:14
伸張されてるかどうかを見分ける方法ってないですか?
見ても色が濃いのか薄いのかわからんのです。

799 :名無しさん@編集中:03/08/11 18:25
モニタじゃなくてTVで見ればいいんだよ

800 :名無しさん@編集中:03/08/12 22:21
>>799
釣れますか?

801 :名無しさん@編集中:03/08/12 22:56
さっぱり食いつかないな。
スレてない奴いないかな?

802 :名無しさん@編集中:03/08/13 04:47
パクッ

803 :名無しさん@編集中:03/08/13 11:22
ネタじゃなくてマジなんですけど。
だって素人がYC伸張の話なんかわかるわけねーよ。
・゚・(ノД`)・゚・。

804 :名無しさん@編集中:03/08/13 12:18
>>803
なら、このスレ最初から読んで出直してね。

805 :名無しさん@編集中:03/08/13 12:24
素人がエンコなんてしなくていい

806 :名無しさん@編集中:03/08/13 15:02

素人はウンコはしてもいい

807 :名無しさん@編集中:03/08/13 22:36
>>804
みんなそればっか言うんだよ。
読んでわからないから聞いてるのに。
そんな意地悪しないで下さいよ。マジで。

808 :名無しさん@編集中:03/08/13 22:39
↑読んでわからないっていうのは、意味がわからないんじゃなくて、どのレスが正しいのかがわからないってこと。
だからテンプレ化して欲しいんです。

809 :名無しさん@編集中:03/08/14 00:24
>>808
ぢんさんが簡潔明瞭にまとめてくださってます。
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic11964

810 :名無しさん@編集中:03/08/14 05:18
>>807
それは意味がわかっていないんじゃないか。思考能力あるのか?

811 :名無しさん@編集中:03/08/14 22:08
>>807
このスレはYC伸張に関する知識を深めるためだけでなく
迷えるトーシロを導くスレでもある
自分のキャプ・エソコ手順を示せば誰かが答えてくれるよ
環境が変わったらまた訊きに来ればいい
オレはアク禁巻き添えでもう、レスできないだろうけど
(今回はラウンジクラシック経由)

812 :名無しさん@編集中:03/08/14 22:38
>>807
ヒストグラム見て画像を見ながら色補正するなら、BT601で出力するのが安全。
元が色については完全で補正がまったく必要なければ、ストレート使え。
(ただし編集ソフトの画面で見た目にはダメダメになるからね)
でもAvisynthでYUVで全て取り扱うのが良いだろうな

813 :名無しさん@編集中:03/08/15 00:39
>>812
BT601の意味がわからず、ググってみましたが、余計わかりません。

ITU-R BT.601 について
ttp://www.marumo.ne.jp/bt601/

伸張せずに出力するということでしょうか?
気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。

DVD2AVIの色に関する設定の組み合わせは

カラースペース=RGB と RGB→YUV=PCスケール
カラースペース=RGB と RGB→YUV=TVスケール
カラースペース=YUV と RGB→YUV=PCスケール
カラースペース=YUV と RGB→YUV=TVスケール

の4つがありますが、どれが正しいのかわからないんです。
目的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。
自分の目で見ればいいだろ、と言われそうですが、その自分の目があてにならないので。

それと、PCで見ると色がうすいですが、PCだからなのかYC伸張しないからなのかもわかりません。

814 :名無しさん@編集中:03/08/15 00:47
というか、このページ、

ttp://www.marumo.ne.jp/bt601/

>PC 上では YC 伸張・圧縮を行う方法が正しいものです。

なんて書いてありますが、このスレのどこかには「PCかテレビかは関係ない」みたいなことが書いてあります。
もうどっちを信じたらいいのか…。

815 :名無しさん@編集中:03/08/15 01:04
>>813
> 気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。
それなら・・・

> カラースペース=YUV と RGB→YUV=PCスケール
> カラースペース=YUV と RGB→YUV=TVスケール
の2つは関係ない。


816 :名無しさん@編集中:03/08/15 01:15
>的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。

このケースはすでに例が出てるんじゃないの?

817 :名無しさん@編集中:03/08/15 01:24
ビデオチップがBT.601から伸張するものなら
データをBT.601準拠で作れば
「PC 上では YC 伸張・圧縮を行う方法が正しい」と
「PCかテレビかは関係ない」は両立する!

鑑賞用にPC用とテレビ用にスケールを違えてデータを作るのはゲフォ厨のやるこった。

818 :名無しさん@編集中:03/08/15 01:58
難しく考えすぎ。
色はRGBで0〜255の値で表される。
0〜255を目いっぱい使って表現された画像を、さらに伸張したら-30〜280とかになって
0〜255を超えた部分が0とか255とかに変化してしまう。
これにさえ気をつけていれば問題はまあ起きないわけ。
(RGBストレート変換ってのは、0〜255じゃなくて、基本は16〜235の範囲でしか色を使いませんよって人向け)

819 :名無しさん@編集中:03/08/15 09:20
>>813
1,DVDレコ(YUV記録)->DVD2AVI(PCスケール)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無チェック)
2,DVDレコ(YUV記録)->DVD2AVI(TVスケール)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にチェック)
どっちかでやれ
現状のDVDレコはYV12しかないので内部YUV記録
DVD2AVIのプロジェクトファイル経由でTMPGEncに食わすということはVFAPI経由
VFAPI経由はすべてRGBで処理される
(そのためDVD2AVIのカラースペースは意味を持たない)
ここでYUV->RGB変換がおきる
1,はストレート変換 2,は伸張変換
どっちを使ってもソースの色空間はある程度保持される
(エンコードするかぎり完全に色空間を保持することはできない)
どっちも正しい


820 :819:03/08/15 17:25
スマソ
1,伸張変換 2,はストレート変換


821 :820:03/08/15 19:35
伸張変換よりストレート変換の方が誤差が小さいというのは本当でしょうか?


822 :821:03/08/15 19:43
あら、821の名前欄は間違いです。820さんごめんなさい。

823 :名無しさん@編集中:03/08/15 20:01
うーん…。
DVDレコ(16-235)→伸張変換(0-255)→CCIR601ではなく…に無チェック(16-235)
ということでしょうか?
最終的に(16-235)になるようにして、再生時に(0-255)に伸張されるような状態でいいんですか?
DVDレコーダーでの再生は勝手に(0-255)に伸張されるんですよね?
質問ばかりですいませんが。

824 :名無しさん@編集中:03/08/15 20:07
それと、VideoStudio4.0でエンコした場合、AVI→AVIとAVI→MPEGでは違う明るさでエンコードされてしまいます。
何故なんでしょう?
(AVI→MPEGだと元より明るくなってしまう)

825 :名無しさん@編集中:03/08/15 20:46
>>823
YUVで(16-235)という認識は間違い
まず、現状において目で見るためにはRGBにしなければならない<重要
テレビだろうがPCモニタだろうが最終的にRGB光線になっている
ところが多くのデジタルフォーマットはYUVで格納されている
そのためYUVを目で見るためのRGBにしたときのYUV->RGB変換公式の規定がいろいろある
DVDレコにおいてはその規格はBT.601に準拠する
BT.601において再生時(目で見るための)のYUV->RGB変換公式はストレート変換
このときRGBは(0-255)の値をとるが有効値は(16-235)
なぜならNTSC民生用テレビにおいて漆黒は16純白は235であるから
ところがPCモニタは漆黒は0純白は255であるため色あせてしまう
そこでYUV->RGB変換後に本来16になる数値を0に、235になる数値を255にしてしまう計算式がつくられた
これが伸張変換
どちらにしてもYUVが(16-235)というわけではない

でだ、最終的にMPEG変換するということはYUVに戻すということだ
ということは経過は兎も角ソースYUVと同じ色に出力YUVになればいい
厳密に言えばすべての過程でYUV処理すれば色変換誤差はcodecによるもの以外起きない
しかしTMPGEncは内部RGBだし、VFAPIはRGB入出力のみなので変換はさけられない

YUV->RGBだけを見ればどっちの式が誤差が少ないかはわからない
だってRGBにした後くらべてもどっちがソースに近いかわからないでしょ?
YUVそのままは見れないんだから
問題はYUV->RGB->YUVにしたときにどっちが・・・ってことだが
繰り返すなら兎も角一回くらいならたいしてかわらない


826 :名無しさん@編集中:03/08/15 22:53
>>825
なるほど。
とりあえず、

>1,DVDレコ(YUV記録)->DVD2AVI(PCスケール)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無チェック)

>2,DVDレコ(YUV記録)->DVD2AVI(TVスケール)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にチェック)

この組み合わせさえ間違えなければOKですね。
ありがとうございました。

827 :山崎 渉:03/08/15 23:15
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

828 :slave:03/08/17 00:23
ついにノンサチュレートAviutl完成
HuffyuvSよ安らかに・・・


829 :名無しさん@編集中:03/08/17 01:25
YUY2への変換時にYを16〜235、UVを16〜240の範囲に飽和させるかの設定を追加。

830 :名無しさん@編集中:03/08/17 01:59
slave さんは >>629 で次のように書きました。

>意地でも直さないだろうな・・・KEN。

831 :名無しさん@編集中:03/08/17 02:09
このスレがKENクンの意地をやわらげたんじゃないの?
あきらかにおかしいものはおかしいから

832 :slave:03/08/17 02:11
あの・・・それよりどうすればサチュレートできるんでしょう?
できないんですけど

833 :名無しさん@編集中:03/08/17 02:13
>>832
したいのかよ(w

834 :名無しさん@編集中:03/08/17 16:02
217 名前:Socket774 :03/08/17 15:45 ID:qrmB2F9/
nVidiaのビデオオーバーレイって、デフォルト画質が変ですよ(当方、FX5600 , 45.23 , AnalogRGB)
少なくとも、ドライバデフォルトでコントラスト90%、彩度114%になっている時点でおかしい。
また、Yレベル16〜235をRGBレベル0〜251として表示しているので、少し暗め。

仕様通りのYUY2オーバーレイを行いたい方は
 明るさ120%、コントラスト・色相・彩度100%
に設定すると良いですよ。これでほぼ仕様通りの色になります。

こんな好き勝手な仕様を組み込んで、業界標準と言っているのだから・・・鬱。


218 名前:217 :03/08/17 15:50 ID:qrmB2F9/
これを、普通の人にわかりやすく言うなら、
 「標準では黒く締まった色調が映える画質になっている」
とでも言えるのかしら?(藁  メーカの宣伝文句的に良く書いたけど、映像屋さんとしては失格です。
勝手にイコライジングしないで欲しい。


219 名前:217 :03/08/17 15:51 ID:qrmB2F9/
>>217
 すみません。入力ミス。以下を訂正
誤: また、Yレベル16〜235をRGBレベル0〜251として表示しているので、少し暗め。
正: また、Yレベル16〜235をRGBレベル0〜219として表示しているので、少し暗め。

835 :nVidiaスレ217:03/08/17 17:48
あ・・・さっそく貼られてしもた(汗

836 :nVidiaスレ217:03/08/17 17:52
ちなみに明るさ120%というのはわかりやすい値を選んだので、極める方は微調整よろしく。

837 :名無しさん@編集中:03/08/17 18:24
私信御免
420いるぅ〜?
書いといたよ。欠点スレおいで〜

838 :名無しさん@編集中:03/08/19 22:41
457 :名無しさん@編集中 :03/08/19 22:05
>>448
>>451
>>456
Re: Ver.99バグレポート 流れ者 - 2003/08/19(Tue) 22:04 No.4252


上記検証で使用したcodecはHuffyuvではなくHuffyuvSでした。
Huffyuvでやり直したところ問題ありませんでした。
どうやらHuffyuvS側の問題のようです。
お騒がせしてたいへん申し訳ありませんでした。


839 :名無しさん@編集中:03/08/19 22:45
>>838
ついにslave(Vmaker)の息の根がとまったな(w。
HuffyuvスレでもSをほしがるヤシは金輪際いないだろうに。

840 :名無しさん@編集中:03/08/19 22:47
HuffyuvSが残していったもの、それは(ry

841 :名無しさん@編集中:03/08/19 23:13
卵スレはネトラン者だらけだから信用できんな

842 :名無しさん@編集中:03/08/20 00:05
>>841
卯スレだよ

843 :名無しさん@編集中:03/08/20 00:11


844 :名無しさん@編集中:03/08/21 00:00
途中まで読んだけど何がなんだかさっぱり稚内ヨ!
とりえあずエンコした動画をaviutlで読み込んでヒストグラムを表示したら
両端がカットされてなかったので下手に弄るのはやめときます・・・。


【コーデック】huffyuvS Conbert to YUY2
 他の設定はデフォルト(Enable full size output-bufferのみonになっているます)
【エンコーダ】Aviutl 0.99
 設定はデフォルト
 「YUY2変換時に・・・・飽和」off
 「YUY2フィルタモード」off

(脱兎

845 :名無しさん@編集中:03/08/21 04:16
slave=流れ者≠vmakerだろ

846 :名無しさん@編集中:03/08/21 05:29
>>844
99だろ?んじゃ
HuffyuvS捨てろ
Huffyuvにせい
Convert to YUY2やめれ
YUY2展開・圧縮にチェキ



847 :名無しさん@編集中:03/08/21 05:40
Aviutlスレからきました。
向こうで「YUV->RGB->YUVストレート変換は諧調がシュリンクされる」
って力説するヤシがいるんだけど、ホント?
RGB->YUVならわかるけど
YUV->RGB->YUVなら元のYUVがYUV色空間に収まるデータしか持たないんだから
シュリンクされない、と思うんだけど?

848 :名無しさん@編集中:03/08/21 13:13
スレ違いだがAviUtl99は、もう大丈夫なんでつか?

849 :名無しさん@編集中:03/08/21 13:24
大丈夫でつぅ

850 :名無しさん@編集中:03/08/21 20:23
>[TMPGEnc Plus 更新履歴]
>2003.7.16/ Ver. 2.520
>MPEGデコーダに 「CRI Sofdec」(TM)を搭載しました。こちらの機能により標準状態でのMPEG-2ファイルの入力が可能になります。
>搭載されたデコーダーでは、パソコン上でTVでの見た目に近い明るさ・色で表示しますので編集作業が容易になります。
>※CRI Sofdec Decoder 利用時は「設定」→「量子化行列」→「YUVデータを CCIR601 ではなく、Basic YCbCr で出力する」のチェックは外してください。

TMPGEnc内蔵のデコーダーは強制YC伸張


851 :名無しさん@編集中:03/08/21 20:27
TMPGEnc終わったな…

852 :名無しさん@編集中:03/08/21 21:54
っていうか、YUV入力できない時点で終っているでしょ。

853 :844:03/08/21 22:04
>>846
御意に。それでやってみます。

854 :名無しさん@編集中:03/08/21 22:21
PremireがYUV処理をProで実装
Aviutlはついにサチュレートしなくなった
ネイティブYUY2であるCCE,Avisynthは当然問題なし
Dub系にはFastcompressがある

ホントTMPGEncとVFAPIがなぁ
どっちも堀やんけ
なんとかシル!!

855 :名無しさん@編集中:03/08/21 22:31
TMPGの3が開発中なんじゃなかったっけ?
きっとYUVに対応するでしょ

856 :名無しさん@編集中:03/08/21 23:16
堀だからわからんよ

857 :名無しさん@編集中:03/08/21 23:43
TMPGEncServerもなかったことになってるしね

858 :名無しさん@編集中:03/08/22 00:39
処理速度とYUV

せめてどっちかは対応して欲しいとこだが
最近のカノプ的な面白機能を目玉にしてくる可能性も

859 :名無しさん@編集中:03/08/22 22:09
>>858
多段パスがほしい・・・

860 :名無しさん@編集中:03/08/22 23:11
名前:名無しさん@編集中[sage] 投稿日:03/08/22 21:38
>>540
YC伸張スレ
キャプチャーボード上のチップはネイティブYUV処理のものが多い。
WindowsのCodecはサイズ圧縮を旨とするためYUV系が多い。
ところが動画処理系のフリーウェアにはRGB入出力系しか持たないものも多い。
そのためYUV->RGB->YUVが必要になるが
その際↑にあるように”ストレート変換”と”伸張変換”の二つの変換公式があり
RGB入力を持つアプリはどちらの変換公式を用いたRGBかを指定するオプションがあるのが普通。
ただし、そのアプリによって表現形式が異なるため初心者は非常に混乱しやすい。
それを説明したり情報交換しあったりするスレ。
の筈だが現在はストレート派と伸張派の戦場。

861 :860:03/08/22 23:17
戦場らしいから戦うか
BSDiLinkキャプしてM2v.aui(BT.709)にしてAviutlに読み込みノンサチュレートでHuffyuvYUY2
それをVirtualDubModで.avs colorYUY2(true)
有効領域外のデータあるじゃん
MPEGエンコードでレンジオーバーするのか?
レンジが狭まるならわかるが・・・
コンポーネントマスターに有効領域外データはないってホントかよ

862 :名無しさん@編集中:03/08/24 02:04
不浄

863 :名無しさん@編集中:03/08/24 23:36
http://www.geocities.co.jp/SiliconValley-SantaClara/1673/

自作板のnVidiaスレでがんがってる人がいるんですが、
考え方は合っているのでしょうか?

上記サイトの推奨設定だと
BSplayerでもオーバーレイ有り/無しで色合いや明るさが同じになるので
合っているとは思うのですが

詳しい人の意見も伺いたいです

864 :名無しさん@編集中:03/08/24 23:45
Aviutl v0.99+CCE Basicを使って、DVD-VIDEOを作る場合、

キャプチャ(YUY2) huffyuv+cce patch(YUY2) ->
->Aviutlで、YUY2読み込み,出力にチェック、飽和をオフ -> 編集 ->
->huffyuv+cce patch(YUY2圧縮)
->CCE (YUY2読み込みを試みる)

でいいですか? Aviutlとhuffyuvの関係が複雑化してきて、さっぱりですよ・・

865 :名無しさん@編集中:03/08/24 23:48
>>863
MSの想定するYUVオーバーレイを基準にすればそれであってる。
ただし単純に
>BSplayerでもオーバーレイ有り/無しで色合いや明るさが同じになるので
>合っている
とはならない
非圧縮YUVで比較しないとCODEC、再生アプリ側の色彩調整の影響があるからね。

866 :名無しさん@編集中:03/08/24 23:50
>>864
ソース色空間および適用範囲を保持したいなら正解

867 :名無しさん@編集中:03/08/25 00:01
>>861
撮影した素材そのまま持ってきたとしても、
カメラの輪郭補正とか、例えばDVの圧縮ノイズ、
ついでに編集かましたときにカラコレしたりで、
範囲外に出ることは多々ある。
あからさまに潜ってたり飛ぶようなことは無いけど。

868 :名無しさん@編集中:03/08/25 00:26
>>865
thx!!

MSの想定(DirectDrowでYUV オーバレイ) = ITU-R BT.601

なんですよね?

869 :名無しさん@編集中:03/08/25 00:30
YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
各ビデオボードごとに表示が違ってくる。

870 :名無しさん@編集中:03/08/25 00:34
>>869
BSplayer等でオーバーレイを無効にした場合について書いたつもりだったのですが
どうでしょうか?

871 :名無しさん@編集中:03/08/25 01:44
オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
ソフトウェアでYUV→RGB変換することになる。

872 :名無しさん@編集中:03/08/25 05:59
>YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
>各ビデオボードごとに表示が違ってくる。



>オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
>ソフトウェアでYUV→RGB変換することになる。

なので
MSが期待するYUV>RGB変換は伸張変換

このスレは独自用語で議論が進みがちなのでわかりにくいが

>MSの想定(DirectDrowでYUV オーバレイ) = ITU-R BT.601

ではない。BT.601はストレート変換。伸張変換はMS・IBM・Appleの想定する変換。

なお、ハードウェアオーバーレイ=GDIに完全に一致するのはまずない。
”ちかくなる”だけ
理由は>>869



873 :名無しさん@編集中:03/08/25 06:03
また,”伸張変換はMS・IBM・Appleの想定する変換。 ”
なのでアメリカの規格にのっとっている。
NTSC-JにのっとればYUV-RGBへの伸張は

(16-235)->(0-255)ではなく

(16-254)->(0-254)になる

235以上が有効範囲外になるのはアメリカの話であって、
日本では254まで有効範囲。

874 :名無しさん@編集中:03/08/25 06:04
訂正
(16-254)->(0-254)になる

(16-254)->(1-254)になる

875 :名無しさん@編集中:03/08/25 06:38
じゃあ、これはウソですか?

IRE Setup +7.5
【あいあーるいー・せっとあっぷ・ぷらす・ななてんご】
輝度信号の黒レベルにセットアップレベル+7.5が付加されていること。
アメリカのNTSC機器では、黒レベルが0IREではなく、7.5IREに設定されている。
日本では輝度レベルを拡張する意味で、黒レベルは0IREになっている。
白レベルの基準はどちらも100IREのため、日本のNTSCのほうが輝度の範囲が広い(日本=0〜100、アメリカ=7.5〜100)。
アメリカのビデオテープを日本の機器で再生させると、全体的に黒が浮いて見える(白っぽくみえる)のはこの違いによる。
この違いを区別する為、ハイエンド向けキャプチャカードや編集ソフトには同じNTSCでも”NTSC(US)”と
”NTSC-JAPAN(又はNHK)”といった別々の表記がある。

876 :名無しさん@編集中:03/08/25 07:14
>>873
チューナーの設定をNTSC-MからNTSC-Jに変えると
明るさがアップするけど、この理由は何?

877 :名無しさん@編集中:03/08/25 07:24
>>876
>>875

878 :名無しさん@編集中:03/08/25 08:01
http://pc.2ch.net/test/read.cgi/avi/993130983/555n

879 :名無しさん@編集中:03/08/25 10:00
結局

アナログ輝度(IRE) 米DTV規格 日本DTV規格 米PC規格 日本PC規格

    0        33     16     0     0

   100        235     235    255    235?
   109        ×     254     ×     255?

ということでしょ。日本のPC事情をどうするかが問題だな。
それとハリウッド映画を日本のDVDで見る場合、
33,235→16,254という伸長も必要なんじゃない?
それぞれのスケーリングに正式な名称をつけて、
どんな変換なのかが一発で分かるようにしてホスイ。


880 :名無しさん@編集中:03/08/25 10:19
+120IRE程度まではあるって聞いたけど?
ちなみにデータハンドリングには関係ないけど、下はSYNC LEVELまでで-40IRE (Color Burst信号は、-20IRE〜20IRE)
それに、RGBで、1〜254って聞いたことない。
(PCでは0-255フルに扱えるのが普通。1-254しか扱えないって専門の編集機器か何か?)

また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
UV(IQでも良いけど)はどのくらい伸張するの?

881 :名無しさん@編集中:03/08/25 11:29
>>880
ん??何番が対象の発言?
+120というのはアナログの場合かコンポジットの場合でしょ。
民生用のアナログカメラは、120IREとか平気で出すインチキっぽいのがあって、
顰蹙かってたなぁ。
コンポジットの場合は色振幅の最高は理論上〜160IREくらい、日本の映像〜133IRE、
米or古い機器など〜120IREってのはあるけど。
何の話だろ・・・・?

882 :名無しさん@編集中:03/08/25 18:18
>また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
>UV(IQでも良いけど)はどのくらい伸張するの?
この部分には俺も興味あるな?
計算式はどうなるの?

883 :名無しさん@編集中:03/08/25 20:21
>>882
デジタルメディア上での計算式なんてないんでは?
ヘタに計算式作っても誤差がでるだけでしょ
どうせYUVはRGBの色空間と1:1じゃないんだから
YUV>RGBはストレートにして
YUVにせよRGBにせよ15以下はサチュレート(16で飽和)
再生環境のキャリブレートは
YUV16が漆黒
YUV255が純白
でいいんでは?

884 :名無しさん@編集中:03/08/25 22:13
また難しい方向へいってしまうんですね。

885 :名無しさん@編集中:03/08/25 22:38
16-245 -> 0-255はおかしい。16-235 -> 0-235 にせよとプロの方は言っていますが?

886 :名無しさん@編集中:03/08/25 23:03
16-235->0-255を16-235->0-245だね。
でもプロの扱うどのソフトならそんな妙な変換を備えたものがあるんだろうか?

887 :名無しさん@編集中:03/08/25 23:16
>>872
返事が遅れましたがthx

話しは変わるのですが、
DOS/V magazine 03/18/15
にオーバーレイ画質とテレビ出力機能について特集が組まれており
*SMPTEカラーバー RGB(0,0,0)〜RGB(255,255,255)をオーバーレイ表示して測定器で計測
というのがありました。

同じnVidia製品でも(ドライバのオーバーレイ設定が同じだとして)
NTSCエンコーダによってテレビ出力のセットアップレベルが全く違うようなので
TV出力を厳密に「NTSC-J」に合わせるのは難しそう(というか不可能)だと感じました。

888 :名無しさん@編集中:03/08/25 23:36
>>886
プロはストレート変換しか使わないよ。

889 :名無しさん@編集中:03/08/25 23:45
>>887
民生テレビ自体を完全キャリブレートすることすら困難だよ。

890 :名無しさん@編集中:03/08/26 00:05
>>889


891 :名無しさん@編集中:03/08/26 00:07
>>889
失敗・・・2重投稿スマソ

でもせめて出力側だけでも規格に合わせたいです

892 :名無しさん@編集中:03/08/26 00:12
>>888
>878 :名無しさん@編集中 :03/08/25 08:01
http://pc.2ch.net/test/read.cgi/avi/993130983/555n

これプロの意見じゃないの?

893 :名無しさん@編集中:03/08/26 00:34
>>879
米 DTV 規格が違う

IRE  米 DTV 規格
 7.5  16
100   235
109   242

NTSC エンコーダーが、NTSC (US) か NTSC-J かの設定で IRE
レベル差を吸収するのが普通

もっとも、規格を読んだだけでの書き込みで、実際に US 向け
業務用機器を触ったり、作ったりしたわけじゃないけど

894 :名無しさん@編集中:03/08/26 02:04
>>893
109IREが242に対応するってところが分からん。
7.5IRE→16、100IRE→235の割りでいくと、
109IREは259とかに対応になるんだけど、
235を超えると線形性は崩れるの?

895 :名無しさん@編集中:03/08/26 03:10
IRE
http://dtv.myplanet.ne.jp/mototaka/DTV-gloss/dtv-i.htm
映像の、輝度レベルの単位。
日本では通常、0IRE=黒、100IRE=白のレベルを表すが、実際には、「白よりも白い」白が存在し、
120IRE位までを取り扱う。YUVの"Y"に相当する。

Vp-pの底(SYNC LEVEL)=-40IRE、BLACK LEVEL=0IRE、WHITE LEVEL=100IREとする単位で
1IRE = 7.14mVになる。

http://www.deetc.isel.ipl.pt/sistemastele/STd/arquivo/video/NTSC-PAL-SECAM.pdf

896 :名無しさん@編集中:03/08/26 03:22
NTSCビデオ信号タイミング規格(RS-170A)概要
http://elm-chan.org/docs/rs170a/spec_j.html

Final Cut Proでは、スーパーホワイトって名前で、109IREまで取り扱う。

897 :名無しさん@編集中:03/08/26 03:23
●NTSC/YCテスト信号

カラー・バー ― SMPTEカラー・バー。
コンバーゼンス ― 14ライン/垂直、17ライン/水平。
レッド・フィールド ― ルミナンス・ぺデスタル:201.74mV。クロミナンス振幅:626.66mVp-p。
グーリン・フィールド ― ルミナンス・ぺデスタル:344.45mV。クロミナンス振幅:585.28mVp-p。
ブルー・フィールド ― ルミナンス・ぺデスタル:110.06mV。クロミナンス振幅:443.76mVp-p。
マルチバースト ― ホワイト・リファレンス・バー振幅:70 IRE。パケット振幅:60 IRE。ペデスタル:40 IRE。バースト周波数:0.5、1.0、2.0、3.0、3.58、4.2MHz。
ライン・スイープ ― 振幅:714.3mVp-p。周波数:500kHz〜5MHz。
マーカ:1.0、2.0、3.0、4.0MHz。
ウィンドウ付パルス&バー ― 2TパルスHAD:250±25nS。ホワイト・バー振幅:100 IRE。フィールド・チルト:0.5%以下。ライン・チルト:0.5%以下。リンギング:1%ピーク以下。
5ステップ階段波 ― 振幅:100 IRE。リニアリティ・エラー:1%以下。
ランプ/変調ランプ ― ルミナンス振幅:100 IRE。クロミナンス振幅:40 IRE。微分利得(DG):0.3%(最大)。微分位相(DP):0.3°(最大)。
クロミナンス・ノイズ ― ルミナンス・ペデスタル:50 IRE。クロミナンス振幅:100 IRE。クロマ位相:レッド。
クロミナンス応答 ― 50 IREぺデスタル上の2.58MHz〜4.58MHzまで60 IREスイープ。
NTC7コンポジット― 100 IREバー、2Tパルス&12.5T変調パルス、振幅40 IREのサブキャリアが重畳した90 IRE5ステップ階段波を組合せた複合信号。
フラット・フィールド ― 0、50、100 IRE。
マトリクス ― マルチバースト、クロマ応答、50 IREフラット・フィールド、クロマ・ノイズ、カラー・バー、NTC7コンポジットで構成されたマトリクス信号。
バウンス ― 振幅:0または100 IREフラット・フィールド、レート:1秒ハイ、1秒ロー。

898 :名無しさん@編集中:03/08/26 03:54
Menu window - NTSC Safe Colors
http://www.mediachance.com/dvdlab/Help/ntsc.htm
ここでは、safe areaを-20% 〜 +20%で、-20IRE〜120IREとなっている。

CAMCODERだと、50IREとか、80/85/90/95/100 IREとか、最高でも102IREぐらい?
around 110IREとか書いてる奴もあった。

899 :888:03/08/26 05:37
>>892
再生環境のキャリブレートと中間処理のYUV>RGBは分けて考えるべき
大体、伸張変換公式だって本来は再生用(ただしアメリカ基準)
中間処理はストレートに決まってる(BT.601)
リンク先の”プロ”はプロ過ぎて”NTSC-J対応伸張公式”を実装したアプリがないことを
知らないんでしょ

900 :名無しさん@編集中:03/08/26 08:10
>>899
あの”プロ”はあのスレで一番エバってるね。
なんか徹夜明けのハイテンション状態で一気呵成に書き込んでるような...
プロなんだから、もっと余裕をもった気持ちで書き込んでほしいものだな。

901 :名無しさん@編集中:03/08/26 09:08
>>899
ピナクルのシステムは16-254のDV映像を、16-235で変換するよ。
これは235以上をクリップすると言うことではなく、
全体を圧縮する方式。したがって235の白は218になる。
ストレート変換だけじゃないよ。
でもって895〜898はなに?新手の荒らし?

902 :名無しさん@編集中:03/08/26 09:31
>>901
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?

903 :893:03/08/26 09:32
>>894
109IRE の 242 ってのは計算ミス。指摘ありがとう。
108IRE が 254 だった。

904 :名無しさん@編集中:03/08/26 10:11
プロの書き込みにはイチイチ頷かされるんだが
実際問題我々下賎なキャプ厨には役にたたない

905 :名無しさん@編集中:03/08/26 10:32
>>901
それって複数回通すとどんどん暗くなっていくような気がするけど大丈夫なの?

906 :名無しさん@編集中:03/08/26 16:56
最初の1回のみ縮退。でもその後はストレート変換で処理。
だからどんどん〜ってことはないよ。
ストレート変換を基本にしながらも、
初回のレンダリング時は
メーカー独自の領域に丸めてしまうものが多いね。

でさぁ、902ってなに?なんか失礼なやつだなぁ!


907 :名無しさん@編集中:03/08/26 18:46
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?

908 :名無しさん@編集中:03/08/26 20:21
なんかシッタカが闊歩しておるな。

909 :名無しさん@編集中:03/08/26 22:09
>>901=>>906
>でもって895〜898はなに?新手の荒らし?
これは>>894の「235を超えると線形性は崩れるの?」に対するレスだろ?
俺にとっては、895-898は非常に有益な情報だったよ。
もしこれが間違ってる/的外れってんなら、プロならプロらしくきちんと説明しろよ。
俺には、荒らし扱いする理由が全く見えないので、(895-898が全く意味無いと判断した)その理由が
非常に気に掛かる。
895-898への訂正意見とか反論とか、知識の出し惜しみせずに本当頼むよ。
(まさかレスする価値も無いスパムだとは言わないよね?)

910 :名無しさん@編集中:03/08/27 01:32
ノウホワイは後回しにしてノウハウの伝授をーーーーーっ!

911 :名無しさん@編集中:03/08/27 14:32
>>909って>>897とか>>907とか書いたやつだろうけど、
言語障害か何かだよな。まともなことばで返せない・・・

912 :名無しさん@編集中:03/08/27 14:39
>>907
1行でやめときゃいいのに

913 :名無しさん@編集中:03/08/27 14:44
>>901
>>906
>>911
┐(´〜`)┌

914 :名無しさん@編集中:03/08/27 14:55
おれにはチンプンカンプンだよ、って?
ごめんね、難しすぎて。

915 :名無しさん@編集中:03/08/27 15:05
なんか>>907>>913が糞スレに仕向けてるぞ。

916 :名無しさん@編集中:03/08/27 15:19
>>901
>>906
>>911
>>915
┐(´〜`)┌

917 :名無しさん@編集中:03/08/27 15:29
>>913>>916も ┐(´〜`)┌


918 :名無しさん@編集中:03/08/27 16:01
┐(´〜`)┌ な病気が流行ってます。気をつけましょう!!


919 :名無しさん@編集中:03/08/27 16:03
>>913
>>916
>>917
>>918
┐(´〜`)┌

920 :名無しさん@編集中:03/08/27 16:57
でさ、ここの住人の人、↑こういうヴァカ放置しとくわけ?
結構キチガイだね。それとも外人さんかな?(藁

921 :名無しさん@編集中:03/08/27 20:40
煽りは無視しろよ。それで良い事だろ。
俺もだんだん、
自分でも、プロにあるまじき、卑しいカキコだと思わんか?少し自省してみてはどうかね?
と思えてきたよ。

>911 :名無しさん@編集中 :03/08/27 14:32
>>909って>>897とか>>907とか書いたやつだろうけど、
>言語障害か何かだよな。まともなことばで返せない・・・

少なくとも、>>909はまじめな質問だろが、答える義務があると思わんのか?

922 :893:03/08/27 21:30
むー 901 でも 906 でも無いんだが、あんまりなので。

>895-898 が非常に有益な情報だったと豪語する 909 にとって

>「235を超えると線形性は崩れるの?」に対する

自分なりに考えてみた結論はどっちなんだろう。有益だったのだから
結論が出せたはずだろうと思ってるのだけど。

私にとって 895-898 は「IRE100 を超える信号が放送局のマスターの
段階で存在する」という情報と、レベルとは殆ど関係の無い NTSC の
同期タイミングに対する情報が書かれてるだけにしか見えないんだ。

で、IRE100 を超える情報が放送局のマスターレベルで存在するって
のは既出だし、それを否定してる人はそんなに居ないように思えるわ
けね。

・既出の情報
・無関係な情報

を延々書き連ねてるようにしか見えないんで、895-898 はスパム扱い
されても仕方が無いんじゃないかな。

あと、-20 〜 120 IRE ってのは色信号を重畳した後の、NTSC 信号で
の許容範囲であって、輝度のみで 120 まで使い切るのが正しいこと
だとか誤解しない方が良い。

923 :名無しさん@編集中:03/08/27 22:06
>IRE100 を超える情報が放送局のマスターレベルで存在するって
>のは既出

え?そう??
ガイシュツはMPEG2-TSしかないんでは?

924 :名無しさん@編集中:03/08/28 00:02
自分にとって既出だったら価値が無いってわけか。プロって観点がやっぱ違うな。
それでスパム扱いするわけ?

925 :名無しさん@編集中:03/08/28 00:05
言葉足らずだった。
俺は、スパム扱いするくらいだから、待ちかっとるよキミ。
ただしくはこうだ。とか説明があるもんだと思ってたよ。
>>895のpdfや>>896のリンクはスゲー良かったよ。

926 :名無しさん@編集中:03/08/28 00:07
895-898も、もうちょっとまとめて書けば荒らし扱いされなかっただけの話だ。
以上。

927 :名無しさん@編集中:03/08/28 00:09
>>897だって、俺には各色が何Vp-p(IRE)なのか判ってうれしい情報だったが?


928 :名無しさん@編集中:03/08/28 00:14
素人が調べた情報を貶すより、玄人からきちんと情報だすのがプロの態度だと思う。
もうスパムだどうだって話はいいから、実際の話をだしてくれよ。
例えば、局に納品するものは、レベルをどの範囲で作っているのかとか。
(109IREとか出してるけど、こんなレベル許されないだろ?)

929 :名無しさん@編集中:03/08/28 00:23
あと、カメラ撮りから編集時のレベル調整じゃなくて、
(歪み補正とか色々あるだろうから、ガンマやニーポイント、ショルダーポイントで複雑に補正するんだろうけど)
俺たち、キャプチャユーザーにとっては、補正後の完成された画像を取り扱うわけよ。
その場合、俺たちはなるべくレベルはオリジナルに近づけたいと思ってるわけ。
そういう観点からも、レクチャしてくれよ。

930 :909:03/08/28 00:37
>911 :名無しさん@編集中 :03/08/27 14:32
>>909って>>897とか>>907とか書いたやつだろうけど、
>言語障害か何かだよな。まともなことばで返せない・・・

俺が909を書いたけど、897や907は書いてない。いったい何処の部分で一緒にされたんだ?
俺の書き方が言語障害だってのはどの部分?
あなたがまともなプロの方だったら、内容はともかく、言語障害と断定したことに
納得できる説明または謝罪を要求する。

931 :名無しさん@編集中:03/08/28 00:55
だめだろう、あのプロは。

932 :893:03/08/28 01:04
つーか私はプロじゃないのだがなぁ(少なくとも編集側の人間じゃない)
聞いた話レベルのことしかいえないけど、それでもいいわけ?

許容される輝度レベル:
・16 以下は絶対不可
・235-254 まではどこまで使っても OK

実際の輝度レベル:
・使ってる機材と使う人でピンキリ

というわけで、明確な基準はない。

あと、プロに過大な幻想を抱くのはどうかと思うぞ。ほんの1年前まで
当たり前のようにコンポジットマスターで DVD を作ってて、今なお HD
を D2 アプコンで放送してるような連中なんだから。

933 :名無しさん@編集中:03/08/28 03:59
そういや、プロと自称しているヤシが NTSC-J (0IRE) と NTSC (7.5IRE) の違いが
デジタル段階でも現れると思いこんでいたりするのにはちと驚愕するね。

934 :名無しさん@編集中:03/08/28 05:59
自分が舌足らずなのに相手の読解力のせいにするスレはここですか?

935 :名無しさん@編集中:03/08/28 09:42
お前ら、そろそろ次スレのテンプレとFAQを、まとめれ。

936 :名無しさん@編集中:03/08/28 10:46
アプリごとの特性
codecごとの特性
ビデオカードごとの特性
フィルターごとの特性

誰か纏めてテンプラにしてくらはい

937 :名無しさん@編集中:03/08/28 12:13
>納得できる説明または謝罪を要求する。

2ちゃんでそれを求めてもなぁ・・・・・・
909がマジで謝罪もとめてるとしたら、けっこうバカかも。
それとも「プロ」煽ってんのかな?
おーい、プロよー、出てこーい!


938 :名無しさん@編集中:03/08/28 13:55
>>937
>あなたがまともなプロの方だったら
と但し書きがあるので、出てきたら幸いだという思いがこもってると見た。

939 :名無しさん@編集中:03/08/28 13:58
>>933
そういや、NTSC-Jだから0IRE=0なんて主張していたのもいたな。

940 :名無しさん@編集中:03/08/28 14:27
出て来ないからまともじゃない、って釣ってもねぇ・・・・・
なんせ2ちゃんだから・・・・

941 :名無しさん@編集中:03/08/28 14:38
要するにこのスレでボスを気取っていた907の前に
ある日突然プロを名乗るツワモノが現れ、
危機を感じた907が追い出そうと必死、ということでいいでつか?

942 :名無しさん@編集中:03/08/28 15:01
>>941
ここのボスって誰?
907ってただの煽りじゃん。
釣り?

943 :名無しさん@編集中:03/08/28 15:03
>>941
このスレ的には、プロ大歓迎だろ。
ただ、プロなら傍若無人な態度をとっても良いってことにはならいだけ。

944 :名無しさん@編集中:03/08/28 15:57
>>939
NTSC-Jでは0IRE=16で、普通のNTSCでは7.5IRE=16ってこと?

945 :名無しさん@編集中:03/08/28 16:34
AviutlのYC伸長の始点ってどうやって選べばいいのか分からない
readmeにはデッキ等の機種によりけりって書いてあるけど
自分のがどうなのかを調べる方法が・・・

946 :名無しさん@編集中:03/08/28 17:01
>>945
ヒストグラム

947 :名無しさん@編集中:03/08/28 17:15
>>944
そ。あくまでアナログ段階の黒レベルの問題であって、ITU-R BT.601に従って
デジタル化した場合は黒レベルはNTSC-JだろうがNTSC-USだろうがPALだろうが16。

948 :名無しさん@編集中:03/08/28 17:20
匿名板には自称プロが多数生息しています。

949 :名無しさん@編集中:03/08/28 20:25
>>932
許容される輝度レベル:
・16 以下は絶対不可(局によっては3IRE以上だったりする)
・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
 全体的に飛ぶと局に納品断られる。
これにクロマが絡んでくるとまた厄介なんだけど。

あと、BSデジタルは制作費があまりもらえないので、
全てのコンテンツをHDでやれないのね。
地上派デジタルになったって、
しばらくはSDのアプコン主流で行くし。

950 :名無しさん@編集中:03/08/28 20:46
なんだ 結局キャプ厨的にはY(16−235)を基準にすれば十分ってことじゃない。

951 :名無しさん@編集中:03/08/28 21:29
>・16 以下は絶対不可(局によっては3IRE以上だったりする)
>・235-254 はオーバーシュートしたパルス部分が出てる分には許容。


普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね


952 :名無しさん@編集中:03/08/28 21:41
>>951
そりゃ規格を知らん自称プロによる腐れオーサリングなソフトがあるってだけだ罠。

953 :名無しさん@編集中:03/08/28 21:46
>>952
いや、クライアントが納得して報酬を支払ってるなら立派なプロだろう。

954 :名無しさん@編集中:03/08/28 21:47
>>952
>>939ってことか。0IRE=0なんてオーサリングしてたら、そりゃ当然そういう
事態になるね。

955 :名無しさん@編集中:03/08/28 21:48
15以下236以上の輝度レベルのピクセルこだわっていたslaveらアンチBT601派は
受信機によって歪まされた輝度レベルを「マスターに近い状態」と信じて有難がっていたわけだな。

956 :名無しさん@編集中:03/08/28 21:49
>>953
そだね。規格を知っている/知らないのとプロ/アマかは無関係。


957 :名無しさん@編集中:03/08/28 21:59
nyで落として焼いてヤフオクで捌いてるのもプロ

958 :名無しさん@編集中:03/08/28 22:11
>>955
HEY!X3のスタジオライブはHDD収録なんだがiLinkキャプすると
範囲外とか言ってる236以上に諧調が存在する。
iLinkキャプは送信されたストリームを記録してるだけだよ。
MPEGエンコーダのせいにするのか?
MPEG圧縮でレンジが拡大するというのか?

そもそもマスターに近い状態って理解してるのか?
iLinkならまだしも民生レベルで地上波の16以下235以上をマスター同等のレンジでキャプできるのか?
おまいが16だって信じてるものがマスターの16である保障はないよ。

959 :名無しさん@編集中:03/08/28 22:15
>>958
結局そうじゃない保障もない・・・という表現もヘンな気がするから
一般視聴者レベルでそんな保障を得る事は不可能に近いから
面白画質にならない範囲で好きなように補正すりゃいいって事じゃね?

960 :名無しさん@編集中:03/08/28 22:38
>>958
マジレスすると
フジ、特にHEYは異常にYが高い

961 :名無しさん@編集中:03/08/28 22:40
>>959
だよな。
iLINKキャプやDVDリップですら範囲外もへったくれもないんだから
規格そのものが現実にそってないんだよな。
それにしてもテレトのハロモニはなんとかして欲しいんだが。
範囲外とか色づけとか演出とかキャプ環境とか、
そういう問題じゃないくらい面白すぎる(泣


962 :名無しさん@編集中:03/08/28 22:43
>>960
日テレはYどころか全部高い。
テレ朝もひどいし。
NHKに合わせてテレビをキャリブレートすると
Mステは目が痛い。
これが現実なのね。

963 :名無しさん@編集中:03/08/28 22:48
>>961
ハロモニは輝度が高いとかそういう問題じゃないからな
どんなに輝度を低めにキャプしても飛んでる色は最初から飛んでる
放送する前から白飛びしてるってアホくさすぎ

964 :名無しさん@編集中:03/08/28 22:50
で、再圧縮するときは(そういう人も少なくないでしょ?)
送り出し側を尊重して面白いままにしておくの?


965 :名無しさん@編集中:03/08/28 22:54
>>964
>>963
白とびに関してはどーにもならないよ。
全体に薄暗くしたって意味ないし、
コントラスト下げれば不足気味の諧調が余計消えるし、
面白い物は面白いままなんだよ。


966 :名無しさん@編集中:03/08/28 22:58
タイミングが悪かった。
ハロモニじゃなくてHEYみたいなものの話。

967 :名無しさん@編集中:03/08/28 23:00
>>966
iLINK前提ならY値だけ下げれば諧調が破壊され
サチュレートすればソースが破壊される。
でもビットレート稼ぎたいからサチュレートしちゃうけどな。


968 :名無しさん@編集中:03/08/28 23:36
ハロモニの白飛びに悩まされてるモヲタは多い

969 :名無しさん@編集中:03/08/28 23:39
白飛びはモヲタ対策なんだよ。

970 :名無しさん@編集中:03/08/28 23:42
ハロモニはたまにやたらと粒子の粗い?カメラがあって
肌が無茶苦茶汚く映るので萎える

971 :名無しさん@編集中:03/08/28 23:44
>>961
規格が現実に沿っていないのではなく、プロでも規格をしらないバカが多いってこと
なんだけどね…

972 :名無しさん@編集中:03/08/29 00:21
モーヲタ氏ねよ

973 :プュロフォッショナル:03/08/29 00:34
次スレッド立てようぜ

974 :名無しさん@編集中:03/08/29 00:58
>>946
ヒストグラムでどう判断するのか分からない・・・

975 :名無しさん@編集中:03/08/29 01:04
そりゃ、きちんとカラーバー入れないと判断つかない罠。

976 :名無しさん@編集中:03/08/29 05:20
>>951
DVDで白飛んで黒潜ってるとか言っとりますが、
マスターに入ってるカラーバーで校正した結果なら仕方ない。
そういうのは、マスター作ってきた制作会社が悪い。
漏れは客に判断仰ぐけどね。
おかしいカットだけカラコレかけられるけど、
そこはうちの責任じゃないので修正しない。

まあ、まともな作品で0IRE以下になることは無いけど。

977 :名無しさん@編集中:03/08/29 07:05
>>951
ちょっと待てや。

>普通にTV番組では使われてる領域だよ
>映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ

0-15が普通にTV番組では使われてる・・・と読めるのだが、
使ってるわけねぇだろ。おまえはちゃんと波形モニで監視してるのか?
0は同期ワードで使用絶対NGだから存在しているわけないし、
1-15はカラリメトリでクリップされるから送出されるわけがない。
どこからこんないい加減な話が出てくるのか疑問。
あんたどの局?どの時点で監視してるの?
サブキャリアの話とか言うオチはなしにしてくれよ。

978 :名無しさん@編集中:03/08/29 07:16
>>976-977
それは
>>201のコピペ

979 :名無しさん@編集中:03/08/29 07:34
976や977のような話が201の後に出てこなかったことが、ちとカナスィ・・・

980 :名無しさん@編集中:03/08/29 09:05
>>976
プロとしてなっちょらん

981 :名無しさん@編集中:03/08/29 10:07
AviUtlサポート掲示板のYC伸張スレ
http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=res&no=4339

982 :名無しさん@編集中:03/08/29 13:51
誰かいい感じのスレタイで次スレ立ててくれ
これは初心者が行き詰まったり気付かないで放置しちゃってる問題だから
誘導しやすいように最初のほうで(できればテンプレで)まとめてくれ
俺はよくわかってないから無理なんだが・・・

983 :名無しさん@編集中:03/08/29 13:56
ここで熱心に虚しい議論してる連中、
脳内空回り的発言多すぎだぞ。
とりあえずハケモニは買ってくれ。
何事も目で確認するのが一番!

984 :名無しさん@編集中:03/08/29 15:28
カラーバーとかキャプチャすると普通に0-15を使ってたりせんか?

985 :名無しさん@編集中:03/08/29 15:36
セットアップバーの-4IREが使ってるだけ。

986 :名無しさん@編集中:03/08/29 16:54
>>984
まず、キャプチャ時にゲインが正しく設定できているか確認したほうがいい。
あと、カラーバーは確かに16以下を使っているけど、それは-4IREの部分だけ
なので0-5は使っていないはずだぞ。

987 :名無しさん@編集中:03/08/29 16:58
あ、いや全く無いみたいな話が上であったからさ
15以下が放送されることは普通にあると思うんだが違うの?

988 :きっぱり:03/08/29 17:23
テスト信号以外、 な  い  。

989 :名無しさん@編集中:03/08/29 17:27
>>987
サブキャリとか言うオチは、なしにしてくれよ。

990 :名無しさん@編集中:03/08/29 17:28
映像製作時にあった場合は放送時に切られるってこと?
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど

991 :名無しさん@編集中:03/08/29 17:33
>>990よ、
映像製作ではなく、映像制作だ。
プロに叱られるぞ

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

993 :名無しさん@編集中:03/08/29 17:42
>明るい部分が黒く再生
それはネガポジ反転が掛かっているからです

994 :名無しさん@編集中:03/08/29 17:44
>>987
アナログ信号だからデコード -> キャプチャしたときにリンギング等の影響で
0IRE以下の信号が出てくる場合はある。けど、これはあくまで受信環境の問題。

995 :名無しさん@編集中:03/08/29 17:45
>>987
お前のキャプチャボードの設定を確認しろ。

996 :名無しさん@編集中:03/08/29 17:48
>>993
馬鹿にしてますね。
それなら逆に暗い部分が明るく再生されるじゃないですか。
明るい部分が黒くなるだけです。

997 :987=990:03/08/29 17:49
ないということは分かったのでできれば990に答えてもらえますか?
ただの確認なんですが

998 :名無しさん@編集中:03/08/29 17:49
>>993
この板に常駐している連中って、皆、不親切だし、独り善がりだし、偉ぶってるし、ドケチだし、ひねくれてるし・・・
なんか実社会において著しく他人とのコミュニケーション能力に欠けてる社会生活不適応者の典型の集まりって感じがする
嫌われ者で笑い者で引き篭もり(若しくは、それに相当する)のヲタばっかなんだろうな、キモッ!

999 :名無しさん@編集中:03/08/29 17:51
>馬鹿にしてますね。
うん。よくわかったね。
>明るい部分が黒く(=0IRE)なるだけです。
そりゃ故障だ。

1000 :名無しさん@編集中:03/08/29 17:52
やったあああああああああああああ!!!!!

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

276 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)