YC伸張する？しない？総合ｽﾚｯﾄﾞ
YC伸張はどんなとき必要か？
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://vmaker.tripod.co.jp/huffyuvs/convlist.html
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://vmaker.tripod.co.jp/huffyuvs/convlist.html
|
|
|
総合？
3 ：名無しさん＠編集中：03/04/14 14:57
1じゃないが
DVDにするならしなくていいだろう
DVDにするならしなくていいだろう
5 ：名無しさん＠編集中：03/04/14 15:01
全部TVスケールにしとけばいいの？
①DVD2AVI(TVｽｹｰﾙ)→AVIutl(YC伸張せず)→VFAPI→CCE(RGB0-255)
②①に同じ
②①に同じ
7 ：名無しさん＠編集中：03/04/14 15:10
>>7
その項目はDVD2AVIでAVI出力したときのみ反映される
ﾌﾟﾛｼﾞｪｸﾄﾌｧｲﾙ経由だとVFAPI経由と同等になる（VFAPIﾌﾟﾗｸﾞｲﾝだから）
そしてVFAPIはRGB入出力しかもたない
その項目はDVD2AVIでAVI出力したときのみ反映される
ﾌﾟﾛｼﾞｪｸﾄﾌｧｲﾙ経由だとVFAPI経由と同等になる（VFAPIﾌﾟﾗｸﾞｲﾝだから）
そしてVFAPIはRGB入出力しかもたない
MPEG2→CCE→DVD化
これじゃだめなの？
わざわざアプリ通して画質悪化させる理由とはいかに？
これじゃだめなの？
わざわざアプリ通して画質悪化させる理由とはいかに？
10 ：名無しさん＠編集中：03/04/14 17:08
AviUtlが勝手にYC伸張するとかしないとかいう話と関係あるんじゃねえ？
14 ：名無しさん＠編集中：03/04/14 18:51
いつもやっているのは
Huffyuv→AviUtilでYC伸張（0-255、4:2:2）→VFAPI経由でmpeg2
Huffyuv→AviUtilでYC伸張（0-255、4:2:2）→VFAPI経由でmpeg2
>>14
情報不足で回答不能
１、ｿｰｽHuffyuvはRGBかYUY2か？
２、AVIutlにおけるYC伸張はなにか？外部ﾌｨﾙﾀか本体ﾌｨﾙﾀか？
３、VFAPI経由で渡されたｴﾝｺｰﾀﾞはなにか？またｴﾝｺｰﾀﾞ側の設定は？
４、視聴環境はPCかTVか？またｵｰｻﾘﾝｸﾞは？
情報不足で回答不能
１、ｿｰｽHuffyuvはRGBかYUY2か？
２、AVIutlにおけるYC伸張はなにか？外部ﾌｨﾙﾀか本体ﾌｨﾙﾀか？
３、VFAPI経由で渡されたｴﾝｺｰﾀﾞはなにか？またｴﾝｺｰﾀﾞ側の設定は？
４、視聴環境はPCかTVか？またｵｰｻﾘﾝｸﾞは？
訂正
２、AVIutlにおけるYC伸張はなにか？外部ﾌｨﾙﾀか本体ﾌｨﾙﾀか？
↓
２、AVIutlにおけるYC伸張はなにか？外部ﾌｨﾙﾀか本体のYUY2設定か？
２、AVIutlにおけるYC伸張はなにか？外部ﾌｨﾙﾀか本体ﾌｨﾙﾀか？
↓
２、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
>４、視聴環境はPCかTVか？またｵｰｻﾘﾝｸﾞは？
これは関係ないでしょ。
これは関係ないでしょ。
>>18
いい人だよ
いい人だよ
>>19
視聴環境をPC限定としており
YC伸張を行わないVGA、ﾌﾟﾚｲﾔｰ、MPEG2codecを使用するため
最終出力はPCｽｹｰﾙ（YC伸張済み）にこだわりたい方もいるか、と
ほんの２年前は↑が多数勢力だったので確認です
視聴環境をPC限定としており
YC伸張を行わないVGA、ﾌﾟﾚｲﾔｰ、MPEG2codecを使用するため
最終出力はPCｽｹｰﾙ（YC伸張済み）にこだわりたい方もいるか、と
ほんの２年前は↑が多数勢力だったので確認です
>>18
なお、私はvmaker氏とは関係ありませんので
なお、私はvmaker氏とは関係ありませんので
CCESPのトライアルやTMPGEncのフリー使って能書き書いてるあたりでDQN度が分か（ｒｙ
CCESPのトライアルやTMPGEncのフリー版が製品と色が違ったら大問題だが
>>23のDQN度がよくわかるな(w
26 ：名無しさん＠編集中：03/04/14 22:31
HuffyuvSってHuffyuvを改造した物らしいけど信頼できるのかい？
ソースコードも公開されてないけど。
ソースコードも公開されてないけど。
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
RGB<->YUVの変換のときのYC伸張を除いただけ。無問題。
＆ソースは公開されてる。→http://vmaker.tripod.co.jp/files/huffyuvs_0.6_-_left_origin_-_base2.1.1_src.zip
30 ：28：03/04/14 22:36
漏れはPC限定の動画はYC伸張しないで代わりに色補正やってる。
PCのモニターでTVで見てるような色にしたいもんで。
PCのモニターでTVで見てるような色にしたいもんで。
だから、PC限定とかっていう言い方には意味がないんだってば。
YUV16-235になってればTVに出すのは問題ではないし
PCなら再生時にビデオチップで伸張されるの。
YUVデータを伸張しないビデオカードで視聴してるんなら買い換えなさいってこった。
YUV16-235になってればTVに出すのは問題ではないし
PCなら再生時にビデオチップで伸張されるの。
YUVデータを伸張しないビデオカードで視聴してるんなら買い換えなさいってこった。
伸張するビデオカードって具体的には何？
>>35
それはビデオオーバーレイの問題では？
使いたいﾌﾟﾚｲﾔｰ以外で見る気のないファイル再生させて
一時停止しといて最小化してから
見たいのを使いたいプレイヤーで再生すれば
ビデオオーバーレイじゃなくなって伸張せずに済むんじゃなかろうか？
試してないけど
それはビデオオーバーレイの問題では？
使いたいﾌﾟﾚｲﾔｰ以外で見る気のないファイル再生させて
一時停止しといて最小化してから
見たいのを使いたいプレイヤーで再生すれば
ビデオオーバーレイじゃなくなって伸張せずに済むんじゃなかろうか？
試してないけど
>>29
それはその通りなんですが
VFAPI入力時にはYUY2展開できませんし、
VFAPI出力時にはYUY2圧縮できませんから、
>>3の場合には問題にならないと思います
ですから>>13のように書きました。
それはその通りなんですが
VFAPI入力時にはYUY2展開できませんし、
VFAPI出力時にはYUY2圧縮できませんから、
>>3の場合には問題にならないと思います
ですから>>13のように書きました。
>>34
伸張しないのって nVidia 以外であるの？
伸張しないのって nVidia 以外であるの？
G400はしない？
TMPGEncもCCEもデフォルトでは16-235になるようになってる。
だからなにも考えない人がRGB0-255に伸張された状態、
つまり編集アプリ上でTVの見た目に近くなるように編集してエンコードしても
Y16-235のデータになるようになってる。
それでいい。
このY16-235のデータを再生するとき、RGB16-235の変換で表示するか、RGB0-255で表示するかは
ビデオドライバに依存する。（まともにハードウェアが働いていれば）
言うまでもなく後者は編集時やTVで見るのに近い表示になる。
変に色気を出すと、二重に伸張したり圧縮したりすることになるのさ。
だからなにも考えない人がRGB0-255に伸張された状態、
つまり編集アプリ上でTVの見た目に近くなるように編集してエンコードしても
Y16-235のデータになるようになってる。
それでいい。
このY16-235のデータを再生するとき、RGB16-235の変換で表示するか、RGB0-255で表示するかは
ビデオドライバに依存する。（まともにハードウェアが働いていれば）
言うまでもなく後者は編集時やTVで見るのに近い表示になる。
変に色気を出すと、二重に伸張したり圧縮したりすることになるのさ。
伸張する ： ATi, S3
伸張しない ： nVidia, Matrox
結局伸張させないほうがいいのかな
伸張させたければプレイヤー側で調整しろってこと？
伸張しない ： nVidia, Matrox
結局伸張させないほうがいいのかな
伸張させたければプレイヤー側で調整しろってこと？
>>47
Matrox(Parhelia) - 伸張する
確認方法
DVD2AVI (1.77.3) で m2p 読み込み
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい
G400/G450 でも伸張してた気がする。今はもう手放してるので確認できないけど
Matrox(Parhelia) - 伸張する
確認方法
DVD2AVI (1.77.3) で m2p 読み込み
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい
G400/G450 でも伸張してた気がする。今はもう手放してるので確認できないけど
MTVとかでTVを生で見るとき
伸張してくれないVGAだとﾏｽﾞｰになるの？
伸張してくれないVGAだとﾏｽﾞｰになるの？
>>48
全然わかってないな（ﾌﾟ
全然わかってないな（ﾌﾟ
>>48
今ここで伸張するしないビデオカードって言っているのは、
『YUVオーバーレイ』再生時のビデオカードの挙動について謂っているのだよ。
（Display表示するには、RGBデータに変換しないといけないわけだが、
YUVデータをビデオカードがどのようにRGB変換するかが問題なの）
つまり具体的には、AVIファイルを例えばWMPで再生させてみて（オーバーレイであることを確認）
その動画とTMPGEncやAviUtl、Dubなどの通常のGDI経由の表示画面が同じ輝度・色合いだったら
伸張されている。（WMP再生の方が暗かったら伸張されてない。Geforceなどが相当）
今ここで伸張するしないビデオカードって言っているのは、
『YUVオーバーレイ』再生時のビデオカードの挙動について謂っているのだよ。
（Display表示するには、RGBデータに変換しないといけないわけだが、
YUVデータをビデオカードがどのようにRGB変換するかが問題なの）
つまり具体的には、AVIファイルを例えばWMPで再生させてみて（オーバーレイであることを確認）
その動画とTMPGEncやAviUtl、Dubなどの通常のGDI経由の表示画面が同じ輝度・色合いだったら
伸張されている。（WMP再生の方が暗かったら伸張されてない。Geforceなどが相当）
>>48,>>49
MTV1000 レビュアーズガイド
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ここのオーバーレイについての記述を参考にしてみてね。
MTV1000 レビュアーズガイド
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
ここのオーバーレイについての記述を参考にしてみてね。
54 ： ◆S/VMAKER3c ：03/04/15 10:24
>1
直接にすると、行方不明者がでるので、できれば、Topから案内してあげて
くださいね(^^;。convlist.html を見て、huffyuvs って何? って人が結構
いたので、レイアウト変えたんだったりするんで。
# convlistはExcel だからリンクの管理がめんどい(ぉぃ)。
>18
ある意味正解(をぃ
>23
なぜトライアルやフリーを使ってテストをしたかと言うと、同じことを誰で
も試せる状況を作って置きたかったからなんですよ。ここで、正式版を持っ
ているもののみで動作を確認して表にしても、「そんなん持ってないから試
せないし～」「あのページみても参考にならんし～」って結果になりがちだ
と思います。
幸い、CCE や TMPGEncは比較的よく使われていて、かつ、トライアルおよび
フリーが用意されていて、かつ動作結果が違わないのでサンプルにするには
丁度良かったと言うのが理由なんです。
>26
これこれ、公開してるって(^^;
huffyuvs を Download できるなら、ソースも一緒に見つかるはずのページ
構成にしてあるつもりなんですが、どうして公開されてないって思ったんで
しょう? 今後のページ構成変更の参考にしたいので、ぜひ教えてください。
直接にすると、行方不明者がでるので、できれば、Topから案内してあげて
くださいね(^^;。convlist.html を見て、huffyuvs って何? って人が結構
いたので、レイアウト変えたんだったりするんで。
# convlistはExcel だからリンクの管理がめんどい(ぉぃ)。
>18
ある意味正解(をぃ
>23
なぜトライアルやフリーを使ってテストをしたかと言うと、同じことを誰で
も試せる状況を作って置きたかったからなんですよ。ここで、正式版を持っ
ているもののみで動作を確認して表にしても、「そんなん持ってないから試
せないし～」「あのページみても参考にならんし～」って結果になりがちだ
と思います。
幸い、CCE や TMPGEncは比較的よく使われていて、かつ、トライアルおよび
フリーが用意されていて、かつ動作結果が違わないのでサンプルにするには
丁度良かったと言うのが理由なんです。
>26
これこれ、公開してるって(^^;
huffyuvs を Download できるなら、ソースも一緒に見つかるはずのページ
構成にしてあるつもりなんですが、どうして公開されてないって思ったんで
しょう? 今後のページ構成変更の参考にしたいので、ぜひ教えてください。
55 ：名無しさん＠編集中：03/04/15 12:16
◆キャプチャ＆エンコード 質問、情報交換スレ◆4
ここの400ぐらいから読めばわかる
ここの400ぐらいから読めばわかる
>>53
>48ではYUV->RGB変換のことを書いておいて、>>53ではColorspaceがRGBかYUVかを取り上げるのか？
>>53の言うように、色空間がYUVの時は、確かにYUVオーバレイで表示されているよ。
（YUV->RGBの指定が、PC ScaleだろうとTV Scaleだろうと無関係に）
>48ではYUV->RGB変換のことを書いておいて、>>53ではColorspaceがRGBかYUVかを取り上げるのか？
>>53の言うように、色空間がYUVの時は、確かにYUVオーバレイで表示されているよ。
（YUV->RGBの指定が、PC ScaleだろうとTV Scaleだろうと無関係に）
①伸張されている場合
YUVオーバーレイと通常表示は同じ明るさ
②伸張されてない場合
YUVオーバーレイの方が通常表示より暗くなる
少なくとも、YUVオーバーレイの方が明るくなることは有りえない
YUVオーバーレイと通常表示は同じ明るさ
②伸張されてない場合
YUVオーバーレイの方が通常表示より暗くなる
少なくとも、YUVオーバーレイの方が明るくなることは有りえない
DVD2AVIのYUV→RGB変換はColor SpaceがRGBの時しか機能しないみたいだし、
YUV→RGB変換がTV ScaleのままでColor Spaceを変えてみたら
RGB TV ScaleよりYUVのほうが明るくなったということを>>48は言いたいのでは。
試してみたらG400も>>48と同じ結果になったのでG400も伸張してるのでしょうか？
YUV→RGB変換がTV ScaleのままでColor Spaceを変えてみたら
RGB TV ScaleよりYUVのほうが明るくなったということを>>48は言いたいのでは。
試してみたらG400も>>48と同じ結果になったのでG400も伸張してるのでしょうか？
>>60
色空間がRGBの場合は、YUV->RGB変換をDVD2AVIが、YUV->RGB変換の指定に従って変換後、
当然の結果としてRGBで表示している。
このときの表示はオーバーレイではない。
ビデオカードが伸張するしないに関わらず、すべからず同じ結果になるであろう。
だから、>>48=53は見当ハズレのトンチンカンなことを言っている。
色空間がRGBの場合は、YUV->RGB変換をDVD2AVIが、YUV->RGB変換の指定に従って変換後、
当然の結果としてRGBで表示している。
このときの表示はオーバーレイではない。
ビデオカードが伸張するしないに関わらず、すべからず同じ結果になるであろう。
だから、>>48=53は見当ハズレのトンチンカンなことを言っている。
つかぬ事を伺いますが、ソフトDVDプレイヤーなんかだと再生の際にプレイヤー側で
0～255に伸張してるって事でいいのでしょうか？
0～255に伸張してるって事でいいのでしょうか？
65 ：名無しさん＠編集中：03/04/15 19:28
>>48
>>60
>>61
いやなんかおかしいぞ？
GeForcemx400でも↓のようになるよ？？
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい
純粋にハードウェアオーバーレイになってないんじゃないの？
他のnVidiaユーザーも試してみてよ
>>60
>>61
いやなんかおかしいぞ？
GeForcemx400でも↓のようになるよ？？
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - 変化無し
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - YUV の方が明るい
純粋にハードウェアオーバーレイになってないんじゃないの？
他のnVidiaユーザーも試してみてよ
>>54
ご、ごめんなさい・・・・
>>65
検証してみました
>>48と同様になるもの
G450,GeForce2
>>48と異なるもの
i845GE
「色空間」を RGB と YUV で変更 - 「映像 -> YUV RGB 変換 」が パソコン色調テレビ色調に関わらずYUVだと明るくなる
ｲﾝﾃﾙﾁｯﾌﾟｾｯﾄ内臓VGAはYUVを伸張する（というか伸張しかできない）ので有名ですから
DVD2AVIの実装がどうなってるのかはわかりませんが、
ﾊﾟｿｺﾝ色調時に変化するかどうかで調べるのが正しいのでは？
できればATiの方の実験結果もでてきてほしいですね。
ご、ごめんなさい・・・・
>>65
検証してみました
>>48と同様になるもの
G450,GeForce2
>>48と異なるもの
i845GE
「色空間」を RGB と YUV で変更 - 「映像 -> YUV RGB 変換 」が パソコン色調テレビ色調に関わらずYUVだと明るくなる
ｲﾝﾃﾙﾁｯﾌﾟｾｯﾄ内臓VGAはYUVを伸張する（というか伸張しかできない）ので有名ですから
DVD2AVIの実装がどうなってるのかはわかりませんが、
ﾊﾟｿｺﾝ色調時に変化するかどうかで調べるのが正しいのでは？
できればATiの方の実験結果もでてきてほしいですね。
言いたいことが伝わったようなので安心した。
判りやすく書けなくて申し訳ない。
ついでに、伸張しない VGA の場合
「映像 -> YUV RGB 変換 -> パソコン色調」で「色空間」を RGB と YUV で変更 - RGB が明るい
「映像 -> YUV RGB 変換 -> テレビ色調」で「色空間」を RGB と YUV で変更 - 変化無し
になる。
デコーダがオーバレイを確実に使うかどうか不明な MediaPlayer よりも、ソースも
公開されてて、同じフレームで検証できる DVD2AVI の方が確実に判定できると思って
確認方法書いたのだけど、邪魔だったかな。
>>60
40&44 かな？
そういうわけで、G400 と同じ見え方を維持したいなら ATI/Intel/Matrox がおすすめ
G400 からなら Parhelia なんてどうでしょ？
判りやすく書けなくて申し訳ない。
ついでに、伸張しない 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
え？
え？
>>64
どもです。要はプレーヤー毎にバラバラなんですな
どもです。要はプレーヤー毎にバラバラなんですな
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のデコーダーを使うと２重に伸張されるということは個人的には信じ難い。
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のデコーダーを使うと２重に伸張されるということは個人的には信じ難い。
>>69
Parhelia の環境は DirectX 9.0
で、67 書いたあとで nVidia Quadra2 (43.45) で試してみたんだけど……
# こちらは DirectX 8.0a
48 とも 67 とも違う結果が出たので戸惑ってる。
TV スケールの RGB よりも、YUV が暗い。
ドライバ設定でオーバーレイの色調補正ができるけど TV スケールにも PC スケールにも
合いそうにない。
ストレート変換よりも、さらに圧縮してるような感じ。
Parhelia の環境は DirectX 9.0
で、67 書いたあとで nVidia Quadra2 (43.45) で試してみたんだけど……
# こちらは DirectX 8.0a
48 とも 67 とも違う結果が出たので戸惑ってる。
TV スケールの RGB よりも、YUV が暗い。
ドライバ設定でオーバーレイの色調補正ができるけど TV スケールにも PC スケールにも
合いそうにない。
ストレート変換よりも、さらに圧縮してるような感じ。
>>72
とりあえず追試してみました
G450&GeForce2
パソコン色調（YUV,RGBとも）テレビ色調YUV > テレビ色調RGB
i845GE
テレビ色調YUVおよびパソコン色調YUV > パソコン色調RGB > テレビ色調RGB
なにがなにやら？？？
とりあえず追試してみました
G450&GeForce2
パソコン色調（YUV,RGBとも）テレビ色調YUV > テレビ色調RGB
i845GE
テレビ色調YUVおよびパソコン色調YUV > パソコン色調RGB > テレビ色調RGB
なにがなにやら？？？
i845GEは伸張しすぎということ？
>>55
>>73
http://pc.2ch.net/test/read.cgi/avi/1035744504/962
キャプ質スレ漁ればわかるがユーザーの希望によってつくられたもんだよ＞パッチ対応版
ぶっちゃけCCESPTrialをクラックしちまうと
Huffyuv2.11は読み込み不良やエンコードエラーがでる
で、海の向こうではHuffyuv2.11を改造してクラックパッチ対応版Huffyuvが作られた
このクラックパッチ対応版をS化したものがbase2.11-CCESP版なのだよ
>>73
http://pc.2ch.net/test/read.cgi/avi/1035744504/962
キャプ質スレ漁ればわかるがユーザーの希望によってつくられたもんだよ＞パッチ対応版
ぶっちゃけCCESPTrialをクラックしちまうと
Huffyuv2.11は読み込み不良やエンコードエラーがでる
で、海の向こうではHuffyuv2.11を改造してクラックパッチ対応版Huffyuvが作られた
このクラックパッチ対応版をS化したものがbase2.11-CCESP版なのだよ
それはｵﾚに訊いても･･････
vmaker氏の降臨を待て
つーかスレ違いだからキャプ質スレに逝け
vmaker氏の降臨を待て
つーかスレ違いだからキャプ質スレに逝け
i815Eの場合です。
Win2K-SP3, DVD2AVI(1.76+), DirectX 8.1(4.08.01.0881)
YUV(TV Scale/PC Scale) = RGB(PC Scale) > RGB(TV Scale)
Win2K-SP3, DVD2AVI(1.76+), DirectX 8.1(4.08.01.0881)
YUV(TV Scale/PC Scale) = RGB(PC Scale) > RGB(TV Scale)
なお、YUVの場合オーバーレイ表示、RGBの場合通常表示であることは確認した結果です。
Alt+PrintScreenでコピーし、ペイントでペーストしたときに
画像が取り込まれているか（通常表示）、真っ暗（オーバーレイ）かで確認済み。
Alt+PrintScreenでコピーし、ペイントでペーストしたときに
画像が取り込まれているか（通常表示）、真っ暗（オーバーレイ）かで確認済み。
AviUtlの再生ウインドウで、オーバーレイ表示にチェックを入れても外しても
同じ表示であったことも付け加えておきます。
（ここでもオーバーレイ表示の場合、Alt+PrintScreenで画像をキャッチできなかったことを確認）
以上のことから、i815Eのビデオ機能はYUVオーバーレイは伸張『あり』です。
同じ表示であったことも付け加えておきます。
（ここでもオーバーレイ表示の場合、Alt+PrintScreenで画像をキャッチできなかったことを確認）
以上のことから、i815Eのビデオ機能はYUVオーバーレイは伸張『あり』です。
理論上、RGB(TV Scale)がRGB(PC Scale)より明るい分けはないと思うんだが。
（ピクセルの数値はPC Scaleの方がTV Scaleよりレンジが大きいんだから）
（ピクセルの数値はPC Scaleの方がTV Scaleよりレンジが大きいんだから）
画像によっては、明るい暗いという見方より色がくっきりか淡いかで見分けた方が良いみたい。
おいおい、0.2.2がクラックパッチ対応とぶっちゃけるとは恐れ入った。
添付のドキュメント読んでないでしょ。
HuffyuvとCCEはYUY2の扱いに食い違いがあったため
RGB Outputをしてやらないとならなかった。
これだとパフォーマンスのロスになるのでHuffyuvをhackしたのさ。
CCEにクラックパッチを当てるからHuffyuvのYUY2で問題が出てたわけではないよ。
またその他、CCEの問題とは別に
Field ThresholdがオリジナルではPAL圏用に288になってるのだが、
0.2.2ではNTSC圏用に240にできるのさ。
添付のドキュメント読んでないでしょ。
HuffyuvとCCEはYUY2の扱いに食い違いがあったため
RGB Outputをしてやらないとならなかった。
これだとパフォーマンスのロスになるのでHuffyuvをhackしたのさ。
CCEにクラックパッチを当てるからHuffyuvのYUY2で問題が出てたわけではないよ。
またその他、CCEの問題とは別に
Field ThresholdがオリジナルではPAL圏用に288になってるのだが、
0.2.2ではNTSC圏用に240にできるのさ。
>>64
どっちもYUV系の出力をするのであればYC伸張しないよ。
動画再生はVGAがYUY2オーバーレイを行い、その際のYUY2＞RGB変換の
際にYC伸張するのが一般的な作法。
＃オーバーレイがうまく効かない、調整値がいじってあるとか言った状態を勘違いする香具師もいるみたいだが・・・
というか明示的に設定する場合を除き、基本的にはPCで扱うディジタルな色空間はすべて
RGB：PCスケール
YUV系：TVスケール
になってると言うことが理解できれば、この話題は特に混乱することもないと思うのだが・・・
どっちもYUV系の出力をするのであればYC伸張しないよ。
動画再生はVGAがYUY2オーバーレイを行い、その際のYUY2＞RGB変換の
際にYC伸張するのが一般的な作法。
＃オーバーレイがうまく効かない、調整値がいじってあるとか言った状態を勘違いする香具師もいるみたいだが・・・
というか明示的に設定する場合を除き、基本的にはPCで扱うディジタルな色空間はすべて
RGB：PCスケール
YUV系：TVスケール
になってると言うことが理解できれば、この話題は特に混乱することもないと思うのだが・・・
91 ：名無しさん＠編集中：03/04/16 00:48
わけわかめです。
92 ：名無しさん＠編集中：03/04/16 05:32
バカにも判るように言えヽ(`Д´)ﾉ ｳﾜｧｧﾝ
動画見て判断すればいいんじゃね？
違いがわからないならどっちの設定でもよさそうだし。
違いがわからないならどっちの設定でもよさそうだし。
94 ： ◆S/VMAKER3c ：03/04/16 08:53
>77
そもそも、huffyuv / huffyuvs / huffyuvs-cce のサイズを比べてもらうと、
「おいこら何か仕込んでないか?」 って思えるほどサイズが違うので、その
辺の理由をば。
最初、まったく動作しないとの報告があり、プログラムの不具合などを疑っ
てたのですが、よくよ聞いてみると、外部 DLLが無いためだった…と言う事
が数例ありました。そのため、huffyuvs は、その DLLを必要しない状態で
コンパイル/リンクされています。これは、外部にあったプログラムを取り
込んでしまっている状態であるため、サイズが大きくなってしまいます。
また、CCEパッチの方は、ToolTip Help のコードとかが増えているために大
きくなっているだけで、プログラム的にはそれほど差がありません。
なので、コンパイルできる環境があるかたは、自前で動的リンクした方が、
HDD に優しいのですが、今時、しかも、ビデオ関連をやろうとしているのに
100K単位以下の差を気にしてもね(^^;
ところで、このスレ。YC伸張関連の話と、ビデオオーバーレイの話が混ざっ
てて混乱してるようにも見えますね。とりあえず、ビデオオーバーレイをし
てるかどうかを確認する方法と、データとして伸張されるのかどうかを確認
する方法に分けて話すってのが良いのではないかと。
そもそも、huffyuv / huffyuvs / huffyuvs-cce のサイズを比べてもらうと、
「おいこら何か仕込んでないか?」 って思えるほどサイズが違うので、その
辺の理由をば。
最初、まったく動作しないとの報告があり、プログラムの不具合などを疑っ
てたのですが、よくよ聞いてみると、外部 DLLが無いためだった…と言う事
が数例ありました。そのため、huffyuvs は、その DLLを必要しない状態で
コンパイル/リンクされています。これは、外部にあったプログラムを取り
込んでしまっている状態であるため、サイズが大きくなってしまいます。
また、CCEパッチの方は、ToolTip Help のコードとかが増えているために大
きくなっているだけで、プログラム的にはそれほど差がありません。
なので、コンパイルできる環境があるかたは、自前で動的リンクした方が、
HDD に優しいのですが、今時、しかも、ビデオ関連をやろうとしているのに
100K単位以下の差を気にしてもね(^^;
ところで、このスレ。YC伸張関連の話と、ビデオオーバーレイの話が混ざっ
てて混乱してるようにも見えますね。とりあえず、ビデオオーバーレイをし
てるかどうかを確認する方法と、データとして伸張されるのかどうかを確認
する方法に分けて話すってのが良いのではないかと。
おまえが話を複雑にしてるんじゃねーかよ
96 ：名無しさん＠編集中：03/04/16 13:24
YC伸張はしない方が良い。
huffyuvよりhuffyuvsの方が良い。
って事ですか？
huffyuvよりhuffyuvsの方が良い。
って事ですか？
98 ：名無しさん＠編集中：03/04/16 16:42
前提なしで「良いか、悪いか」の結論を付けたがる奴って必ずいるよな。
>>96
ヴぉけすれあげんなヴぉけ
ヴぉけすれあげんなヴぉけ
100 ：名無しさん＠編集中：03/04/16 19:21
１００げっつ
101 ：名無しさん＠編集中：03/04/17 01:34
>>97
いやだ おまえもしちゃ駄目
いやだ おまえもしちゃ駄目
意味不明
（＾＾）
俺の身長も伸ばしたい
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やってる人はｹﾞﾌｫ厨の言うことに惑わされないように注意しよう。
出力方法や見た目で場合分けする奴はｹﾞﾌｫ厨。
YUVデータを伸張しないｹﾞﾌｫで
Y(16-235)のデータをテレビと同じ輝度でPCでモニタするには
ソースそのものをY(0-255)に伸張しないといけないからな。
こいつをTVで見れば当たり前のように色飛びするわな。
だからTVで見るから、とかPCでしか見ないからという言い方をする。
一方、ﾗﾃﾞやインテルのように伸張するチップだと
データそのものを伸張しなくても
PCのモニタとTVとで同じ輝度で見えるから
PCで見るのこととTVで見ることに区別をつける必要がないし、
余計な伸張処理をしてればおかしいことに気付くことが出来るのさ。
趣味でDTVやってる人はｹﾞﾌｫ厨の言うことに惑わされないように注意しよう。
つっても乗ってるカードがｹﾞﾌｫだからなぁ。
ﾗﾃﾞが乗ってるならそれでいいんだろうけど。
自分の環境に合った設定でエンコする、では不満ですか？
ﾗﾃﾞが乗ってるならそれでいいんだろうけど。
自分の環境に合った設定でエンコする、では不満ですか？
>>107
それじゃあ、ビデオカードを買い換えたときに後悔するかも。
Geforceであっても、BT.601準拠で作成するほうがいいぞ。
GeforceのYUVオーバーレイに合わせると、TV出力する場合や友人にやる場合とかに困るだろ。
それでPCで再生する場合、ffdshowとかで伸張しながら再生すると万事解決だね。
それじゃあ、ビデオカードを買い換えたときに後悔するかも。
Geforceであっても、BT.601準拠で作成するほうがいいぞ。
GeforceのYUVオーバーレイに合わせると、TV出力する場合や友人にやる場合とかに困るだろ。
それでPCで再生する場合、ffdshowとかで伸張しながら再生すると万事解決だね。
仲間外れはｹﾞﾌｫ厨だけでよろしいか？
>>110
kyro厨も入れておいてくれ
kyro厨も入れておいてくれ
gefo使ってるけどTV出力はVG1000使ってる俺もﾅｶﾏ外れですか？
基本的に俺はYC伸張しない派なんだが。
>113
YC伸張する派しない派なんていうのが見当違いなんだよ。
最終的なデータをBT.601に準拠させるために
伸張したりその逆をしたりという処理が必要な場合があるんだよ。
よくあるのがRGB(16-235)のデータ（例えばMPEGキャプチャのソースをTV出力するからと言ってDVD2AVIでRGB TV色調にして）を
TMPGEncで「BasicYCbCrで出力～」にチェックを入れない状態でエンコードするやつ。
YC伸張する派しない派なんていうのが見当違いなんだよ。
最終的なデータをBT.601に準拠させるために
伸張したりその逆をしたりという処理が必要な場合があるんだよ。
よくあるのがRGB(16-235)のデータ（例えばMPEGキャプチャのソースをTV出力するからと言ってDVD2AVIでRGB TV色調にして）を
TMPGEncで「BasicYCbCrで出力～」にチェックを入れない状態でエンコードするやつ。
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
＞オーバーレイを行う場合には、デジタルコンポーネントビデオをグラフィックスボードが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
>>115
他人が作った動画を自分がもらうことを前提に話してる？
他人が作った動画を自分がもらうことを前提に話してる？
>>118
動画自体じゃなくても、そういうちょっと間違った情報を初心者に吹聴する人を前提にしてる。
動画自体じゃなくても、そういうちょっと間違った情報を初心者に吹聴する人を前提にしてる。
DVD2AVIなんか使わなければよい
121 ：名無しさん＠編集中：03/04/19 10:29
良スレだね…
122 ：名無しさん＠編集中：03/04/19 23:12
ageられてもﾀﾞﾚもﾚｽできないくらい良ｽﾚですな
考えるのが面倒だから伸張なしでｴﾝｺ
∧＿∧
（ ＾＾ ）＜ ぬるぽ（＾＾）
（ ＾＾ ）＜ ぬるぽ（＾＾）
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で１回やっている。これを無効にすると少しMPEG2より
すこし輝度が落ちかつ色が少し薄い？感じになった。俺の場合はオリジナル
に一番近いかどうかで判断しているため、YC伸張してる。まちがいがあったら
指摘ください（グラボはマトG550使用）。
DVD2AVI(TV Scale・d2v保存)→TMPGEnc(音ずれ補正のみ使用・DVD2AVIで
音声出力時の-66msとかを修正)→aviutl(拡張色調補正でTV→PCスケール
補正・ここでYC伸張される・aup保存）→VFAPIConv（aupから参照aviへ
変換・音声含む）→WME9（WMV9エンコ）
の順でやっている。これでMPEG2とほぼ同じ輝度だった（CRTで確認）。
YC伸張はaviutlで１回やっている。これを無効にすると少しMPEG2より
すこし輝度が落ちかつ色が少し薄い？感じになった。俺の場合はオリジナル
に一番近いかどうかで判断しているため、YC伸張してる。まちがいがあったら
指摘ください（グラボはマトG550使用）。
126 ：大田遺産：03/04/20 15:59
修正
×少しMPEG2→○MPEG2
×少しMPEG2→○MPEG2
>>125
>aviutl(拡張色調補正でTV→PCスケール補正・ここでYC伸張される・aup保存）
>→VFAPIConv（aupから参照aviへ変換・音声含む）
VFAPIConv通すってのは無圧縮RGB出力してんのと同じだから
WME9がRGB>YV12変換時にYC圧縮→再生時にYC伸長してるだけでないの？
YUVｴﾝｺｰﾀﾞがRGBで入力されたときは「伸長されてるもの」として扱うのは極一般的
YUVで受け取ったときはどうなる？
VFAPI使えないけど・・・
あと
音声出力時が-66msだったら音ｽﾞﾚ補正などせんで
まるもﾌﾟﾗｸﾞｲﾝで直にAVIutlつっこんだほうがいいでしょうな
まぁ音声.m2pじゃないとあかんけど
>aviutl(拡張色調補正でTV→PCスケール補正・ここでYC伸張される・aup保存）
>→VFAPIConv（aupから参照aviへ変換・音声含む）
VFAPIConv通すってのは無圧縮RGB出力してんのと同じだから
WME9がRGB>YV12変換時にYC圧縮→再生時にYC伸長してるだけでないの？
YUVｴﾝｺｰﾀﾞがRGBで入力されたときは「伸長されてるもの」として扱うのは極一般的
YUVで受け取ったときはどうなる？
VFAPI使えないけど・・・
あと
音声出力時が-66msだったら音ｽﾞﾚ補正などせんで
まるもﾌﾟﾗｸﾞｲﾝで直にAVIutlつっこんだほうがいいでしょうな
まぁ音声.m2pじゃないとあかんけど
http://vmaker.tripod.co.jp/huffyuvs/convlist.html
↑の表を見ると
HuffyuvS(YUY2)→AviUtl (YUY2チェック無)→VFAPI→Codec
だとストレートって読めるけど
この場合YC伸張or圧縮はされてないと判断していいの？
それともやはりVFAPIの時点で伸張されてしまうの？
↑の表を見ると
HuffyuvS(YUY2)→AviUtl (YUY2チェック無)→VFAPI→Codec
だとストレートって読めるけど
この場合YC伸張or圧縮はされてないと判断していいの？
それともやはりVFAPIの時点で伸張されてしまうの？
>>127
>WME9がRGB>YV12変換時にYC圧縮
そうされるのを見越してAviUtlの時にYC伸張(RGBフルスケール化)してるんでしょ。
そこで伸張しないとTVスケールから更に圧縮されることになる。
結果として前後でYUVオーバーレイの色調が同じになってるんだから
なにもマズいところはないはずだけど。
>WME9がRGB>YV12変換時にYC圧縮
そうされるのを見越してAviUtlの時にYC伸張(RGBフルスケール化)してるんでしょ。
そこで伸張しないとTVスケールから更に圧縮されることになる。
結果として前後でYUVオーバーレイの色調が同じになってるんだから
なにもマズいところはないはずだけど。
>>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に準拠しない）
ﾏｽﾞｲって書いてないんだが？
本人が理解してるのかどうか自信がないようなんで解説つけて
なおかつあえて質問つけてるだけよん
>>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作ってる。それから音ずれ
チェックはまるもさん(aviutl２つ起動して音波形確認)のと比べて-66msで
ほぼ合っていることを確認した。
YC圧縮→再生時にYC伸長してるだけでないの？>>メディアプレーヤー９は
再生時はYC伸長していないと思う（確信なし）
>>129へ
>WME9がRGB>YV12変換時にYC圧縮
なるほどWME9でYC圧縮してるからaviutlでTV→PCスケール（YC伸張）しない
とWMVの色が薄くなった感じになるわけだ。勉強になります（CRTでオーバー
レイの画像比較でのみ判断してたもんで）
まるもさんのMPEGデコーダでaviutlでaupやってみたらWME9で画面が出力
されなかったので（原因不明）125のやり方でWMV作ってる。それから音ずれ
チェックはまるもさん(aviutl２つ起動して音波形確認)のと比べて-66msで
ほぼ合っていることを確認した。
YC圧縮→再生時にYC伸長してるだけでないの？>>メディアプレーヤー９は
再生時はYC伸長していないと思う（確信なし）
>>129へ
>WME9がRGB>YV12変換時にYC圧縮
なるほどWME9でYC圧縮してるからaviutlでTV→PCスケール（YC伸張）しない
とWMVの色が薄くなった感じになるわけだ。勉強になります（CRTでオーバー
レイの画像比較でのみ判断してたもんで）
好きなようにやれよ。
135 ：大田遺産：03/04/20 20:55
>(0-255)のうち(16-235)の領域を(0-255)に伸長してRGBにする
>これがYUVｵｰﾊﾞｰﾚｲ表示における常識的なﾋﾞﾃﾞｵｶｰﾄﾞの伸長動作（つーかBT.601準拠の動作）
カノープスではビデオチップでは伸張されないことが常識とされていて、
伸張するビデオチップは異端であるかのような扱いだ。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
#127に突っかかってるわけじゃないからよろしく。
>これがYUVｵｰﾊﾞｰﾚｲ表示における常識的なﾋﾞﾃﾞｵｶｰﾄﾞの伸長動作（つーかBT.601準拠の動作）
カノープスではビデオチップでは伸張されないことが常識とされていて、
伸張するビデオチップは異端であるかのような扱いだ。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
#127に突っかかってるわけじゃないからよろしく。
>>137
つっかかれてると思ってるわけではないが
あくまでも「BT.601準拠の動作」を基本に解説しただけ
質問者のﾋﾞﾃﾞｵｶｰﾄﾞはｹﾞﾌｫちゃうしな
それにｶﾉｰﾌﾟｽはﾗﾃﾞに乗り換えるようだから
そこの表記も変わるんでない？
つっかかれてると思ってるわけではないが
あくまでも「BT.601準拠の動作」を基本に解説しただけ
質問者のﾋﾞﾃﾞｵｶｰﾄﾞはｹﾞﾌｫちゃうしな
それにｶﾉｰﾌﾟｽはﾗﾃﾞに乗り換えるようだから
そこの表記も変わるんでない？
>>136でした（w
カノープス独自ドライバで伸張させないようにしたりして
ありえる（w
141 ：大田遺産：03/04/20 22:34
もひとつ聞きたいのですが
>>47 48の人が伸張する ： ATi, S3、伸張しない ： nVidia, Matrox
Matrox(Parhelia) - 伸張すると書いてるが俺の作ったWMV9はYC伸張したもの
ばかり。ということはラデオンとかにグラボ換えたときオーバーレイ表示で
２重にYC伸張されちゃうのか？だとしたらマズー（ON・OFF切替あるか？）
その辺どうなんでしょ。
>>47 48の人が伸張する ： ATi, S3、伸張しない ： nVidia, Matrox
Matrox(Parhelia) - 伸張すると書いてるが俺の作ったWMV9はYC伸張したもの
ばかり。ということはラデオンとかにグラボ換えたときオーバーレイ表示で
２重にYC伸張されちゃうのか？だとしたらマズー（ON・OFF切替あるか？）
その辺どうなんでしょ。
>>141
その後の調査でMatroxも伸張してるということになりました。
伸張する ： ATI, S3, Matrox, Intel
伸張しない ： nVidia, ST Microelectronics(KYRO)
その後の調査でMatroxも伸張してるということになりました。
伸張する ： ATI, S3, Matrox, Intel
伸張しない ： nVidia, ST Microelectronics(KYRO)
144 ：大田遺産：03/04/20 23:02
>>142 ゲゲーー。ということは俺はG550ユーザー（Ti4600もサブ機に付けて
いるが）だからYC伸張してるグラボにさらにYC伸張かけたWMVで２重伸張
されたものをみてたわけか？どうりでDVDMAXでのTV出力でやけに画像が
明るいとおもった。でもCRTのオーバーレイではオリジナルMPEG2（MTV2000）
と俺の作ったWMV9の輝度と色調が同じなんだよな（エロアニメでの肌色の
確認にて・けっこうはっきりわかる）。結局どのやり方が正しいんでしょか？
（Ti4600ではオーバーレイが汚いかつTV出力オーバースキャンせずの２重苦で
見る気がせん。）
いるが）だからYC伸張してるグラボにさらにYC伸張かけたWMVで２重伸張
されたものをみてたわけか？どうりでDVDMAXでのTV出力でやけに画像が
明るいとおもった。でもCRTのオーバーレイではオリジナルMPEG2（MTV2000）
と俺の作ったWMV9の輝度と色調が同じなんだよな（エロアニメでの肌色の
確認にて・けっこうはっきりわかる）。結局どのやり方が正しいんでしょか？
（Ti4600ではオーバーレイが汚いかつTV出力オーバースキャンせずの２重苦で
見る気がせん。）
＞大田遺産
そもそも、どうして最初にDVD2AVIでTVスケールにしているの？
あなたの使い方の場合、ここでPCスケールにするのが普通だと思うけどなあ。
そもそも、どうして最初にDVD2AVIでTVスケールにしているの？
あなたの使い方の場合、ここでPCスケールにするのが普通だと思うけどなあ。
>>144
いや、WMV9 がエンコード時に圧縮してるから、気にしなくて良い
いや、WMV9 がエンコード時に圧縮してるから、気にしなくて良い
DVD2AVIのやつはAVI出力時のみ反映されるんじゃなかったっけ
148 ：名無しさん＠編集中：03/04/20 23:08
>>137
マジでカノプラデにのりかえるの？
マジでカノプラデにのりかえるの？
>>145のいうように、できるだけ伸張・圧縮の回数を減らすようにした方がよい。
大多数の人間は、RGBではPCスケールで処理するとおもう。
DVD2AVI ：YUV(YV12)->RGB(RGB24) ここでPCスケールにする
TMPGEnc ：RGB24
AviUtl ：RGB??
VFAPI ：RGB24
WME ：YUV(YV12) BT.601準拠の標準YUVに変換してくれる
こうすればAviUtlで伸張しないで良い。
大体、情報量はできるだけ無くさないように処理することを心がける。
圧縮->伸張するとデータの詳細な点が無くなる
最初にTVスケールにする特殊な場合を使う人は、特定の目的のために
メリット・デメリットをしっかり把握してその上でやってるわけ。
大多数の人間は、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にに突っかかってるわけじゃないからよろしく。
カノープスでは動画はBT.601準拠に準拠したレベルで作られているということが常識とされていて
エンコードの段階でYC伸張して調整してある動画は異端であるかのような扱いだ。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
136にに突っかかってるわけじゃないからよろしく。
誤字多すぎ、漏れ・・・・。
154 ：名無しさん＠編集中：03/04/20 23:34
>>152
いやいや、
BT.601準拠に準拠したレベルの動画を、オーバーレイの調整で伸張するのは
カノープスにとっては普通ではないという書き方がされてるんであって、
（「●オーバーレイ領域の映像調整でコントラストを上げても、あまり良くならない」の部分）
エンコードの段階でYC伸張して調整してある動画のことなんてどこにも出てこないよ。
いやいや、
BT.601準拠に準拠したレベルの動画を、オーバーレイの調整で伸張するのは
カノープスにとっては普通ではないという書き方がされてるんであって、
（「●オーバーレイ領域の映像調整でコントラストを上げても、あまり良くならない」の部分）
エンコードの段階でYC伸張して調整してある動画のことなんてどこにも出てこないよ。
>>150
今TMPGEncで確認してみた。プロジェクト経由でもしっかりPC/TV Scale指定は反映されてた。
色空間をYUVに指定しても、DVD2AVIのプロジェクトVFAPIプラグインで必ずRGB24に変換されるみたい。
あと、変換時に範囲オーバーの値がカットされるのを心配しているようだが、
カノプのMTVだったらその点は問題ないと思う。
圧縮->伸張すると色分布に隙間が開くデメリットがある。
（つまり隣り合わせの似た色の差が同じになるデメリットがある。色情報が潰れる）
今TMPGEncで確認してみた。プロジェクト経由でもしっかりPC/TV Scale指定は反映されてた。
色空間をYUVに指定しても、DVD2AVIのプロジェクトVFAPIプラグインで必ずRGB24に変換されるみたい。
あと、変換時に範囲オーバーの値がカットされるのを心配しているようだが、
カノプのMTVだったらその点は問題ないと思う。
圧縮->伸張すると色分布に隙間が開くデメリットがある。
（つまり隣り合わせの似た色の差が同じになるデメリットがある。色情報が潰れる）
カノプーのページで書かれてることはbt.601準拠の映像データがオーバーレイでどう表示されるのかが書かれてるだけだね。
エンコードするのにYC伸張するのが正しいのか誤りなのかは書かれていないね。
エンコードするのにYC伸張するのが正しいのか誤りなのかは書かれていないね。
157 ：名無しさん＠編集中：03/04/20 23:53
あちらこちらのスレで、エンコの仕方について
偉そうに能書きたれている人を見かけるけれど
世間に出回っている動画を見ると
しょぼいペグ１ばかりが目につく。
はやりのアプロダなんかをチェックしてても
高画質な動画なんかどこにもない。
ということは、えらそうな口をきいているやつらも
実力のないアホばかりということらしい。
偉そうに能書きたれている人を見かけるけれど
世間に出回っている動画を見ると
しょぼいペグ１ばかりが目につく。
はやりのアプロダなんかをチェックしてても
高画質な動画なんかどこにもない。
ということは、えらそうな口をきいているやつらも
実力のないアホばかりということらしい。
>>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使用
なので再生時伸張される
つまりｿｰｽとｴﾝｺ後でﾃﾞｰﾀのｽｹｰﾘﾝｸﾞも再生時の動作も一緒
あってるじゃん
しょーがないから詳細に説明
>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使用
なので再生時伸張される
つまりｿｰｽとｴﾝｺ後でﾃﾞｰﾀのｽｹｰﾘﾝｸﾞも再生時の動作も一緒
あってるじゃん
>>150
>>155
まぁどっちにしろ伸張してRGBになる作業がはいると白ﾄﾋﾞ黒つぶれはさけられない
ただその問題はTV出力した場合にかぎるし
避けようとするといかなる段階でも伸張せずに
YUVのままでｴﾝｺｰﾀﾞまでもってかなきゃならんのでｽｷﾙがいる
ぶっちゃけAVIsynthか、どうしてもAVIutl使うならHuffyuvSで中間ﾌｧｲﾙを出すしかない
つーか、だからHuffyuvSがつくられたんでしょう
勿論RGBになる段で伸張しないという手もあるが
その場合はｴﾝｺｰﾀﾞの設定で伸張されてないことをはっきりさせる必要がある
TMPGEncやCCEはその設定があるんだが他のｴﾝｺｰﾀﾞはｼﾗｿ
>>155
まぁどっちにしろ伸張してRGBになる作業がはいると白ﾄﾋﾞ黒つぶれはさけられない
ただその問題はTV出力した場合にかぎるし
避けようとするといかなる段階でも伸張せずに
YUVのままでｴﾝｺｰﾀﾞまでもってかなきゃならんのでｽｷﾙがいる
ぶっちゃけAVIsynthか、どうしてもAVIutl使うならHuffyuvSで中間ﾌｧｲﾙを出すしかない
つーか、だからHuffyuvSがつくられたんでしょう
勿論RGBになる段で伸張しないという手もあるが
その場合はｴﾝｺｰﾀﾞの設定で伸張されてないことをはっきりさせる必要がある
TMPGEncやCCEはその設定があるんだが他のｴﾝｺｰﾀﾞはｼﾗｿ
>>158
＞ｿｰｽから見るとYUV．．．
分かりにくい。
単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。
ところで、微妙な表現に関して。（説明の省略だってことは分かってる）
YUV(0)->RGB(0)になるわけじゃない。（普通はならない YUV(0,128,128)->(0,0,0)にはなるけど）
独り言
●PCスケール、TVスケールって、YUVの場合で言うのはなんかしっくりこない
●RGB(TVスケール)にしてたって、その後、伸張しちゃったら意味は無い。
（この場合は伸張せずに最後まで処理しないとTVスケールにした意味は無い）
（または、手動色補正で伸張作業を行いPCスケールにまでもっていくこと）
＞ｿｰｽから見るとYUV．．．
分かりにくい。
単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。
ところで、微妙な表現に関して。（説明の省略だってことは分かってる）
YUV(0)->RGB(0)になるわけじゃない。（普通はならない YUV(0,128,128)->(0,0,0)にはなるけど）
独り言
●PCスケール、TVスケールって、YUVの場合で言うのはなんかしっくりこない
●RGB(TVスケール)にしてたって、その後、伸張しちゃったら意味は無い。
（この場合は伸張せずに最後まで処理しないとTVスケールにした意味は無い）
（または、手動色補正で伸張作業を行いPCスケールにまでもっていくこと）
>>159
＞ただその問題はTV出力した場合にかぎるし
何言ってんの？
中間ファイル出力なんて誰も言ってないし、
そこまで気を配る人は詳細情報の欠損を気にして、HuffyuvでもRGBで保存するはず。
＞ただその問題はTV出力した場合にかぎるし
何言ってんの？
中間ファイル出力なんて誰も言ってないし、
そこまで気を配る人は詳細情報の欠損を気にして、HuffyuvでもRGBで保存するはず。
>>160
>単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。
それも思ったんだが受け渡しはRGBなんだが内部処理が違うもんが入ってるんで
こっちのがわかりいいか、と
ちなみにそれはAVIutl
内部YUV24ﾋﾞｯﾄ（なんと4:4:4YUV）処理で色調補正系ﾌｨﾙﾀとﾓﾆﾀ表示はRGB24ﾋﾞｯﾄ変換（あたりまえ）というｷﾃﾚﾂ仕様
しかもYUV<>RGBは古い計算式で誤差盛りだくさん
いや、色調補正はRGB32ﾋﾞｯﾄたったかも・・・
>単純に、一旦YUV->RGBに変換後は、あとは常にRGBで受け渡されているだけと言えば。
それも思ったんだが受け渡しはRGBなんだが内部処理が違うもんが入ってるんで
こっちのがわかりいいか、と
ちなみにそれはAVIutl
内部YUV24ﾋﾞｯﾄ（なんと4:4:4YUV）処理で色調補正系ﾌｨﾙﾀとﾓﾆﾀ表示はRGB24ﾋﾞｯﾄ変換（あたりまえ）というｷﾃﾚﾂ仕様
しかもYUV<>RGBは古い計算式で誤差盛りだくさん
いや、色調補正はRGB32ﾋﾞｯﾄたったかも・・・
>>161
ｵﾚがいったのはRGB(PC Scale)に途中でするとｸﾛｯﾌﾟされる情報があるよ、ってことだけ
またｿｰｽか途中段で伸張せずにHuffyuv RGB(TV Scaleなら)にするなら確かに問題はないね
ぶっちゃけTMPGEncなら伸張せずにHuffyuv RGB
CCEならHuffyuvS YUY2が一番なんだが
途中段で処理間違ったらどーもこーもだがな
ｵﾚがいったのはRGB(PC Scale)に途中でするとｸﾛｯﾌﾟされる情報があるよ、ってことだけ
またｿｰｽか途中段で伸張せずにHuffyuv RGB(TV Scaleなら)にするなら確かに問題はないね
ぶっちゃけTMPGEncなら伸張せずにHuffyuv RGB
CCEならHuffyuvS YUY2が一番なんだが
途中段で処理間違ったらどーもこーもだがな
>>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 で処理するものがある
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 で処理するものがある
GF4使っててffdshowで伸張する場合レベルのインプットを16-235でいいの？
>>154
んじゃ、カノプの言うままに調整した環境で「エンコードの段階でYC伸張して調整してある動画」を
再生するとどうなるよ？
普通の動画(BT601準拠)と「エンコードの段階でYC伸張して調整してある動画」を再生するたびに調整しなおす？
んじゃ、カノプの言うままに調整した環境で「エンコードの段階でYC伸張して調整してある動画」を
再生するとどうなるよ？
普通の動画(BT601準拠)と「エンコードの段階でYC伸張して調整してある動画」を再生するたびに調整しなおす？
167 ：大田遺産：03/04/21 00:47
>>127様他の皆様方、さまざまな意見、アドバイスをどうもありがとう。自分
のエンコのやり方がマチガっていなくて安心しました。理論的なことがよく
わからんかったのでCRTでのみ（色々なスレをみながら）確認していたので
自信がもてなかった（以前にDixXでエンコしてたときはDVD2AVIでTV Scale
そしてAviUtlでそのまま（拡張色調補正OFF）でやってて出来上がりの動画・
エロAVがどうしても肌色が薄いというか暗いというかそんな感じであれー
なんかちがうなーと思ってた）。そこでたまたまYC伸張スレを見て思い切
ってみんなはどーやっているのか聞いてみたわけです。どーもありがとー、
でわまたあうひまで（といいつつすぐ書くかもしれんが）。
のエンコのやり方がマチガっていなくて安心しました。理論的なことがよく
わからんかったのでCRTでのみ（色々なスレをみながら）確認していたので
自信がもてなかった（以前にDixXでエンコしてたときはDVD2AVIでTV Scale
そしてAviUtlでそのまま（拡張色調補正OFF）でやってて出来上がりの動画・
エロAVがどうしても肌色が薄いというか暗いというかそんな感じであれー
なんかちがうなーと思ってた）。そこでたまたまYC伸張スレを見て思い切
ってみんなはどーやっているのか聞いてみたわけです。どーもありがとー、
でわまたあうひまで（といいつつすぐ書くかもしれんが）。
168 ：名無しさん＠編集中：03/04/21 00:51
>>166
そういうこと。
フルスケールのYUVデータを作ってしまってた人はご愁傷様。
だから、>>109の言うようにBT.601準拠のデータを作りましょうという話なのさ。
そもそも伸張しないチップのユーザーがカノプの言うようにちゃんと調整してれば
「エンコードの段階でYC伸張して調整してしまった動画」なんて作りようがない。
そういうこと。
フルスケールのYUVデータを作ってしまってた人はご愁傷様。
だから、>>109の言うようにBT.601準拠のデータを作りましょうという話なのさ。
そもそも伸張しないチップのユーザーがカノプの言うようにちゃんと調整してれば
「エンコードの段階でYC伸張して調整してしまった動画」なんて作りようがない。
>>166
カノプは別に、Geforceに合わせて伸張しろとは言ってない。
言っていることは、
『オーバーレイにすると暗くなるけど、そのために伸張して明るくするのはダメ、
むしろ伸張せずにオーバーレイの方をなんとか調整して普通に見えるようにしたほうが良い』
って良いこと言っていると思うけど。
カノプは別に、Geforceに合わせて伸張しろとは言ってない。
言っていることは、
『オーバーレイにすると暗くなるけど、そのために伸張して明るくするのはダメ、
むしろ伸張せずにオーバーレイの方をなんとか調整して普通に見えるようにしたほうが良い』
って良いこと言っていると思うけど。
>>166
「エンコードの段階でYC伸張して調整してある動画」なんて存在
するのか？
BT.601 形式の YUV を、YUV でフルスケールに拡大するとしたら
TMPGEnc でフルスケール RGB を BasicYCbCr でエンコードする
ぐらいの方法しかないと思うのだが。
エンコーダ（CODEC）が RGB -> YUV の際に、RGB フルスケール
から BT.601 スケール YUV に変更するから、YUV から RGB に変
換するときには BT.601 スケール YUV からフルスケール RGB に
変換するって、それだけのことしかやってないぞ。
「エンコードの段階でYC伸張して調整してある動画」なんて存在
するのか？
BT.601 形式の YUV を、YUV でフルスケールに拡大するとしたら
TMPGEnc でフルスケール RGB を BasicYCbCr でエンコードする
ぐらいの方法しかないと思うのだが。
エンコーダ（CODEC）が RGB -> YUV の際に、RGB フルスケール
から BT.601 スケール YUV に変更するから、YUV から RGB に変
換するときには BT.601 スケール YUV からフルスケール RGB に
変換するって、それだけのことしかやってないぞ。
読み違えた。メンゴ
>>170
そういうもっともな事じゃなくて、
巷には何と！色補正でYC伸張(別にTMPGEncでもAviUtlでもなんでも良い）してから
エンコした動画が出回ってるわけ。
（当然カノプのいうように、白飛び、黒潰れのクソ動画になってるわけ）
そういうもっともな事じゃなくて、
巷には何と！色補正でYC伸張(別にTMPGEncでもAviUtlでもなんでも良い）してから
エンコした動画が出回ってるわけ。
（当然カノプのいうように、白飛び、黒潰れのクソ動画になってるわけ）
>>170
GeforceはYUV→RGB変換がストレート変換なので
エンコード後のデータをフルスケールYUVになるようにしておかないと
BT.601 スケール YUV → フルスケール RGB と同じに見えないらしい。
GeforceはYUV→RGB変換がストレート変換なので
エンコード後のデータをフルスケールYUVになるようにしておかないと
BT.601 スケール YUV → フルスケール RGB と同じに見えないらしい。
>>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)にサチュレーションされるみたいだから
さらに情報が欠損するけど。
DivXでもXviDでもRGB->YUV変換時、サチュレーチョンなぞしてない。
つまり、通常は色バランスが崩れているから、RGB(PC Scale)->YUV(TV Scale)に変換後でも
YUVで、16-235(240)を外れたデータが出来てしまう。
（極端なことをいったら、YUV=(255,128,128)はBT.601準拠で変換しても範囲内に収まる）
TMPGEncで普通にエンコしたら、必ず16-235(240)にサチュレーションされるみたいだから
さらに情報が欠損するけど。
DVソース→Avisynth→HuffyuvS→CCE
の場合はColorYUY2で411->422にしておくのが適当かな。
オーサリング前提です。
の場合はColorYUY2で411->422にしておくのが適当かな。
オーサリング前提です。
えーとつまり・・・huffyuvS(YUY2)の0-16,235-255部分を
犠牲にしたくないならAviutil使ってる時点でもうアウト？
どうしてもAviutilを使いたいならhuffyuvSの
Convert YUY2形式で中間を吐けばOK？
犠牲にしたくないならAviutil使ってる時点でもうアウト？
どうしてもAviutilを使いたいならhuffyuvSの
Convert YUY2形式で中間を吐けばOK？
>>178
意味わからん。
huffyuvS(YUY2)だったら、YUY2なんでしょ。AviUtl使っても大丈夫だよ。
AviUtlのYUV444(12bit)なら、オーバーフローなんてしないし。
どうしてConvertYUY2なんて出てくるの？そのままYUY2で出力すれば？
意味わからん。
huffyuvS(YUY2)だったら、YUY2なんでしょ。AviUtl使っても大丈夫だよ。
AviUtlのYUV444(12bit)なら、オーバーフローなんてしないし。
どうしてConvertYUY2なんて出てくるの？そのままYUY2で出力すれば？
知恵熱出てきた(つд`)
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部分が
ちょびひげ程度なのか、フルレンジびったりなのか、
犠牲の意味が、切り捨てされることなのか、スケールを圧縮しなくちゃならんことなのか
それが分からないと第三者にはどうするのが良いかは分からないよ。
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部分が
ちょびひげ程度なのか、フルレンジびったりなのか、
犠牲の意味が、切り捨てされることなのか、スケールを圧縮しなくちゃならんことなのか
それが分からないと第三者にはどうするのが良いかは分からないよ。
>>179
AviutilからhuffyuvS(YUY2)で出力するとYC圧縮かかっちゃうので。
>>181
｢犠牲｣は切り捨ての意味で使いました。
やはりConvertYUY2で中間ファイル吐いた方がいいみたいですね。
メインで使ってるWMV9がRGB(0-255)→YUY2(0-255)変換できれば
わざわざ中間ファイルいらないのになぁ
AviutilからhuffyuvS(YUY2)で出力するとYC圧縮かかっちゃうので。
>>181
｢犠牲｣は切り捨ての意味で使いました。
やはりConvertYUY2で中間ファイル吐いた方がいいみたいですね。
メインで使ってるWMV9がRGB(0-255)→YUY2(0-255)変換できれば
わざわざ中間ファイルいらないのになぁ
>>172
それは茂木とあにぺぐのせいのような・・・
書かれた当時と状況が違うとはいえ
ﾈｯﾄってﾔｼはずっとそのときの情報がｸﾞﾙｸﾞﾙ回ってたりするからな
今は変更されたが茂木なんか「CanopusDVをｽﾄﾚｰﾄで扱うのはおかしい」みたいなこと書いてたでしょ
それは茂木とあにぺぐのせいのような・・・
書かれた当時と状況が違うとはいえ
ﾈｯﾄってﾔｼはずっとそのときの情報がｸﾞﾙｸﾞﾙ回ってたりするからな
今は変更されたが茂木なんか「CanopusDVをｽﾄﾚｰﾄで扱うのはおかしい」みたいなこと書いてたでしょ
>>181
色補正は、TV→PCスケール変換 後の値に補正値が掛けられるの？
もしそうだったらチェックを外すと補正値じゃ若干大きくなるから
補正時にはその分小さく（0.7倍程度にする？）設定しないといけない？
色補正は、TV→PCスケール変換 後の値に補正値が掛けられるの？
もしそうだったらチェックを外すと補正値じゃ若干大きくなるから
補正時にはその分小さく（0.7倍程度にする？）設定しないといけない？
PCでしか見ないなら伸張する、TV出力するなら伸張しない
なんてわめいてる奴の方がよっぽど罪が重いと思うがな。
なんてわめいてる奴の方がよっぽど罪が重いと思うがな。
PCのみに限定してても伸張するとコントラストがえぐくなりすぎてダメだ。
どんどん訳わかめになっていく。
huffyuvでUYVYキャプしてそのままCCEで縁故するのはだめなんですか？
huffyuvでUYVYキャプしてそのままCCEで縁故するのはだめなんですか？
188 ：名無しさん＠編集中：03/04/22 00:17
YC 伸張 (わいしーしんちょう)
YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
行う一部 CODEC （Canopus DV など）の仕様をユーザレベルで回避するた
めの緊急回避的処理。
通常は CODEC の YUV -> RGB 変換の際に同時に伸張処理が行われるので
使用してはいけない。また YUV データのまま、RGB に変換せずに処理す
るばあいも、使用してはいけない。
常識だと思ってたのだけど、不安になったので書いとく。
YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
行う一部 CODEC （Canopus DV など）の仕様をユーザレベルで回避するた
めの緊急回避的処理。
通常は CODEC の YUV -> RGB 変換の際に同時に伸張処理が行われるので
使用してはいけない。また YUV データのまま、RGB に変換せずに処理す
るばあいも、使用してはいけない。
常識だと思ってたのだけど、不安になったので書いとく。
>>189
確かに常識だ。
ただし、HuffyuvSでもYUY2で入出力せずに、RGBでの入出力する場合は、
＞YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
＞行う一部 CODEC
に該当するってだけ。
確かに常識だ。
ただし、HuffyuvSでもYUY2で入出力せずに、RGBでの入出力する場合は、
＞YUV -> RGB 変換において、BT.601 スケールを考慮せずストレート変換を
＞行う一部 CODEC
に該当するってだけ。
huffyuvSでキャプ（0-255)、そのままTMPGEncで伸張せずにBT601にてエンコしたものは
PCで見ると(16-235)だが、ﾏﾄ様でTV出力すれば問題なし、ってことでOK?
PCで見ると(16-235)だが、ﾏﾄ様でTV出力すれば問題なし、ってことでOK?
>>191
YUV -(ストレート)-> RGB -(圧縮)-> YUV になるけど
キャプチャ時に YUV で (0-255) まできっちり広がるように
設定を詰めてるんなら問題なし
>PCで見ると(16-235)だが
ハードウェアオーバレイで伸張しない VGA で見ればなら問題なし
パソコン色調のDVD2AVIで見ても(16-235)なら問題あり
>ﾏﾄ様でTV出力
DVDMax はデフォルトだと BT.601 からさらに伸張かけるので基準に
使わない方がいい (自分で調整済みなら別)
YUV -(ストレート)-> RGB -(圧縮)-> YUV になるけど
キャプチャ時に YUV で (0-255) まできっちり広がるように
設定を詰めてるんなら問題なし
>PCで見ると(16-235)だが
ハードウェアオーバレイで伸張しない VGA で見ればなら問題なし
パソコン色調のDVD2AVIで見ても(16-235)なら問題あり
>ﾏﾄ様でTV出力
DVDMax はデフォルトだと BT.601 からさらに伸張かけるので基準に
使わない方がいい (自分で調整済みなら別)
>>180
同じく…
で、質問なんでスが、2Passエンコしたいがために今まで
1. Huffyuv（YUY2)でキャプって、
2. AviUtlで処理してHuffyuv（YUY2で展開・圧縮・圧縮設定保持）で出力
3. VDub使って2Passエンコ
ってしてたんだけど、これだと2の段階で余計な伸張・圧縮が起きてるってこと？
>>1 の表を見るとモロにそういうことになるみたいなんだけど…
どうしたら回避できるんですか？
同じく…
で、質問なんでスが、2Passエンコしたいがために今まで
1. Huffyuv（YUY2)でキャプって、
2. AviUtlで処理してHuffyuv（YUY2で展開・圧縮・圧縮設定保持）で出力
3. VDub使って2Passエンコ
ってしてたんだけど、これだと2の段階で余計な伸張・圧縮が起きてるってこと？
>>1 の表を見るとモロにそういうことになるみたいなんだけど…
どうしたら回避できるんですか？
>>193
AviUtlは処理ビット数が大きいため変換誤差は気にすることはないと思われ。
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は使ったことないが、それを考慮して再生時に調節されるんだろうな。
------------------------------------------------------------------------------------
Q: 録画したファイルを再生すると色が薄い。
A: PCのディスプレイとテレビでは仕組みが違うので、そういうもん。テレビで見るときれいに映る。
------------------------------------------------------------------------------------
先日MTV2000を購入して初のキャプチャをしまして、出来たm2pファイルを
メディアプレーヤで見ようとしたのですが、何か画面がとても暗いんです。
G-Specで見ると普通なんですが、メディアプレーヤ（6.4と7と9で確認）では
明らかに暗いです。
これはテンプレにある、「録画したファイルを再生すると色が薄い。 」って
やつのことでしょうか？
だとしたら、皆さんどうやって見てますか？
------------------------------------------------------------------------------------
MTVのキャプチャはTV出力したときに普通の色になるようにキャプチャされるから、
当然PCのモニタで見た場合には暗い感じになる。
G-Specは使ったことないが、それを考慮して再生時に調節されるんだろうな。
>>193
せっかく中間ファイル吐くんなら
1.HuffyuvS(YUY2)でキャプ
2.AviutilでYUY2展開・圧縮ノーチェックで読み込んで
HuffyuvS(Convert YUY2)で中間ファイル出力
3.VDubの再圧縮（高速）でエンコ
がいいかと（手間も一緒だし）。
途中でYC伸張・圧縮されないから
0-15,236-255の範囲も保持される。
せっかく中間ファイル吐くんなら
1.HuffyuvS(YUY2)でキャプ
2.AviutilでYUY2展開・圧縮ノーチェックで読み込んで
HuffyuvS(Convert YUY2)で中間ファイル出力
3.VDubの再圧縮（高速）でエンコ
がいいかと（手間も一緒だし）。
途中でYC伸張・圧縮されないから
0-15,236-255の範囲も保持される。
・・・ん？
伸長しない方が良いってなってるけど、AVIUTLでYUVで保存するなら
（つーかDirectXの規定ではRGBはフルスケールで扱いYUVは16-235
で扱うことになってるから）画面に表示された状態では伸長しとかな
いとまずいんでは？
YUVに再変換されるときにYC圧縮かかる訳だし。
YUV読み込みで既に伸長されている物を更に伸長するのはあれだが。
YUV出力しないなら話は別な。
もっとも伸長圧縮しないでYUVのまま回せれれば一番いいんだが。
伸長しない方が良いってなってるけど、AVIUTLでYUVで保存するなら
（つーかDirectXの規定ではRGBはフルスケールで扱いYUVは16-235
で扱うことになってるから）画面に表示された状態では伸長しとかな
いとまずいんでは？
YUVに再変換されるときにYC圧縮かかる訳だし。
YUV読み込みで既に伸長されている物を更に伸長するのはあれだが。
YUV出力しないなら話は別な。
もっとも伸長圧縮しないでYUVのまま回せれれば一番いいんだが。
>>197
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html
↑を見る限りでは>>196の通りにすれば
YUVに再変換する際にYC圧縮されないんじゃ？
確かにAviutilで編集するとき（PCモニタ上で）
一時的にPCスケールにしておいた方が
フィルタの調整はやりやすいと思うけどね。
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html
↑を見る限りでは>>196の通りにすれば
YUVに再変換する際にYC圧縮されないんじゃ？
確かにAviutilで編集するとき（PCモニタ上で）
一時的にPCスケールにしておいた方が
フィルタの調整はやりやすいと思うけどね。
0-15,236-255を無駄にしたくないって人いるけど、
その範囲って、画面の何割も占めたり重要なピクセルなの？
自分は16-235に収めて、その範囲外はノイズだったりシュートしてオーバーした部分程度だったりするんだけど。
その範囲って、画面の何割も占めたり重要なピクセルなの？
自分は16-235に収めて、その範囲外はノイズだったりシュートしてオーバーした部分程度だったりするんだけど。
>DirectXの規定ではRGBはフルスケールで扱いYUVは16-235
で扱うことになってるから
それはオーバーレイの話ですな
AVIutlのデフォルト表示はGDIですがな
で扱うことになってるから
それはオーバーレイの話ですな
AVIutlのデフォルト表示はGDIですがな
>200
いや、そういう意味で言ってる訳じゃなくて、動画の格納形式の意味
で言っているんだけど、RGB格納だと0-255でYUVだと16-235で収まって
いないといけないって意味で
YUVで格納するときは16-235で納めるのは前提としてこのスケールで
格納するためには画面表示は0-255にしておかなきゃいけないんじゃ
ないかなってこと。
VFAPIで他のソフトに渡すなら伸長する必要はないんだけど。
保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしまうと思うんですが。
98系と97以前で動作が違うからややこしいね^^;;;
DirectXってYUV-RGBの時VGA側で伸長するのかCODEC側で伸長するの
か定義してないんだよな。
だからこんなややこしいことになるんじゃないかと。
いや、そういう意味で言ってる訳じゃなくて、動画の格納形式の意味
で言っているんだけど、RGB格納だと0-255でYUVだと16-235で収まって
いないといけないって意味で
YUVで格納するときは16-235で納めるのは前提としてこのスケールで
格納するためには画面表示は0-255にしておかなきゃいけないんじゃ
ないかなってこと。
VFAPIで他のソフトに渡すなら伸長する必要はないんだけど。
保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしまうと思うんですが。
98系と97以前で動作が違うからややこしいね^^;;;
DirectXってYUV-RGBの時VGA側で伸長するのかCODEC側で伸長するの
か定義してないんだよな。
だからこんなややこしいことになるんじゃないかと。
>>197
ひょっとするとHuffyuvSを知らないのでは？
Huffyuvの話じゃないよ
つーか
>>1なり>>198なりのﾘﾝｸ先みてる？
>保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしま
いません
逆にAVIutlに伸張させてYUVで保存すると15以下や236以上はｸﾘｯﾌﾟされる
実際に伸張させてYUV保存したﾓﾉを読み込んでﾋｽﾄｸﾞﾗﾑみてごらん
見事にｸﾘｯﾌﾟされちゃうから
ひょっとするとHuffyuvSを知らないのでは？
Huffyuvの話じゃないよ
つーか
>>1なり>>198なりのﾘﾝｸ先みてる？
>保存するときに伸長掛けないでYUVで保存すると16-235が更に圧縮さ
れて色あせてしま
いません
逆にAVIutlに伸張させてYUVで保存すると15以下や236以上はｸﾘｯﾌﾟされる
実際に伸張させてYUV保存したﾓﾉを読み込んでﾋｽﾄｸﾞﾗﾑみてごらん
見事にｸﾘｯﾌﾟされちゃうから
ぶっちゃけAVIutlのYUV展開・圧縮の動作がおかしいだけなんだけどね
205 ：名無しさん＠編集中：03/04/23 22:41
一般化して話をするのは難しいよね。
だから単純にYC伸張するのしないのというんではアテにならない。
こういう話をするときは、アプリとCODEC、そのオプションなど前提をハッキリさせておかないとおかしいことになりますね。
だから単純にYC伸張するのしないのというんではアテにならない。
こういう話をするときは、アプリとCODEC、そのオプションなど前提をハッキリさせておかないとおかしいことになりますね。
HuffyuvSソースではないキャプったmpeg2ソースの場合、
m2v.vfp (ストレート)でAviUtlに渡せば 0-15,236-255 の範囲は保持されるの？
m2v.vfp (ストレート)でAviUtlに渡せば 0-15,236-255 の範囲は保持されるの？
あとGDI表示ｱﾌﾟﾘは画面表示にDirectX通さないと思うが？
実際AVIutlもcodecの展開した値（無論ここでDirectShowはよびだされることもある）を内部で自前でRGBにして表示するんだけど
だからYUV展開するときはAVIutlが伸張し
圧縮するときはAVIutl自身が圧縮するわけだ
で、その動作がDirectX上の動作ともBT.601の動作とも違う、と
だからAVIutlで展開、圧縮せずにcodecでやろう、と
そういう話なんだけど？
実際AVIutlもcodecの展開した値（無論ここでDirectShowはよびだされることもある）を内部で自前でRGBにして表示するんだけど
だからYUV展開するときはAVIutlが伸張し
圧縮するときはAVIutl自身が圧縮するわけだ
で、その動作がDirectX上の動作ともBT.601の動作とも違う、と
だからAVIutlで展開、圧縮せずにcodecでやろう、と
そういう話なんだけど？
>>206
される
なぜなら
ｿｰｽはYUV(のうちこの場合はYV12)ということは
ﾃﾞｰﾀ上は(0-255)を持ち、ｵｰﾊﾞｰﾚｲ表示するときは伸張される（のが正しい）ﾃﾞｰﾀ形式を持つ
そしてm2v.vfp はVFAPIなのでAVIutlからはRGBとしてみえる
しかもｽﾄﾚｰﾄを選んでいるのでこのRGB(0-255)はｿｰｽのYUV(0-255)を持つ（厳密には”ほぼ”だけどね）
伸張、圧縮をおこなってないので伸張、圧縮によるﾃﾞｰﾀ欠損はない
される
なぜなら
ｿｰｽはYUV(のうちこの場合はYV12)ということは
ﾃﾞｰﾀ上は(0-255)を持ち、ｵｰﾊﾞｰﾚｲ表示するときは伸張される（のが正しい）ﾃﾞｰﾀ形式を持つ
そしてm2v.vfp はVFAPIなのでAVIutlからはRGBとしてみえる
しかもｽﾄﾚｰﾄを選んでいるのでこのRGB(0-255)はｿｰｽのYUV(0-255)を持つ（厳密には”ほぼ”だけどね）
伸張、圧縮をおこなってないので伸張、圧縮によるﾃﾞｰﾀ欠損はない
HuffyuvSをAvisynthを通してReadAVS.dllでTMPGEncに読ましたら
伸張されるような気がするんだけど、こういう場合はどうしたらいいの？
伸張されるような気がするんだけど、こういう場合はどうしたらいいの？
.aui登録するとAVIutlのcodecの設定のとこにm2vでるの？
出るならそのとおりだが
でなけりゃ・・・
あ！？
出ないときはｽﾄﾚｰﾄRGB読み込みだからどっちにしろ伸張されないな
出るならそのとおりだが
でなけりゃ・・・
あ！？
出ないときはｽﾄﾚｰﾄRGB読み込みだからどっちにしろ伸張されないな
>>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で渡されるかどうかは自分で確認すること。（｢ファイルの情報｣で見れる）
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で渡されるかどうかは自分で確認すること。（｢ファイルの情報｣で見れる）
>HuffyuvSでストレート変換するというのは、このYC圧縮->YC拡張に相当する作業）
というのがわからんなぁ
>>196でやってるのは
YUV444->RGB24->YUY2であって
YC圧縮->YC拡張に相当しないと思うが？
>ストレート変換YUV->RGBの時に大きく質を落とす
のは同意だが、AVIutlを使いたいとなると・・・
しかもそのあとVirtualDUBやCCEに突っ込むとなると・・・
というのがわからんなぁ
>>196でやってるのは
YUV444->RGB24->YUY2であって
YC圧縮->YC拡張に相当しないと思うが？
>ストレート変換YUV->RGBの時に大きく質を落とす
のは同意だが、AVIutlを使いたいとなると・・・
しかもそのあとVirtualDUBやCCEに突っ込むとなると・・・
>>210
コーデックのトコには全く出ませんでした(;´Д`)
ってカキコした後から試してみましたが、
1：キャプソースmpeg2→m2v.vfp(ストレート)→AviUtl
2：キャプソースmpeg2→m2v.aui→AviUtl（PC -> TV スケール補正）
これらはヒストグラム上で全く同じでした。
>>214
こちらもレス有り難うございます。
AviUtlにYUY2で扱うと、
>おまけとして16-235(240)にカットされる
よって劣化が生じると、、、
ちなみにファイル情報では「ビデオ圧縮」「ビデオ展開形式」ともに
YUY2と確認出来ました。
コーデックのトコには全く出ませんでした(;´Д`)
ってカキコした後から試してみましたが、
1：キャプソースmpeg2→m2v.vfp(ストレート)→AviUtl
2：キャプソースmpeg2→m2v.aui→AviUtl（PC -> TV スケール補正）
これらはヒストグラム上で全く同じでした。
>>214
こちらもレス有り難うございます。
AviUtlにYUY2で扱うと、
>おまけとして16-235(240)にカットされる
よって劣化が生じると、、、
ちなみにファイル情報では「ビデオ圧縮」「ビデオ展開形式」ともに
YUY2と確認出来ました。
あと、
>YUY2出力時、YC圧縮と1/16倍に変換するけど
ってことは、上記216で（PC -> TV スケール補正）をかけた値が
ヒストグラム上同じでも、AVI出力時にはチェックを外さないと、
2度YC圧縮されているって事なんですね、、、
うーんイマイチ理解出来ない。
>YUY2出力時、YC圧縮と1/16倍に変換するけど
ってことは、上記216で（PC -> TV スケール補正）をかけた値が
ヒストグラム上同じでも、AVI出力時にはチェックを外さないと、
2度YC圧縮されているって事なんですね、、、
うーんイマイチ理解出来ない。
>>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？）
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？）
>>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とより詳細が潰れるということ。
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とより詳細が潰れるということ。
つまり、わかり易く言うと、
HuffyuvSで YUY2->RGB24->YUY2 するのは、
YC圧縮して、0-255の範囲を飛び出さないようにRGBに変換して、YC拡張してYUY2に戻すということ。
HuffyuvSで YUY2->RGB24->YUY2 するのは、
YC圧縮して、0-255の範囲を飛び出さないようにRGBに変換して、YC拡張してYUY2に戻すということ。
>>220
追記しておくと、
HuffyuvSで YUY2->RGB24 変換しても、0-255の範囲に納まるというわけではない。
それでも、範囲外の値になってカットされるものも出てくる。
ただし、実際面でいうとカットされるのは、BT.601と比べれば断然少ないので
目に見える影響は小さい（無視できる？といえるか）ということ。
追記しておくと、
HuffyuvSで YUY2->RGB24 変換しても、0-255の範囲に納まるというわけではない。
それでも、範囲外の値になってカットされるものも出てくる。
ただし、実際面でいうとカットされるのは、BT.601と比べれば断然少ないので
目に見える影響は小さい（無視できる？といえるか）ということ。
おまけ
以上のことは、視点を何処に置くかで表現は変わる。
HuffyuvSが、そのまま変換で、BT.601が拡張・圧縮すると言い換えることもできる。
（世の中の常識、世界的にみても、BT.601の方がノーマル変換という見方だけど）
言い方を変えたとしても、HuffyuvSの方が変換誤差が大きく出ることに違いはない。
以上のことは、視点を何処に置くかで表現は変わる。
HuffyuvSが、そのまま変換で、BT.601が拡張・圧縮すると言い換えることもできる。
（世の中の常識、世界的にみても、BT.601の方がノーマル変換という見方だけど）
言い方を変えたとしても、HuffyuvSの方が変換誤差が大きく出ることに違いはない。
ここまで言っててなんだけど、HuffyuvSを使う方が普通の人には悪影響が少ないだろう。
【推奨】
●YUY2のまま処理する。
（ただしNR等はフォーマットの弱点が出てYUV444,RGB24で処理するよりは劣化度は大きい。
でも最終的にMPEG圧縮するならあまり気にしないで良い程度）
どうしても、RGB変換が必要な場合
●色バランスが崩れていて、キャプチャの入力レベルが大きく、BT.601変換すると
範囲オーバーする場合は、HuffyuvSを使う
●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。
●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して、
色補正等でバランス、レベルを整えてからYUY2で出力する方がベター
【推奨】
●YUY2のまま処理する。
（ただしNR等はフォーマットの弱点が出てYUV444,RGB24で処理するよりは劣化度は大きい。
でも最終的にMPEG圧縮するならあまり気にしないで良い程度）
どうしても、RGB変換が必要な場合
●色バランスが崩れていて、キャプチャの入力レベルが大きく、BT.601変換すると
範囲オーバーする場合は、HuffyuvSを使う
●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。
●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して、
色補正等でバランス、レベルを整えてからYUY2で出力する方がベター
すばらしい
ちょっと訂正
＞【推奨】
＞●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とか掛けると話は違ってきて左右のピクセル値をブレンドした方が良くなる。
＞【推奨】
＞●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とか掛けると話は違ってきて左右のピクセル値をブレンドした方が良くなる。
【AviUtlへの要望】
BT.601も、16-235(240)が絶対じゃなくて、推奨であり 1～254までなら
存在しても良いことになってるんだから、
AviUtlも、サチュレートするかどうかチェックボタンを追加してくれないかな。
DivXもXviDも別にサチュレートしないわけだし。
BT.601も、16-235(240)が絶対じゃなくて、推奨であり 1～254までなら
存在しても良いことになってるんだから、
AviUtlも、サチュレートするかどうかチェックボタンを追加してくれないかな。
DivXもXviDも別にサチュレートしないわけだし。
＞○も
あなたが来ると盛りあがります
あなたが来ると盛りあがります
1. PIC（4/2/2)でキャプ
2. AviUtl（YUY2で展開するチェック無し）で読みこみ
YC伸張してHuffyuvで出力
3. VDubでFast recompressエンコ
としているのですが、この場合2のところを
2. AviUtl（YUY2で展開するチェック無し）で読みこみYC伸張せず
YUY2で圧縮するチェック無しでHuffyuvS（Convert to YUY2）で出力
とした方がよいのでしょうか？
2. AviUtl（YUY2で展開するチェック無し）で読みこみ
YC伸張してHuffyuvで出力
3. VDubでFast recompressエンコ
としているのですが、この場合2のところを
2. AviUtl（YUY2で展開するチェック無し）で読みこみYC伸張せず
YUY2で圧縮するチェック無しでHuffyuvS（Convert to YUY2）で出力
とした方がよいのでしょうか？
ストレート変換時にYC圧縮→拡大されてるってのが
イマイチ信じられん。ソースを提示してほしい。
＞●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して
このYUY2のコーデックは何？Huffyuv？
ひょっとして色空間とCodecを混同してないか？
イマイチ信じられん。ソースを提示してほしい。
＞●AviUtlを使う場合、HuffyuvSを使うよりは、YUY2で入力して
このYUY2のコーデックは何？Huffyuv？
ひょっとして色空間とCodecを混同してないか？
>>229
YUY2で入力するとき、CODECなんか関係あるのか？
Huffyuv = HuffyuvS (YUY2->YUY2の場合）
それとも、YUY2->YUY2時に色変換するバカなCODECが存在するとでも。
もっとちゃんと読んだら。
BT.601と比較したら、ストレート変換は圧縮・拡張するように見えるって書かれているじゃん。
見方を変えたら、BT.601の方が拡張・圧縮すると言い換えることもできると。
YUY2で入力するとき、CODECなんか関係あるのか？
Huffyuv = HuffyuvS (YUY2->YUY2の場合）
それとも、YUY2->YUY2時に色変換するバカなCODECが存在するとでも。
もっとちゃんと読んだら。
BT.601と比較したら、ストレート変換は圧縮・拡張するように見えるって書かれているじゃん。
見方を変えたら、BT.601の方が拡張・圧縮すると言い換えることもできると。
＞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変換する時点で
劣化は避けられないのには同意だけど。
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変換する時点で
劣化は避けられないのには同意だけど。
なんかストレート変換って言葉に騙されてないか？
YUV->RGB変換するのに、情報を落とさずに変換するためには
RGBは、-100～+400程度はないとダメなんだぞ。
結局、YUV<->RGBは、見方によって片方が拡張->圧縮する、もう片方が圧縮->拡張する
としか言えないのでは。
YUV->RGB変換するのに、情報を落とさずに変換するためには
RGBは、-100～+400程度はないとダメなんだぞ。
結局、YUV<->RGBは、見方によって片方が拡張->圧縮する、もう片方が圧縮->拡張する
としか言えないのでは。
>>233
ごめん、多分オレの目が節穴なんだろうけど「huffyuv(YUY2) の aviutl (YUY2 チェック)」 と
「huffyuv2 (YUY2) の aviutl (YUY2 チェック) 」の違いが何処にあるのか見つけられないんだ。
違いが何処にあるのか教えてくれないか？
ごめん、多分オレの目が節穴なんだろうけど「huffyuv(YUY2) の aviutl (YUY2 チェック)」 と
「huffyuv2 (YUY2) の aviutl (YUY2 チェック) 」の違いが何処にあるのか見つけられないんだ。
違いが何処にあるのか教えてくれないか？
>>233,>>235
「huffyuv(YUY2) の aviutl (YUY2 チェック)」 に注意書きで、
一旦RGBにしているようで精度が悪いとある。
でも、普通考えてそんな処理しているはずが無いではないか。
AviUtlがRGBとしてHuffyuvから貰っていたら入力は｢YUY2｣とはならないし、
Huffyuvの中で一旦RGBに変換するはずはない。そのことはHuffyuvを元にHuffyuvS
を作った本人が一番良くしってるだろう。
別の疑問として、
「huffyuvS(YUY2) の Avisynth」が伸張で、
「huffyuv(YUY2) の Avisynth」がYUY2
というのはどういう意味？
「huffyuv(YUY2) の aviutl (YUY2 チェック)」 に注意書きで、
一旦RGBにしているようで精度が悪いとある。
でも、普通考えてそんな処理しているはずが無いではないか。
AviUtlがRGBとしてHuffyuvから貰っていたら入力は｢YUY2｣とはならないし、
Huffyuvの中で一旦RGBに変換するはずはない。そのことはHuffyuvを元にHuffyuvS
を作った本人が一番良くしってるだろう。
別の疑問として、
「huffyuvS(YUY2) の Avisynth」が伸張で、
「huffyuv(YUY2) の Avisynth」がYUY2
というのはどういう意味？
>>233
Yは置いとくとして、通常映像でUVの取り得る範囲は意外な程小さい。
俺の経験から、-50～+50も振れれば上出来。
（カラーバーのようなフルレンジをとるものもあるけど）
これを、より変換レンジの小さいストレート変換で変換すると、
情報が潰れちゃいそうな気がしない？？
Yは置いとくとして、通常映像でUVの取り得る範囲は意外な程小さい。
俺の経験から、-50～+50も振れれば上出来。
（カラーバーのようなフルレンジをとるものもあるけど）
これを、より変換レンジの小さいストレート変換で変換すると、
情報が潰れちゃいそうな気がしない？？
>>233
頭かたいなあ
HuffyuvSがストレートで伸張も圧縮もしない、という視点しか持ってないんだろうな。
視点の中心をBT.601に置き変えてみるということが出来ないもんかねえ。
（BT.601の変換方法が、｢ストレート｣だとしてみるってことだよ。
何のためにBT.601がYUV->RGBのそういう変換式を採用したのかってことを考えてごらんよ。）
頭かたいなあ
HuffyuvSがストレートで伸張も圧縮もしない、という視点しか持ってないんだろうな。
視点の中心をBT.601に置き変えてみるということが出来ないもんかねえ。
（BT.601の変換方法が、｢ストレート｣だとしてみるってことだよ。
何のためにBT.601がYUV->RGBのそういう変換式を採用したのかってことを考えてごらんよ。）
>>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 伸張とは関係ない話ですまない。
> 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
メーカーサービス呼んでチューナ調整してもらえ
「8ch だけ受信感度が異常に高いので、調整してもらえないでしょうか」
と低姿勢で頼めば、ユーザサポートを重視する企業ならやってくれるだろう。
メーカーサービス呼んでチューナ調整してもらえ
「8ch だけ受信感度が異常に高いので、調整してもらえないでしょうか」
と低姿勢で頼めば、ユーザサポートを重視する企業ならやってくれるだろう。
>>242
そうそう。
放送信号自体に100%以上が許されているっていうのを、
235以上も必要な情報があたかもあるかのように言っているけど、
作成元のコンポーネントマスターには、BT.601の範囲外は無いと思うぞ。
そうそう。
放送信号自体に100%以上が許されているっていうのを、
235以上も必要な情報があたかもあるかのように言っているけど、
作成元のコンポーネントマスターには、BT.601の範囲外は無いと思うぞ。
HuffyuvS使って対して重要じゃない部分を残そうとやっきになってるﾔｼは負け組
俺なんか、
BT.601で変換しても範囲オーバーになる情報は、元々要らない情報だよ。
BT.601で変換したものっていうのは、元々、直にRGB24でキャプチャしたのと同様ってことだぜ。
色補正で、有効な情報だって多少はオーバーさせてカットしてるってのに。
（>>199が言ってるように、リンギングやシュートした部分なんて不要だぜ）
BT.601で変換しても範囲オーバーになる情報は、元々要らない情報だよ。
BT.601で変換したものっていうのは、元々、直にRGB24でキャプチャしたのと同様ってことだぜ。
色補正で、有効な情報だって多少はオーバーさせてカットしてるってのに。
（>>199が言ってるように、リンギングやシュートした部分なんて不要だぜ）
>>246
判りやすくかけなくて申し訳ない。
RGB で -100 だの 400 だのになるような YUV データは、よっぽど腐った設定の
キャプチャ環境でないかぎりありえない。
# なので、そんなもんを考慮すんのは無駄だ。
239 では 234 個人にそう伝えたかっただけなんだ
判りやすくかけなくて申し訳ない。
RGB で -100 だの 400 だのになるような YUV データは、よっぽど腐った設定の
キャプチャ環境でないかぎりありえない。
# なので、そんなもんを考慮すんのは無駄だ。
239 では 234 個人にそう伝えたかっただけなんだ
>>248
そんな御託は、デジタルキャプチャできるようになってから言ってくれ！！！
そんな御託は、デジタルキャプチャできるようになってから言ってくれ！！！
>>250
>>234はそんなことを問題にしてないだろが。
頭の固い野郎がいて、そいつが、YUV->RGBストレート変換は、伸張も圧縮もしてない
って思っていることに対する反論のために言っただけじゃん。
>>234はそんなことを問題にしてないだろが。
頭の固い野郎がいて、そいつが、YUV->RGBストレート変換は、伸張も圧縮もしてない
って思っていることに対する反論のために言っただけじゃん。
>243
おいおい、キャプチャ時に16-235に収まるように調整してないのかYO!
まず調整すれ、話はそれからだ。
それでも飛び出た信号が時たま来るけどそれぞれに余裕あるからオーバ
ーするこたない。
おいおい、キャプチャ時に16-235に収まるように調整してないのかYO!
まず調整すれ、話はそれからだ。
それでも飛び出た信号が時たま来るけどそれぞれに余裕あるからオーバ
ーするこたない。
>>253
おいおい、色バランスってことを知らんのか。
16-235に納まってても、RGB変換時にオーバーするってのはそれじゃん。
だって、元々RGBをYUVにして送出してるってことは、
色バランスが送出元と同じだったら、変換してオーバーになることは無いってことなんだから。
お前だって、言っただろ。
＞RGB -> YUV (RGB よりも範囲が広い) -> RGB
＞としてる限りは、レンジオーバーはまず発生しないから
ここで、まず、なんて言わずに絶対って言ったって良かったぞ。
おいおい、色バランスってことを知らんのか。
16-235に納まってても、RGB変換時にオーバーするってのはそれじゃん。
だって、元々RGBをYUVにして送出してるってことは、
色バランスが送出元と同じだったら、変換してオーバーになることは無いってことなんだから。
お前だって、言っただろ。
＞RGB -> YUV (RGB よりも範囲が広い) -> RGB
＞としてる限りは、レンジオーバーはまず発生しないから
ここで、まず、なんて言わずに絶対って言ったって良かったぞ。
>>253
お前は、その時たま飛び出た信号が必要なのか？ 本当に？
お前は、その時たま飛び出た信号が必要なのか？ 本当に？
そりゃコンポーネントマスターと同じ色範囲と輝度範囲なら
＞RGB -> YUV (RGB よりも範囲が広い) -> RGB
＞としてる限りは、レンジオーバーはまず発生しないから
これは成り立つけど、キャプチャ時に狂っていたら意味無い
じゃん。
カラーバーで調整してそれでも飛び出る信号は無視してもいい
って話なんだが。
調整しても0以下の信号や255を越える信号が入って来てもそれ
はいらない信号だと思うが
＞お前は、その時たま飛び出た信号が必要なのか？ 本当に？
調整してても飛び出すなら、多分いらない信号だと判断してますが
＞RGB -> YUV (RGB よりも範囲が広い) -> RGB
＞としてる限りは、レンジオーバーはまず発生しないから
これは成り立つけど、キャプチャ時に狂っていたら意味無い
じゃん。
カラーバーで調整してそれでも飛び出る信号は無視してもいい
って話なんだが。
調整しても0以下の信号や255を越える信号が入って来てもそれ
はいらない信号だと思うが
＞お前は、その時たま飛び出た信号が必要なのか？ 本当に？
調整してても飛び出すなら、多分いらない信号だと判断してますが
＞RGB -> YUV (RGB よりも範囲が広い) -> RGB
＞としてる限りは、レンジオーバーはまず（絶対）発生しないから。
これは言えるけど。誤解を生みやすいぞ
BT.601変換で見える範囲に限れば、YUVがRGBより必ず範囲が広いわけじゃない。
RGB->YUV変換でも、範囲を超えてオーバーすることはある。
まあ、問題にしているストレート変換の場合だと、
YUVがRGBより必ず広いって言えるけど、ここでいっているのは放送現場だからBT.601の事だよな。
＞としてる限りは、レンジオーバーはまず（絶対）発生しないから。
これは言えるけど。誤解を生みやすいぞ
BT.601変換で見える範囲に限れば、YUVがRGBより必ず範囲が広いわけじゃない。
RGB->YUV変換でも、範囲を超えてオーバーすることはある。
まあ、問題にしているストレート変換の場合だと、
YUVがRGBより必ず広いって言えるけど、ここでいっているのは放送現場だからBT.601の事だよな。
＞＞お前は、その時たま飛び出た信号が必要なのか？ 本当に？
＞調整してても飛び出すなら、多分いらない信号だと判断してますが
なんだ。
結局喧嘩してるように見えただけか。
お前だって、BT.601で変換して十分だって意見なのか。
最初は、16-235を超えるデータも必要だから（100%以上の信号もコンポーネントマスタにも存在するから）
って言ってたから、ストレート変換じゃないと許せないって言ってるもんだと思ったよ。
＞調整してても飛び出すなら、多分いらない信号だと判断してますが
なんだ。
結局喧嘩してるように見えただけか。
お前だって、BT.601で変換して十分だって意見なのか。
最初は、16-235を超えるデータも必要だから（100%以上の信号もコンポーネントマスタにも存在するから）
って言ってたから、ストレート変換じゃないと許せないって言ってるもんだと思ったよ。
●適正レベルまたは多少控えめにキャプチャしている場合は、BT.601準拠のHuffyuvを使う。
結論は、これに相当するわけだね
結論は、これに相当するわけだね
結局huffyuv(YUY2)でBT.601準拠キャプした場合
Aviutilに読ませるときはYUY2チェックするの？しないの？
Aviutilに読ませるときはYUY2チェックするの？しないの？
ttp://www.marumo.ne.jp/bt601/
↑より抜粋
＜ストレート変換の場合＞
○利点
・ITU-R BT.601 の輝度スケール 16 ～ 235 を超えた信号も作れる
・YUV→RGB→YUV→RGB と変換を繰り返した場合の画質の変化が
最小限に抑えられる
○欠点
・PC のディスプレイ上での画質調整が困難になる
＜YC 伸張・圧縮する場合＞
○利点
・TV に出力されるイメージに近い画質が、PC ディスプレイの段階で手に入る
○欠点
・規格外のデータを入れられなくなる
・YUV <-> RGB 変換時のロスが大きくなる
↑より抜粋
＜ストレート変換の場合＞
○利点
・ITU-R BT.601 の輝度スケール 16 ～ 235 を超えた信号も作れる
・YUV→RGB→YUV→RGB と変換を繰り返した場合の画質の変化が
最小限に抑えられる
○欠点
・PC のディスプレイ上での画質調整が困難になる
＜YC 伸張・圧縮する場合＞
○利点
・TV に出力されるイメージに近い画質が、PC ディスプレイの段階で手に入る
○欠点
・規格外のデータを入れられなくなる
・YUV <-> RGB 変換時のロスが大きくなる
DVキャプのときもYC伸張はいりませんか？
補間だけでいいのですかね？
補間だけでいいのですかね？
ffdshowってYC伸張してるの？
>>265
選択可能
選択可能
268 ：名無しさん＠編集中：03/04/25 19:20
ふと思ったんだが
VirtualDubとAVIsynthの環境でLoadAviUtlFilterPlugin(aufilters.avs)使えば
AVIutlのﾌｨﾙﾀ使用でｻﾁｭﾚｰｼｮﾝも中途RGB化もないHuffyuv出力ができるんでなかろうか？
VirtualDubとAVIsynthの環境でLoadAviUtlFilterPlugin(aufilters.avs)使えば
AVIutlのﾌｨﾙﾀ使用でｻﾁｭﾚｰｼｮﾝも中途RGB化もないHuffyuv出力ができるんでなかろうか？
>>268
手順は？
手順は？
270 ：267：03/04/25 22:32
271 ：267：03/04/25 22:37
ひょっとして・・・
AVIutlのｺﾏﾝﾄﾞﾗｲﾝ入出力ってRGB?
それとも選択制？
選択制にしてもaufilters.avs使用時に
どうやってYUY2展開になるんだろ？
aufilters.avsがAVIutlｺﾏﾝﾄﾞﾗｲﾝをYUY2展開で開かないと意味ないんだが
AVIutlのｺﾏﾝﾄﾞﾗｲﾝ入出力ってRGB?
それとも選択制？
選択制にしてもaufilters.avs使用時に
どうやってYUY2展開になるんだろ？
aufilters.avsがAVIutlｺﾏﾝﾄﾞﾗｲﾝをYUY2展開で開かないと意味ないんだが
272 ：名無しさん＠編集中：03/04/25 22:57
半角カナだと読みにくい
う～んffdshowの設定に伸張に関する項目が見当たらない。
ゲフォ房なんでもうこれっきゃないな～と思ったんだけど・・・
ゲフォ房なんでもうこれっきゃないな～と思ったんだけど・・・
>>273
Levelsにチェック -> Input(16-235) , Output(0-255) に設定
Levelsにチェック -> Input(16-235) , Output(0-255) に設定
275 ：名無しさん＠編集中：03/04/26 13:24
>>275
シカトかよゴルア!!
シカトかよゴルア!!
ﾜﾗﾀ
ここまで読んだけど、高度すぎてほとんど理解できませんでした。
MTV2000でMPEG2でキャプチャ
↓
AVIutlで読み込み（MPEG-2 VIDEO VFAPI Plug-In 使用）（ストレート変換）
↓
DivXに出力
としてるのですが、AVIutlの出力でYC伸張が必要でしょうか？
DivXのコーデックが伸張すると聞いて、今は伸張していないのですが……。
それと微妙な諧調が失われてしまっているのか心配です。
よろしくお願いします。
MTV2000でMPEG2でキャプチャ
↓
AVIutlで読み込み（MPEG-2 VIDEO VFAPI Plug-In 使用）（ストレート変換）
↓
DivXに出力
としてるのですが、AVIutlの出力でYC伸張が必要でしょうか？
DivXのコーデックが伸張すると聞いて、今は伸張していないのですが……。
それと微妙な諧調が失われてしまっているのか心配です。
よろしくお願いします。
>>280
もし、書かれているようにAviUtlで色補正せずエンコだけやってるなら、
最初にm2v.vfpではストレート変換は止めたほうがいいでしょう。
（AviUtlでYC伸張してもいいけど、m2v.vfpで伸張したほうが手間いらず）
今のストレート変換、YC伸張なしだと、結局YC圧縮したままなので暗く淡くなってるでしょう。
もし、書かれているようにAviUtlで色補正せずエンコだけやってるなら、
最初にm2v.vfpではストレート変換は止めたほうがいいでしょう。
（AviUtlでYC伸張してもいいけど、m2v.vfpで伸張したほうが手間いらず）
今のストレート変換、YC伸張なしだと、結局YC圧縮したままなので暗く淡くなってるでしょう。
ゲフォだと２段圧縮か．．．見られたもんじゃないな。
>>288
お前は、>>282の言うとおりにしとけ。
このスレに来る意味なし。
＞DivXに出力、
ここでDivXがBT.601に従ってYC圧縮するのを忘れてない？
ここで議論してるのは、編集途中で伸張するかしないかであって、
最終エンコを伸張するしないじゃない。
お前は、>>282の言うとおりにしとけ。
このスレに来る意味なし。
＞DivXに出力、
ここでDivXがBT.601に従ってYC圧縮するのを忘れてない？
ここで議論してるのは、編集途中で伸張するかしないかであって、
最終エンコを伸張するしないじゃない。
伸張したのと、しないのと、圧縮したのと、しないのと、
見分けがつかないはずが無いんだがなぁ。
何で質問してくるんだろうか？わからん？
見分けがつかないはずが無いんだがなぁ。
何で質問してくるんだろうか？わからん？
誰か分かってる奴これまでのまとめ書けよ。
>>286みたいなのはいつまでも理解できずに現れるよって．．．
>>286みたいなのはいつまでも理解できずに現れるよって．．．
訂正>>288．．．
ここまで読みましたが、低知能には話が高度すぎて難儀であります
mpeg2 -> DVD2AVI(VFAPI) -> Aviutl(YC伸張) -> LCL(RGB) -> WMV9
でエンコしてるんですけど、自分のPCで見るにはいい感じなのですが、
人様のPCで見ると化けるのでしょうか
ちなみにラデ8500.
mpeg2 -> DVD2AVI(VFAPI) -> Aviutl(YC伸張) -> LCL(RGB) -> WMV9
でエンコしてるんですけど、自分のPCで見るにはいい感じなのですが、
人様のPCで見ると化けるのでしょうか
ちなみにラデ8500.
>>294
同一環境(例えばラデ)でソースとエンコード後の再生画面を見比べて
同じになってればスケール変換に誤りはないということ。
その同じデータを違う環境(ラデとゲフォ)で再生比較したときに色が違って見えるかどうかはまた別の話です。
同一環境(例えばラデ)でソースとエンコード後の再生画面を見比べて
同じになってればスケール変換に誤りはないということ。
その同じデータを違う環境(ラデとゲフォ)で再生比較したときに色が違って見えるかどうかはまた別の話です。
mpeg2 → d2v(TV scale) → avs → AviUtl → DivX を
DVDMaxでテレビ出力する場合、YC伸張は必要？
DVDMaxでテレビ出力する場合、YC伸張は必要？
>>294
本当に分かってないね。
その手順には、ある重要な情報が提示されてない。
読んだ人にとっては正しいことにも間違っていることにもどっちにでも受け取れる。
結果として、>>296の言うように自分の目でみて正しかったか間違ってたか判断してくれ。
本当に分かってないね。
その手順には、ある重要な情報が提示されてない。
読んだ人にとっては正しいことにも間違っていることにもどっちにでも受け取れる。
結果として、>>296の言うように自分の目でみて正しかったか間違ってたか判断してくれ。
>avs → AviUtl → DivX
このへんでﾅﾆしてんだか全然わからんし
そもそもDVDMaxは(ry
このへんでﾅﾆしてんだか全然わからんし
そもそもDVDMaxは(ry
さて、今日はERなワケだが(´ー`)
>>297
一見公平そうだけど、あるベクトルを感じるリストではあるな。
一見公平そうだけど、あるベクトルを感じるリストではあるな。
http://niiyan.s8.xrea.com/avisynth/color_test.html
なんでHuffyuvじゃﾀﾞﾒなんだろ？？？
なんでHuffyuvじゃﾀﾞﾒなんだろ？？？
にーやんに聞いてみな。
>>304
ﾒｰﾙ発射してみました
ﾒｰﾙ発射してみました
306 ：名無しさん＠編集中：03/04/27 01:36
誰？
readavs.dll通す時点でだめだめ
つかフツーavsinp.auiを使うだろ
avsinp.aui通すと伸張されるん？
310 ：名無しさん＠編集中：03/04/27 07:42
慎重に扱えよ
YUY2で入力できるわけ
312 ：大田遺産：03/04/27 11:12
>>280さんへ 282さんもおっしゃるとおり
以前にその方法でやってたけどまるもさんのMPEG-2 VIDEO VFAPI Plug-In
で伸張をかけないとソースMPEG2(MTV2000)とエンコ後DivX(Ver5.02)で色調
や輝度が少し落ちた（薄い・淡い）感じだったので伸張したほうがいいと
思う。何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
あたりで）ソースとエンコ後を比較するとわかると思います。
>>それと微妙な諧調が失われてしまっているのか心配です
その件はDivXにした時点であきらめましょう（暗部でのブロックノイズ化・
モスキートノイズの嵐）。WMV9でも同様だが、あまり目立たないので良い
と思う。
>>298 DVDMaxでテレビ出力する場合、YC伸張は必要？
DVDMAXで比較しないほうがいいかと（デフォルトでかなり輝度高し）
CRTオーバーレイ比較がいいと思います。それとavsの事はよくわかり
ませんがDVD2AVIかAviUtlのどちらかで伸張をかけたほうが（AviUtl
のほうが元ソースに近い感じとの報告あり（DVD2AVIスレにて・俺には
よくわからんかった））良いと思う。
以前にその方法でやってたけどまるもさんのMPEG-2 VIDEO VFAPI Plug-In
で伸張をかけないとソースMPEG2(MTV2000)とエンコ後DivX(Ver5.02)で色調
や輝度が少し落ちた（薄い・淡い）感じだったので伸張したほうがいいと
思う。何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
あたりで）ソースとエンコ後を比較するとわかると思います。
>>それと微妙な諧調が失われてしまっているのか心配です
その件はDivXにした時点であきらめましょう（暗部でのブロックノイズ化・
モスキートノイズの嵐）。WMV9でも同様だが、あまり目立たないので良い
と思う。
>>298 DVDMaxでテレビ出力する場合、YC伸張は必要？
DVDMAXで比較しないほうがいいかと（デフォルトでかなり輝度高し）
CRTオーバーレイ比較がいいと思います。それとavsの事はよくわかり
ませんがDVD2AVIかAviUtlのどちらかで伸張をかけたほうが（AviUtl
のほうが元ソースに近い感じとの報告あり（DVD2AVIスレにて・俺には
よくわからんかった））良いと思う。
ええと・・・
なんて言えばいいのかな・・・
うんとね。
伸長しても元のスケールが正しいなら問題ないんだ、0-255になるだけだから。
最近はYUY2だと伸長するボードが出てきてるから、再生するときに伸長したデ
ーターだと２重に伸長してしまうから問題になってる訳で。
勿論データーレベルでは正しく伸長されていれば損なわれることはないんだけ
ど。
だから、伸長しないボードの場合にはプレイヤーで伸長して伸長するボードの
場合にはボードに任せると、でデーター自体は伸長しないほうが良いんじゃな
いかなぁ。ってなってる話なんですよ。
AVUTLが正しく伸長圧縮をしてくれるならYUY2読み込み→伸長 YUY2書き出
し→圧縮で全く問題ないんだけど。どうも伸長はともかく圧縮がおかしいと・・
だったら最初から伸長圧縮しないでなんとかしましょうってのが趣旨なんだけ
ど・・・・
ってこの話の流れで合ってます？>ALL
なんて言えばいいのかな・・・
うんとね。
伸長しても元のスケールが正しいなら問題ないんだ、0-255になるだけだから。
最近はYUY2だと伸長するボードが出てきてるから、再生するときに伸長したデ
ーターだと２重に伸長してしまうから問題になってる訳で。
勿論データーレベルでは正しく伸長されていれば損なわれることはないんだけ
ど。
だから、伸長しないボードの場合にはプレイヤーで伸長して伸長するボードの
場合にはボードに任せると、でデーター自体は伸長しないほうが良いんじゃな
いかなぁ。ってなってる話なんですよ。
AVUTLが正しく伸長圧縮をしてくれるならYUY2読み込み→伸長 YUY2書き出
し→圧縮で全く問題ないんだけど。どうも伸長はともかく圧縮がおかしいと・・
だったら最初から伸長圧縮しないでなんとかしましょうってのが趣旨なんだけ
ど・・・・
ってこの話の流れで合ってます？>ALL
>>313
大体あってる
とりあえず>>196のやり方で伸張圧縮なしｴﾝｺできるんだが
このやり方だとYUV>ストレートでRGB>YUV変換がはいってるんじゃないのか？
それはYUV>BT601準拠RGB>YUV変換より変換誤差がでかいんじゃないか？
じゃぁどーすんだよ、ﾎﾞｹが！！
という流れ
大体あってる
とりあえず>>196のやり方で伸張圧縮なしｴﾝｺできるんだが
このやり方だとYUV>ストレートでRGB>YUV変換がはいってるんじゃないのか？
それはYUV>BT601準拠RGB>YUV変換より変換誤差がでかいんじゃないか？
じゃぁどーすんだよ、ﾎﾞｹが！！
という流れ
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の色調のことなのかな
だとしたらすみません分かってませんでした
でも、そうすると元の色と変わってしまうので、元の色を再現する為に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の色調のことなのかな
だとしたらすみません分かってませんでした
伸張を＋1、圧縮を－1として完成ファイルが0になってればいい
って感じに置き換えて考えてますが正しいでしょうか？
って感じに置き換えて考えてますが正しいでしょうか？
>>317
そんなかんじ。
ファイル自体のデータの話と自分の環境での見え方の話を分けて考えないから
ごちゃごちゃするんだよ。
用は>>317の言うように完成ファイルが0（TV出力時が0、PC出力で＋1）に作るだけ
ここでビデオカードの仕様でPC出力=0だからってYC伸張で補完するのはダメ
あとは個別のコーデックと加工ソフトの入力、出力の＋、－を知ればいいだけ
そんなかんじ。
ファイル自体のデータの話と自分の環境での見え方の話を分けて考えないから
ごちゃごちゃするんだよ。
用は>>317の言うように完成ファイルが0（TV出力時が0、PC出力で＋1）に作るだけ
ここでビデオカードの仕様でPC出力=0だからってYC伸張で補完するのはダメ
あとは個別のコーデックと加工ソフトの入力、出力の＋、－を知ればいいだけ
>317
キャプチャ時に 0 になっていることが大前提ね
キャプチャ時に 0 になっていることが大前提ね
にーやん氏から返事がきました
メールの内容貼るのはアレなんでアドバイスを元に実験しました
まずは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
メールの内容貼るのはアレなんでアドバイスを元に実験しました
まずは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
変なとこで改行してｽﾏｿ
>>320
そんな大幅な範囲外の値じゃ実質、意味が無いと思う。
誰かが言ってたけど、ストレート変換でも、-100～400程度の値をとる。
変換誤差はこれが0～255にサチュレートされたものを再YUV変換するので発生。
もっと、ボーダーラインの近傍でテストしてみれば、
どれだけ問題があるのかないのかが判ると思う。
もちろん、3,4の方法は値を保持するけどそれが果たしてよい結果を生むのか疑問。
むしろ、1の結果の誤差変換の方が結果的に良いと言えるかも知れない。
そんな大幅な範囲外の値じゃ実質、意味が無いと思う。
誰かが言ってたけど、ストレート変換でも、-100～400程度の値をとる。
変換誤差はこれが0～255にサチュレートされたものを再YUV変換するので発生。
もっと、ボーダーラインの近傍でテストしてみれば、
どれだけ問題があるのかないのかが判ると思う。
もちろん、3,4の方法は値を保持するけどそれが果たしてよい結果を生むのか疑問。
むしろ、1の結果の誤差変換の方が結果的に良いと言えるかも知れない。
あと書き忘れたけど
YUV(254.1.158)なんてｷｬﾌﾟﾃﾞｰﾀは普通ないから
初心者は慌ててAvisynth勉強し始めたりしないように
YUV(254.1.158)なんてｷｬﾌﾟﾃﾞｰﾀは普通ないから
初心者は慌ててAvisynth勉強し始めたりしないように
>>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再生のみならｻﾁｭﾚｰﾄしてもいいけどね
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
初心者はハイブリットレコ買った方がいいみたいですね
大抵の市販DVDは、範囲外の値を含んでいるといっても、別にそんなに問題じゃない。
YUVで、1-15,235-254を含んでいても、RGBに変換(BT.601で）したら0-255に納まる
か又は0.xx%というような極僅かのピクセルが僅かに範囲外になるか程度。
YUVで、1-15,235-254を含んでいても、RGBに変換(BT.601で）したら0-255に納まる
か又は0.xx%というような極僅かのピクセルが僅かに範囲外になるか程度。
>>312
>何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
>あたりで）ソースとエンコ後を比較するとわかると思います。
DirectX9とVMR9を使う環境だと
複数のオーバーレイがサポートされてるから単純に比較できなかったり。
とくにWMP9あたりでやると。
なんて書くとまた混乱させちゃうかなあ…
>何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
>あたりで）ソースとエンコ後を比較するとわかると思います。
DirectX9とVMR9を使う環境だと
複数のオーバーレイがサポートされてるから単純に比較できなかったり。
とくにWMP9あたりでやると。
なんて書くとまた混乱させちゃうかなあ…
・・・・つーか白より白い白や黒より黒い色のデーターって必要なの？
サチュレートされても別に良いと思うけどなぁ。
そりゃYC展開圧縮の計算式が間違っていたりしたら困るけどさ。
ちゃんと調整してもはみ出すデーターなんていらないYO!
4:3映像で705以上のピクセルのデーターを残すか残さないかの議論に
似てないか？この問題
サチュレートされても別に良いと思うけどなぁ。
そりゃYC展開圧縮の計算式が間違っていたりしたら困るけどさ。
ちゃんと調整してもはみ出すデーターなんていらないYO!
4:3映像で705以上のピクセルのデーターを残すか残さないかの議論に
似てないか？この問題
でもテレビを完全にキャリブレートすることなんて実質ムリ
テレビ視聴とキャプの入力チューナーを同一にしてる環境なら
やっぱサチュレートするのはイヤだよ
テレビ視聴とキャプの入力チューナーを同一にしてる環境なら
やっぱサチュレートするのはイヤだよ
330 ：大田遺産：03/04/27 23:42
>>327へ
>>何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
>>あたりで）ソースとエンコ後を比較するとわかると思います。
簡潔に言い過ぎた、失礼。
俺の場合は、元ソース（MPEG2・MTV2000）はMediaPlayer6.4（デコーダー
はinterVideoになってる）でエンコ後WMV9はカノプVG1000用の付属ソフト
VideoGatePlayer（デコーダーはWMVideoDecoderDMOと書いてあった）を
同時に立ち上げてCRT比較している。たぶん問題ないと思う（どっちも
シンプルだし）。
>>何通りか作ってみてCRTでオーバーレイ２つ立ち上げて（MediaPlayer
>>あたりで）ソースとエンコ後を比較するとわかると思います。
簡潔に言い過ぎた、失礼。
俺の場合は、元ソース（MPEG2・MTV2000）はMediaPlayer6.4（デコーダー
はinterVideoになってる）でエンコ後WMV9はカノプVG1000用の付属ソフト
VideoGatePlayer（デコーダーはWMVideoDecoderDMOと書いてあった）を
同時に立ち上げてCRT比較している。たぶん問題ないと思う（どっちも
シンプルだし）。
オーバーレイ表示と比べるなんて間違いのもと。
同じ編集ツールでGDI表示同士でソースとエンコ結果を比べるほうが確実。
これだと、RGBになるけどピクセル単位でRGBの各数値で比較可能になるから。
（虫眼鏡ツールでRGBを確認できる）
同じ編集ツールでGDI表示同士でソースとエンコ結果を比べるほうが確実。
これだと、RGBになるけどピクセル単位でRGBの各数値で比較可能になるから。
（虫眼鏡ツールでRGBを確認できる）
まるもさんの日記読みました。
正直感心しています。
人間的に成熟している部分に目を見晴らせさせました。
私は小心者のくせに我を張るタイプなので、正直とてもかないません。
（小心者なので、これも自分のwebページではなく、ここに書いてます）
まるもさんとは、他スレでもどうやら色々と何度もぶつかっているようです。
（ドット妨害、GPL事件等、私の書き込みへのレスが今回以外にも何度か日記に登場してます。
私は深夜にナチュラルハイになりすぎます。後で反省しきりです。）
私はAvisynth中心なので、正直AviUtlは縁がありません。
YUY2出力のサチュレートも先人の発表の受け売りです。（事実確認はしましたけど）
まるもさん（の成果物、とくに日記）には今までかなりお世話になっています。
これからも精力的に魅力的な活動を期待しています。
以上
Best Regards.
正直感心しています。
人間的に成熟している部分に目を見晴らせさせました。
私は小心者のくせに我を張るタイプなので、正直とてもかないません。
（小心者なので、これも自分のwebページではなく、ここに書いてます）
まるもさんとは、他スレでもどうやら色々と何度もぶつかっているようです。
（ドット妨害、GPL事件等、私の書き込みへのレスが今回以外にも何度か日記に登場してます。
私は深夜にナチュラルハイになりすぎます。後で反省しきりです。）
私はAvisynth中心なので、正直AviUtlは縁がありません。
YUY2出力のサチュレートも先人の発表の受け売りです。（事実確認はしましたけど）
まるもさん（の成果物、とくに日記）には今までかなりお世話になっています。
これからも精力的に魅力的な活動を期待しています。
以上
Best Regards.
333 ：大田遺産：03/04/28 10:16
＞○も氏
192と235の間にもあなたの書きこみは相当あるんじゃないの？
192と235の間にもあなたの書きこみは相当あるんじゃないの？
そんなことはどうでもいいよ。
大事なのは誰が言ったかじゃなくて何を言ったかだろ
しかしﾎﾝﾄなんで「まるもさん」なんだろ？
茂木さんでしょうに
それは置いとくとしてAVIutlが茂木氏やこのｽﾚの何人かが言うように
圧縮時にｻﾁｭﾚｰﾄしない（飽和処理しない）ようになったら
HuffyuvSって何に使えるんだ？
茂木さんでしょうに
それは置いとくとしてAVIutlが茂木氏やこのｽﾚの何人かが言うように
圧縮時にｻﾁｭﾚｰﾄしない（飽和処理しない）ようになったら
HuffyuvSって何に使えるんだ？
やっぱりHuffyuvSは無意味だったってことか･･･
>>337-338
AviUtlがサチュレートするからその対策としてHuffyuvSが出てきたんだろ。
未来の人間にとっては必要なくなるかもしれないが、今の人間は必要とされてるならそれでいいんだよ。
天然痘ウイルスが絶滅したらワクチンってなんに使うんだ？と言ってるようなもんだ。
AviUtlがサチュレートするからその対策としてHuffyuvSが出てきたんだろ。
未来の人間にとっては必要なくなるかもしれないが、今の人間は必要とされてるならそれでいいんだよ。
天然痘ウイルスが絶滅したらワクチンってなんに使うんだ？と言ってるようなもんだ。
(・∀・)ﾅﾙﾎﾄﾞ!
Vmaker氏が現れやすそうな雰囲気になったんでちと書くが
>AviSynth で YUY2のみ処理を行うと、
>YUY2 <-> RGB の変換誤差から開放される…筈だったんだけど、
> 調べた結果は、一度 RGB にストレート変換を行い、
>その結果を huffyuvs の Convert YUY2 で変換 しないことには、元データを保持することができない
とかいうことが
ttp://vmaker.tripod.co.jp/other/graphedit.html
にあるんだが、これってにーやん氏や>>320の結果と異なるんでは？
>AviSynth で YUY2のみ処理を行うと、
>YUY2 <-> RGB の変換誤差から開放される…筈だったんだけど、
> 調べた結果は、一度 RGB にストレート変換を行い、
>その結果を huffyuvs の Convert YUY2 で変換 しないことには、元データを保持することができない
とかいうことが
ttp://vmaker.tripod.co.jp/other/graphedit.html
にあるんだが、これってにーやん氏や>>320の結果と異なるんでは？
何とかHuffyuvSを使ってもらおうと、あの手この手で勧誘しているんじゃないの？
>>338
主なターゲットはAviUtlじゃなくてCCEだと思うが。
主なターゲットはAviUtlじゃなくてCCEだと思うが。
>>346
http://vmaker.tripod.co.jp/other/graphedit.html
でも、↑ってAvisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)の話じゃないの？
AviUtlの部分は想像だけど。
ちなみに、vmakerさんはVirtualDubModに乗り換えたって話を読んだ気がする。
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 に
# 言い返せなかったり (^^;;;
つまり、TMPGEnc の出力を YUY2で保存して中間ファイルにする時に、
何度でも通せるようにしたかったのです(ぉぃ
# って事で、選択肢を増やして混乱させてしまったのは私なので、 >95 に
# 言い返せなかったり (^^;;;
349 ：名無しさん＠編集中：03/04/29 06:18
>AviSynth で YUY2のみ処理を行うと、
>YUY2 <-> RGB の変換誤差から開放される
をどう読み解けば
>でも、↑ってAvisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)の話じゃないの？
なるんだ？
本人スルーだし・・・
>YUY2 <-> RGB の変換誤差から開放される
をどう読み解けば
>でも、↑ってAvisynth→(RGBストレート)→AviUt→Huffyuvs(ConvertToYUY2)の話じゃないの？
なるんだ？
本人スルーだし・・・
>>341
読んで見た。俺にも真意は分からんが、最後にこんなこと書いてあった。
＞■ 蛇足
＞読込み・出力の対応表を見て頂くと判ることですが、 TMPGEnc/AviUtl ともに RGBストレートスケールでのみ
元の YUV空間のデータ範囲をなんとか 保持できます。同様に VirtualDubでも RGB 処理です
(とは言うものの、fastでスルーも可能ですね。しかし、それは Dubを使っているのかと(笑))。
これ読んで、俺はこう思った。
Dubで Fast recompressやDirect stream copy（無圧縮YUY2で中間吐くには最適）を使えば
大丈夫だが、これはDubを使ったことにはならん。
う～ん、やっぱり分からん。何処にAvisynthの問題があるというのだろう？
これ、単なる『俺って、GraphEdit使えるんだぜ！スゴイだろ！』って自慢を披露したかっただけじゃないかな？
例の比較表にも訳分からん部分がいくつかあるし。
（どうやって確認したか、またその比較結果データを別に置いておいて欲しい。
実験レポートってのは、結果だけじゃなくて、ときにはその何百倍もの実験データが添付資料として付くもんだぞ）
読んで見た。俺にも真意は分からんが、最後にこんなこと書いてあった。
＞■ 蛇足
＞読込み・出力の対応表を見て頂くと判ることですが、 TMPGEnc/AviUtl ともに RGBストレートスケールでのみ
元の YUV空間のデータ範囲をなんとか 保持できます。同様に VirtualDubでも RGB 処理です
(とは言うものの、fastでスルーも可能ですね。しかし、それは Dubを使っているのかと(笑))。
これ読んで、俺はこう思った。
Dubで Fast recompressやDirect stream copy（無圧縮YUY2で中間吐くには最適）を使えば
大丈夫だが、これはDubを使ったことにはならん。
う～ん、やっぱり分からん。何処にAvisynthの問題があるというのだろう？
これ、単なる『俺って、GraphEdit使えるんだぜ！スゴイだろ！』って自慢を披露したかっただけじゃないかな？
例の比較表にも訳分からん部分がいくつかあるし。
（どうやって確認したか、またその比較結果データを別に置いておいて欲しい。
実験レポートってのは、結果だけじゃなくて、ときにはその何百倍もの実験データが添付資料として付くもんだぞ）
351 ：名無しさん＠編集中：03/04/29 07:04
ほんと都合が悪いのはあからさまにスルーするよね
アメリカ軍の司令官みたいだ
アメリカ軍の司令官みたいだ
>>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さんらしき投稿を参考に推測したもの。
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さんらしき投稿を参考に推測したもの。
あと、↓とか。
http://pc.2ch.net/test/read.cgi/avi/1042666068/518
「YUY2を～」というのは、旧ページでの
「YUY2 を一度 RGB に変換しないと、期待する結果を得ることができないなんて…。」
http://pc.2ch.net/test/read.cgi/avi/1042666068/518
「YUY2を～」というのは、旧ページでの
「YUY2 を一度 RGB に変換しないと、期待する結果を得ることができないなんて…。」
354 ：名無しさん＠編集中：03/04/29 22:56
age
必死な奴がいるな
使いたくなければ使わなければいいだけのこと
ｿｰｽ公開までしてるのに、何が気に入らないのだ？
現状でHuffyuvSは便利だけどなー
ｿｰｽ公開までしてるのに、何が気に入らないのだ？
現状でHuffyuvSは便利だけどなー
>>355
質問に答えただけなのだが・・・。
質問に答えただけなのだが・・・。
>ｿｰｽ公開までしてるのに
公開しないとそっちの方が問題になるんじゃないの？
公開しないとそっちの方が問題になるんじゃないの？
あーあ、また墓穴ほっちゃったよ
>>361
Avisynthに問題があるって誰が言ったの？
Avisynthに問題があるって誰が言ったの？
>>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を使うことでしか解決しない。と言っている訳だったんだ。
ああ、悪かった。俺の勘違いだわ。
＞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を使うことでしか解決しない。と言っている訳だったんだ。
でも、やっぱりソース読んでも意味がないな。
問題なのは、DirectShow FilterのPinの接続の仕方だと言っているわけだから。
問題なのは、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版を使った理由と共通しているのですが。誰でも試すことのできる
データやプログラムをベースにテストしているので、試したデータを添付する必要は
無いと踏んだのです。
とりあえず
>364
> 問題なのは、DirectShow FilterのPinの接続の仕方だと言っているわけだから。
これは、どの部分のことでしょうか? 2G超えのあたり?
そとれも、Avisynth で RGB だと…って部分ですか?
>363
えっと、実は Convlistを作成した時は、VirtualDubの Fast の動作を知らなかっ
たんです。で、知らなかったなんて恥ずかしいから、いつだったかGraphEditの蛇
足にコソーリと追加したんじゃなかったかな(^^;;。で結局混乱の元。すみません。
>352
ありがとうございます。私もよく覚えてませんが。そんな感じかと思います。
ちゃんと全部メンテしないとダメですね。
>350
> 単なる『俺って、GraphEdit使えるんだぜ！スゴイだろ！』って自慢を披露したかった
流石に、こんな風に言われると悲しいものがあるんですが、そういう風に見えちゃ
いますかねぇ～。GraphEdit関連の情報は意外に少ないので、実は簡単で、結構便利
ってな意味もあって残してあるんですが、削除しよかっな(^^;
> 実験レポートってのは、結果だけじゃなくて、ときにはその何百倍もの実験データ
> が添付資料として付くもんだぞ
その通りかもしれません。ただ、今回の場合必要でしょうか?
FREE版や、Trial版を使った理由と共通しているのですが。誰でも試すことのできる
データやプログラムをベースにテストしているので、試したデータを添付する必要は
無いと踏んだのです。
このときは別にそんなに本気で書いたわけじゃなく、チラッとそう思ったってことで、
そんなに落ち込まないでください。
ではどうしてそう思ったかは、>>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の表かなんかに、最大、平均、最小２乗誤差とかいろいろまとめてくれないかな？）
そんなに落ち込まないでください。
ではどうしてそう思ったかは、>>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の表かなんかに、最大、平均、最小２乗誤差とかいろいろまとめてくれないかな？）
なんか違うなあ、って思って読み返したら．．．．
＞ゲスの考えって
『下衆の勘ぐり』の間違いです。どうしてこんなの間違えたんだろう？
こんな主文的な重要な部分に間違いがあって申し訳ない。
俺って、やっぱりこの程度の奴です。
＞ゲスの考えって
『下衆の勘ぐり』の間違いです。どうしてこんなの間違えたんだろう？
こんな主文的な重要な部分に間違いがあって申し訳ない。
俺って、やっぱりこの程度の奴です。
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行目のことですよね? 違うのかな。
版数や日付などは確かにそうですね。入れるよう気をつけて行きたいと思いま
す。プログラムの更新日には気をつけているんですけどね(^^;;
どうもありがとうございます。気分的に少し復活できました。でと
>「huffyuvS (YUY2) の aviutl (YUY2 チェック) 」が伸張 で
>「huffyuv (YUY2) の aviutl (YUY2 チェック) 」が伸張 ※9 だったりして
これって? どういう意味でしょうか? 私がアップロードしている convlistを
参照して頂く限りは
> HuffyuvS (YUY2) AviUtl (YUY2チェック有) 伸張 ※9
> Huffyuv (YUY2) AviUtl (YUY2チェック有) 伸張 ※9
となっている筈です。ちょっと前ということは、抜けてたことがある…のかな?
# Application列で見て、11行目と、29行目のことですよね? 違うのかな。
版数や日付などは確かにそうですね。入れるよう気をつけて行きたいと思いま
す。プログラムの更新日には気をつけているんですけどね(^^;;
蛇足ってのは余計な付け足しって意味で、
今回のように重要な訂正を書くもんじゃないでっせ！
今回のように重要な訂正を書くもんじゃないでっせ！
と言っても、今回はそう誤解されても仕様が無かったようにした、
◆S/VMAKER3cさんの所為だと言っただけ。
>>350さんは、>>214さんですね。きっと。
◆S/VMAKER3cさんにお願い
>>214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
調査して報告しようとは思いません？
◆S/VMAKER3cさんの所為だと言っただけ。
>>350さんは、>>214さんですね。きっと。
◆S/VMAKER3cさんにお願い
>>214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
調査して報告しようとは思いません？
確かﾄﾘｯﾌﾟがmarumoじゃないっけ？
2chでの
2chでの
MPEG2(D-VHS)→MPEG-2 VIDEO VFAPI Plug-In→TMPGEnc→DVD の場合はどうすればいいですか？
m2v_vfpでストレート変換にして、
TMPGEncでYUV データをCCIR601 ではなく、BasicYCbCr で出力するにチェック有りであってます？
今まではITU-R BT.601から伸張、TMPGEncでチェックなしでMPEG2を作ってました。
m2v_vfpでストレート変換にして、
TMPGEncでYUV データをCCIR601 ではなく、BasicYCbCr で出力するにチェック有りであってます？
今まではITU-R BT.601から伸張、TMPGEncでチェックなしでMPEG2を作ってました。
MPEG2(D-VHS)→MPEG-2 VIDEO VFAPI Plug-In
ここで伸張
→TMPGEnc
でﾁｪｯｸなしのが精度は高いでしょう
ただ、その差が果たしてわかるかどうか・・・
ここで伸張
→TMPGEnc
でﾁｪｯｸなしのが精度は高いでしょう
ただ、その差が果たしてわかるかどうか・・・
376 ： ◆S/VMAKER3c ：03/05/01 10:10
>371
> 214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
> 調査して報告しようとは思いません？
言わんとしている事はなんとなく解る気がするのですが、それを調べて把握
して置くメリットって何でしょう?
> 214さんの言うようなHuffyuvに対してHuffyuvSが誤差を拡大するものなのかどうか
> 調査して報告しようとは思いません？
言わんとしている事はなんとなく解る気がするのですが、それを調べて把握
して置くメリットって何でしょう?
>>376
＞それを調べて把握して置くメリットって何でしょう?
自作ソフトを使って貰おうという人間の言葉とも思えません
このソフトには、これこれこういう特徴（メリット）があります
でも、こういうリスク（デメリット）もあります
両者を天秤にかけて使用するかどうかご判断ください
ってのが正直者の態度だと思う
まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね
“そんなものがもしあったとしても俺が調べる謂れはないだろっ”
って態度はいかがなものかと
中傷なら無視するのも当然だけど、中傷だと思っているわけ？
＞それを調べて把握して置くメリットって何でしょう?
自作ソフトを使って貰おうという人間の言葉とも思えません
このソフトには、これこれこういう特徴（メリット）があります
でも、こういうリスク（デメリット）もあります
両者を天秤にかけて使用するかどうかご判断ください
ってのが正直者の態度だと思う
まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね
“そんなものがもしあったとしても俺が調べる謂れはないだろっ”
って態度はいかがなものかと
中傷なら無視するのも当然だけど、中傷だと思っているわけ？
>>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 〈機械･装置を〉始動させる.
古期英語｢踏む｣の意
＞確かﾄﾘｯﾌﾟが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 〈機械･装置を〉始動させる.
古期英語｢踏む｣の意
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 になんて変換してはいけません。どっちでもオーバーフローしますから。
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
>まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
>おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね
えっ? 不具合があったんですか? どこに書いてあるんでしょう? すみませんが、どうも
見落としているようですので、ポインタを示して頂けないでしょうか。
なぜそういう事になるのやら…。少なくとも、>214 に書かれた事は、特性ですから、
それを比較すること自体には意味を感じてません。ですから、とてもよい目的がある
のであれば聞きたいと思ったのでけど。
>378
>まして、不具合があると指摘されているにも関わらず、それを発表するかどうかは
>おいておくにしても、自分自身は把握しておく義務感に駆られるものだと思うがね
えっ? 不具合があったんですか? どこに書いてあるんでしょう? すみませんが、どうも
見落としているようですので、ポインタを示して頂けないでしょうか。
>>381
Avisynth + VirtualDub (fast recompress) な人だと、既に RGB なにそれ? と
なっているよん。んまぁ、1394 で HD キャプでもやる人だと、いったん
BT.709 に従って YUV -> RGB 変換しないとまずいことになるから、しょうがなく
RGB に変換かけているだろうけど。
Avisynth + VirtualDub (fast recompress) な人だと、既に RGB なにそれ? と
なっているよん。んまぁ、1394 で HD キャプでもやる人だと、いったん
BT.709 に従って YUV -> RGB 変換しないとまずいことになるから、しょうがなく
RGB に変換かけているだろうけど。
386 ：名無しさん＠編集中：03/05/01 21:37
>Avisynth + VirtualDub (fast recompress) な人だと、既に RGB なにそれ? と
>なっているよん。
そういう人はそもそもこのスレの話題は関係ないのに、なにしに来てんの？
>なっているよん。
そういう人はそもそもこのスレの話題は関係ないのに、なにしに来てんの？
>>386
俺もAvisynth + VirtualDub (fast recompress) な人だけど、ここに見に来てるよ。
だって面白いんだもん。iyahonntoni
マジな話、そういう俺でもRGBは無視できないね。
だって、YUVで色補正するとき、RGBベースでやっぱり調整しなきゃならないもん。
表示がRGBなんだから、あんまりRGBの範囲をはみ出すわけにはいかん。
俺もAvisynth + VirtualDub (fast recompress) な人だけど、ここに見に来てるよ。
だって面白いんだもん。iyahonntoni
マジな話、そういう俺でもRGBは無視できないね。
だって、YUVで色補正するとき、RGBベースでやっぱり調整しなきゃならないもん。
表示がRGBなんだから、あんまりRGBの範囲をはみ出すわけにはいかん。
ピクセラ厨とMTV厨がYC伸張してるだのしてないだの騒いでます。
あいつ等は放置した方がいいと思います
HuffyuvSマンセーのスレになる筈だった公算がすこしくるってきました
MEDIACRUSEってビデオ入力を表示するときって
ソフトウェアでYUV→RGB(伸張)変換してからオーバーレイに転送してるんですかね？
ソフトウェアでYUV→RGB(伸張)変換してからオーバーレイに転送してるんですかね？
>>388
PCスケールとかTVスケールという言葉が一人歩きしているようだ
PCスケールとかTVスケールという言葉が一人歩きしているようだ
>>392
へへん、知ったようなことを
へへん、知ったようなことを
ここまで読んでて思ったこと。
プログラミングの技術うんぬんはおいて置いてVMAKERさんって人間的にはまったくの子供なんだね。
まあ今後社会に出てもまれて立派な社会人になることを期待しとります。
プログラミングの技術うんぬんはおいて置いてVMAKERさんって人間的にはまったくの子供なんだね。
まあ今後社会に出てもまれて立派な社会人になることを期待しとります。
>>394
へへん、(ry
へへん、(ry
>>394
とっくに社会に出てるわけだが
ああいうタイプの人間は社会に出ればいくらでもいるわけだが
そんなこともわからない>>394は明らかに社会に出てないわけだが
おまいは、脛かじりもいい加減にしる！
とっくに社会に出てるわけだが
ああいうタイプの人間は社会に出ればいくらでもいるわけだが
そんなこともわからない>>394は明らかに社会に出てないわけだが
おまいは、脛かじりもいい加減にしる！
もういいよ・・・これ以上恥の上塗りをしないでくれ（つД｀）
398 ：名無し募集中。。。：03/05/02 17:51
HuffyuvSとHuffyuv
HuffyuvR の登場が待たれます
400 ：名無しさん＠編集中：03/05/02 18:48
保守
401 ：名無しさん＠編集中：03/05/08 18:42
Huffyuv（あるいはHuffyuvS）でカラーバーをキャプチャーして
AviUtlの波形表示プラグインで調整する場合、
読み込み時のコーデックの環境設定は展開圧縮ノーチェック
にしなければならないのでしょうか？
AviUtlの波形表示プラグインで調整する場合、
読み込み時のコーデックの環境設定は展開圧縮ノーチェック
にしなければならないのでしょうか？
402 ：401：03/05/08 18:45
波形表示プラグインの補助線はCCIR601用で調整してます。
波形表示プラグインの解説にあるように
カラーバーで調整するときはストレート変換が前提。
なのでHuffyuvSで展開ノーチェックがよろしいかと
カラーバーで調整するときはストレート変換が前提。
なのでHuffyuvSで展開ノーチェックがよろしいかと
404 ：401：03/05/08 20:38
ご回答ありがとうございました。
何かこのスレ、コーデックとハードとソフト、
それぞれの問題がごっちゃになっていてわかりづらいですね。
何かこのスレ、コーデックとハードとソフト、
それぞれの問題がごっちゃになっていてわかりづらいですね。
>>404
動画再生時はハードウェアオーバーレイが前提になるんでしょうがない。
動画再生時はハードウェアオーバーレイが前提になるんでしょうがない。
伸張する？とか、しない？とか、
最初に言い出したのは誰なのかしら？
最初に言い出したのは誰なのかしら？
407 ：名無しさん＠編集中：03/05/08 22:50
>>406
あにぺぐであろうな
あにぺぐであろうな
ここってバカが転がり込んで来るスレですか？
イマイチ古いネタだけど。このスレッドの方々にとって
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 の辺りについて。
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 の辺りについて。
どっちの言い分が正しいかは分からないけど、
このメーカーにしてあのユーザーありって感じ＜カノプ
このメーカーにしてあのユーザーありって感じ＜カノプ
411 ：名無しさん＠編集中：03/05/10 01:11
age
412 ：動画直リン：03/05/10 01:12
>>409
まさにこのスレでの議論と似たようなことをメーカ間でやっている感じ。
スゲー面白い。
YUVとRGBのどっちが大きいかは、BT.601で比較すると
・全体的にはYUVの方が大きい
・でもRGBの方が大きい部分もある
元々カメラ撮影がRGBでそれをYUV変換したものをソースにした場合、
・YUV->RGBでのロスは少ない
・RGB->YUVのロスは無い
でも、RGB空間でトランジション処理したら、
・RGB->YUVでもロスが出る
matroxの言い分もある程度聞けるけど、
ことYUV->RGB変換に関してはやっぱり変換ロスはどうしても出るだろうね。
まさにこのスレでの議論と似たようなことをメーカ間でやっている感じ。
スゲー面白い。
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で見るのを前提としています
自分はcanopusのDVキャプなんですが
DV→AviUtl (YUY2 チェック無)で読み込み→Huffyuv S(Conv YUY2) で出力
CCE(0-255)でエンコードでいいんでしょうかね？
DVDにしてTVで見るのを前提としています
416 ：名無しさん＠編集中：03/05/15 17:26
>>416
そのとーり。
そのとーり。
418 ：名無しさん＠編集中：03/05/15 17:57
>>415
AviutlのcanopusのYUY2で展開するをはずし
Huffyuv SのYUY2で圧縮するもはずしておいてConv YUY2
CCEはYUY2チェックでいいと思うんだが
頭のいい人俺も正解知りたいから教えてくれ
AviutlのcanopusのYUY2で展開するをはずし
Huffyuv SのYUY2で圧縮するもはずしておいてConv YUY2
CCEはYUY2チェックでいいと思うんだが
頭のいい人俺も正解知りたいから教えてくれ
canopus DV → CCE → DVD
これだと16-235なの？？
これだと16-235なの？？
>>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にはならない
ちがう。
スケール変換というものは、ある色空間を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にはならない
423 ：名無しさん＠編集中：03/05/16 08:16
canopus DV → CCE → DVD
って4:1:1→4:2:2補完せんのかよw
って4:1:1→4:2:2補完せんのかよw
424 ：419：03/05/16 14:55
>>423
うむ。Avisynth挟んでColorYUY2でinterpolation使ったほうがよさげ。
うむ。Avisynth挟んでColorYUY2でinterpolation使ったほうがよさげ。
初心者にそこまでいわんでも・・・
とりあえずYUV422補完しないでやって
気に入らなかったら補完するようにすればいいんでない？
多分このスレの常駐者でも、動画をひと目見て
「む？DVソースだな。補完しないとは愚かなヤシだ。」
なんてわかるのは、皆無か極少数だよ
とりあえずYUV422補完しないでやって
気に入らなかったら補完するようにすればいいんでない？
多分このスレの常駐者でも、動画をひと目見て
「む？DVソースだな。補完しないとは愚かなヤシだ。」
なんてわかるのは、皆無か極少数だよ
これを見て、識者の皆さんはどう思われますか？
http://pc.2ch.net/test/read.cgi/avi/1052654576/733-734n
http://pc.2ch.net/test/read.cgi/avi/1052654576/733-734n
上手く調整されてると思いますが。
>>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
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
これで合ってますか？
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
#--- プラグイン ---
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
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
>>430
一瞬で試せることを訊くな
一瞬で試せることを訊くな
たまには
最終的に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入力時の挙動がはっきりしないので。
ソース 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入力時の挙動がはっきりしないので。
YUVにもYV12にも(X-Y)という概念はありません
(X-Y)という表記はYUV>RGB変換時の値です
大体YUVの範囲は0～255じゃないですよ
それにYV12はあくまでもYUVの一種です
(X-Y)という表記はYUV>RGB変換時の値です
大体YUVの範囲は0～255じゃないですよ
それにYV12はあくまでもYUVの一種です
もうひとつ言えばCCEやTMPGEncはエンコーダ
DivXやXviDはコーデックです
コーデックに色情報を受け渡すのはエンコーダですから
コーデックが直にソースを受け取ることはできません
つまりエンコーダ（正確にはフロントエンド）に依存します
DivXやXviDはコーデックです
コーデックに色情報を受け渡すのはエンコーダですから
コーデックが直にソースを受け取ることはできません
つまりエンコーダ（正確にはフロントエンド）に依存します
>>434
>>435
ども、やっぱ書き方まずかったですね。
過去ログにあった「DivXはRGBで渡すとコーデックが圧縮(0-255>16-235)する」ってのが発端で疑問に思ったので
最終的にCODECに渡した場合に(CCE,TMPGEncはエンコーダーですが、MPEG(YV12)に変換する部分の話ということで)
RGB、YUVで渡した時の処理の差が知りたかったということです。
>>435
ども、やっぱ書き方まずかったですね。
過去ログにあった「DivXはRGBで渡すとコーデックが圧縮(0-255>16-235)する」ってのが発端で疑問に思ったので
最終的にCODECに渡した場合に(CCE,TMPGEncはエンコーダーですが、MPEG(YV12)に変換する部分の話ということで)
RGB、YUVで渡した時の処理の差が知りたかったということです。
>>436
XviD はソースがあるから、それを確認するのが確実（確か伸張・圧縮してたはず）
後、YUY2/YV12 で渡した場合にスケール変換するコーデックは存在しないはずだから
AviUtl で YUY2 チェックを圧縮・復号で ON/OFF して比較を推奨
XviD はソースがあるから、それを確認するのが確実（確か伸張・圧縮してたはず）
後、YUY2/YV12 で渡した場合にスケール変換するコーデックは存在しないはずだから
AviUtl で YUY2 チェックを圧縮・復号で ON/OFF して比較を推奨
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
（･∀･）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モニタ上の色はあくまでもプレビュー程度という認識です。
元々、DVDなどはビデオ信号に載せてNTSCなどのビデオモニタで見る事を
前提として作られているので、色もその場合に最適になるように調整してあるのです。
なので、RGB信号で出力した際の色は、制作者の意図した色と違います。
具体的には、色が薄く、コントラストが弱くなります。
#私はPCでCG映像などを制作する仕事をしていますが、
#色調整は必ずNTSCモニタ上で行います。映像業界では常識です。
#色調整をNTSCモニタで行うための専用のソフトやハードまであります。
#NTSCモニタとPCでは色が全然変わってきてしまうので、
#PCモニタ上の色はあくまでもプレビュー程度という認識です。
>>440
リンク先も読んだがちと事実誤謬があるな
「制作者の意図した色と違います」のはモニタ色温度の問題であって（もしくはスケール変換やグラボのオーバーレイの問題）
「RGB信号で出力」することには起因しない
NTSCビデオモニタだって内部RGB変換して表示してるんだからね
実際表示するさいの出力形式はNTSCだろうがPALだろうが、マスターモニタだろうが民生テレビだろうが
RGB信号なんだよ
リンク先も読んだがちと事実誤謬があるな
「制作者の意図した色と違います」のはモニタ色温度の問題であって（もしくはスケール変換やグラボのオーバーレイの問題）
「RGB信号で出力」することには起因しない
NTSCビデオモニタだって内部RGB変換して表示してるんだからね
実際表示するさいの出力形式はNTSCだろうがPALだろうが、マスターモニタだろうが民生テレビだろうが
RGB信号なんだよ
とうとうｽﾈちゃったのかな
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html
ttp://vmaker.tripod.co.jp/huffyuvs/convlist.html
まあいいんでない？
あらら・・・
それじゃthejamのﾎﾞｹと同じだな
thejam氏は復活した
thejam以外はみんなうんこ
またMXやってんのか？
これからは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
>漏れも映像CG屋なんだけど、NTSCで納品する場合の色の補正って、
>（中略）
>こういうこと恥ずかしいからあまり会社で聞けない（汗
http://pc.2ch.net/test/read.cgi/cg/1041868484/388-390
453 ：名無しさん＠編集中：03/05/27 23:02
>>452
ところでセーフカラーに入らなかった時にどういう問題になるか知ってて書いてる？
ところでセーフカラーに入らなかった時にどういう問題になるか知ってて書いてる？
>>454
知りません。教えてください。
知りません。教えてください。
∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
457 ：名無しさん＠編集中：03/05/28 20:47
もぐったら事故
あ、もう正解が書いてある（ｗ
460 ：名無しさん＠編集中：03/06/04 12:42
おまえらのせいでvmakerさんが公開止めちゃったじゃないか
しねしねしね
>>460
vmakerさん久しぶり。元気？
vmakerさん久しぶり。元気？
462 ：名無しさん＠編集中：03/06/04 14:16
vmakerさーーーーーーん
463 ：名無しさん＠編集中：03/06/04 18:15
vmaker＝slave＝１だったってことで
>>463
違いますよ
vmaker氏には「ｽﾚがあんな状況になってｽｲﾏｾｿ」
というﾒｰﾙを出したんですが返事は来ませんでした
そしてしばらくしてｻｲﾄが・・・
listやHuffyuvSは兎も角、他のﾌﾟﾗｸﾞｲｿまで・・・
ｷｬﾌﾟｴｿ質ｽﾚでも以前からやりとりしており
気さくな方だと認識しておりましたから
ｻｲﾄ永続ｱﾎﾞｰｿはないと信じたいんですけど・・・
違いますよ
vmaker氏には「ｽﾚがあんな状況になってｽｲﾏｾｿ」
というﾒｰﾙを出したんですが返事は来ませんでした
そしてしばらくしてｻｲﾄが・・・
listやHuffyuvSは兎も角、他のﾌﾟﾗｸﾞｲｿまで・・・
ｷｬﾌﾟｴｿ質ｽﾚでも以前からやりとりしており
気さくな方だと認識しておりましたから
ｻｲﾄ永続ｱﾎﾞｰｿはないと信じたいんですけど・・・
サイトが消えたのはその話題の直後じゃなくて、
誰も振り向きもしなくなって数週間後のことだから、
ちょっとこのスレとは関連があるとは思えないけど。
誰も振り向きもしなくなって数週間後のことだから、
ちょっとこのスレとは関連があるとは思えないけど。
パッチがまずかったんだろうか、、
パッチってなんのパッチ？
みなしご
上から読んだけどｻﾊﾟｰﾘ。
キャプボじゃなくてDVDレコーダーでキャプってるんですが、
どういう処理をすればいいんでしょう？
DVD2AVIでプロジェクトファイルとWAVを作成後、
Aviutlで各種フィルタをかけて(色はいじらない)Huffyuvに変換。
そして特に余計なフィルタをかけずにTMPGEncでMPEG1やSVCDやに変換してます。
特にHuffyuvに変換にする時の設定がｻﾊﾟｰﾘ。
キャプボじゃなくてDVDレコーダーでキャプってるんですが、
どういう処理をすればいいんでしょう？
DVD2AVIでプロジェクトファイルとWAVを作成後、
Aviutlで各種フィルタをかけて(色はいじらない)Huffyuvに変換。
そして特に余計なフィルタをかけずにTMPGEncでMPEG1やSVCDやに変換してます。
特にHuffyuvに変換にする時の設定がｻﾊﾟｰﾘ。
470 ：名無しさん＠編集中：03/06/06 16:26
>>469
エンコード前後で色調が同じになってれば良いだけだよ。
エンコード前後で色調が同じになってれば良いだけだよ。
471 ：名無しさん＠編集中：03/06/06 18:37
>>469
DVD2AVI→RGB TV色調
AviUtl→コーデックの設定でYUY2で出力のチェックを外す
huffyuv→RGB compression methodをConvert to YUV以外にする
TMPGEnc→BasicYCbCrで出力にチェックを入れる
DVD2AVI→RGB TV色調
AviUtl→コーデックの設定でYUY2で出力のチェックを外す
huffyuv→RGB compression methodをConvert to YUV以外にする
TMPGEnc→BasicYCbCrで出力にチェックを入れる
>TMPGEnc→BasicYCbCrで出力にチェックを入れる
Σ（ﾟдﾟlll）ｶﾞｰﾝ
今までエンコした動画、全部チェック入れてなかった。
DVではONにした方がいいとか書いてありますが、DVDレコも同じようなものなんですか。
Σ（ﾟдﾟlll）ｶﾞｰﾝ
今までエンコした動画、全部チェック入れてなかった。
DVではONにした方がいいとか書いてありますが、DVDレコも同じようなものなんですか。
>>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でもこれらは変わらないんでしょうか？
キャプを始めて早一年・・。かなりの腕になったと思ってたんですが、先は長そうです。
今までずっとこういう設定でやってきたんですが・・。(ていうか知らずにそのままにしてた)
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厨のたわ言なので気にすることはありません。
自分の使う機器にベストなセッティングで動画を作りましょう。
>やはりPCで観るためのMPEG1でもテレビで観るためのVCD・SVCD・DVD-Videoでもこれらは変わらないんでしょうか？
それはBT.601厨のたわ言なので気にすることはありません。
自分の使う機器にベストなセッティングで動画を作りましょう。
でもまあ、BT601に準拠させとくのが無難かと。
>>475でもBT.601に準拠するわけだが
コントかこのスレは
むしろ>>472はBT.601準拠してないわけだが
でもできたファイルは大差ないけど
でもできたファイルは大差ないけど
誰の言う事が本当なのかわかんねぇよもう･ﾟ･(ﾉД`)･ﾟ･｡
>>480
472を書いたのは私ですが、BT.601に準拠させるつもりでああ書いたのではなくて
DVDレコーダーがどういうように記録してるのか分からないので
16-235外のデータも保持できるように配慮した設定を書きました。
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の
”でもできたファイルは大差ないけど”も正しい
>>470が正しい
ちなみに>>472でも>>475でも結果は>>470になる
>>472だと途中経過がBT.601に準拠せずかつ
色調補正がしづらく、またYUY2<>RGB変換誤差の不安が残る
>>475だとAviutlによってサチュレートされてしまう問題が残る
それぞれの欠点が逆では利点になる
だから>>480の
”でもできたファイルは大差ないけど”も正しい
地上波もDVDもBT.601の推奨範囲を守らないのに、
なんで地上波やDVDﾘｯﾌﾟしてるｱﾏが推奨範囲を金科玉条にするんだろ?
どんなﾁｭｰﾅｰもｼｭｰﾄするし、
NTSCﾋﾞﾃﾞｵﾓﾆﾀは勿論民生ﾃﾚﾋﾞだってBT.601ｵｰﾊﾞｰを表示できるのに、
ほんとうにBT.601の推奨範囲を守ることが正しいの？
なんで地上波やDVDﾘｯﾌﾟしてるｱﾏが推奨範囲を金科玉条にするんだろ?
どんなﾁｭｰﾅｰもｼｭｰﾄするし、
NTSCﾋﾞﾃﾞｵﾓﾆﾀは勿論民生ﾃﾚﾋﾞだってBT.601ｵｰﾊﾞｰを表示できるのに、
ほんとうにBT.601の推奨範囲を守ることが正しいの？
485 ：名無しさん＠編集中：03/06/08 00:09
>>484
むこうのスレが生きてるのにコピペすることもないんだが
一応コピペレスしてやろう
白トビ黒つぶれも映像表現だと言われればそれまでなんだよ
だけどキャプるとき（もしくは色調補正するとき）の指標は必要でしょ？
PC環境が変わっても破綻のない絵柄を選ぶ、という目的のためには
推奨範囲を守るのが一番正しいんじゃないかなぁ？
実際キャリブレーションというのは
推奨範囲内でのダイナミックレンジを有効に利用する設定なわけだし・・・。
まぁ俺スケールでもかまわないとは思うけどね。
AV機器ヲタなんてキャリブレートなんかより俺色合い重視だしな。
むこうのスレが生きてるのにコピペすることもないんだが
一応コピペレスしてやろう
白トビ黒つぶれも映像表現だと言われればそれまでなんだよ
だけどキャプるとき（もしくは色調補正するとき）の指標は必要でしょ？
PC環境が変わっても破綻のない絵柄を選ぶ、という目的のためには
推奨範囲を守るのが一番正しいんじゃないかなぁ？
実際キャリブレーションというのは
推奨範囲内でのダイナミックレンジを有効に利用する設定なわけだし・・・。
まぁ俺スケールでもかまわないとは思うけどね。
AV機器ヲタなんてキャリブレートなんかより俺色合い重視だしな。
オーバーも許容されるんだからBT601にしと毛
やっぱ、テストパターンを極めるところから始めないと。
テストパターンを極めたところで
テレビ放送を録画してそれが正しい色調で録画できると言えるか？
テレビ放送を録画してそれが正しい色調で録画できると言えるか？
テストパターンさえ綺麗になれば満足です
調整しないよりいいんじゃﾈｰﾉ？
少なくとも、色調に対する感受性というか、
判断力を養う訓練にはなるんでない?
判断力を養う訓練にはなるんでない?
>>489
いえない
ｶﾗｰﾊﾞｰ送出機をｷｬﾌﾟってもｷｬﾌﾟﾎﾞのﾃﾞｼﾞﾀｲｻﾞ特性がわかるだけ
ﾁｭｰﾅｰ特性はわからない
ﾃｽﾄﾊﾟﾀｰﾝDVDを使ってもいったん送信させてからｷｬﾌﾟることになるため
送信側の特性に埋もれてしまう
局から送信されたものをｷｬﾌﾟってもそのときの受信状況の特性しかわからない
わからないどころかSMPTEｶﾗｰﾊﾞｰですらない
でも他に方法が・・・・俺ｽｹｰﾙ？？
いえない
ｶﾗｰﾊﾞｰ送出機をｷｬﾌﾟってもｷｬﾌﾟﾎﾞのﾃﾞｼﾞﾀｲｻﾞ特性がわかるだけ
ﾁｭｰﾅｰ特性はわからない
ﾃｽﾄﾊﾟﾀｰﾝDVDを使ってもいったん送信させてからｷｬﾌﾟることになるため
送信側の特性に埋もれてしまう
局から送信されたものをｷｬﾌﾟってもそのときの受信状況の特性しかわからない
わからないどころかSMPTEｶﾗｰﾊﾞｰですらない
でも他に方法が・・・・俺ｽｹｰﾙ？？
>493
えらそうに薀蓄たれてるが
ｷｬﾌﾟじゃなくて録画の話じゃねーのか？
えらそうに薀蓄たれてるが
ｷｬﾌﾟじゃなくて録画の話じゃねーのか？
>>475
DVDレコーダーの人はメーカーさんが自信を持ってコンフィギュレーションしてんだから
PC用とかTV用とか考えないでそれを維持するように努めれば良いんじゃないの？
Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。
DVDレコーダーの人はメーカーさんが自信を持ってコンフィギュレーションしてんだから
PC用とかTV用とか考えないでそれを維持するように努めれば良いんじゃないの？
Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。
カラーバーで調整したキャプボでTV放送をキャプチャしたものと
DVDになったもので色を比べたら全然ちがくてあせった
こんな場合でも何処に問題があるのか特定できないんだよな
DVDの色は間違ってないと思いたいんだが…
DVDになったもので色を比べたら全然ちがくてあせった
こんな場合でも何処に問題があるのか特定できないんだよな
DVDの色は間違ってないと思いたいんだが…
半角カナ=slave=1
チャンネルごとのカラーバーキャプって調整すれば
完璧と言っていいんじゃないの？
しょせんエアチェックなんだし、それ以上は無理。
受信状況なんかそんなに変化するもんじゃないよ。
完璧と言っていいんじゃないの？
しょせんエアチェックなんだし、それ以上は無理。
受信状況なんかそんなに変化するもんじゃないよ。
もはや嗜好の問題でしかないような・・・・・
>>499
玄人は日本で調整してないからダメだよ
玄人は日本で調整してないからダメだよ
みなさんありがとうございます。
とりあえず、問題ないなら今までの方法でやります。
>Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。
ただこれが気になります。
Geforce以外のやつなのにテレビより暗くなるんです。
DVDレコで録画したものを、何もいじらずそのままWMPで再生してもそうなります。
グラフィックカードはIntelのi810かi815のどちらかです。
再生時の設定がおかしいということでしょうか？
とりあえず、問題ないなら今までの方法でやります。
>Geforce以外のビデオチップならそれをPCで見たってテレビと同じ見栄えになるんだし。
ただこれが気になります。
Geforce以外のやつなのにテレビより暗くなるんです。
DVDレコで録画したものを、何もいじらずそのままWMPで再生してもそうなります。
グラフィックカードはIntelのi810かi815のどちらかです。
再生時の設定がおかしいということでしょうか？
最近フジ（東京8ch）の色が赤くなってない？
こないだカラーバーで調整したらフジだけ色相が回ってた
実際通常放送時の見た目も赤っぽくなってる
前は大丈夫だったんだけどな
まあうちの受信環境の問題かも知れんが
こないだカラーバーで調整したらフジだけ色相が回ってた
実際通常放送時の見た目も赤っぽくなってる
前は大丈夫だったんだけどな
まあうちの受信環境の問題かも知れんが
>>502
このスレとは関係ないですが、家のテレビで一台だけPALを白黒表示できるやつがあります。
90年前後のパナのテレビです。
それ以外はPALを表示させようとすると、カラーですが画面が乱れます。
謎。
このスレとは関係ないですが、家のテレビで一台だけPALを白黒表示できるやつがあります。
90年前後のパナのテレビです。
それ以外はPALを表示させようとすると、カラーですが画面が乱れます。
謎。
あぁi815か
チップがそもそも糞
チップがそもそも糞
509 ：名無しさん＠編集中：03/06/08 01:12
>>507
市販DVDだと明るさが変わります。
DVDレコのやつとか拾ったMPEG2だとあまり変わりません。
ただ市販DVDとレコを見比べる途中に、一度MPEG2コーデックを変えてるんですよ。
関係ないかもしれませんが。
市販DVDだと明るさが変わります。
DVDレコのやつとか拾ったMPEG2だとあまり変わりません。
ただ市販DVDとレコを見比べる途中に、一度MPEG2コーデックを変えてるんですよ。
関係ないかもしれませんが。
>>508
Σ（ﾟдﾟlll）
Σ（ﾟдﾟlll）
516 ：名無しさん＠編集中：03/06/08 22:39
もぐったら事故
ConvTo持ってるぞ？
ConvTo_0.4-IF1_dll
ConvTo_0.4-IF2_dll
ConvTo_0.4-IF1_dll
ConvTo_0.4-IF2_dll
YUY2で0-255で取り込むとまずいの？
519 ：名無しさん＠編集中：03/06/09 18:17
>>518
PCが爆発する
PCが爆発する
>>519
もっと早く言ってくれよ。爆発しちゃったじゃん！！
もっと早く言ってくれよ。爆発しちゃったじゃん！！
521 ：名無しさん＠編集中：03/06/09 19:26
>>518
もぐったら事故
もぐったら事故
522 ：名無しさん＠編集中：03/06/09 19:59
まず全裸になり、自分の尻を両手でバンバン叩きながら白目をむき
「びっくりするほどユートピア！びっくりするほどユートピア！」
とハイトーンで連呼しながらベットを昇り降りする
これを１０分程続けるばＯＫ
すると妙な脱力感に襲われ、解脱気分に一日中浸れる
「びっくりするほどユートピア！びっくりするほどユートピア！」
とハイトーンで連呼しながらベットを昇り降りする
これを１０分程続けるばＯＫ
すると妙な脱力感に襲われ、解脱気分に一日中浸れる
523 ：名無しさん＠編集中：03/06/14 19:40
TMPGEncの RGB to YUV 変換の問題点
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic10951
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic10951
このスレを読めば読むほど訳分からなくなってきてしまったのでお助け下さい。
GeForce2MXを使っているのですが、AviUtlでオーバーレイ表示すると、しないときに比べ確かに画面が暗いです。
しかしDivXを出力して、これをWMP(オーバーレイ)で再生させるとAviUtlのプレビュー画面（非オーバーレイ）と色味は一致してしまいます。
AviUtlとWMPでオーバーレイの色味が変わることなんであるんでしょうか？
ここまでスレを読んできまして、GeForceではWMP再生時に画像が暗くなると理解してしまったのですが・・・・。
以下の点は確認してみました。
・デコーダの方では色設定を変更していません。
・ffdshowでは伸張していません。
・DivXデコーダの YUV Extended mode はOFFです。
・DirectXは8.0aです。オーバーレイの設定はデフォルトのままです。
・GeForceのプロパティはすべてデフォルトのままです。
・WMPの画像をPrint Screenしてペイントに貼り付けると真っ黒になりました。
よろしくお願いします。
GeForce2MXを使っているのですが、AviUtlでオーバーレイ表示すると、しないときに比べ確かに画面が暗いです。
しかしDivXを出力して、これをWMP(オーバーレイ)で再生させるとAviUtlのプレビュー画面（非オーバーレイ）と色味は一致してしまいます。
AviUtlとWMPでオーバーレイの色味が変わることなんであるんでしょうか？
ここまでスレを読んできまして、GeForceではWMP再生時に画像が暗くなると理解してしまったのですが・・・・。
以下の点は確認してみました。
・デコーダの方では色設定を変更していません。
・ffdshowでは伸張していません。
・DivXデコーダの YUV Extended mode はOFFです。
・DirectXは8.0aです。オーバーレイの設定はデフォルトのままです。
・GeForceのプロパティはすべてデフォルトのままです。
・WMPの画像をPrint Screenしてペイントに貼り付けると真っ黒になりました。
よろしくお願いします。
あんなテストじゃ判らんよ。
YV12->YUY2補間があって、当然データはコントラストが縮小方向に向かうからね。
何回も繰り返せば元とどんどん違ってきて当然。
補間なしでできるものは現在存在しないから、プログラムできる人じゃないと
テスト自体出来ない。
YV12->YUY2補間があって、当然データはコントラストが縮小方向に向かうからね。
何回も繰り返せば元とどんどん違ってきて当然。
補間なしでできるものは現在存在しないから、プログラムできる人じゃないと
テスト自体出来ない。
528 ：名無しさん＠編集中：03/06/16 01:51
なんだ、GeforceのハードウェアオーバーレイってYC伸張してるのかよ。
>>525
バッチエンコ中だったのでレス遅れましたです。
設定確認してみました。
＜コーデックの設定＞
・圧縮プログラム DivX Pro 5.0.5 Codec
・YUY2で展開する ON
・YUY2で圧縮する ON
・圧縮の設定を保持する ON
ソースは、MPEG2(MTV2000)→AviUtl(m2v_vfp)(BT.601 から伸張)→DivXに出力です。
#「ソース読み込み時にYUY2展開にチェック」ってどこで確認すれば良いんでしたっけ？
こんなんで何かわかりますでしょうか？
バッチエンコ中だったのでレス遅れましたです。
設定確認してみました。
＜コーデックの設定＞
・圧縮プログラム DivX Pro 5.0.5 Codec
・YUY2で展開する ON
・YUY2で圧縮する ON
・圧縮の設定を保持する ON
ソースは、MPEG2(MTV2000)→AviUtl(m2v_vfp)(BT.601 から伸張)→DivXに出力です。
#「ソース読み込み時にYUY2展開にチェック」ってどこで確認すれば良いんでしたっけ？
こんなんで何かわかりますでしょうか？
m2v.vfpをm2v.auiにリネームしてAviUtlフォルダに置きなさい。
入力プラグイン優先度の設定で「MPEG-2 VIDEO File Reader」の優先度を上げておくように。
入力プラグイン優先度の設定で「MPEG-2 VIDEO File Reader」の優先度を上げておくように。
532 ：名無しさん＠編集中：03/06/16 23:30
>>527=XXX
おまいｲｲ!ﾔｼだなぁ
おまいｲｲ!ﾔｼだなぁ
>>532
多分皮肉で言ってるのだと思うが……
YV12 と YUY2 では Y の補間なんて発生しないぞ
補間が発生するとしたら U/V (Cb/Cr) だけだし、補間でコントラストが
下がるなんてことは、よっぽど変なコードでない限りありえない
多分皮肉で言ってるのだと思うが……
YV12 と YUY2 では Y の補間なんて発生しないぞ
補間が発生するとしたら U/V (Cb/Cr) だけだし、補間でコントラストが
下がるなんてことは、よっぽど変なコードでない限りありえない
>>533
確かに、YV12->YUY2補間では、UVのみだけど、コントラストは下がるよ。
Avisynthで確認済み。
それにTMPGEncだと、一旦RGBに変換するから、
UVの変化がRGB全てに関係してくる。
その後、エンコすれば、Yにも当然影響することは自明。
確かに、YV12->YUY2補間では、UVのみだけど、コントラストは下がるよ。
Avisynthで確認済み。
それにTMPGEncだと、一旦RGBに変換するから、
UVの変化がRGB全てに関係してくる。
その後、エンコすれば、Yにも当然影響することは自明。
ゲフォ厨のやつ>>524に答えてよ
いややっぱ>>527はｲｲ!ﾔｼだって
オレも検証続行しよっと
オレも検証続行しよっと
>>524
画面のプロパティの詳細に入ってオーバーレイの色調整しろ
画面のプロパティの詳細に入ってオーバーレイの色調整しろ
ゲフォだけどやっぱり伸張しないよ
CCEはRGB->YCbCr変換式を公開してるね。
実際のコードじゃないからその情報に価値があるかは分からんけど。
実際のコードじゃないからその情報に価値があるかは分からんけど。
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) に変換する式が使われます。
となります。
堀 さん 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) に変換する式が使われます。
となります。
ソースがCCIR601に準拠しているかどうか、
いったいどうやって判断しているんだ？
いったいどうやって判断しているんだ？
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
いずれの場合も，割り算の結果の小数点以下は切り捨てられます。
“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って無断転載禁止なはずだが・・・・
うーん
うちもゲフォだけどどうも伸張してるっぽい．．．
ffdshowで伸張すると伸張されすぎてる
こんなこと言ったらここでは村八分ですか？
うちもゲフォだけどどうも伸張してるっぽい．．．
ffdshowで伸張すると伸張されすぎてる
こんなこと言ったらここでは村八分ですか？
ゲフォはゲフォでもチップの型とドライババージョンをはっきりさせたらどうでしょうかね。
VPEで動画機能を強化したコアもあることですし。
VPEで動画機能を強化したコアもあることですし。
最新のデトネイターにしてみた
が、
ｵｰﾊﾞﾚｲ表示だとｺﾝﾄﾗｽﾄがあがったような画になりました
伸張って感じじゃないな
輝度自体は圧縮されたかのように暗くなってる
ｹﾞﾌｫ2MX200・WinXPSP3
が、
ｵｰﾊﾞﾚｲ表示だとｺﾝﾄﾗｽﾄがあがったような画になりました
伸張って感じじゃないな
輝度自体は圧縮されたかのように暗くなってる
ｹﾞﾌｫ2MX200・WinXPSP3
デジタルバイブランスってやつか？
う～ん、ドライバのバージョンの違いでそんなに挙動が違うとなると、
GeForce はちと恐くて使えんな。この辺、nVIDIAはいったいなにを
どう考えているんだろう…。
GeForce はちと恐くて使えんな。この辺、nVIDIAはいったいなにを
どう考えているんだろう…。
（カラープロファイル…
４月２８日（月） 2ch DTV 板 YC 伸張総合スレッド
大体想像がついてる人もいるかもしれませんが、48, 53, 67, 72, 164, 170, 189, 192, 235, 239, 244, 248, 250 は私の書き込みだったりします。それ以外では書いてません。
私は AviUtl の YUY2 出力での飽和処理に気づいてなかった人間だったりするので、214 さんを私扱いすると失礼ですよと。こちらでも確認しましたが、この処理は弁護
の余地がないですね。ここだけでも直して GW 中に 0.98e をリリースして欲しい（SSE2 対応/内部 YUY2 化は後回しでいいから）ところです。
大体想像がついてる人もいるかもしれませんが、48, 53, 67, 72, 164, 170, 189, 192, 235, 239, 244, 248, 250 は私の書き込みだったりします。それ以外では書いてません。
私は AviUtl の YUY2 出力での飽和処理に気づいてなかった人間だったりするので、214 さんを私扱いすると失礼ですよと。こちらでも確認しましたが、この処理は弁護
の余地がないですね。ここだけでも直して GW 中に 0.98e をリリースして欲しい（SSE2 対応/内部 YUY2 化は後回しでいいから）ところです。
そろそろKENくん死亡説がまた流れるころかな
以前と違ってAvisynthやVirtualDubのプラグインが進歩してきてしっかりと
使えてきているんで、AviUtlがあのままでもかまわないや。
使えてきているんで、AviUtlがあのままでもかまわないや。
557 ：名無しさん＠編集中：03/06/23 04:29
全部読んだ。
キャプ厨ってのはどうしようもない人種だなと思った。
趣味でやってるはずのことを何故もっとハッピーに進められないんだろう？
こういう↓スレを立てる奴の感性は正しいと思う。
http://pc.2ch.net/test/read.cgi/avi/1050071901/l50
キャプ厨ってのはどうしようもない人種だなと思った。
趣味でやってるはずのことを何故もっとハッピーに進められないんだろう？
こういう↓スレを立てる奴の感性は正しいと思う。
http://pc.2ch.net/test/read.cgi/avi/1050071901/l50
558 ：名無しさん＠編集中：03/06/23 05:49
物事を突き詰めるのに趣味もくそもないでしょ。
相手にすんなって
趣味はともかく、くそは無いな、確かに
msyuv.dllのYUV→RGBは伸張処理するようになってるね。
>>563
それが普通。
なぜなら基本的にRGB変換というものは再生時、表示時のためのオプションだからだ。
趣味のDTV人口の拡大に伴う複数ソフトへの動画の受け渡しや、
中間ファイルの一般化なんぞ考慮してないからな。
それが普通。
なぜなら基本的にRGB変換というものは再生時、表示時のためのオプションだからだ。
趣味のDTV人口の拡大に伴う複数ソフトへの動画の受け渡しや、
中間ファイルの一般化なんぞ考慮してないからな。
つまりｹﾞﾌｫは異端ってことだ
DirectX 8.1 YUV Color Space Fix
567 ：名無しさん＠編集中：03/06/26 23:22
msyuv.dll
fixということはそれ以前は伸張しないか俺スケールかだったのか・・・
つまりはAviUtlでTV→PCスケール補正で最終保存するとまずいって事？
ノーチェックで保存が当たり前？
ノーチェックで保存が当たり前？
だから、ソースによるって言ってるだろ。あほんだら
572 ：名無しさん＠編集中：03/06/27 01:37
>>573
キャプチャする時、どの様に輝度等を調整してるか分からない。
取り込み方がRGB24かYUY2か分からない。
どのMJPEG codecを使ってるのか分からない。
AviutlのMJPEGのcodec設定がRGB24かYUY2か分からない。
キャプチャする時、どの様に輝度等を調整してるか分からない。
取り込み方がRGB24かYUY2か分からない。
どのMJPEG codecを使ってるのか分からない。
AviutlのMJPEGのcodec設定がRGB24かYUY2か分からない。
自作板の自作HTPCスレでBT.601厨が火種をまいてますね。
>>575
論破されたバカ?
論破されたバカ?
huffyuvで圧縮されたファイルが、yuvで記録されてるか、rgbで記録されてるか、
判別する方法無いですかね。
あとで、エンコードしようとして放置してたら、どんな設定で圧縮したか分からなく
なってしまいまして。
判別する方法無いですかね。
あとで、エンコードしようとして放置してたら、どんな設定で圧縮したか分からなく
なってしまいまして。
AviUtl(0.86d)で読み込んで[その他]->[ファイルの情報]->ビデオ展開形式
でどを?
でどを?
ああそういうことあるね
でもhuffyuvならYUV→RGB時には伸張するから区別できるんじゃ？
でもhuffyuvならYUV→RGB時には伸張するから区別できるんじゃ？
0.86dって何だよヽ(`Д´)ﾉ 0.98dだよ
>>582
ストレート変換って？
Huffyuvでは、YUVとRGBで見た目に違いは無い(BT.601伸張変換されるから同じに見えて当然）
（レンジオーバーしてればサチュレートされるから違いは出るけどそれが見てわかるかどうか？）
>>578の言うようにAviUtlかAvisynthでチェックするか
ストレート変換って？
Huffyuvでは、YUVとRGBで見た目に違いは無い(BT.601伸張変換されるから同じに見えて当然）
（レンジオーバーしてればサチュレートされるから違いは出るけどそれが見てわかるかどうか？）
>>578の言うようにAviUtlかAvisynthでチェックするか
>>584
RGBはストレート展開じゃないの？
RGBはストレート展開じゃないの？
>>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になるはず。
試してみな。見て分かるか？
>>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になるはず。
>>586
試してみたよ。見て分かったよ。
たぶん俺の言いたいことがちゃんと伝わってないだけ
１．動画編集ソフト（たとえばTMPGEnc）にそのままそのAVIを読み込ませてみる
２．そのAVIをConvTo.dllでストレートRGB展開するようにしたAVSを読み込ませてみる
３．１と２を見比べてみて変化があればYUV、なければRGB
試してみたよ。見て分かったよ。
たぶん俺の言いたいことがちゃんと伝わってないだけ
１．動画編集ソフト（たとえばTMPGEnc）にそのままそのAVIを読み込ませてみる
２．そのAVIをConvTo.dllでストレートRGB展開するようにしたAVSを読み込ませてみる
３．１と２を見比べてみて変化があればYUV、なければRGB
>>587
あほ。
それじゃAvisynth使えって言ってるじゃんか。
Avisynth使うなら、そんなことしなくたって簡単に判別つくわい。
Dubでavs読み込んで、file information見たって良いし、
ColorYUY2でdebug=3,5で見たって、YUY2のみしか使えないフィルタを追加したって分かる。
方法なんて他にもまだまだ幾つもあるぞ。
あほ。
それじゃAvisynth使えって言ってるじゃんか。
Avisynth使うなら、そんなことしなくたって簡単に判別つくわい。
Dubでavs読み込んで、file information見たって良いし、
ColorYUY2でdebug=3,5で見たって、YUY2のみしか使えないフィルタを追加したって分かる。
方法なんて他にもまだまだ幾つもあるぞ。
あほって言われてもなあ
Avisynth使うなって言われてないし
一番簡単な判別の仕方を教えろとか言われてないし…
普段やってることだから全然手間じゃないんだよな俺の場合
TMPG使うから必ずストレート変換するのよ
Avisynth使うなって言われてないし
一番簡単な判別の仕方を教えろとか言われてないし…
普段やってることだから全然手間じゃないんだよな俺の場合
TMPG使うから必ずストレート変換するのよ
教えてください。現在、LDからDVD-VIDEOへの変換を行っているのですが、
CANOPUS DigitalVideoRecorder+ふぬああにて、
UYVY&huffyuvS->Aviutl(YUY2展開無)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮無)->huffyuvS(ConvertYUY2)->CCEと、してるんですが、これで
あってるでしょうか。
CANOPUS DigitalVideoRecorder+ふぬああにて、
UYVY&huffyuvS->Aviutl(YUY2展開無)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮無)->huffyuvS(ConvertYUY2)->CCEと、してるんですが、これで
あってるでしょうか。
>>590
ふぬああの設定が不明
まぁUYVYならレンジは普通のYUVにしていると考えればあってることはあってる
勿論CCEはYUY2読み込みでしょ？
でもhuffyuv(S)キャプでCCEならAvisynthのほうが利口だよ
ふぬああの設定が不明
まぁUYVYならレンジは普通のYUVにしていると考えればあってることはあってる
勿論CCEはYUY2読み込みでしょ？
でもhuffyuv(S)キャプでCCEならAvisynthのほうが利口だよ
ふぬああでのレンジ設定って、UYVY以外にいじるところって有りますか？
色調整項目は、MTV系なので、基本的に自動で放置してますです。
あと、CCEはYUY2読み込みさせてます。
以前は、UYVY&huffyuvS->Aviutl(YUY2展開有)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮有)->huffyuvS(YUY2圧縮?)->CCE(YUY2読込?)と、していましたが、
こちらのスレでAviutlで展開圧縮すると、0-15,236-255が切り捨てられるってな話をみて、
590のやり方に変えてみました。
色調整項目は、MTV系なので、基本的に自動で放置してますです。
あと、CCEはYUY2読み込みさせてます。
以前は、UYVY&huffyuvS->Aviutl(YUY2展開有)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮有)->huffyuvS(YUY2圧縮?)->CCE(YUY2読込?)と、していましたが、
こちらのスレでAviutlで展開圧縮すると、0-15,236-255が切り捨てられるってな話をみて、
590のやり方に変えてみました。
せっかくAVIキャプ時は手動で調整できるんだから
できるなら手動で調整したほうがいいと思うけど
できるなら手動で調整したほうがいいと思うけど
>>590
このスレをくまなく見れば,そのやりかたではYUV->RGB->YUV処理が入ることがわかるはず
そしてYUV->RGB->YUVには色変換誤差が生じることも・・・
Avisynthにしなはれ
このスレをくまなく見れば,そのやりかたではYUV->RGB->YUV処理が入ることがわかるはず
そしてYUV->RGB->YUVには色変換誤差が生じることも・・・
Avisynthにしなはれ
>>595
ｱﾅﾛｸﾞなんだから当然かけてもいいでしょ
ｱﾅﾛｸﾞなんだから当然かけてもいいでしょ
アナログだからって意味分かんね
デジタルならいらないのか？
ああアニメの話か
ああアニメの話か
>>599
ﾃﾞｼﾞﾀﾙならば最終出力形式と好みの問題もあるが
ﾃﾞｼﾞﾀﾙｽﾄﾘｰﾑ記録の場合ｿｰｽにあるﾉｲｽﾞは送信側に既に存在するﾉｲｽﾞ
ｿｰｽ至上主義ならばﾃﾞｼﾞﾀﾙ記録はﾉｲｽﾞﾚｽということになる
つまりﾉｲｽﾞﾘﾀﾞｸｼｮﾝはいらない
最終出力時にﾃﾞｰﾀを圧縮しやすくするための画像処理はﾉｲｽﾞﾘﾀﾞｸｼｮﾝではなくﾌｨﾙﾀﾘﾝｸﾞでしょ
ﾃﾞｼﾞﾀﾙならば最終出力形式と好みの問題もあるが
ﾃﾞｼﾞﾀﾙｽﾄﾘｰﾑ記録の場合ｿｰｽにあるﾉｲｽﾞは送信側に既に存在するﾉｲｽﾞ
ｿｰｽ至上主義ならばﾃﾞｼﾞﾀﾙ記録はﾉｲｽﾞﾚｽということになる
つまりﾉｲｽﾞﾘﾀﾞｸｼｮﾝはいらない
最終出力時にﾃﾞｰﾀを圧縮しやすくするための画像処理はﾉｲｽﾞﾘﾀﾞｸｼｮﾝではなくﾌｨﾙﾀﾘﾝｸﾞでしょ
>>600
ｿｰｽ至上主義ならばアナログでもLDからじゃﾉｲｽﾞﾘﾀﾞｸｼｮﾝするべきじゃないと思うが
ｿｰｽ至上主義ならばアナログでもLDからじゃﾉｲｽﾞﾘﾀﾞｸｼｮﾝするべきじゃないと思うが
スレ違い。
>>601
LDがないならVHSﾃﾞｯｷでもいいから同じｿｰｽを何度もｷｬﾌﾟってみればわかる
ﾄﾞｯﾄ妨害の出現ﾊﾟﾀｰﾝは毎回かわる
>>602
無理やりｽﾚの趣旨に近くしようとしてみるﾃｽﾄ
LDｷｬﾌﾟﾁｬｰ（正確にはｱﾅﾛｸﾞｷｬﾌﾟﾁｬｰ全般）時に載るﾉｲｽﾞをﾘﾀﾞｸｼｮﾝする一番いい方法は
何度もｷｬﾌﾟﾁｬｰし、それぞれをﾌﾞﾚﾝﾄﾞし、逆鼠算的にﾌﾞﾚﾝﾄﾞを繰り返すこと
この、内容は同一だがﾉｲｽﾞの出現ﾊﾟﾀｰﾝの異なる動画のﾌﾞﾚﾝﾄﾞを繰り返すというﾌｨﾙﾀは
Vmakerが作ってて公開してたんだがな
当人もLD->DVD時に有効と書いてたが、
いい加減ｻﾗっとﾌｶｰﾂしねーかな
Huffyuvsはどーでもいいから<ｽﾚ違い
LDがないならVHSﾃﾞｯｷでもいいから同じｿｰｽを何度もｷｬﾌﾟってみればわかる
ﾄﾞｯﾄ妨害の出現ﾊﾟﾀｰﾝは毎回かわる
>>602
無理やりｽﾚの趣旨に近くしようとしてみるﾃｽﾄ
LDｷｬﾌﾟﾁｬｰ（正確にはｱﾅﾛｸﾞｷｬﾌﾟﾁｬｰ全般）時に載るﾉｲｽﾞをﾘﾀﾞｸｼｮﾝする一番いい方法は
何度もｷｬﾌﾟﾁｬｰし、それぞれをﾌﾞﾚﾝﾄﾞし、逆鼠算的にﾌﾞﾚﾝﾄﾞを繰り返すこと
この、内容は同一だがﾉｲｽﾞの出現ﾊﾟﾀｰﾝの異なる動画のﾌﾞﾚﾝﾄﾞを繰り返すというﾌｨﾙﾀは
Vmakerが作ってて公開してたんだがな
当人もLD->DVD時に有効と書いてたが、
いい加減ｻﾗっとﾌｶｰﾂしねーかな
Huffyuvsはどーでもいいから<ｽﾚ違い
毎回かわるから何
馬鹿はレスしなくていいよ。
>>603
slave乙
slave乙
>>606
どういたしまして
どういたしまして
何か語り口調が見たことあると思ったら、slaveってあの師匠だったのね
>>603
2.52標準のMergeChroma / MergeLumaがその用途のためにある。
2.52標準のMergeChroma / MergeLumaがその用途のためにある。
>>609
お、ｸｽｺ！
お、ｸｽｺ！
>>611
綺麗なソースの定義は人それぞれ。
好きなようにやればよし。
画像も見ずに「LDソースだから綺麗」というのはおかしい。
それにLDプレイヤー（DVDも準ずる）は高ければソースにピュアなわけでもなく。
勿論安いLDプレイヤーがピュアなわけでもなし。
画像なしでは判断できないが、ひとついえることは、
LDプレイヤーのYC分離は総じて糞であり、
それどころかその多くはコンポジット出力しかもたない。
LDソースが綺麗なソースだとはとても思えない。
画像を見なければわからないけどね。
スレ違いなんでsage。
綺麗なソースの定義は人それぞれ。
好きなようにやればよし。
画像も見ずに「LDソースだから綺麗」というのはおかしい。
それにLDプレイヤー（DVDも準ずる）は高ければソースにピュアなわけでもなく。
勿論安いLDプレイヤーがピュアなわけでもなし。
画像なしでは判断できないが、ひとついえることは、
LDプレイヤーのYC分離は総じて糞であり、
それどころかその多くはコンポジット出力しかもたない。
LDソースが綺麗なソースだとはとても思えない。
画像を見なければわからないけどね。
スレ違いなんでsage。
>>612
LDプレイヤーがコンポジット出力しか持たないのが多いのはその機器の特性上別に問題でもなんでもない。
LDソースが綺麗だと思わないとは・・・・貴公はどんなソースが綺麗だと思うんだ？
あくまで、一般家庭の話ですよ。
LDプレイヤーがコンポジット出力しか持たないのが多いのはその機器の特性上別に問題でもなんでもない。
LDソースが綺麗だと思わないとは・・・・貴公はどんなソースが綺麗だと思うんだ？
あくまで、一般家庭の話ですよ。
LDPによってはコンポジット出力がY/C分離したあと再混合した信号を出力
していたりするけどな。
していたりするけどな。
何かどんどんスレ違いに・・。>590に一つ助言すると、LDプレイヤーの
S-端子は確かにあんま性能が良くないことが多い。これは>612の言っている
通りだ。だから、コンポジット出力をS-VIDEOデッキの３次元Y/C分離を
通してS出力すると綺麗になる場合もある。ただしこれは、>616の言う機能を
有したLDプレイヤーの場合、効果は薄い。
S-端子は確かにあんま性能が良くないことが多い。これは>612の言っている
通りだ。だから、コンポジット出力をS-VIDEOデッキの３次元Y/C分離を
通してS出力すると綺麗になる場合もある。ただしこれは、>616の言う機能を
有したLDプレイヤーの場合、効果は薄い。
>>592
Avisynth使えって言ってるだろが ヽ(`Д´)ﾉ
LDをキャプチャーするスレ
http://pc.2ch.net/test/read.cgi/avi/1051885045/
こちらもよろしく
Avisynth使えって言ってるだろが ヽ(`Д´)ﾉ
LDをキャプチャーするスレ
http://pc.2ch.net/test/read.cgi/avi/1051885045/
こちらもよろしく
どうも皆さん助言を頂きありがとうございました。
えと、うちのプレイヤーですが、コンポジット出力は再混合したものが出力される
タイプなんで、Ｓ端子で繋いでいます。
で、16-235 <-> 0-255間違ってたら、あからさまなんで確認したかった訳なんですが、
0-15,236-255のためにAvisynthに乗り替えるのもめんどいんで、Aviutlでまったりと
逝きます。
えと、うちのプレイヤーですが、コンポジット出力は再混合したものが出力される
タイプなんで、Ｓ端子で繋いでいます。
で、16-235 <-> 0-255間違ってたら、あからさまなんで確認したかった訳なんですが、
0-15,236-255のためにAvisynthに乗り替えるのもめんどいんで、Aviutlでまったりと
逝きます。
本当に、Aviutlもいい加減サチュレートしないバージョンださないかなぁ
Avisynth使うの面倒くさくなってきた
Avisynth使うの面倒くさくなってきた
つーかこのスレに来たのってAvisynth使うの面倒だからだったんだけど
今やこっちの方がメンドイな
今やこっちの方がメンドイな
AviUtlを貶しているけど、
AviUtlがRGBだったころ(0.97まで)、または、0.98でサチュレートしていることを
知る前までならみんな文句言わずに使ってたよな。
高画質で綺麗綺麗と言って。
サチュレートしているって聞いたとたん、AviUtl使うのは問題だよな、
っていうのはどういうものなのか。
AviUtlがRGBだったころ(0.97まで)、または、0.98でサチュレートしていることを
知る前までならみんな文句言わずに使ってたよな。
高画質で綺麗綺麗と言って。
サチュレートしているって聞いたとたん、AviUtl使うのは問題だよな、
っていうのはどういうものなのか。
そうですね。痛いﾊｲｴﾝﾄﾞｵｰﾃﾞｨｵに現を抜かしてるﾔｼみたいで
ｱﾌｫくさいですよね。洩れは綺麗に見えるように自分が納得した
設定にしています。それに、苦労して何時間もかけてｴﾝｺｰﾄﾞした
ﾌｧｲﾙって、HDD の肥やしにしかなってないのが現状だしね～。
ｱﾌｫくさいですよね。洩れは綺麗に見えるように自分が納得した
設定にしています。それに、苦労して何時間もかけてｴﾝｺｰﾄﾞした
ﾌｧｲﾙって、HDD の肥やしにしかなってないのが現状だしね～。
後で鑑賞するのが目的なはずなのに、いかに理論に沿って
ｿｰｽに忠実にｴﾝｺｰﾄﾞするかが目的になっちゃってる自分に
ふと気付くと、本当に無駄な時間の過ごし方してる。
ｿｰｽに忠実にｴﾝｺｰﾄﾞするかが目的になっちゃってる自分に
ふと気付くと、本当に無駄な時間の過ごし方してる。
エンコードそのものに試行錯誤することが快感になってることに早く気付けよ
この板にはそんな人間がいくらでもいるから安心しろって
この板にはそんな人間がいくらでもいるから安心しろって
自己満足ｵﾅﾇｨ板（;´Д`）ﾊｧﾊｧ…
628 ：名無しさん＠編集中：03/07/03 18:29
>>624-625
slaveうぜえ
slaveうぜえ
Aviutlの98以降がｻﾁｭﾚｰﾄするのは本家BBSでもここのAviutlｽﾚでも
98発表当時問題になってる
「TVｽｹｰﾙとPCｽｹｰﾙつけるからいいでしょ」ってな返答をKENがして
「ちげーよ、色がｸﾛｯﾌﾟされるって言ってるんだよ」って突っ込まれてたんだが
「ﾊｧ?BT.601だとこれが正規ですよ、と。おまいの環境のｷｬﾘﾌﾞﾚｰﾄがｵｶｼｲｶﾓﾅｰ」
みてーな返答でｽﾙｰされておった。
意地でも直さないだろうな・・・KEN。
98発表当時問題になってる
「TVｽｹｰﾙとPCｽｹｰﾙつけるからいいでしょ」ってな返答をKENがして
「ちげーよ、色がｸﾛｯﾌﾟされるって言ってるんだよ」って突っ込まれてたんだが
「ﾊｧ?BT.601だとこれが正規ですよ、と。おまいの環境のｷｬﾘﾌﾞﾚｰﾄがｵｶｼｲｶﾓﾅｰ」
みてーな返答でｽﾙｰされておった。
意地でも直さないだろうな・・・KEN。
>>629
slaveは恐ろしい釣り氏だな。
「そこまでAviutlをおとしめたいのか？」
と思ってAviutlスレ3から6まで読んじゃったじゃねーか。
完全に釣られました。
そんな話はでてきておりません。
途中音ずれの話題でレスが埋め尽くされてたのはワラタが,
あの頃は結構まともに機能してたんだな ＞Aviutlスレ。
slaveは恐ろしい釣り氏だな。
「そこまでAviutlをおとしめたいのか？」
と思ってAviutlスレ3から6まで読んじゃったじゃねーか。
完全に釣られました。
そんな話はでてきておりません。
途中音ずれの話題でレスが埋め尽くされてたのはワラタが,
あの頃は結構まともに機能してたんだな ＞Aviutlスレ。
似たようなので、YUY2入力するとスケール伸張されるって騒いでたな。
そしたら内部は12bit有効なので伸張されてもクロップされないってマルモがしゃしゃり出たんじゃなかったっけ？
そしたら内部は12bit有効なので伸張されてもクロップされないってマルモがしゃしゃり出たんじゃなかったっけ？
aviutlは途中でクリップされないのがいいとこなんだがな
YCCは各12ビット表現だけど出力フレームが確定するまでは16ビットフルに有効だから
（プラグイン作者が想定してるのは13ビット以内のデータだけだろうけど）
YUY2読みしてもYゲインを下げれば範囲外の階調もちゃんと残ってることに気付くよ
avisynthの場合、データは8ビットでしか扱えないから
何かのフィルタで一度飽和させてしまうともう元に戻せないしね
まぁ速いし、YUY2読みしたものをそのままCCEに渡せるから愛用してるけど。。
YCCは各12ビット表現だけど出力フレームが確定するまでは16ビットフルに有効だから
（プラグイン作者が想定してるのは13ビット以内のデータだけだろうけど）
YUY2読みしてもYゲインを下げれば範囲外の階調もちゃんと残ってることに気付くよ
avisynthの場合、データは8ビットでしか扱えないから
何かのフィルタで一度飽和させてしまうともう元に戻せないしね
まぁ速いし、YUY2読みしたものをそのままCCEに渡せるから愛用してるけど。。
>>632
m2v.vfpでYC伸長してAviUtlに渡すよりm2v.auiでYUY読み込みしたほうが
AviUtlでYUY2のソースをYUY2で展開してYUY2で圧縮する設定なら
RGBのヒストグラムを0-255まで使ってYUY2に圧縮するときに
BT.601の範囲内に収まるYUY2データを残せて良いと理解していいですか?
m2v.vfpでYC伸長してAviUtlに渡すよりm2v.auiでYUY読み込みしたほうが
AviUtlでYUY2のソースをYUY2で展開してYUY2で圧縮する設定なら
RGBのヒストグラムを0-255まで使ってYUY2に圧縮するときに
BT.601の範囲内に収まるYUY2データを残せて良いと理解していいですか?
>>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変換の欠点・利点は↑のほうでガヤガヤやっとるんで、
ログ参照。
小一時間悩んだが、俺はお前の言いたいことが理解できない。
日本語勉強しなおしてくれ。
”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変換の欠点・利点は↑のほうでガヤガヤやっとるんで、
ログ参照。
radeonは規格準拠なのがはっきりしたわけだが
> ちなみにRADEONはDTVについてのPDFで
> >RADEON supports any of the color spaces defined by the MPEG-2 standard,
> としている。
> http://mirror.ati.com/developer/atirdv.pdf
> ちなみにRADEONはDTVについてのPDFで
> >RADEON supports any of the color spaces defined by the MPEG-2 standard,
> としている。
> http://mirror.ati.com/developer/atirdv.pdf
>>636
はっきりしてないわけだがw
はっきりしてないわけだがw
こういう言い方はあいまいにするための常套手段だねｗ。
つか、準拠という言葉自体が。。。
つか、準拠という言葉自体が。。。
MPEG2規格のいかなる色空間もサポートするよ、と。
それはYV12,YUY2,IYU2をサポートするよ、と言ってるだけだろ。
大体このスレで誰も突っ込みが入らないのが不思議なんだが、
BT.601規格にはストレート変換も入っているのだよ。
”BT.601準拠=伸張変換”みたいなレスが多いが
それは間違い。
それはYV12,YUY2,IYU2をサポートするよ、と言ってるだけだろ。
大体このスレで誰も突っ込みが入らないのが不思議なんだが、
BT.601規格にはストレート変換も入っているのだよ。
”BT.601準拠=伸張変換”みたいなレスが多いが
それは間違い。
>>639
IYU2ってなに？
IYU2ってなに？
ここって常駐者しかいないのに
新情報なんてﾛｸにないから
初心者がくだらないｶｷｺしないとﾚｽが進まないね
まぁその初心者も常駐はしないだろうし
新情報なんてﾛｸにないから
初心者がくだらないｶｷｺしないとﾚｽが進まないね
まぁその初心者も常駐はしないだろうし
644 ：名無しさん＠編集中：03/07/06 00:45
>>643
slave氏ね
slave氏ね
646 ：名無しさん＠編集中：03/07/11 01:19
90さんの書いてることが真実なんだろ。悩むことないよな。
YUV形式の動画 → RGB形式の動画 YC伸張する
RGB形式の動画 → YUV形式の動画 YC圧縮する
で良いんだろ？
あとは使うソフトによって精度が変わるくらいで大した問題じゃないな。
YUV形式の動画 → RGB形式の動画 YC伸張する
RGB形式の動画 → YUV形式の動画 YC圧縮する
で良いんだろ？
あとは使うソフトによって精度が変わるくらいで大した問題じゃないな。
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スケールっていうのもあながちそうでもない
ということになる。
> 残念ながら>>90に書いてあることは真実ではない
真実ではないのはどういう点なんだい？
俺がひとつ疑問かなぁと思ったのはキャプチャーで出来るMPEGはTVスケール
（16-235）で間違いないと思うんだけど、hunuaaなんかでhuffyuv圧縮（yuv形式）
で取り込んだAVIもTVスケール（16-235）なのかなぁっていう点。個人的には
RGBをYC圧縮なしにRGB>YUV変換してるような気がするのでPCスケール（0-255）
のような気がする。
とすれば、90さんの言うYUV系：TVスケールっていうのもあながちそうでもない
ということになる。
お前ら、どっちでもいいんだよ。綺麗に見える方。これ最強。理屈などいらぬ！
またあふぉがきた
TVスケールとかPCスケールとかいう言葉に納得がいかない
650は648へのレス
>>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]
のうちどれを使ってるか把握出来てれば問題ないんだろ？あとは些細な精度の問題で。
full-range RGB [0,255]
compressed-range RGB [16,235]
full-range YUV [0,255]
compressed-range YUV [16,235]
のうちどれを使ってるか把握出来てれば問題ないんだろ？あとは些細な精度の問題で。
わけわからん
659 ：名無しさん＠編集中：03/07/11 21:43
そもそもMSがちゃんと動画フォーマットの仕様決めないからこんなことに
なるんだな。
WIN上で扱うRGBはすべてfull rangeに汁！YUVはすべてcompressed rangeに汁！
Video Cardはオーバーレイ使う時はHWでYC伸張汁！ってすれば無問題なのにな。
なるんだな。
WIN上で扱うRGBはすべてfull rangeに汁！YUVはすべてcompressed rangeに汁！
Video Cardはオーバーレイ使う時はHWでYC伸張汁！ってすれば無問題なのにな。
661 ：名無しさん＠編集中：03/07/11 21:52
>>658
まぁね。些細な問題じゃない人もいるわな。そのへんは個人の価値観ってことで。
俺はYC伸張や圧縮を二重にかけたりしさえしなけりゃそれでOKって思える人間
だからなぁ。
ノイズやアルゴリズムの計算上の誤差なんてのはこだわりだしたらきりがない
からな。それこそ最終的にはソース見せろや、ごるぁってところまでいかないと
ほんとの信用なんて出来ない訳だしな。ｗ
まぁね。些細な問題じゃない人もいるわな。そのへんは個人の価値観ってことで。
俺はYC伸張や圧縮を二重にかけたりしさえしなけりゃそれでOKって思える人間
だからなぁ。
ノイズやアルゴリズムの計算上の誤差なんてのはこだわりだしたらきりがない
からな。それこそ最終的にはソース見せろや、ごるぁってところまでいかないと
ほんとの信用なんて出来ない訳だしな。ｗ
662 ：名無しさん＠編集中：03/07/11 21:55
663 ：名無しさん＠編集中：03/07/11 22:04
腐れアプリ：Avisynth厨が言うところのAviUtl
腐れCodec：HuffyuvS厨が言うところのHuffyuv
腐れアプリ:内部RGBのTMPGEnc
腐れコーデック:いわずもがなのHuffyuvSとHuffyuvのconv->yuy2
腐れ仕様:VFAPI
腐れコーデック:いわずもがなのHuffyuvSとHuffyuvのconv->yuy2
腐れ仕様:VFAPI
>>661がどうやってるのかは知らない
ただよくやる以下の手法は
正直どう見ても色がかわる
DVD2AVI->.d2vでAviutl->Huffyuv(YUY2)中間ﾌｧｲﾙ->TMPGEnc
↑こんなことしといて
「エンコードって色が変わるねぇ」
いわれてもさぁ・・・
いや、エンコードによる色変わりは当然あるけど
それ以上の問題があるだろ？
まぁ手順の問題というか
目の問題というか
ただよくやる以下の手法は
正直どう見ても色がかわる
DVD2AVI->.d2vでAviutl->Huffyuv(YUY2)中間ﾌｧｲﾙ->TMPGEnc
↑こんなことしといて
「エンコードって色が変わるねぇ」
いわれてもさぁ・・・
いや、エンコードによる色変わりは当然あるけど
それ以上の問題があるだろ？
まぁ手順の問題というか
目の問題というか
腐れcodec:WMV9のインターレース
668 ：661：03/07/12 01:07
>>666
俺の手順は
hunuaa（huffyuvキャプ、YUY2）→AVIUTLで編集(フィルタ類は一切使わず、
カット＆ペーストのみで再圧縮なしで保存）→WME9でインタレエンコ
VGAはG450、AVIUTLも再圧縮なしだと高速だし、TV出力してもモニタで見ても
同じように見えるし、俺的には画質も無問題。
俺の手順は
hunuaa（huffyuvキャプ、YUY2）→AVIUTLで編集(フィルタ類は一切使わず、
カット＆ペーストのみで再圧縮なしで保存）→WME9でインタレエンコ
VGAはG450、AVIUTLも再圧縮なしだと高速だし、TV出力してもモニタで見ても
同じように見えるし、俺的には画質も無問題。
インタレを壊すNRって何？
671 ：名無しさん＠編集中：03/07/12 02:30
672 ：名無しさん＠編集中：03/07/12 02:36
>>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
なんてのなら、ライン間でブレンドされるだろが。
上下に隣接している点を考慮するNRはインタレ構造を壊すことが分からんか？
たとえば、P(x,y)=( P(x,y) + P(x,y-1) + P(x,y+1) + P(x-1,y) + P(x+1,y) ) / 5
なんてのなら、ライン間でブレンドされるだろが。
675 ：名無しさん＠編集中：03/07/12 09:32
>>659
PCで完結してもダメなのよ
PCで完結してもダメなのよ
676 ：名無しさん＠編集中：03/07/12 11:59
またアフォが一人現れたな ＞675
やっと理解できた。みなさんありがとう。
678 ：名無しさん＠編集中：03/07/12 12:26
678必死だな（藁
680 ：名無しさん＠編集中：03/07/12 13:52
679 名前：名無しさん＠編集中[sage] 投稿日：03/07/12 13:45
678必死だな（藁
678必死だな（藁
681 ：名無しさん＠編集中：03/07/12 16:02
242 ：名無しさん＠編集中 ：03/07/13 16:52
>>240
本当は可逆圧縮より圧縮しないで良いならそのほうが良いが、
ＭＰＥＧからなら普通Huffyuv を使うという事。
元の情報よりHuffyuvにした時点で少し劣化する。
243 ：名無しさん＠編集中 ：03/07/13 17:21
>>242
若干わかりにくい文章かも。
244 ：名無しさん＠編集中 ：03/07/13 17:30
>>242
Huffyuvってハフマン符号化だけじゃないの？だとしたら劣化しないはずだけど。
>>240
本当は可逆圧縮より圧縮しないで良いならそのほうが良いが、
ＭＰＥＧからなら普通Huffyuv を使うという事。
元の情報よりHuffyuvにした時点で少し劣化する。
243 ：名無しさん＠編集中 ：03/07/13 17:21
>>242
若干わかりにくい文章かも。
244 ：名無しさん＠編集中 ：03/07/13 17:30
>>242
Huffyuvってハフマン符号化だけじゃないの？だとしたら劣化しないはずだけど。
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ソースは非圧縮じゃない。
>>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ソースは非圧縮じゃない。
251 ：名無しさん＠編集中 ：03/07/13 18:40
ＡＶＩ(YUY2)を編集後に中間ファイルを出して
その後DIVX化する場合にHuffyuv(YUY2)でやると
元のＡＶＩ(YUY2)よりサイズが小さくて明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。
252 ：名無しさん＠編集中 ：03/07/13 18:47
？？？
253 ：251 ：03/07/13 18:48
修正。AVI(UYVY)
ＡＶＩ(YUY2)を編集後に中間ファイルを出して
その後DIVX化する場合にHuffyuv(YUY2)でやると
元のＡＶＩ(YUY2)よりサイズが小さくて明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。
252 ：名無しさん＠編集中 ：03/07/13 18:47
？？？
253 ：251 ：03/07/13 18:48
修正。AVI(UYVY)
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
同意。
ハフマン符号化して劣化するなら、世のプログラムは圧縮した段階で
正常に動作しなくなりなります。
>>251
カラーフォーマットの変換による色(色差)情報の劣化と、圧縮形式による情報の欠落を
ごっちゃになっているような。
通常、圧縮による劣化の有無は、カラーフォーマットの変換を含めないで話した方が
いいんじゃないだろうか？
256 ：名無しさん＠編集中 ：03/07/13 19:40
>>251
もとのAVI(UYVY)はどうやって生成した？
その編集とやらはVirtualDub系のFastRecompresなのか？
257 ：名無しさん＠編集中 ：03/07/13 19:42
>>255
同意。
ハフマン符号化して劣化するなら、世のプログラムは圧縮した段階で
正常に動作しなくなりなります。
259 ：名無しさん＠編集中 ：03/07/13 19:44
釣りだろ
”元のＡＶＩ(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のやり方では以下のような減少がおこる
ＡＶＩ(UYVY)を編集後に中間ファイルを出して
その後DIVX化する場合にＡＶＩ(UYVY)でやると明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。
釣りだろ
”元のＡＶＩ(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のやり方では以下のような減少がおこる
ＡＶＩ(UYVY)を編集後に中間ファイルを出して
その後DIVX化する場合にＡＶＩ(UYVY)でやると明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。
また、やってる・・・
358 ：名無しさん＠編集中 ：03/07/14 19:32
>>261
ＡＶＩ(UYVY)で撮ったならhufにしないほうが結果はいい。
自分の環境ではＡＶＩ(YUY2)でも撮れるが、その場合はhufにしても劣化はない。
要するにYUY2よりUYVYのほうがはっきりわかるほど綺麗なんですよ。UYVYで
プレミア編集後無圧縮で書き出してdubでＤＩＶＸ化するので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/
>>261
ＡＶＩ(UYVY)で撮ったならhufにしないほうが結果はいい。
自分の環境ではＡＶＩ(YUY2)でも撮れるが、その場合はhufにしても劣化はない。
要するにYUY2よりUYVYのほうがはっきりわかるほど綺麗なんですよ。UYVYで
プレミア編集後無圧縮で書き出してdubでＤＩＶＸ化するので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です。
>>689
omaedareda?
omaedareda?
691 ：名無しさん＠編集中：03/07/14 20:50
ﾈｲﾃｨﾌﾞUYVYだからRGB変換誤差がおこる だから
hufにしない。で間違ってないじゃん。
hufにしない。で間違ってないじゃん。
692 ：x：03/07/14 20:52
◎無修正画像をご覧下さい◎２日間無料です◎
★http://yahooo.s2.x-beat.com/linkvp/linkvp.html★
★http://yahooo.s2.x-beat.com/linkvp/linkvp.html★
>>691
ﾈｲﾃｨﾌﾞUYVYでも
”UYVYであってもAvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。”
ってのはどうよ。
つーか
”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”
ってなんじゃ？
ﾈｲﾃｨﾌﾞUYVYでも
”UYVYであってもAvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。”
ってのはどうよ。
つーか
”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”
ってなんじゃ？
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
Huffyuvの対応色空間
YUY2、UYVY、RGB24、RGB32(RGBA)
UYVYもそのまま圧縮可能だよ。
YUY2、UYVY、RGB24、RGB32(RGBA)
UYVYもそのまま圧縮可能だよ。
>>696
AvisynthはYV12かYUY2かRGB32にしか対応しとらんやん
AvisynthはYV12かYUY2かRGB32にしか対応しとらんやん
>>697
それはフィルタの話でしょ？
I420でもswapUVでYUY2にできるわけだから。
でも”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”は不可能？
Directshowで読めるならYUY2に変更して展開するんかな？
UYVYの動画がないんでよくわからないんだが。
それはフィルタの話でしょ？
I420でもswapUVでYUY2にできるわけだから。
でも”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”は不可能？
Directshowで読めるならYUY2に変更して展開するんかな？
UYVYの動画がないんでよくわからないんだが。
Avisynth2.52でUYVY試してみた。
無圧縮UYVYの場合、RGB32にdecompressされた。(vidc.UYVY=msyuv.dll、huffyuv.dllとも）
Huffyuv(UYVY)の場合、YUY2にdecompressされた。
どうやら、Huffyuv(msyuvも同様）は、UYVYでdecompressQueryすると、RGB32/24を返すようだ。
無圧縮UYVYの場合、RGB32にdecompressされた。(vidc.UYVY=msyuv.dll、huffyuv.dllとも）
Huffyuv(UYVY)の場合、YUY2にdecompressされた。
どうやら、Huffyuv(msyuvも同様）は、UYVYでdecompressQueryすると、RGB32/24を返すようだ。
>>699
UYUVの見た目はYUY2なんだが
UYUVの見た目はYUY2なんだが
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に変換されるので使用しない方が良い。
ということになる。
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に変換されるので使用しない方が良い。
ということになる。
間違い訂正
intype=-2(RGB24) -> intype=-2(HFYU(RGB24))
intype=-3(RGB32) -> intype=-3(HFYU(RGB32))
intype=-2(RGB24) -> intype=-2(HFYU(RGB24))
intype=-3(RGB32) -> intype=-3(HFYU(RGB32))
706 ：名無しさん＠編集中：03/07/17 20:59
落ちるには惜しいスレ
707 ：名無しさん＠編集中：03/07/17 21:37
VirtualDubで非圧縮UYVY読ましてからDivxにしてる。
間にHuffyuv入れる事はない。というかVirtualDubで
取り扱えるんじゃないの。自分はHuffyuvにすると
容量３パーセントほど減って重くなるし、コーデックHuffyuvのＡＶＩで
撮ってもそう。
間にHuffyuv入れる事はない。というかVirtualDubで
取り扱えるんじゃないの。自分はHuffyuvにすると
容量３パーセントほど減って重くなるし、コーデックHuffyuvのＡＶＩで
撮ってもそう。
708 ：名無しさん＠編集中：03/07/17 21:44
UYVYを展開するのはmsyuv.dllじゃないの？
VirtualDubはfast recompressでもYUY2/RGBじゃないと入力できないはずだけど。
710 ：名無しさん＠編集中：03/07/17 22:11
YUY2で撮るとさらに汚いけど…
ｹﾞﾌｫ厨発見
622 ：名無しさん＠編集中 ：03/07/17 03:59
>>619
PCのモニタで見てない？
TVに出力すればちゃんとしたメリハリの効いた画になってるはず。
PCモニタでTVと同じ画を表示しようってのは絶対無理。
622 ：名無しさん＠編集中 ：03/07/17 03:59
>>619
PCのモニタで見てない？
TVに出力すればちゃんとしたメリハリの効いた画になってるはず。
PCモニタでTVと同じ画を表示しようってのは絶対無理。
蛍光体の違いはあるからTVと同じように表示するのは難しいことは確か。
でも、蛍光体の違い以前にTVのキャリブレーションがまったくされていない
ため、見栄えが違ってくる場合がほとんど。TVはRed Pushしたりガンマ補正
したりと、原信号を思いっきり歪めて表示していることが非常に多い。
でも、蛍光体の違い以前にTVのキャリブレーションがまったくされていない
ため、見栄えが違ってくる場合がほとんど。TVはRed Pushしたりガンマ補正
したりと、原信号を思いっきり歪めて表示していることが非常に多い。
民生用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を使ったキャプに乗り換える予定なのです。
何か間違いがあれば指摘してください。
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を使ったキャプに乗り換える予定なのです。
何か間違いがあれば指摘してください。
なんか難しいことやってるなぁ。
YUY2で展開/圧縮をオフるとRGBになっちゃうからオンの方がいいと思うぞ。
それから、YC伸張プラグインを使ってAviUtl上でyuv411>422補完、とか
Avisynth上でフィールド別処理のcolorYUY2で411>422補完→avsinp.auiを使ってAviUtlにわたす、とか
すれば処理が少なくてすむかな。
あとは中間吐くなりVFAPI Reader CodecつかうなりでCCEに渡すと。
最後までyuvでいきたいなら中間つくった方がいいのかな。
中間出力するならDVよりHuffyuvかLCLのほうがいいよ。
俺もあんまり詳しくないんで間違ってるかもしれんけど。
YUY2で展開/圧縮をオフるとRGBになっちゃうからオンの方がいいと思うぞ。
それから、YC伸張プラグインを使ってAviUtl上でyuv411>422補完、とか
Avisynth上でフィールド別処理のcolorYUY2で411>422補完→avsinp.auiを使ってAviUtlにわたす、とか
すれば処理が少なくてすむかな。
あとは中間吐くなりVFAPI Reader CodecつかうなりでCCEに渡すと。
最後までyuvでいきたいなら中間つくった方がいいのかな。
中間出力するならDVよりHuffyuvかLCLのほうがいいよ。
俺もあんまり詳しくないんで間違ってるかもしれんけど。
>>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のフィルタを使う方法です。
ちょっとその方法はひどすぎ
大体ソフトウェアで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のフィルタを使う方法です。
>>718
なるほど、今YC伸張フィルタ落としてきたところです。
中間ファイル作るのもいいけど、HDDに余裕あるわけでもないので、
最後だけVFAPI経由でCCEに渡して16-235でエンコすることにします。
何にしても、波形表示フィルタでヒストグラム見ながら、
おかしなことにならないように確認していこうと思います。
ありがとうございました。
なるほど、今YC伸張フィルタ落としてきたところです。
中間ファイル作るのもいいけど、HDDに余裕あるわけでもないので、
最後だけVFAPI経由でCCEに渡して16-235でエンコすることにします。
何にしても、波形表示フィルタでヒストグラム見ながら、
おかしなことにならないように確認していこうと思います。
ありがとうございました。
>>719
YC伸張フィルタを使用したのに、Avisynthでも伸張？補完？するのは何故ですか？
あと、AVIUTLからAvisynthへの持っていき方がわからないです。ソースを読み込むとか....
というか、Avisynth使ったことないのでさっぱりな自分があかんのですけど。
もうすこし解かりやすい説明をして頂けないでしょうか。
YC伸張フィルタを使用したのに、Avisynthでも伸張？補完？するのは何故ですか？
あと、AVIUTLからAvisynthへの持っていき方がわからないです。ソースを読み込むとか....
というか、Avisynth使ったことないのでさっぱりな自分があかんのですけど。
もうすこし解かりやすい説明をして頂けないでしょうか。
>>722
AvisynthのAviutlFilterPluginは
Avisynth上でAviutlのフィルタを使うプラグインなんだけど
なんせスクリプトだから数値を変化させても動的に画質をチェックしにくい
だからAviutl上でいっかいフィルタの各設定値を煮詰めておいて
その数値をAvisynthのスクリプトに書き写してるんだよ
だから”5,Aviutlでは出力しない”
Aviutlは設定を決めるために使ってるだけ
AvisynthのAviutlFilterPluginは
Avisynth上でAviutlのフィルタを使うプラグインなんだけど
なんせスクリプトだから数値を変化させても動的に画質をチェックしにくい
だからAviutl上でいっかいフィルタの各設定値を煮詰めておいて
その数値をAvisynthのスクリプトに書き写してるんだよ
だから”5,Aviutlでは出力しない”
Aviutlは設定を決めるために使ってるだけ
いや、すんません。頑張ってきます。
>>723
具体的にどのフィルターをAviutlFilterPluginで読み込んでる?
できればAvisynthだけで完結したいんだけどwavelet系が弱いからまだAviUtlフィルター手放せないんだよなぁ。
具体的にどのフィルターをAviutlFilterPluginで読み込んでる?
できればAvisynthだけで完結したいんだけどwavelet系が弱いからまだAviUtlフィルター手放せないんだよなぁ。
>>717
430見れ
430見れ
1から読んだけど全然わからん。
結論を書いては貰えませんか？
普通にキャプって、普通にエンコする場合どうすればいいんです？
ふぬああとかHuffyuvとかややこしい物は使いません。
結論を書いては貰えませんか？
普通にキャプって、普通にエンコする場合どうすればいいんです？
ふぬああとかHuffyuvとかややこしい物は使いません。
そもそもふぬああやHuffyuvを使わない普通じゃない方法ってあるのか？
思いつくのはDVDレコやDVやD-VHS使う方法くらいだが。
何も考えずMPEG2→MPEG1みたいなことじゃないのか？
思いつくのはDVDレコやDVやD-VHS使う方法くらいだが。
何も考えずMPEG2→MPEG1みたいなことじゃないのか？
何も考えないにしてもどーゆー手順でどーゆーソフト使ったか
わからんとどーにもならないわけで
わからんとどーにもならないわけで
730じゃないですけど、松下のDMR-E80Hで録画したものを、
DVD2AVIとTMPGEncでVCD・MPEG2・Divx等にエンコードする時はどうすればいいんでしょう？
DVD2AVIとTMPGEncでVCD・MPEG2・Divx等にエンコードする時はどうすればいいんでしょう？
>>735
ｴﾝｺの仕方勉強して出直してこい
ｴﾝｺの仕方勉強して出直してこい
MPEG2-TS → DVD2AVI → Avisynth → CCE → DVD
この場合ですが、AvisynthにColorYUY2(levels="709->601")と入れておくと良いんでしょうか？
DVD2AVI1.77.3、Avisynth2.52、MPEG2Dec3を使ってます。
この場合ですが、AvisynthにColorYUY2(levels="709->601")と入れておくと良いんでしょうか？
DVD2AVI1.77.3、Avisynth2.52、MPEG2Dec3を使ってます。
色が薄いと思ったら伸張すれ
ちょうどいいと思ったらしない
それだけだ
ちょうどいいと思ったらしない
それだけだ
イジワル
>>737
MPEG2-TSだからといって、必ずしもBT.709とは限らないよ。SDならBT.601だし。
MPEG2-TSだからといって、必ずしもBT.709とは限らないよ。SDならBT.601だし。
>>741
HDの時だけですか？
HDの時だけですか？
HDってプログレだけだっけ？
744 ：名無しさん＠編集中：03/07/30 20:50
DOS/V magazine で 動画の表示比較記事があったが
nVIDIAはGeforceFXになっても、ATIやMatroxやS3とは明らかにスケールの取り方が違うことが分かったよ。
nVIDIAはGeforceFXになっても、ATIやMatroxやS3とは明らかにスケールの取り方が違うことが分かったよ。
nVIDIAもうだめぽ
マジで？？
720p
720pの時にfalseなんでつね
Interlaced指定は、YUY2なら気にしなくてよいぞ。
720pってBS朝日で1回放送しただけなんだっけ。以前、地上デジタルでは720pなんて
話があったけど、結局1080iになったみたいだし。
話があったけど、結局1080iになったみたいだし。
753 ：ぼるじょあ ◆yBEncckFOU ：03/08/02 05:04
∧＿∧ ∧＿∧
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
直リンしてしまった。ごめんなさい。
756 ：名無しさん＠編集中：03/08/03 23:36
757 ：名無しさん＠編集中：03/08/04 06:19
美少女コスプレイヤーのパンチラと
パイパンおまんこが見れるサイトを発見でつ！！！
http://plaza16.mbn.or.jp/~satchel/idolno_omanko/
パイパンおま○こは本当に美しい… (*´∀`*)ハァハァ
パイパンおまんこが見れるサイトを発見でつ！！！
http://plaza16.mbn.or.jp/~satchel/idolno_omanko/
パイパンおま○こは本当に美しい… (*´∀`*)ハァハァ
NHKに問い合わせりゃいいじゃん。
おかしな知障が何か言っております
762 ：名無しさん＠編集中：03/08/05 13:23
高ビットレートMPEG2からDVDサイズのMPEG2への変換における
カラースケールの設定について詳しく、しかしなるべく簡単に
説明をお願いします。
過去ログ嫁とかはなしで。
次からテンプレにできますしね。
カラースケールの設定について詳しく、しかしなるべく簡単に
説明をお願いします。
過去ログ嫁とかはなしで。
次からテンプレにできますしね。
おかしな知障が何か言っております
夏真っ盛り
///////
///////＿＿＿＿＿＿＿＿＿＿＿_
/////// ￣￣￣￣￣￣￣￣￣|￣￣
/////// (~) ﾁﾘﾝﾁﾘﾝ
/////// ﾉ,,
/////// ∧＿∧ ／￣￣￣￣￣￣
/////// （ ´∀｀）（ 厨 ） )） ＜ 夏だなあ～
/////// （つ へへ つ ＼＿＿＿＿＿＿
/////// //△ ヽλ ） ） 旦
////// l￣￣￣￣￣￣￣￣￣￣￣l
///// ￣| .|￣￣￣￣￣￣￣| .|￣
//// ^＾^ ^＾^
2chの夏。厨房の夏。
///////＿＿＿＿＿＿＿＿＿＿＿_
/////// ￣￣￣￣￣￣￣￣￣|￣￣
/////// (~) ﾁﾘﾝﾁﾘﾝ
/////// ﾉ,,
/////// ∧＿∧ ／￣￣￣￣￣￣
/////// （ ´∀｀）（ 厨 ） )） ＜ 夏だなあ～
/////// （つ へへ つ ＼＿＿＿＿＿＿
/////// //△ ヽλ ） ） 旦
////// l￣￣￣￣￣￣￣￣￣￣￣l
///// ￣| .|￣￣￣￣￣￣￣| .|￣
//// ^＾^ ^＾^
2chの夏。厨房の夏。
>>766
じゃおまえがやれば
じゃおまえがやれば
769 ：名無しさん＠編集中：03/08/05 19:18
というわけで最強のテンプレ案↓
YC伸張はどんなとき必要か？
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://www.studiomilk.com/ichigomilk/diary/orenatsu2opdemo.swf
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://www.studiomilk.com/ichigomilk/diary/orenatsu2opdemo.swf
>>770
お前、楽しい?
お前、楽しい?
773 ：名無しさん＠編集中：03/08/05 23:50
slaveがスネちゃったからテンプレ化は無理だろうな
ビデオカードでGEフォースを使ってるのですが、
そのためにWMPで再生したときオーバーレイを切らないと
暗くなってしまいます。
オーバーレイを切らずに暗くしない方法ってありますか？
あと、今、WIN2ｋを使ってるのでわからないのですが、
将来WINXPで60fps再生したとき、オーバーレイを有効にしないと
できないと思うのですが、そのときも暗くなってしまうのでしょうか？
そのためにWMPで再生したときオーバーレイを切らないと
暗くなってしまいます。
オーバーレイを切らずに暗くしない方法ってありますか？
あと、今、WIN2ｋを使ってるのでわからないのですが、
将来WINXPで60fps再生したとき、オーバーレイを有効にしないと
できないと思うのですが、そのときも暗くなってしまうのでしょうか？
775 ：名無しさん＠編集中：03/08/06 04:29
>>774
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
これ読んでモニタとデスクトップガンマを調整する、か
ffdshowをRAW ModeにしてLevalsで調節するか、か
Radeonを買うか。
http://www.canopus.co.jp/press/2001/mtv1000_review.htm
これ読んでモニタとデスクトップガンマを調整する、か
ffdshowをRAW ModeにしてLevalsで調節するか、か
Radeonを買うか。
Levelsね
HTTPの知識もないし
自分が使わないﾊﾟﾀｰｿはよくわからないし
大体あの実験をやる気が・・・
Vmaker氏のﾍﾟｰｼﾞをﾌｧｲﾙ化しとくべきでしたね
誰か保存してないんでしょうか？
自分が使わないﾊﾟﾀｰｿはよくわからないし
大体あの実験をやる気が・・・
Vmaker氏のﾍﾟｰｼﾞをﾌｧｲﾙ化しとくべきでしたね
誰か保存してないんでしょうか？
持ってるけど、どうしよう。いる？
>>779
おながいします
おながいします
>>779
頼む
頼む
>>779
よきにはからえ
よきにはからえ
>>779
兄貴って呼んで良いですか？
兄貴って呼んで良いですか？
>>779
是非！是非！！
是非！是非！！
すいません、しばらくＰＣの前から離れてたもんで、、、
ていうか、本当にconvlist.htmlでいいんですよね？
なんかとんでもないボケをかましているような気がしてきました。。。
>>783 残念ながら見あたりません。
自分が持っているのは、ブラウザの履歴によると、2003年4月28日にアクセスしたときの
もののようです。チョット古い？
ていうか、本当にconvlist.htmlでいいんですよね？
なんかとんでもないボケをかましているような気がしてきました。。。
>>783 残念ながら見あたりません。
自分が持っているのは、ブラウザの履歴によると、2003年4月28日にアクセスしたときの
もののようです。チョット古い？
>>786
個人的にはconvlist.htmlだけで結構です
個人的にはconvlist.htmlだけで結構です
できればwakamelist.htmlもお願いしたいのだが。
勝手にうｐしてもいいの？
796 ：名無しさん＠編集中：03/08/06 23:08
著作権を侵してる奴らがいるな
>>796
この板の多くの連中がそうだな。
この板の多くの連中がそうだな。
伸張されてるかどうかを見分ける方法ってないですか？
見ても色が濃いのか薄いのかわからんのです。
見ても色が濃いのか薄いのかわからんのです。
モニタじゃなくてTVで見ればいいんだよ
>>799
釣れますか?
釣れますか?
さっぱり食いつかないな。
スレてない奴いないかな？
スレてない奴いないかな？
パクッ
ネタじゃなくてマジなんですけど。
だって素人がYC伸張の話なんかわかるわけねーよ。
･ﾟ･(ﾉД`)･ﾟ･｡
だって素人がYC伸張の話なんかわかるわけねーよ。
･ﾟ･(ﾉД`)･ﾟ･｡
>>803
なら、このスレ最初から読んで出直してね。
なら、このスレ最初から読んで出直してね。
素人がエンコなんてしなくていい
素人はウンコはしてもいい
↑読んでわからないっていうのは、意味がわからないんじゃなくて、どのレスが正しいのかがわからないってこと。
だからテンプレ化して欲しいんです。
だからテンプレ化して欲しいんです。
>>808
ぢんさんが簡潔明瞭にまとめてくださってます。
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic11964
ぢんさんが簡潔明瞭にまとめてくださってます。
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic11964
>>807
それは意味がわかっていないんじゃないか。思考能力あるのか?
それは意味がわかっていないんじゃないか。思考能力あるのか?
>>807
このスレはYC伸張に関する知識を深めるためだけでなく
迷えるトーシロを導くスレでもある
自分のキャプ・エソコ手順を示せば誰かが答えてくれるよ
環境が変わったらまた訊きに来ればいい
オレはアク禁巻き添えでもう、レスできないだろうけど
（今回はラウンジクラシック経由）
このスレはYC伸張に関する知識を深めるためだけでなく
迷えるトーシロを導くスレでもある
自分のキャプ・エソコ手順を示せば誰かが答えてくれるよ
環境が変わったらまた訊きに来ればいい
オレはアク禁巻き添えでもう、レスできないだろうけど
（今回はラウンジクラシック経由）
>>807
ヒストグラム見て画像を見ながら色補正するなら、BT601で出力するのが安全。
元が色については完全で補正がまったく必要なければ、ストレート使え。
（ただし編集ソフトの画面で見た目にはダメダメになるからね）
でもAvisynthでYUVで全て取り扱うのが良いだろうな
ヒストグラム見て画像を見ながら色補正するなら、BT601で出力するのが安全。
元が色については完全で補正がまったく必要なければ、ストレート使え。
（ただし編集ソフトの画面で見た目にはダメダメになるからね）
でもAvisynthでYUVで全て取り扱うのが良いだろうな
>>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伸張しないからなのかもわかりません。
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伸張しないからなのかもわかりません。
というか、このページ、
ttp://www.marumo.ne.jp/bt601/
>PC 上では YC 伸張・圧縮を行う方法が正しいものです。
なんて書いてありますが、このスレのどこかには「PCかテレビかは関係ない」みたいなことが書いてあります。
もうどっちを信じたらいいのか…。
ttp://www.marumo.ne.jp/bt601/
>PC 上では YC 伸張・圧縮を行う方法が正しいものです。
なんて書いてありますが、このスレのどこかには「PCかテレビかは関係ない」みたいなことが書いてあります。
もうどっちを信じたらいいのか…。
>>813
> 気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。
それなら・・・
> カラースペース＝YUV と RGB→YUV＝PCスケール
> カラースペース＝YUV と RGB→YUV＝TVスケール
の２つは関係ない。
> 気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。
それなら・・・
> カラースペース＝YUV と RGB→YUV＝PCスケール
> カラースペース＝YUV と RGB→YUV＝TVスケール
の２つは関係ない。
＞的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。
このケースはすでに例が出てるんじゃないの？
このケースはすでに例が出てるんじゃないの？
ビデオチップがBT.601から伸張するものなら
データをBT.601準拠で作れば
「PC 上では YC 伸張・圧縮を行う方法が正しい」と
「PCかテレビかは関係ない」は両立する！
鑑賞用にPC用とテレビ用にスケールを違えてデータを作るのはｹﾞﾌｫ厨のやるこった。
データをBT.601準拠で作れば
「PC 上では YC 伸張・圧縮を行う方法が正しい」と
「PCかテレビかは関係ない」は両立する！
鑑賞用にPC用とテレビ用にスケールを違えてデータを作るのはｹﾞﾌｫ厨のやるこった。
難しく考えすぎ。
色はRGBで0～255の値で表される。
0～255を目いっぱい使って表現された画像を、さらに伸張したら-30～280とかになって
0～255を超えた部分が0とか255とかに変化してしまう。
これにさえ気をつけていれば問題はまあ起きないわけ。
（RGBストレート変換ってのは、0～255じゃなくて、基本は16～235の範囲でしか色を使いませんよって人向け）
色はRGBで0～255の値で表される。
0～255を目いっぱい使って表現された画像を、さらに伸張したら-30～280とかになって
0～255を超えた部分が0とか255とかに変化してしまう。
これにさえ気をつけていれば問題はまあ起きないわけ。
（RGBストレート変換ってのは、0～255じゃなくて、基本は16～235の範囲でしか色を使いませんよって人向け）
>>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,は伸張変換
どっちを使ってもｿｰｽの色空間はある程度保持される
（ｴﾝｺｰﾄﾞするかぎり完全に色空間を保持することはできない）
どっちも正しい
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,は伸張変換
どっちを使ってもｿｰｽの色空間はある程度保持される
（ｴﾝｺｰﾄﾞするかぎり完全に色空間を保持することはできない）
どっちも正しい
ｽﾏｿ
1,伸張変換 2,はｽﾄﾚｰﾄ変換
1,伸張変換 2,はｽﾄﾚｰﾄ変換
伸張変換よりストレート変換の方が誤差が小さいというのは本当でしょうか？
あら、821の名前欄は間違いです。820さんごめんなさい。
うーん…。
DVDレコ(16-235)→伸張変換(0-255)→CCIR601ではなく…に無ﾁｪｯｸ(16-235)
ということでしょうか？
最終的に(16-235)になるようにして、再生時に(0-255)に伸張されるような状態でいいんですか？
DVDレコーダーでの再生は勝手に(0-255)に伸張されるんですよね？
質問ばかりですいませんが。
DVDレコ(16-235)→伸張変換(0-255)→CCIR601ではなく…に無ﾁｪｯｸ(16-235)
ということでしょうか？
最終的に(16-235)になるようにして、再生時に(0-255)に伸張されるような状態でいいんですか？
DVDレコーダーでの再生は勝手に(0-255)に伸張されるんですよね？
質問ばかりですいませんが。
それと、VideoStudio4.0でエンコした場合、AVI→AVIとAVI→MPEGでは違う明るさでエンコードされてしまいます。
何故なんでしょう？
(AVI→MPEGだと元より明るくなってしまう)
何故なんでしょう？
(AVI→MPEGだと元より明るくなってしまう)
>>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にしたときにどっちが・・・ってことだが
繰り返すなら兎も角一回くらいならたいしてかわらない
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にしたときにどっちが・・・ってことだが
繰り返すなら兎も角一回くらいならたいしてかわらない
>>825
なるほど。
とりあえず、
>1,DVDﾚｺ(YUV記録)->DVD2AVI(PCｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無ﾁｪｯｸ)
>2,DVDﾚｺ(YUV記録)->DVD2AVI(TVｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にﾁｪｯｸ)
この組み合わせさえ間違えなければOKですね。
ありがとうございました。
なるほど。
とりあえず、
>1,DVDﾚｺ(YUV記録)->DVD2AVI(PCｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無ﾁｪｯｸ)
>2,DVDﾚｺ(YUV記録)->DVD2AVI(TVｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にﾁｪｯｸ)
この組み合わせさえ間違えなければOKですね。
ありがとうございました。
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
828 ：slave：03/08/17 00:23
ついにﾉﾝｻﾁｭﾚｰﾄAviutl完成
HuffyuvSよ安らかに・・・
HuffyuvSよ安らかに・・・
YUY2への変換時にYを16～235、UVを16～240の範囲に飽和させるかの設定を追加。
830 ：名無しさん＠編集中：03/08/17 01:59
このスレがKENクンの意地をやわらげたんじゃないの？
あきらかにおかしいものはおかしいから
あきらかにおかしいものはおかしいから
あの・・・それよりどうすればｻﾁｭﾚｰﾄできるんでしょう？
できないんですけど
できないんですけど
>>832
したいのかよ(w
したいのかよ(w
217 名前：Socket774 ：03/08/17 15:45 ID:qrmB2F9/
nVidiaのビデオオーバーレイって、デフォルト画質が変ですよ（当方、FX5600 , 45.23 , AnalogRGB）
少なくとも、ドライバデフォルトでコントラスト９０％、彩度１１４％になっている時点でおかしい。
また、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として表示しているので、少し暗め。
nVidiaのビデオオーバーレイって、デフォルト画質が変ですよ（当方、FX5600 , 45.23 , AnalogRGB）
少なくとも、ドライバデフォルトでコントラスト９０％、彩度１１４％になっている時点でおかしい。
また、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%というのはわかりやすい値を選んだので、極める方は微調整よろしく。
私信御免
420いるぅ～？
書いといたよ。欠点スレおいで～
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側の問題のようです。
お騒がせしてたいへん申し訳ありませんでした。
>>448
>>451
>>456
Re: Ver.99バグレポート 流れ者 - 2003/08/19(Tue) 22:04 No.4252
上記検証で使用したcodecはHuffyuvではなくHuffyuvSでした。
Huffyuvでやり直したところ問題ありませんでした。
どうやらHuffyuvS側の問題のようです。
お騒がせしてたいへん申し訳ありませんでした。
HuffyuvSが残していったもの、それは（ry
卵スレはネトラン者だらけだから信用できんな
>>841
卯スレだよ
卯スレだよ
烏
途中まで読んだけど何がなんだかさっぱり稚内ヨ！
とりえあずエンコした動画をaviutlで読み込んでヒストグラムを表示したら
両端がカットされてなかったので下手に弄るのはやめときます・・・。
【コーデック】huffyuvS Conbert to YUY2
他の設定はデフォルト（Enable full size output-bufferのみonになっているます）
【エンコーダ】Aviutl 0.99
設定はデフォルト
「YUY2変換時に････飽和」off
「YUY2フィルタモード」off
（脱兎
とりえあずエンコした動画をaviutlで読み込んでヒストグラムを表示したら
両端がカットされてなかったので下手に弄るのはやめときます・・・。
【コーデック】huffyuvS Conbert to YUY2
他の設定はデフォルト（Enable full size output-bufferのみonになっているます）
【エンコーダ】Aviutl 0.99
設定はデフォルト
「YUY2変換時に････飽和」off
「YUY2フィルタモード」off
（脱兎
slave=流れ者≠vmakerだろ
847 ：名無しさん＠編集中：03/08/21 05:40
Aviutlスレからきました。
向こうで「YUV->RGB->YUVストレート変換は諧調がシュリンクされる」
って力説するヤシがいるんだけど、ホント？
RGB->YUVならわかるけど
YUV->RGB->YUVなら元のYUVがYUV色空間に収まるデータしか持たないんだから
シュリンクされない、と思うんだけど？
向こうで「YUV->RGB->YUVストレート変換は諧調がシュリンクされる」
って力説するヤシがいるんだけど、ホント？
RGB->YUVならわかるけど
YUV->RGB->YUVなら元のYUVがYUV色空間に収まるデータしか持たないんだから
シュリンクされない、と思うんだけど？
スレ違いだがAviUtl99は、もう大丈夫なんでつか？
大丈夫でつぅ
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伸張
>2003.7.16/ Ver. 2.520
>MPEGデコーダに 「CRI Sofdec」(TM)を搭載しました。こちらの機能により標準状態でのMPEG-2ファイルの入力が可能になります。
>搭載されたデコーダーでは、パソコン上でTVでの見た目に近い明るさ・色で表示しますので編集作業が容易になります。
>※CRI Sofdec Decoder 利用時は「設定」→「量子化行列」→「YUVデータを CCIR601 ではなく、Basic YCbCr で出力する」のチェックは外してください。
TMPGEnc内蔵のデコーダーは強制YC伸張
TMPGEnc終わったな…
っていうか、YUV入力できない時点で終っているでしょ。
>>846
御意に。それでやってみます。
御意に。それでやってみます。
PremireがYUV処理をProで実装
Aviutlはついにサチュレートしなくなった
ネイティブYUY2であるCCE,Avisynthは当然問題なし
Dub系にはFastcompressがある
ホントTMPGEncとVFAPIがなぁ
どっちも堀やんけ
なんとかシル！！
Aviutlはついにサチュレートしなくなった
ネイティブYUY2であるCCE,Avisynthは当然問題なし
Dub系にはFastcompressがある
ホントTMPGEncとVFAPIがなぁ
どっちも堀やんけ
なんとかシル！！
TMPGの3が開発中なんじゃなかったっけ？
きっとYUVに対応するでしょ
きっとYUVに対応するでしょ
堀だからわからんよ
TMPGEncServerもなかったことになってるしね
処理速度とYUV
せめてどっちかは対応して欲しいとこだが
最近のカノプ的な面白機能を目玉にしてくる可能性も
せめてどっちかは対応して欲しいとこだが
最近のカノプ的な面白機能を目玉にしてくる可能性も
>>858
多段パスがほしい・・・
多段パスがほしい・・・
名前：名無しさん＠編集中[sage] 投稿日：03/08/22 21:38
>>540
YC伸張スレ
キャプチャーボード上のチップはネイティブYUV処理のものが多い。
WindowsのCodecはサイズ圧縮を旨とするためYUV系が多い。
ところが動画処理系のフリーウェアにはRGB入出力系しか持たないものも多い。
そのためYUV->RGB->YUVが必要になるが
その際↑にあるように”ストレート変換”と”伸張変換”の二つの変換公式があり
RGB入力を持つアプリはどちらの変換公式を用いたRGBかを指定するオプションがあるのが普通。
ただし、そのアプリによって表現形式が異なるため初心者は非常に混乱しやすい。
それを説明したり情報交換しあったりするスレ。
の筈だが現在はストレート派と伸張派の戦場。
>>540
YC伸張スレ
キャプチャーボード上のチップはネイティブYUV処理のものが多い。
WindowsのCodecはサイズ圧縮を旨とするためYUV系が多い。
ところが動画処理系のフリーウェアにはRGB入出力系しか持たないものも多い。
そのためYUV->RGB->YUVが必要になるが
その際↑にあるように”ストレート変換”と”伸張変換”の二つの変換公式があり
RGB入力を持つアプリはどちらの変換公式を用いたRGBかを指定するオプションがあるのが普通。
ただし、そのアプリによって表現形式が異なるため初心者は非常に混乱しやすい。
それを説明したり情報交換しあったりするスレ。
の筈だが現在はストレート派と伸張派の戦場。
戦場らしいから戦うか
BSDiLinkキャプしてM2v.aui(BT.709)にしてAviutlに読み込みノンサチュレートでHuffyuvYUY2
それをVirtualDubModで.avs colorYUY2(true)
有効領域外のデータあるじゃん
MPEGエンコードでレンジオーバーするのか？
レンジが狭まるならわかるが・・・
コンポーネントマスターに有効領域外データはないってホントかよ
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でもオーバーレイ有り／無しで色合いや明るさが同じになるので
合っているとは思うのですが
詳しい人の意見も伺いたいです
自作板のnVidiaスレでがんがってる人がいるんですが、
考え方は合っているのでしょうか？
上記サイトの推奨設定だと
BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
合っているとは思うのですが
詳しい人の意見も伺いたいです
Aviutl v0.99+CCE Basicを使って、DVD-VIDEOを作る場合、
キャプチャ(YUY2) huffyuv+cce patch(YUY2) ->
->Aviutlで、YUY2読み込み,出力にチェック、飽和をオフ -> 編集 ->
->huffyuv+cce patch(YUY2圧縮)
->CCE (YUY2読み込みを試みる)
でいいですか？ Aviutlとhuffyuvの関係が複雑化してきて、さっぱりですよ・・
キャプチャ(YUY2) huffyuv+cce patch(YUY2) ->
->Aviutlで、YUY2読み込み,出力にチェック、飽和をオフ -> 編集 ->
->huffyuv+cce patch(YUY2圧縮)
->CCE (YUY2読み込みを試みる)
でいいですか？ Aviutlとhuffyuvの関係が複雑化してきて、さっぱりですよ・・
>>863
MSの想定するYUVオーバーレイを基準にすればそれであってる。
ただし単純に
>BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
>合っている
とはならない
非圧縮YUVで比較しないとCODEC、再生アプリ側の色彩調整の影響があるからね。
MSの想定するYUVオーバーレイを基準にすればそれであってる。
ただし単純に
>BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
>合っている
とはならない
非圧縮YUVで比較しないとCODEC、再生アプリ側の色彩調整の影響があるからね。
>>864
ソース色空間および適用範囲を保持したいなら正解
ソース色空間および適用範囲を保持したいなら正解
>>861
撮影した素材そのまま持ってきたとしても、
カメラの輪郭補正とか、例えばDVの圧縮ノイズ、
ついでに編集かましたときにカラコレしたりで、
範囲外に出ることは多々ある。
あからさまに潜ってたり飛ぶようなことは無いけど。
撮影した素材そのまま持ってきたとしても、
カメラの輪郭補正とか、例えばDVの圧縮ノイズ、
ついでに編集かましたときにカラコレしたりで、
範囲外に出ることは多々ある。
あからさまに潜ってたり飛ぶようなことは無いけど。
YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
各ビデオボードごとに表示が違ってくる。
各ビデオボードごとに表示が違ってくる。
オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
ソフトウェアでYUV→RGB変換することになる。
ソフトウェアでYUV→RGB変換することになる。
>YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
>各ビデオボードごとに表示が違ってくる。
が
>オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
>ソフトウェアでYUV→RGB変換することになる。
なので
MSが期待するYUV>RGB変換は伸張変換
このスレは独自用語で議論が進みがちなのでわかりにくいが
>MSの想定（DirectDrowでYUV オーバレイ） = ITU-R BT.601
ではない。BT.601はストレート変換。伸張変換はMS・IBM・Appleの想定する変換。
なお、ハードウェアオーバーレイ=GDIに完全に一致するのはまずない。
”ちかくなる”だけ
理由は>>869
>各ビデオボードごとに表示が違ってくる。
が
>オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
>ソフトウェアでYUV→RGB変換することになる。
なので
MSが期待するYUV>RGB変換は伸張変換
このスレは独自用語で議論が進みがちなのでわかりにくいが
>MSの想定（DirectDrowでYUV オーバレイ） = ITU-R BT.601
ではない。BT.601はストレート変換。伸張変換はMS・IBM・Appleの想定する変換。
なお、ハードウェアオーバーレイ=GDIに完全に一致するのはまずない。
”ちかくなる”だけ
理由は>>869
また,”伸張変換はMS・IBM・Appleの想定する変換。 ”
なのでアメリカの規格にのっとっている。
NTSC-JにのっとればYUV-RGBへの伸張は
(16-235)->(0-255)ではなく
(16-254)->(0-254)になる
235以上が有効範囲外になるのはアメリカの話であって、
日本では254まで有効範囲。
なのでアメリカの規格にのっとっている。
NTSC-JにのっとればYUV-RGBへの伸張は
(16-235)->(0-255)ではなく
(16-254)->(0-254)になる
235以上が有効範囲外になるのはアメリカの話であって、
日本では254まで有効範囲。
訂正
(16-254)->(0-254)になる
↓
(16-254)->(1-254)になる
(16-254)->(0-254)になる
↓
(16-254)->(1-254)になる
じゃあ、これはウソですか？
IRE Setup +7.5
【あいあーるいー・せっとあっぷ・ぷらす・ななてんご】
輝度信号の黒レベルにセットアップレベル+7.5が付加されていること。
アメリカのNTSC機器では、黒レベルが0IREではなく、7.5IREに設定されている。
日本では輝度レベルを拡張する意味で、黒レベルは0IREになっている。
白レベルの基準はどちらも100IREのため、日本のNTSCのほうが輝度の範囲が広い(日本＝0～100、アメリカ＝7.5～100)。
アメリカのビデオテープを日本の機器で再生させると、全体的に黒が浮いて見える（白っぽくみえる）のはこの違いによる。
この違いを区別する為、ハイエンド向けキャプチャカードや編集ソフトには同じNTSCでも”NTSC（US)”と
”NTSC-JAPAN（又はNHK）”といった別々の表記がある。
IRE Setup +7.5
【あいあーるいー・せっとあっぷ・ぷらす・ななてんご】
輝度信号の黒レベルにセットアップレベル+7.5が付加されていること。
アメリカのNTSC機器では、黒レベルが0IREではなく、7.5IREに設定されている。
日本では輝度レベルを拡張する意味で、黒レベルは0IREになっている。
白レベルの基準はどちらも100IREのため、日本のNTSCのほうが輝度の範囲が広い(日本＝0～100、アメリカ＝7.5～100)。
アメリカのビデオテープを日本の機器で再生させると、全体的に黒が浮いて見える（白っぽくみえる）のはこの違いによる。
この違いを区別する為、ハイエンド向けキャプチャカードや編集ソフトには同じNTSCでも”NTSC（US)”と
”NTSC-JAPAN（又はNHK）”といった別々の表記がある。
878 ：名無しさん＠編集中：03/08/25 08:01
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という伸長も必要なんじゃない？
それぞれのスケーリングに正式な名称をつけて、
どんな変換なのかが一発で分かるようにしてホスイ。
アナログ輝度（IRE） 米DTV規格 日本DTV規格 米PC規格 日本PC規格
0 33 16 0 0
100 235 235 255 235？
109 × 254 × 255？
ということでしょ。日本のPC事情をどうするかが問題だな。
それとハリウッド映画を日本のDVDで見る場合、
33,235→16,254という伸長も必要なんじゃない？
それぞれのスケーリングに正式な名称をつけて、
どんな変換なのかが一発で分かるようにしてホスイ。
+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でも良いけど)はどのくらい伸張するの？
ちなみにデータハンドリングには関係ないけど、下は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ってのはあるけど。
何の話だろ・・・・？
ん？？何番が対象の発言？
＋120というのはアナログの場合かコンポジットの場合でしょ。
民生用のアナログカメラは、120IREとか平気で出すインチキっぽいのがあって、
顰蹙かってたなぁ。
コンポジットの場合は色振幅の最高は理論上～160IREくらい、日本の映像～133IRE、
米or古い機器など～120IREってのはあるけど。
何の話だろ・・・・？
＞また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
＞UV(IQでも良いけど)はどのくらい伸張するの？
この部分には俺も興味あるな？
計算式はどうなるの？
＞UV(IQでも良いけど)はどのくらい伸張するの？
この部分には俺も興味あるな？
計算式はどうなるの？
>>882
デジタルメディア上での計算式なんてないんでは？
ヘタに計算式作っても誤差がでるだけでしょ
どうせYUVはRGBの色空間と1:1じゃないんだから
YUV>RGBはストレートにして
YUVにせよRGBにせよ15以下はサチュレート（16で飽和）
再生環境のキャリブレートは
YUV16が漆黒
YUV255が純白
でいいんでは？
デジタルメディア上での計算式なんてないんでは？
ヘタに計算式作っても誤差がでるだけでしょ
どうせYUVはRGBの色空間と1:1じゃないんだから
YUV>RGBはストレートにして
YUVにせよRGBにせよ15以下はサチュレート（16で飽和）
再生環境のキャリブレートは
YUV16が漆黒
YUV255が純白
でいいんでは？
また難しい方向へいってしまうんですね。
16-245 -> 0-255はおかしい。16-235 -> 0-235 にせよとプロの方は言っていますが？
16-235->0-255を16-235->0-245だね。
でもプロの扱うどのソフトならそんな妙な変換を備えたものがあるんだろうか？
でもプロの扱うどのソフトならそんな妙な変換を備えたものがあるんだろうか？
>>872
返事が遅れましたがthx
話しは変わるのですが、
DOS/V magazine 03/18/15
にオーバーレイ画質とテレビ出力機能について特集が組まれており
*SMPTEカラーバー RGB(0,0,0)～RGB(255,255,255)をオーバーレイ表示して測定器で計測
というのがありました。
同じnVidia製品でも（ドライバのオーバーレイ設定が同じだとして）
NTSCエンコーダによってテレビ出力のセットアップレベルが全く違うようなので
ＴＶ出力を厳密に「NTSC-J」に合わせるのは難しそう（というか不可能）だと感じました。
返事が遅れましたがthx
話しは変わるのですが、
DOS/V magazine 03/18/15
にオーバーレイ画質とテレビ出力機能について特集が組まれており
*SMPTEカラーバー RGB(0,0,0)～RGB(255,255,255)をオーバーレイ表示して測定器で計測
というのがありました。
同じnVidia製品でも（ドライバのオーバーレイ設定が同じだとして）
NTSCエンコーダによってテレビ出力のセットアップレベルが全く違うようなので
ＴＶ出力を厳密に「NTSC-J」に合わせるのは難しそう（というか不可能）だと感じました。
>>886
プロはストレート変換しか使わないよ。
プロはストレート変換しか使わないよ。
>>887
民生テレビ自体を完全キャリブレートすることすら困難だよ。
民生テレビ自体を完全キャリブレートすることすら困難だよ。
>>888
＞878 ：名無しさん＠編集中 ：03/08/25 08:01
＞http://pc.2ch.net/test/read.cgi/avi/993130983/555n
これプロの意見じゃないの？
＞878 ：名無しさん＠編集中 ：03/08/25 08:01
＞http://pc.2ch.net/test/read.cgi/avi/993130983/555n
これプロの意見じゃないの？
>>879
米 DTV 規格が違う
IRE 米 DTV 規格
7.5 16
100 235
109 242
NTSC エンコーダーが、NTSC (US) か NTSC-J かの設定で IRE
レベル差を吸収するのが普通
もっとも、規格を読んだだけでの書き込みで、実際に US 向け
業務用機器を触ったり、作ったりしたわけじゃないけど
米 DTV 規格が違う
IRE 米 DTV 規格
7.5 16
100 235
109 242
NTSC エンコーダーが、NTSC (US) か NTSC-J かの設定で IRE
レベル差を吸収するのが普通
もっとも、規格を読んだだけでの書き込みで、実際に US 向け
業務用機器を触ったり、作ったりしたわけじゃないけど
>>893
109IREが242に対応するってところが分からん。
7.5IRE→16、100IRE→235の割りでいくと、
109IREは259とかに対応になるんだけど、
235を超えると線形性は崩れるの？
109IREが242に対応するってところが分からん。
7.5IRE→16、100IRE→235の割りでいくと、
109IREは259とかに対応になるんだけど、
235を超えると線形性は崩れるの？
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
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
NTSCビデオ信号タイミング規格(RS-170A)概要
http://elm-chan.org/docs/rs170a/spec_j.html
Final Cut Proでは、スーパーホワイトって名前で、109IREまで取り扱う。
http://elm-chan.org/docs/rs170a/spec_j.html
Final Cut Proでは、スーパーホワイトって名前で、109IREまで取り扱う。
●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秒ロー。
カラー・バー ― 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秒ロー。
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とか書いてる奴もあった。
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とか書いてる奴もあった。
>>892
再生環境のキャリブレートと中間処理のYUV>RGBは分けて考えるべき
大体、伸張変換公式だって本来は再生用（ただしアメリカ基準）
中間処理はストレートに決まってる(BT.601)
リンク先の”プロ”はプロ過ぎて”NTSC-J対応伸張公式”を実装したアプリがないことを
知らないんでしょ
再生環境のキャリブレートと中間処理のYUV>RGBは分けて考えるべき
大体、伸張変換公式だって本来は再生用（ただしアメリカ基準）
中間処理はストレートに決まってる(BT.601)
リンク先の”プロ”はプロ過ぎて”NTSC-J対応伸張公式”を実装したアプリがないことを
知らないんでしょ
901 ：名無しさん＠編集中：03/08/26 09:08
>>899
ピナクルのシステムは16-254のDV映像を、16-235で変換するよ。
これは235以上をクリップすると言うことではなく、
全体を圧縮する方式。したがって235の白は218になる。
ストレート変換だけじゃないよ。
でもって895～898はなに？新手の荒らし？
ピナクルのシステムは16-254のDV映像を、16-235で変換するよ。
これは235以上をクリップすると言うことではなく、
全体を圧縮する方式。したがって235の白は218になる。
ストレート変換だけじゃないよ。
でもって895～898はなに？新手の荒らし？
>>901
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
プロの書き込みにはイチイチ頷かされるんだが
実際問題我々下賎なキャプ厨には役にたたない
実際問題我々下賎なキャプ厨には役にたたない
>>901
それって複数回通すとどんどん暗くなっていくような気がするけど大丈夫なの？
それって複数回通すとどんどん暗くなっていくような気がするけど大丈夫なの？
最初の１回のみ縮退。でもその後はストレート変換で処理。
だからどんどん～ってことはないよ。
ストレート変換を基本にしながらも、
初回のレンダリング時は
メーカー独自の領域に丸めてしまうものが多いね。
でさぁ、902ってなに？なんか失礼なやつだなぁ！
だからどんどん～ってことはないよ。
ストレート変換を基本にしながらも、
初回のレンダリング時は
メーカー独自の領域に丸めてしまうものが多いね。
でさぁ、902ってなに？なんか失礼なやつだなぁ！
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
なんかシッタカが闊歩しておるな。
>>901=>>906
＞でもって895～898はなに？新手の荒らし？
これは>>894の「235を超えると線形性は崩れるの？」に対するレスだろ？
俺にとっては、895-898は非常に有益な情報だったよ。
もしこれが間違ってる／的外れってんなら、プロならプロらしくきちんと説明しろよ。
俺には、荒らし扱いする理由が全く見えないので、（895-898が全く意味無いと判断した）その理由が
非常に気に掛かる。
895-898への訂正意見とか反論とか、知識の出し惜しみせずに本当頼むよ。
（まさかレスする価値も無いスパムだとは言わないよね？）
＞でもって895～898はなに？新手の荒らし？
これは>>894の「235を超えると線形性は崩れるの？」に対するレスだろ？
俺にとっては、895-898は非常に有益な情報だったよ。
もしこれが間違ってる／的外れってんなら、プロならプロらしくきちんと説明しろよ。
俺には、荒らし扱いする理由が全く見えないので、（895-898が全く意味無いと判断した）その理由が
非常に気に掛かる。
895-898への訂正意見とか反論とか、知識の出し惜しみせずに本当頼むよ。
（まさかレスする価値も無いスパムだとは言わないよね？）
ノウホワイは後回しにしてノウハウの伝授をーーーーーっ！
911 ：名無しさん＠編集中：03/08/27 14:32
912 ：名無しさん＠編集中：03/08/27 14:39
>>907
１行でやめときゃいいのに
１行でやめときゃいいのに
914 ：名無しさん＠編集中：03/08/27 14:55
おれにはチンプンカンプンだよ、って？
ごめんね、難しすぎて。
ごめんね、難しすぎて。
915 ：名無しさん＠編集中：03/08/27 15:05
917 ：名無しさん＠編集中：03/08/27 15:29
┐(´～｀)┌ な病気が流行ってます。気をつけましょう！！
920 ：名無しさん＠編集中：03/08/27 16:57
でさ、ここの住人の人、↑こういうヴァカ放置しとくわけ？
結構キチガイだね。それとも外人さんかな？（藁
結構キチガイだね。それとも外人さんかな？（藁
煽りは無視しろよ。それで良い事だろ。
俺もだんだん、
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
と思えてきたよ。
＞911 ：名無しさん＠編集中 ：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・
少なくとも、>>909はまじめな質問だろが、答える義務があると思わんのか？
俺もだんだん、
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
と思えてきたよ。
＞911 ：名無しさん＠編集中 ：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・
少なくとも、>>909はまじめな質問だろが、答える義務があると思わんのか？
むー 901 でも 906 でも無いんだが、あんまりなので。
>895-898 が非常に有益な情報だったと豪語する 909 にとって
>「235を超えると線形性は崩れるの？」に対する
自分なりに考えてみた結論はどっちなんだろう。有益だったのだから
結論が出せたはずだろうと思ってるのだけど。
私にとって 895-898 は「IRE100 を超える信号が放送局のマスターの
段階で存在する」という情報と、レベルとは殆ど関係の無い NTSC の
同期タイミングに対する情報が書かれてるだけにしか見えないんだ。
で、IRE100 を超える情報が放送局のマスターレベルで存在するって
のは既出だし、それを否定してる人はそんなに居ないように思えるわ
けね。
・既出の情報
・無関係な情報
を延々書き連ねてるようにしか見えないんで、895-898 はスパム扱い
されても仕方が無いんじゃないかな。
あと、-20 ～ 120 IRE ってのは色信号を重畳した後の、NTSC 信号で
の許容範囲であって、輝度のみで 120 まで使い切るのが正しいこと
だとか誤解しない方が良い。
>895-898 が非常に有益な情報だったと豪語する 909 にとって
>「235を超えると線形性は崩れるの？」に対する
自分なりに考えてみた結論はどっちなんだろう。有益だったのだから
結論が出せたはずだろうと思ってるのだけど。
私にとって 895-898 は「IRE100 を超える信号が放送局のマスターの
段階で存在する」という情報と、レベルとは殆ど関係の無い NTSC の
同期タイミングに対する情報が書かれてるだけにしか見えないんだ。
で、IRE100 を超える情報が放送局のマスターレベルで存在するって
のは既出だし、それを否定してる人はそんなに居ないように思えるわ
けね。
・既出の情報
・無関係な情報
を延々書き連ねてるようにしか見えないんで、895-898 はスパム扱い
されても仕方が無いんじゃないかな。
あと、-20 ～ 120 IRE ってのは色信号を重畳した後の、NTSC 信号で
の許容範囲であって、輝度のみで 120 まで使い切るのが正しいこと
だとか誤解しない方が良い。
>IRE100 を超える情報が放送局のマスターレベルで存在するって
>のは既出
え？そう？？
ガイシュツはMPEG2-TSしかないんでは？
>のは既出
え？そう？？
ガイシュツはMPEG2-TSしかないんでは？
自分にとって既出だったら価値が無いってわけか。プロって観点がやっぱ違うな。
それでスパム扱いするわけ？
それでスパム扱いするわけ？
895-898も、もうちょっとまとめて書けば荒らし扱いされなかっただけの話だ。
以上。
以上。
>>897だって、俺には各色が何Vp-p(IRE)なのか判ってうれしい情報だったが？
素人が調べた情報を貶すより、玄人からきちんと情報だすのがプロの態度だと思う。
もうスパムだどうだって話はいいから、実際の話をだしてくれよ。
例えば、局に納品するものは、レベルをどの範囲で作っているのかとか。
（109IREとか出してるけど、こんなレベル許されないだろ？）
もうスパムだどうだって話はいいから、実際の話をだしてくれよ。
例えば、局に納品するものは、レベルをどの範囲で作っているのかとか。
（109IREとか出してるけど、こんなレベル許されないだろ？）
あと、カメラ撮りから編集時のレベル調整じゃなくて、
（歪み補正とか色々あるだろうから、ガンマやニーポイント、ショルダーポイントで複雑に補正するんだろうけど）
俺たち、キャプチャユーザーにとっては、補正後の完成された画像を取り扱うわけよ。
その場合、俺たちはなるべくレベルはオリジナルに近づけたいと思ってるわけ。
そういう観点からも、レクチャしてくれよ。
（歪み補正とか色々あるだろうから、ガンマやニーポイント、ショルダーポイントで複雑に補正するんだろうけど）
俺たち、キャプチャユーザーにとっては、補正後の完成された画像を取り扱うわけよ。
その場合、俺たちはなるべくレベルはオリジナルに近づけたいと思ってるわけ。
そういう観点からも、レクチャしてくれよ。
＞911 ：名無しさん＠編集中 ：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・
俺が909を書いたけど、897や907は書いてない。いったい何処の部分で一緒にされたんだ？
俺の書き方が言語障害だってのはどの部分？
あなたがまともなプロの方だったら、内容はともかく、言語障害と断定したことに
納得できる説明または謝罪を要求する。
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・
俺が909を書いたけど、897や907は書いてない。いったい何処の部分で一緒にされたんだ？
俺の書き方が言語障害だってのはどの部分？
あなたがまともなプロの方だったら、内容はともかく、言語障害と断定したことに
納得できる説明または謝罪を要求する。
だめだろう、あのプロは。
つーか私はプロじゃないのだがなぁ（少なくとも編集側の人間じゃない）
聞いた話レベルのことしかいえないけど、それでもいいわけ？
許容される輝度レベル：
・16 以下は絶対不可
・235-254 まではどこまで使っても OK
実際の輝度レベル：
・使ってる機材と使う人でピンキリ
というわけで、明確な基準はない。
あと、プロに過大な幻想を抱くのはどうかと思うぞ。ほんの１年前まで
当たり前のようにコンポジットマスターで DVD を作ってて、今なお HD
を D2 アプコンで放送してるような連中なんだから。
聞いた話レベルのことしかいえないけど、それでもいいわけ？
許容される輝度レベル：
・16 以下は絶対不可
・235-254 まではどこまで使っても OK
実際の輝度レベル：
・使ってる機材と使う人でピンキリ
というわけで、明確な基準はない。
あと、プロに過大な幻想を抱くのはどうかと思うぞ。ほんの１年前まで
当たり前のようにコンポジットマスターで DVD を作ってて、今なお HD
を D2 アプコンで放送してるような連中なんだから。
そういや、プロと自称しているヤシが NTSC-J (0IRE) と NTSC (7.5IRE) の違いが
デジタル段階でも現れると思いこんでいたりするのにはちと驚愕するね。
デジタル段階でも現れると思いこんでいたりするのにはちと驚愕するね。
自分が舌足らずなのに相手の読解力のせいにするスレはここですか？
お前ら、そろそろ次ｽﾚのﾃﾝﾌﾟﾚとFAQを、まとめれ。
アプリごとの特性
codecごとの特性
ビデオカードごとの特性
フィルターごとの特性
誰か纏めてﾃﾝﾌﾟﾗにしてくらはい
codecごとの特性
ビデオカードごとの特性
フィルターごとの特性
誰か纏めてﾃﾝﾌﾟﾗにしてくらはい
937 ：名無しさん＠編集中：03/08/28 12:13
＞納得できる説明または謝罪を要求する。
２ちゃんでそれを求めてもなぁ・・・・・・
909がマジで謝罪もとめてるとしたら、けっこうバカかも。
それとも「プロ」煽ってんのかな？
おーい、プロよー、出てこーい！
２ちゃんでそれを求めてもなぁ・・・・・・
909がマジで謝罪もとめてるとしたら、けっこうバカかも。
それとも「プロ」煽ってんのかな？
おーい、プロよー、出てこーい！
>>933
そういや、NTSC-Jだから0IRE=0なんて主張していたのもいたな。
そういや、NTSC-Jだから0IRE=0なんて主張していたのもいたな。
出て来ないからまともじゃない、って釣ってもねぇ・・・・・
なんせ２ちゃんだから・・・・
なんせ２ちゃんだから・・・・
要するにこのスレでボスを気取っていた907の前に
ある日突然プロを名乗るツワモノが現れ、
危機を感じた907が追い出そうと必死、ということでいいでつか？
ある日突然プロを名乗るツワモノが現れ、
危機を感じた907が追い出そうと必死、ということでいいでつか？
>>939
NTSC-Jでは0IRE=16で、普通のNTSCでは7.5IRE=16ってこと?
NTSC-Jでは0IRE=16で、普通のNTSCでは7.5IRE=16ってこと?
AviutlのYC伸長の始点ってどうやって選べばいいのか分からない
readmeにはデッキ等の機種によりけりって書いてあるけど
自分のがどうなのかを調べる方法が・・・
readmeにはデッキ等の機種によりけりって書いてあるけど
自分のがどうなのかを調べる方法が・・・
>>945
ヒストグラム
ヒストグラム
匿名板には自称プロが多数生息しています。
>>932
許容される輝度レベル：
・16 以下は絶対不可(局によっては3IRE以上だったりする)
・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
全体的に飛ぶと局に納品断られる。
これにクロマが絡んでくるとまた厄介なんだけど。
あと、BSデジタルは制作費があまりもらえないので、
全てのコンテンツをHDでやれないのね。
地上派デジタルになったって、
しばらくはSDのアプコン主流で行くし。
許容される輝度レベル：
・16 以下は絶対不可(局によっては3IRE以上だったりする)
・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
全体的に飛ぶと局に納品断られる。
これにクロマが絡んでくるとまた厄介なんだけど。
あと、BSデジタルは制作費があまりもらえないので、
全てのコンテンツをHDでやれないのね。
地上派デジタルになったって、
しばらくはSDのアプコン主流で行くし。
なんだ 結局キャプ厨的にはＹ（１６－２３５）を基準にすれば十分ってことじゃない。
＞・16 以下は絶対不可(局によっては3IRE以上だったりする)
＞・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね
＞・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね
>>951
そりゃ規格を知らん自称プロによる腐れオーサリングなソフトがあるってだけだ罠。
そりゃ規格を知らん自称プロによる腐れオーサリングなソフトがあるってだけだ罠。
>>952
いや、クライアントが納得して報酬を支払ってるなら立派なプロだろう。
いや、クライアントが納得して報酬を支払ってるなら立派なプロだろう。
15以下236以上の輝度レベルのピクセルこだわっていたslaveらアンチBT601派は
受信機によって歪まされた輝度レベルを「マスターに近い状態」と信じて有難がっていたわけだな。
受信機によって歪まされた輝度レベルを「マスターに近い状態」と信じて有難がっていたわけだな。
nyで落として焼いてヤフオクで捌いてるのもプロ
>>955
HEY!X3のスタジオライブはHDD収録なんだがiLinkキャプすると
範囲外とか言ってる236以上に諧調が存在する。
iLinkキャプは送信されたストリームを記録してるだけだよ。
MPEGエンコーダのせいにするのか？
MPEG圧縮でレンジが拡大するというのか？
そもそもマスターに近い状態って理解してるのか？
iLinkならまだしも民生レベルで地上波の16以下235以上をマスター同等のレンジでキャプできるのか？
おまいが16だって信じてるものがマスターの16である保障はないよ。
HEY!X3のスタジオライブはHDD収録なんだがiLinkキャプすると
範囲外とか言ってる236以上に諧調が存在する。
iLinkキャプは送信されたストリームを記録してるだけだよ。
MPEGエンコーダのせいにするのか？
MPEG圧縮でレンジが拡大するというのか？
そもそもマスターに近い状態って理解してるのか？
iLinkならまだしも民生レベルで地上波の16以下235以上をマスター同等のレンジでキャプできるのか？
おまいが16だって信じてるものがマスターの16である保障はないよ。
>>959
だよな。
iLINKキャプやDVDリップですら範囲外もへったくれもないんだから
規格そのものが現実にそってないんだよな。
それにしてもテレトのハロモニはなんとかして欲しいんだが。
範囲外とか色づけとか演出とかキャプ環境とか、
そういう問題じゃないくらい面白すぎる(泣
だよな。
iLINKキャプやDVDリップですら範囲外もへったくれもないんだから
規格そのものが現実にそってないんだよな。
それにしてもテレトのハロモニはなんとかして欲しいんだが。
範囲外とか色づけとか演出とかキャプ環境とか、
そういう問題じゃないくらい面白すぎる(泣
で、再圧縮するときは（そういう人も少なくないでしょ？）
送り出し側を尊重して面白いままにしておくの？
送り出し側を尊重して面白いままにしておくの？
タイミングが悪かった。
ハロモニじゃなくてHEYみたいなものの話。
ハロモニじゃなくてHEYみたいなものの話。
ハロモニの白飛びに悩まされてるモヲタは多い
白飛びはモヲタ対策なんだよ。
ハロモニはたまにやたらと粒子の粗い？カメラがあって
肌が無茶苦茶汚く映るので萎える
肌が無茶苦茶汚く映るので萎える
モーヲタ氏ねよ
973 ：プュロフォッショナル：03/08/29 00:34
次スレッド立てようぜ
>>946
ヒストグラムでどう判断するのか分からない・・・
ヒストグラムでどう判断するのか分からない・・・
そりゃ、きちんとカラーバー入れないと判断つかない罠。
>>951
DVDで白飛んで黒潜ってるとか言っとりますが、
マスターに入ってるカラーバーで校正した結果なら仕方ない。
そういうのは、マスター作ってきた制作会社が悪い。
漏れは客に判断仰ぐけどね。
おかしいカットだけカラコレかけられるけど、
そこはうちの責任じゃないので修正しない。
まあ、まともな作品で0IRE以下になることは無いけど。
DVDで白飛んで黒潜ってるとか言っとりますが、
マスターに入ってるカラーバーで校正した結果なら仕方ない。
そういうのは、マスター作ってきた制作会社が悪い。
漏れは客に判断仰ぐけどね。
おかしいカットだけカラコレかけられるけど、
そこはうちの責任じゃないので修正しない。
まあ、まともな作品で0IRE以下になることは無いけど。
977 ：名無しさん＠編集中：03/08/29 07:05
>>951
ちょっと待てや。
＞普通にTV番組では使われてる領域だよ
＞映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
0-15が普通にTV番組では使われてる・・・と読めるのだが、
使ってるわけねぇだろ。おまえはちゃんと波形モニで監視してるのか？
0は同期ワードで使用絶対NGだから存在しているわけないし、
1-15はカラリメトリでクリップされるから送出されるわけがない。
どこからこんないい加減な話が出てくるのか疑問。
あんたどの局？どの時点で監視してるの？
サブキャリアの話とか言うオチはなしにしてくれよ。
ちょっと待てや。
＞普通にTV番組では使われてる領域だよ
＞映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
0-15が普通にTV番組では使われてる・・・と読めるのだが、
使ってるわけねぇだろ。おまえはちゃんと波形モニで監視してるのか？
0は同期ワードで使用絶対NGだから存在しているわけないし、
1-15はカラリメトリでクリップされるから送出されるわけがない。
どこからこんないい加減な話が出てくるのか疑問。
あんたどの局？どの時点で監視してるの？
サブキャリアの話とか言うオチはなしにしてくれよ。
976や977のような話が201の後に出てこなかったことが、ちとカナスィ・・・
>>976
プロとしてなっちょらん
プロとしてなっちょらん
AviUtlサポート掲示板のYC伸張スレ
http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=res&no=4339
http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=res&no=4339
誰かいい感じのスレタイで次スレ立ててくれ
これは初心者が行き詰まったり気付かないで放置しちゃってる問題だから
誘導しやすいように最初のほうで（できればテンプレで）まとめてくれ
俺はよくわかってないから無理なんだが・・・
これは初心者が行き詰まったり気付かないで放置しちゃってる問題だから
誘導しやすいように最初のほうで（できればテンプレで）まとめてくれ
俺はよくわかってないから無理なんだが・・・
983 ：名無しさん＠編集中：03/08/29 13:56
ここで熱心に虚しい議論してる連中、
脳内空回り的発言多すぎだぞ。
とりあえずハケモニは買ってくれ。
何事も目で確認するのが一番！
脳内空回り的発言多すぎだぞ。
とりあえずハケモニは買ってくれ。
何事も目で確認するのが一番！
カラーバーとかキャプチャすると普通に0-15を使ってたりせんか？
セットアップバーの-4IREが使ってるだけ。
あ、いや全く無いみたいな話が上であったからさ
15以下が放送されることは普通にあると思うんだが違うの？
15以下が放送されることは普通にあると思うんだが違うの？
988 ：きっぱり：03/08/29 17:23
テスト信号以外、 な い 。
>>987
サブキャリとか言うオチは、なしにしてくれよ。
サブキャリとか言うオチは、なしにしてくれよ。
映像製作時にあった場合は放送時に切られるってこと？
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
992 ：名無しさん＠編集中：03/08/29 17:40
MPEG2を再生するときに、明るい部分が黒く再生されてしまうんですが、
これって伸張に間違いがあるということでしょうか？
これって伸張に間違いがあるということでしょうか？
＞明るい部分が黒く再生
それはネガポジ反転が掛かっているからです
それはネガポジ反転が掛かっているからです
>>987
お前のキャプチャボードの設定を確認しろ。
お前のキャプチャボードの設定を確認しろ。
996 ：名無しさん＠編集中：03/08/29 17:48
ないということは分かったのでできれば990に答えてもらえますか？
ただの確認なんですが
ただの確認なんですが
>>993
この板に常駐している連中って、皆、不親切だし、独り善がりだし、偉ぶってるし、ドケチだし、ひねくれてるし・・・
なんか実社会において著しく他人とのコミュニケーション能力に欠けてる社会生活不適応者の典型の集まりって感じがする
嫌われ者で笑い者で引き篭もり（若しくは、それに相当する）のヲタばっかなんだろうな、ｷﾓｯ!
この板に常駐している連中って、皆、不親切だし、独り善がりだし、偉ぶってるし、ドケチだし、ひねくれてるし・・・
なんか実社会において著しく他人とのコミュニケーション能力に欠けてる社会生活不適応者の典型の集まりって感じがする
嫌われ者で笑い者で引き篭もり（若しくは、それに相当する）のヲタばっかなんだろうな、ｷﾓｯ!
999 ：名無しさん＠編集中：03/08/29 17:51
＞馬鹿にしてますね。
うん。よくわかったね。
＞明るい部分が黒く（＝0IRE）なるだけです。
そりゃ故障だ。
うん。よくわかったね。
＞明るい部分が黒く（＝0IRE）なるだけです。
そりゃ故障だ。
1000 ：名無しさん＠編集中：03/08/29 17:52
やったあああああああああああああ！！！！！
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。