YC伸張する？しない？総合ｽﾚｯﾄﾞ

DirectX 8.1 YUV Color Space Fix

>>566
どこの情報？
つーかなんの？？

msyuv.dll

fixということはそれ以前は伸張しないか俺スケールかだったのか・・・

つまりはAviUtlでTV→PCスケール補正で最終保存するとまずいって事？

ノーチェックで保存が当たり前？

だから、ソースによるって言ってるだろ。あほんだら

>>569
DirectX8のmsyuv.dllは YUV→RGBをRGB16に変換する。
いわゆる msyuvの減色バグと言われてたやつだ。それのfix。

>>571
TV→S端子経由→玄人志向SAA-7130→MJPEG
このｿｰｽの場合は？

>>573
キャプチャする時、どの様に輝度等を調整してるか分からない。
取り込み方がRGB24かYUY2か分からない。
どのMJPEG codecを使ってるのか分からない。
AviutlのMJPEGのcodec設定がRGB24かYUY2か分からない。

自作板の自作HTPCスレでBT.601厨が火種をまいてますね。

>>575
論破されたバカ?

huffyuvで圧縮されたファイルが、yuvで記録されてるか、rgbで記録されてるか、
判別する方法無いですかね。
あとで、エンコードしようとして放置してたら、どんな設定で圧縮したか分からなく
なってしまいまして。

AviUtl(0.86d)で読み込んで[その他]->[ファイルの情報]->ビデオ展開形式
でどを?

ああそういうことあるね
でもhuffyuvならYUV→RGB時には伸張するから区別できるんじゃ？

0.86dって何だよヽ(`Д´)ﾉ　0.98dだよ

>>579
伸張するから同じ画になって区別つかないんじゃ？
伸張しなけりゃぱっと見た目で区別できるよ。

>>581
？
ストレート変換したものと見た目に違いがあるならYUVってそういう意味だったんだけど。
違わないならRGB

>>566
ttp://www.doom9.org/Soft21/SupportUtils/dx81-yuv-fix.exe
これでそ？

>>582
ストレート変換って？

Huffyuvでは、YUVとRGBで見た目に違いは無い(BT.601伸張変換されるから同じに見えて当然）
（レンジオーバーしてればサチュレートされるから違いは出るけどそれが見てわかるかどうか？）
>>578の言うようにAviUtlかAvisynthでチェックするか

>>584
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になるはず。

>>586
試してみたよ。見て分かったよ。
たぶん俺の言いたいことがちゃんと伝わってないだけ

１．動画編集ソフト（たとえばTMPGEnc）にそのままそのAVIを読み込ませてみる
２．そのAVIをConvTo.dllでストレートRGB展開するようにしたAVSを読み込ませてみる
３．１と２を見比べてみて変化があればYUV、なければRGB

>>587
あほ。
それじゃAvisynth使えって言ってるじゃんか。
Avisynth使うなら、そんなことしなくたって簡単に判別つくわい。
Dubでavs読み込んで、file information見たって良いし、
ColorYUY2でdebug=3,5で見たって、YUY2のみしか使えないフィルタを追加したって分かる。
方法なんて他にもまだまだ幾つもあるぞ。

あほって言われてもなあ
Avisynth使うなって言われてないし
一番簡単な判別の仕方を教えろとか言われてないし…
普段やってることだから全然手間じゃないんだよな俺の場合
TMPG使うから必ずストレート変換するのよ

教えてください。現在、LDからDVD-VIDEOへの変換を行っているのですが、
CANOPUS DigitalVideoRecorder+ふぬああにて、

UYVY&huffyuvS->Aviutl(YUY2展開無)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮無)->huffyuvS(ConvertYUY2)->CCEと、してるんですが、これで
あってるでしょうか。

>>590
ふぬああの設定が不明
まぁ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のやり方に変えてみました。

せっかくAVIキャプ時は手動で調整できるんだから
できるなら手動で調整したほうがいいと思うけど

>>590
このスレをくまなく見れば,そのやりかたではYUV->RGB->YUV処理が入ることがわかるはず
そしてYUV->RGB->YUVには色変換誤差が生じることも・・・
Avisynthにしなはれ

>>592
LDからの取り込みで、ノイズリダクションって必要なの？

>>595
ｱﾅﾛｸﾞなんだから当然かけてもいいでしょ

アナログだからって意味分かんね

>>597
どんなに設備・環境を整えてもｱﾅﾛｸﾞ波には必ずS/Nの問題が生じる
ﾉｲｽﾞからけっして逃げられないんだよ

デジタルならいらないのか？
ああアニメの話か

>>599
ﾃﾞｼﾞﾀﾙならば最終出力形式と好みの問題もあるが

ﾃﾞｼﾞﾀﾙｽﾄﾘｰﾑ記録の場合ｿｰｽにあるﾉｲｽﾞは送信側に既に存在するﾉｲｽﾞ
ｿｰｽ至上主義ならばﾃﾞｼﾞﾀﾙ記録はﾉｲｽﾞﾚｽということになる
つまりﾉｲｽﾞﾘﾀﾞｸｼｮﾝはいらない
最終出力時にﾃﾞｰﾀを圧縮しやすくするための画像処理はﾉｲｽﾞﾘﾀﾞｸｼｮﾝではなくﾌｨﾙﾀﾘﾝｸﾞでしょ

>>600
ｿｰｽ至上主義ならばアナログでもLDからじゃﾉｲｽﾞﾘﾀﾞｸｼｮﾝするべきじゃないと思うが

スレ違い。

>>601
LDがないならVHSﾃﾞｯｷでもいいから同じｿｰｽを何度もｷｬﾌﾟってみればわかる
ﾄﾞｯﾄ妨害の出現ﾊﾟﾀｰﾝは毎回かわる
>>602
無理やりｽﾚの趣旨に近くしようとしてみるﾃｽﾄ
LDｷｬﾌﾟﾁｬｰ（正確にはｱﾅﾛｸﾞｷｬﾌﾟﾁｬｰ全般）時に載るﾉｲｽﾞをﾘﾀﾞｸｼｮﾝする一番いい方法は
何度もｷｬﾌﾟﾁｬｰし、それぞれをﾌﾞﾚﾝﾄﾞし、逆鼠算的にﾌﾞﾚﾝﾄﾞを繰り返すこと
この、内容は同一だがﾉｲｽﾞの出現ﾊﾟﾀｰﾝの異なる動画のﾌﾞﾚﾝﾄﾞを繰り返すというﾌｨﾙﾀは
Vmakerが作ってて公開してたんだがな
当人もLD->DVD時に有効と書いてたが、
いい加減ｻﾗっとﾌｶｰﾂしねーかな
Huffyuvsはどーでもいいから<ｽﾚ違い

毎回かわるから何

馬鹿はレスしなくていいよ。

>>603
slave乙

>>606
どういたしまして

何か語り口調が見たことあると思ったら、slaveってあの師匠だったのね

>>603
2.52標準のMergeChroma / MergeLumaがその用途のためにある。

>>609
お、ｸｽｺ！

>>601
同じ意見。正直、ノイズリダクションしたら、映像が元ソースと
ちがってしまうのは嫌だ。
綺麗なソースがあるならそのままやったほうがいい。
安いＬＤプレイヤーなら仕方ないかもしれないけど。

>>611
綺麗なソースの定義は人それぞれ。
好きなようにやればよし。
画像も見ずに「LDソースだから綺麗」というのはおかしい。
それにLDプレイヤー（DVDも準ずる）は高ければソースにピュアなわけでもなく。
勿論安いLDプレイヤーがピュアなわけでもなし。
画像なしでは判断できないが、ひとついえることは、
LDプレイヤーのYC分離は総じて糞であり、
それどころかその多くはコンポジット出力しかもたない。
LDソースが綺麗なソースだとはとても思えない。
画像を見なければわからないけどね。
スレ違いなんでsage。

>>609
他の使い道

mergechroma(c,blur(c,1.3))
mergechroma(c,fluxsmooth(c,7,7))

>>612
LDプレイヤーがコンポジット出力しか持たないのが多いのはその機器の特性上別に問題でもなんでもない。
LDソースが綺麗だと思わないとは・・・・貴公はどんなソースが綺麗だと思うんだ？
あくまで、一般家庭の話ですよ。

LD って、ｺﾝﾎﾟｼﾞｯﾄ信号（Y/C混合）で記録されているって
当然知ってて書いてるんだよねぇ？ちみたちは。

>>612
ｿｰｽにﾋﾟｭｱって話するなら、ｺﾝﾎﾟｼﾞｯﾄ出力だと思うが？

LDPによってはコンポジット出力がY/C分離したあと再混合した信号を出力
していたりするけどな。

>>615
すまん、ＬＤにＳ出力があるんだとばかり思ってた。
ごめんなさい。

何かどんどんスレ違いに・・。>590に一つ助言すると、LDプレイヤーの
S-端子は確かにあんま性能が良くないことが多い。これは>612の言っている
通りだ。だから、コンポジット出力をS-VIDEOデッキの３次元Y/C分離を
通してS出力すると綺麗になる場合もある。ただしこれは、>616の言う機能を
有したLDプレイヤーの場合、効果は薄い。

>>592
Avisynth使えって言ってるだろが　ヽ(`Д´)ﾉ


LDをキャプチャーするスレ
http://pc.2ch.net/test/read.cgi/avi/1051885045/

こちらもよろしく

どうも皆さん助言を頂きありがとうございました。
えと、うちのプレイヤーですが、コンポジット出力は再混合したものが出力される
タイプなんで、Ｓ端子で繋いでいます。

で、16-235 <-> 0-255間違ってたら、あからさまなんで確認したかった訳なんですが、
0-15,236-255のためにAvisynthに乗り替えるのもめんどいんで、Aviutlでまったりと
逝きます。

本当に、Aviutlもいい加減サチュレートしないバージョンださないかなぁ
Avisynth使うの面倒くさくなってきた

つーかこのスレに来たのってAvisynth使うの面倒だからだったんだけど
今やこっちの方がメンドイな

AviUtlを貶しているけど、
AviUtlがRGBだったころ(0.97まで)、または、0.98でサチュレートしていることを
知る前までならみんな文句言わずに使ってたよな。
高画質で綺麗綺麗と言って。
サチュレートしているって聞いたとたん、AviUtl使うのは問題だよな、
っていうのはどういうものなのか。

そうですね。痛いﾊｲｴﾝﾄﾞｵｰﾃﾞｨｵに現を抜かしてるﾔｼみたいで
ｱﾌｫくさいですよね。洩れは綺麗に見えるように自分が納得した
設定にしています。それに、苦労して何時間もかけてｴﾝｺｰﾄﾞした
ﾌｧｲﾙって、HDD の肥やしにしかなってないのが現状だしね〜。

後で鑑賞するのが目的なはずなのに、いかに理論に沿って
ｿｰｽに忠実にｴﾝｺｰﾄﾞするかが目的になっちゃってる自分に
ふと気付くと、本当に無駄な時間の過ごし方してる。

エンコードそのものに試行錯誤することが快感になってることに早く気付けよ
この板にはそんな人間がいくらでもいるから安心しろって

自己満足ｵﾅﾇｨ板（;´Д`）ﾊｧﾊｧ…

>>624-625
slaveうぜえ

Aviutlの98以降がｻﾁｭﾚｰﾄするのは本家BBSでもここのAviutlｽﾚでも
98発表当時問題になってる
「TVｽｹｰﾙとPCｽｹｰﾙつけるからいいでしょ」ってな返答をKENがして
「ちげーよ、色がｸﾛｯﾌﾟされるって言ってるんだよ」って突っ込まれてたんだが
「ﾊｧ?BT.601だとこれが正規ですよ、と。おまいの環境のｷｬﾘﾌﾞﾚｰﾄがｵｶｼｲｶﾓﾅｰ」
みてーな返答でｽﾙｰされておった。
意地でも直さないだろうな・・・KEN。

>>629
slaveは恐ろしい釣り氏だな。

「そこまでAviutlをおとしめたいのか？」

と思ってAviutlスレ3から6まで読んじゃったじゃねーか。
完全に釣られました。
そんな話はでてきておりません。
途中音ずれの話題でレスが埋め尽くされてたのはワラタが,
あの頃は結構まともに機能してたんだな　＞Aviutlスレ。

似たようなので、YUY2入力するとスケール伸張されるって騒いでたな。
そしたら内部は12bit有効なので伸張されてもクロップされないってマルモがしゃしゃり出たんじゃなかったっけ？

aviutlは途中でクリップされないのがいいとこなんだがな
YCCは各12ビット表現だけど出力フレームが確定するまでは16ビットフルに有効だから
（プラグイン作者が想定してるのは13ビット以内のデータだけだろうけど）
YUY2読みしてもYゲインを下げれば範囲外の階調もちゃんと残ってることに気付くよ

avisynthの場合、データは8ビットでしか扱えないから
何かのフィルタで一度飽和させてしまうともう元に戻せないしね
まぁ速いし、YUY2読みしたものをそのままCCEに渡せるから愛用してるけど。。

>>632
飽和させるフィルターって何？
ちょっとそれは考えられないけどな。縮小されるフィルターばっかし。
もちろん、色補正関係のフィルターを除いての話。

>>632
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変換の欠点・利点は↑のほうでガヤガヤやっとるんで、
ログ参照。

radeonは規格準拠なのがはっきりしたわけだが

> ちなみに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

こういう言い方はあいまいにするための常套手段だねｗ。
つか、準拠という言葉自体が。。。

MPEG2規格のいかなる色空間もサポートするよ、と。
それはYV12,YUY2,IYU2をサポートするよ、と言ってるだけだろ。
大体このスレで誰も突っ込みが入らないのが不思議なんだが、
BT.601規格にはストレート変換も入っているのだよ。
”BT.601準拠=伸張変換”みたいなレスが多いが
それは間違い。

>>639
IYU2ってなに？

>>640
24bitYUV4:4:4
ｸﾞｸﾞﾚよ、これくらい

>>639
そんなにムキになるなよ。
ここにいる奴はまるものページぐらいは読んでるって。
BT.601とストレートで十分に通じるぞ。

ここって常駐者しかいないのに
新情報なんてﾛｸにないから
初心者がくだらないｶｷｺしないとﾚｽが進まないね
まぁその初心者も常駐はしないだろうし

>>643
slave氏ね

>>633
実際にはゴーストリダクション系くらいだろうな。
設定値によってはシャープ系でも飽和させれるけど、
そんな設定値使わないだろうし。

90さんの書いてることが真実なんだろ。悩むことないよな。

YUV形式の動画　→　RGB形式の動画　YC伸張する
RGB形式の動画　→　YUV形式の動画　YC圧縮する

で良いんだろ？

あとは使うソフトによって精度が変わるくらいで大した問題じゃないな。

>>646
残念ながら>>90に書いてあることは真実ではない
でも、二重伸張や二重圧縮に比べたら
YUV<->RGB変換誤差やサチュレートなんてたいした問題ではない

>>647
> 残念ながら>>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
DTV なんか究極の自己満足じゃねーかよ。
自分が良ければ、それでOKだろう。

650は648へのレス

>>653
了解

結局あれだろ？各動画フォーマットが

full-range RGB [0,255]
compressed-range RGB [16,235]
full-range YUV [0,255]
compressed-range YUV [16,235]

のうちどれを使ってるか把握出来てれば問題ないんだろ？あとは些細な精度の問題で。

>>655
動画フォーマットがどっちのスケールを使うかということより
動画系アプリがどういう設定のときどっちのスケールを使うか？が問題。
それによって出力された動画のスケールが決定されるから。

わけわからん

>>655
>>317が正解
ただYUV<->RGB変換誤差が些細な問題かどうかは
>>381を御覧あれ

そもそもMSがちゃんと動画フォーマットの仕様決めないからこんなことに
なるんだな。

WIN上で扱うRGBはすべてfull rangeに汁！YUVはすべてcompressed rangeに汁！
Video Cardはオーバーレイ使う時はHWでYC伸張汁！ってすれば無問題なのにな。

>>659
基本的にはそうなっているっしょ。問題はそれを無視する腐れアプリ・codec・
グラフィックカードがあるってこと。

>>658
まぁね。些細な問題じゃない人もいるわな。そのへんは個人の価値観ってことで。
俺はYC伸張や圧縮を二重にかけたりしさえしなけりゃそれでOKって思える人間
だからなぁ。

ノイズやアルゴリズムの計算上の誤差なんてのはこだわりだしたらきりがない
からな。それこそ最終的にはソース見せろや、ごるぁってところまでいかないと
ほんとの信用なんて出来ない訳だしな。ｗ

>>660
腐れグラフィックカード；ゲフォ

腐れアプリと腐れCodecって何がある？

腐れアプリ：Avisynth厨が言うところのAviUtl

腐れCodec：HuffyuvS厨が言うところのHuffyuv

腐れアプリ:内部RGBのTMPGEnc
腐れコーデック:いわずもがなのHuffyuvSとHuffyuvのconv->yuy2
腐れ仕様:VFAPI

>>661がどうやってるのかは知らない
ただよくやる以下の手法は
正直どう見ても色がかわる
DVD2AVI->.d2vでAviutl->Huffyuv(YUY2)中間ﾌｧｲﾙ->TMPGEnc
↑こんなことしといて
「エンコードって色が変わるねぇ」
いわれてもさぁ・・・
いや、エンコードによる色変わりは当然あるけど
それ以上の問題があるだろ？
まぁ手順の問題というか
目の問題というか

腐れcodec:WMV9のインターレース

>>666

俺の手順は

hunuaa（huffyuvキャプ、YUY2）→AVIUTLで編集(フィルタ類は一切使わず、
カット＆ペーストのみで再圧縮なしで保存）→WME9でインタレエンコ

VGAはG450、AVIUTLも再圧縮なしだと高速だし、TV出力してもモニタで見ても
同じように見えるし、俺的には画質も無問題。

>>668
ある意味理想かも知れないね。
キャプチャ時の設定がジャストミートしてればさ。
でもNRぐらい掛けたら？（インタレを壊さないNRってことだけど）

インタレを壊すNRって何？

>>669

時間以外はそれなりに満足してるんだけどね。いろいろ試行錯誤して結局
こうなったんだよな。

２２０GBほどHD用意してるけど３時間ちょっとしかキャプ出来ないんで
録りだめは出来ないね。ｗ

こっちでももめてる
http://pc.2ch.net/test/read.cgi/avi/1044370473/909-

>>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
なんてのなら、ライン間でブレンドされるだろが。

>>672
RGBで253ってのはまあ妥当じゃないの？
べつにこんなのじゃもめないよ。

>>659
PCで完結してもダメなのよ

またアフォが一人現れたな　＞675

やっと理解できた。みなさんありがとう。

>>675
この人言ってる意味不明、恐らく何も分かってないと思われ。

659で触れてる規格はむしろ映像業界のフォーマットに後発のPC側が
合わせた結果であって別にPCで完結しようとしてる訳ではない。

678必死だな（藁

679 名前：名無しさん＠編集中[sage] 投稿日：03/07/12 13:45
678必死だな（藁

◆◇◆◇　海外サイトだから安心無修正　◇◆◇◆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html

　↑　
ココは丸見え！　今ならまだ消されてないよ。たぶん・・・

242 ：名無しさん＠編集中 ：03/07/13 16:52
>>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ソースは非圧縮じゃない。

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)

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
同意。
ハフマン符号化して劣化するなら、世のプログラムは圧縮した段階で
正常に動作しなくなりなります。

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)でやると明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。

また、やってる・・・

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/

ﾈｲﾃｨﾌﾞUYVYです。

>>689
omaedareda?

ﾈｲﾃｨﾌﾞUYVYだからRGB変換誤差がおこる だから
hufにしない。で間違ってないじゃん。

◎無修正画像をご覧下さい◎２日間無料です◎
★http://yahooo.s2.x-beat.com/linkvp/linkvp.html★

>>691
ﾈｲﾃｨﾌﾞUYVYでも
”UYVYであってもAvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。”
ってのはどうよ。
つーか
”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”
ってなんじゃ？

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

Huffyuvの対応色空間
YUY2、UYVY、RGB24、RGB32(RGBA)

UYVYもそのまま圧縮可能だよ。

>>695
じゃぁAvisynthがUYVYに対応しないってことか？

>>696
AvisynthはYV12かYUY2かRGB32にしか対応しとらんやん

>>697
それはフィルタの話でしょ？
I420でもswapUVでYUY2にできるわけだから。
でも”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”は不可能？
Directshowで読めるならYUY2に変更して展開するんかな？
UYVYの動画がないんでよくわからないんだが。

>>698
それは見た目がYUY2だからだろ。Avisynthは基本的にコーデックがYUY2に展開して
くれないと話にならん。

Avisynth2.52でUYVY試してみた。
無圧縮UYVYの場合、RGB32にdecompressされた。(vidc.UYVY=msyuv.dll、huffyuv.dllとも）
Huffyuv(UYVY)の場合、YUY2にdecompressされた。
どうやら、Huffyuv(msyuvも同様）は、UYVYでdecompressQueryすると、RGB32/24を返すようだ。

>>699
UYUVの見た目はYUY2なんだが

>>700
おお！クスコ。

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に変換されるので使用しない方が良い。
ということになる。

間違い訂正
intype=-2(RGB24) -> intype=-2(HFYU(RGB24))
intype=-3(RGB32) -> intype=-3(HFYU(RGB32))

>>703
VirtualDubでもﾀﾞﾒかな？
Dubに非圧縮UYVY読ましてFastでHuffyuvにしちゃえば
あとはやりたい砲台なのでは？

落ちるには惜しいスレ

VirtualDubで非圧縮UYVY読ましてからDivxにしてる。
間にHuffyuv入れる事はない。というかVirtualDubで
取り扱えるんじゃないの。自分はHuffyuvにすると
容量３パーセントほど減って重くなるし、コーデックHuffyuvのＡＶＩで
撮ってもそう。

UYVYを展開するのはmsyuv.dllじゃないの？

VirtualDubはfast recompressでもYUY2/RGBじゃないと入力できないはずだけど。

YUY2で撮るとさらに汚いけど…

>>710
>>688

>>710
http://pc.2ch.net/test/read.cgi/avi/1050299614/566-

ｹﾞﾌｫ厨発見

622 ：名無しさん＠編集中 ：03/07/17 03:59
>>619
PCのモニタで見てない？
TVに出力すればちゃんとしたメリハリの効いた画になってるはず。
PCモニタでTVと同じ画を表示しようってのは絶対無理。

>>713
いやあ、どんなビデオボードでだってTVと同じには表示できんよ。
TVとPC画面を２つ並べて見比べてごらんよ。

蛍光体の違いはあるからTVと同じように表示するのは難しいことは確か。
でも、蛍光体の違い以前にTVのキャリブレーションがまったくされていない
ため、見栄えが違ってくる場合がほとんど。TVはRed Pushしたりガンマ補正
したりと、原信号を思いっきり歪めて表示していることが非常に多い。

民生用TVで動画見てるやつは知障

スレ読んでたら混乱してきたのでちょっと質問。
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のほうがいいよ。

俺もあんまり詳しくないんで間違ってるかもしれんけど。

>>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のフィルタを使う方法です。

>>718
なるほど、今YC伸張フィルタ落としてきたところです。
中間ファイル作るのもいいけど、HDDに余裕あるわけでもないので、
最後だけVFAPI経由でCCEに渡して16-235でエンコすることにします。

何にしても、波形表示フィルタでヒストグラム見ながら、
おかしなことにならないように確認していこうと思います。
ありがとうございました。

>>720
Avisynth2,0系なら.avsそのままCCEにもってけるよ
VFAPIになんぞせんでもよろしい

>>719
YC伸張フィルタを使用したのに、Avisynthでも伸張？補完？するのは何故ですか？
あと、AVIUTLからAvisynthへの持っていき方がわからないです。ソースを読み込むとか....

というか、Avisynth使ったことないのでさっぱりな自分があかんのですけど。
もうすこし解かりやすい説明をして頂けないでしょうか。

>>722
AvisynthのAviutlFilterPluginは
Avisynth上でAviutlのフィルタを使うプラグインなんだけど
なんせスクリプトだから数値を変化させても動的に画質をチェックしにくい
だからAviutl上でいっかいフィルタの各設定値を煮詰めておいて
その数値をAvisynthのスクリプトに書き写してるんだよ
だから”5,Aviutlでは出力しない”
Aviutlは設定を決めるために使ってるだけ

>>722
説明求めるまえに自分で調べるようにしろよ…。そんなんじゃ、いつまでたっても
厨のまんまだぞ。

>>722
とりあえずAvisynthスレからにーやんのページにいってみな
くれぐれもAvisynthスレでそんな質問せんほうがいいぞ

いや、すんません。頑張ってきます。

>>723
具体的にどのフィルターをAviutlFilterPluginで読み込んでる?
できればAvisynthだけで完結したいんだけどwavelet系が弱いからまだAviUtlフィルター手放せないんだよなぁ。

>>727
WaveletTYPEG,3DNR2,リンギング低減,視聴覚感度ぼかし
あとはAvisynthのフィルタを使ってる
てか、スレ違いでない？

>>717
430見れ

1から読んだけど全然わからん。

結論を書いては貰えませんか？
普通にキャプって、普通にエンコする場合どうすればいいんです？
ふぬああとかHuffyuvとかややこしい物は使いません。

>>730
結論？
自分の環境と目的と同じ物を探せばいいだろうが

>>730
お前がキャプしてる方法が世界標準とでも思ってるの？
何だよ普通にキャプって・・・。

そもそもふぬああやHuffyuvを使わない普通じゃない方法ってあるのか？
思いつくのはDVDレコやDVやD-VHS使う方法くらいだが。
何も考えずMPEG2→MPEG1みたいなことじゃないのか？

何も考えないにしてもどーゆー手順でどーゆーソフト使ったか
わからんとどーにもならないわけで

730じゃないですけど、松下のDMR-E80Hで録画したものを、
DVD2AVIとTMPGEncでVCD・MPEG2・Divx等にエンコードする時はどうすればいいんでしょう？

>>735
ｴﾝｺの仕方勉強して出直してこい

MPEG2-TS → DVD2AVI → Avisynth → CCE → DVD
この場合ですが、AvisynthにColorYUY2(levels="709->601")と入れておくと良いんでしょうか？

DVD2AVI1.77.3、Avisynth2.52、MPEG2Dec3を使ってます。

>>736
あ、エンコの仕方は知ってます。
YC伸張のことです。

色が薄いと思ったら伸張すれ
ちょうどいいと思ったらしない
それだけだ

イジワル

>>737
MPEG2-TSだからといって、必ずしもBT.709とは限らないよ。SDならBT.601だし。

>>741
HDの時だけですか？

HDってプログレだけだっけ？

DOS/V magazine で 動画の表示比較記事があったが
nVIDIAはGeforceFXになっても、ATIやMatroxやS3とは明らかにスケールの取り方が違うことが分かったよ。

nVIDIAもうだめぽ

>>742
そ。

>>743
普通1080iだからインターレース。

>>746
じゃYV12の色空間だったら
ColorYUY2(levels="709->601",interlaced=true)
が良いのだろうな。

マジで？？

720p

720pの時にfalseなんでつね

Interlaced指定は、YUY2なら気にしなくてよいぞ。

720pってBS朝日で1回放送しただけなんだっけ。以前、地上デジタルでは720pなんて
話があったけど、結局1080iになったみたいだし。

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

これで見たらSDのおね２はBT.709だったが。
TS>PS変換しただけなら変わらないよね？
http://www.sakurachan.org/soft/mediatools/index.html

直リンしてしまった。ごめんなさい。

>>754
webでも情報が錯綜していてよくわからないんだよ
BSDハイビジョン(1080i)はBT.709は確定なんだが
他の解像度についてはﾏﾁﾏﾁで

美少女コスプレイヤーのパンチラと
パイパンおまんこが見れるサイトを発見でつ！！！
http://plaza16.mbn.or.jp/~satchel/idolno_omanko/

パイパンおま○こは本当に美しい…　(*´∀`*)ハァハァ

http://homepage.mac.com/hiroyuki44/

NHKに問い合わせりゃいいじゃん。

>>759
そんなことしたらデジタルコピーしてることがバレるじゃんか。
犯罪者は犯罪を犯しているという自覚を持ってないとボロがでるぞ。

おかしな知障が何か言っております

高ビットレートMPEG2からDVDサイズのMPEG2への変換における
カラースケールの設定について詳しく、しかしなるべく簡単に
説明をお願いします。
過去ログ嫁とかはなしで。
次からテンプレにできますしね。

おかしな知障が何か言っております

夏真っ盛り

>>762
1から嫁
答えはすぐそこにある

>>765
自分でレスしてるんだから気付けよ。

テンプレ化しないから、
>>762　→　>>765　のようなやり取りが繰り返されることになる。
(テンプレ化しても質問するアホはたまにいるけど)

　　　　 ///////
　　　　///////＿＿＿＿＿＿＿＿＿＿＿_
　　　 /////// ￣￣￣￣￣￣￣￣￣|￣￣
　　　///////　　　　　　　　　　　　　 (~)　ﾁﾘﾝﾁﾘﾝ
　　 ///////　　　　　　　　　　　　　　ﾉ,,
　　///////　　　　 ∧＿∧　　　　　　　　 ／￣￣￣￣￣￣
　 ///////　　　　 （　´∀｀）（ 厨 ） )）　＜　　夏だなあ〜
　/////// 　　　　 （つ　へへ つ　　　　　 ＼＿＿＿＿＿＿
///////　　　//△ ヽλ　 ）　）　旦
//////　　l￣￣￣￣￣￣￣￣￣￣￣l
/////　　　￣| .|￣￣￣￣￣￣￣| .|￣
////　　　　　^＾^　　　　　　　　　 ^＾^

　　　　　　　　　2chの夏。厨房の夏。

>>766
じゃおまえがやれば

というわけで最強のテンプレ案↓

YC伸張はどんなとき必要か？
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://www.studiomilk.com/ichigomilk/diary/orenatsu2opdemo.swf

>>770
お前、楽しい?

>>762
すべてYUVで処理する。
そうすればカラースケールなど無関係。
君もAvisynth+CCEの世界にきなさい

slaveがスネちゃったからテンプレ化は無理だろうな

ビデオカードでGEフォースを使ってるのですが、
そのためにWMPで再生したときオーバーレイを切らないと
暗くなってしまいます。
オーバーレイを切らずに暗くしない方法ってありますか？

あと、今、WIN2ｋを使ってるのでわからないのですが、
将来WINXPで60fps再生したとき、オーバーレイを有効にしないと
できないと思うのですが、そのときも暗くなってしまうのでしょうか？

>>774
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

これ読んでモニタとデスクトップガンマを調整する、か
ffdshowをRAW ModeにしてLevalsで調節するか、か
Radeonを買うか。

Levelsね

HTTPの知識もないし
自分が使わないﾊﾟﾀｰｿはよくわからないし
大体あの実験をやる気が・・・
Vmaker氏のﾍﾟｰｼﾞをﾌｧｲﾙ化しとくべきでしたね
誰か保存してないんでしょうか？

ttp://www.archive.org/にもなかったな。。。

持ってるけど、どうしよう。いる？

>>779
おながいします

>>779
頼む

>>779
よきにはからえ

>>779
BlendClips (Avisynth plugin)
CutOff (Avisynth plugin)
もありますか？

>>779
兄貴って呼んで良いですか？

>>779
是非！是非！！

すいません、しばらくＰＣの前から離れてたもんで、、、

ていうか、本当にconvlist.htmlでいいんですよね？
なんかとんでもないボケをかましているような気がしてきました。。。

>>783 残念ながら見あたりません。
自分が持っているのは、ブラウザの履歴によると、2003年4月28日にアクセスしたときの
もののようです。チョット古い？

>>786
個人的にはconvlist.htmlだけで結構です

できればwakamelist.htmlもお願いしたいのだが。

convlist.htmlはすぐにでもうpします。

>>788
探してみます。履歴にはアクセスした形跡があるんだけど、ものが見つからない。。

勝手にうｐしてもいいの？

うｐしました。

http://up.isp.2ch.net/up/921f8fd5d0ef.zip

２ｃｈうｐろーだなのでお早めに。。

>>791
いただきました
ありがとうございました

>>788

ブラウザはネットスケープを使っているのですが、
ブラウザがクラッシュした時に、キャッシュも吹っ飛んでしまったみたいです。
保存しておけばよかった。。すいません（Ｔ Ｔ）

>>793
すいません。
コンブとワカメをかけた、ただのダジャレで
そんなファイル自体存在するかどうかすら知りませんでした。
本当にあったのかな…？
なかったなら…申し訳ない…

>>794
もちろん無いですｗ
お気になさらずにｗ

ただ、ホントに探していたgraphedit.htmlはネタじゃなくありません。。。

著作権を侵してる奴らがいるな

>>796
この板の多くの連中がそうだな。

伸張されてるかどうかを見分ける方法ってないですか？
見ても色が濃いのか薄いのかわからんのです。

モニタじゃなくてTVで見ればいいんだよ

>>799
釣れますか?

さっぱり食いつかないな。
スレてない奴いないかな？

パクッ

ネタじゃなくてマジなんですけど。
だって素人がYC伸張の話なんかわかるわけねーよ。
･ﾟ･(ﾉД`)･ﾟ･｡

>>803
なら、このスレ最初から読んで出直してね。

素人がエンコなんてしなくていい

素人はウンコはしてもいい

>>804
みんなそればっか言うんだよ。
読んでわからないから聞いてるのに。
そんな意地悪しないで下さいよ。マジで。

↑読んでわからないっていうのは、意味がわからないんじゃなくて、どのレスが正しいのかがわからないってこと。
だからテンプレ化して欲しいんです。

>>808
ぢんさんが簡潔明瞭にまとめてくださってます。
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic11964

>>807
それは意味がわかっていないんじゃないか。思考能力あるのか?

>>807
このスレはYC伸張に関する知識を深めるためだけでなく
迷えるトーシロを導くスレでもある
自分のキャプ・エソコ手順を示せば誰かが答えてくれるよ
環境が変わったらまた訊きに来ればいい
オレはアク禁巻き添えでもう、レスできないだろうけど
（今回はラウンジクラシック経由）

>>807
ヒストグラム見て画像を見ながら色補正するなら、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伸張しないからなのかもわかりません。

というか、このページ、

ttp://www.marumo.ne.jp/bt601/

>PC 上では YC 伸張・圧縮を行う方法が正しいものです。

なんて書いてありますが、このスレのどこかには「PCかテレビかは関係ない」みたいなことが書いてあります。
もうどっちを信じたらいいのか…。

>>813
> 気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。
それなら・・・

> カラースペース＝YUV　と　RGB→YUV＝PCスケール
> カラースペース＝YUV　と　RGB→YUV＝TVスケール
の２つは関係ない。

＞的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。

このケースはすでに例が出てるんじゃないの？

ビデオチップがBT.601から伸張するものなら
データをBT.601準拠で作れば
「PC 上では YC 伸張・圧縮を行う方法が正しい」と
「PCかテレビかは関係ない」は両立する！

鑑賞用にPC用とテレビ用にスケールを違えてデータを作るのはｹﾞﾌｫ厨のやるこった。

難しく考えすぎ。
色は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,伸張変換 2,はｽﾄﾚｰﾄ変換

伸張変換よりストレート変換の方が誤差が小さいというのは本当でしょうか？

あら、821の名前欄は間違いです。820さんごめんなさい。

うーん…。
DVDレコ(16-235)→伸張変換(0-255)→CCIR601ではなく…に無ﾁｪｯｸ(16-235)
ということでしょうか？
最終的に(16-235)になるようにして、再生時に(0-255)に伸張されるような状態でいいんですか？
DVDレコーダーでの再生は勝手に(0-255)に伸張されるんですよね？
質問ばかりですいませんが。

それと、VideoStudio4.0でエンコした場合、AVI→AVIと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にしたときにどっちが・・・ってことだが
繰り返すなら兎も角一回くらいならたいしてかわらない

>>825
なるほど。
とりあえず、

>1,DVDﾚｺ(YUV記録)->DVD2AVI(PCｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無ﾁｪｯｸ)

>2,DVDﾚｺ(YUV記録)->DVD2AVI(TVｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にﾁｪｯｸ)

この組み合わせさえ間違えなければOKですね。
ありがとうございました。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

ついにﾉﾝｻﾁｭﾚｰﾄAviutl完成
HuffyuvSよ安らかに・・・

YUY2への変換時にYを16〜235、UVを16〜240の範囲に飽和させるかの設定を追加。

slave さんは >>629 で次のように書きました。

＞意地でも直さないだろうな・・・KEN。

このスレがKENクンの意地をやわらげたんじゃないの？
あきらかにおかしいものはおかしいから

あの・・・それよりどうすればｻﾁｭﾚｰﾄできるんでしょう？
できないんですけど

>>832
したいのかよ(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として表示しているので、少し暗め。

あ・・・さっそく貼られてしもた（汗

ちなみに明るさ120%というのはわかりやすい値を選んだので、極める方は微調整よろしく。

私信御免
420いるぅ〜？
書いといたよ。欠点スレおいで〜

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側の問題のようです。
お騒がせしてたいへん申し訳ありませんでした。

>>838
ついにslave(Vmaker)の息の根がとまったな(w。
HuffyuvスレでもSをほしがるヤシは金輪際いないだろうに。

HuffyuvSが残していったもの、それは（ry

卵スレはネトラン者だらけだから信用できんな

>>841
卯スレだよ

烏

途中まで読んだけど何がなんだかさっぱり稚内ヨ！
とりえあずエンコした動画をaviutlで読み込んでヒストグラムを表示したら
両端がカットされてなかったので下手に弄るのはやめときます・・・。


【コーデック】huffyuvS　Conbert to YUY2
　他の設定はデフォルト（Enable full size output-bufferのみonになっているます）
【エンコーダ】Aviutl 0.99
　設定はデフォルト
　「YUY2変換時に････飽和」off
　「YUY2フィルタモード」off

（脱兎

slave=流れ者≠vmakerだろ

>>844
99だろ？んじゃ
HuffyuvS捨てろ
Huffyuvにせい
Convert to YUY2やめれ
YUY2展開・圧縮にチェキ

Aviutlスレからきました。
向こうで「YUV->RGB->YUVストレート変換は諧調がシュリンクされる」
って力説するヤシがいるんだけど、ホント？
RGB->YUVならわかるけど
YUV->RGB->YUVなら元のYUVがYUV色空間に収まるデータしか持たないんだから
シュリンクされない、と思うんだけど？

スレ違いだがAviUtl99は、もう大丈夫なんでつか？

大丈夫でつぅ

>[TMPGEnc Plus 更新履歴]
>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がなぁ
どっちも堀やんけ
なんとかシル！！

TMPGの3が開発中なんじゃなかったっけ？
きっとYUVに対応するでしょ

堀だからわからんよ

TMPGEncServerもなかったことになってるしね

処理速度とYUV

せめてどっちかは対応して欲しいとこだが
最近のカノプ的な面白機能を目玉にしてくる可能性も

>>858
多段パスがほしい・・・

名前：名無しさん＠編集中[sage] 投稿日：03/08/22 21:38
>>540
YC伸張スレ
キャプチャーボード上のチップはネイティブYUV処理のものが多い。
WindowsのCodecはサイズ圧縮を旨とするためYUV系が多い。
ところが動画処理系のフリーウェアにはRGB入出力系しか持たないものも多い。
そのためYUV->RGB->YUVが必要になるが
その際↑にあるように”ストレート変換”と”伸張変換”の二つの変換公式があり
RGB入力を持つアプリはどちらの変換公式を用いたRGBかを指定するオプションがあるのが普通。
ただし、そのアプリによって表現形式が異なるため初心者は非常に混乱しやすい。
それを説明したり情報交換しあったりするスレ。
の筈だが現在はストレート派と伸張派の戦場。

戦場らしいから戦うか
BSDiLinkキャプしてM2v.aui(BT.709)にしてAviutlに読み込みノンサチュレートでHuffyuvYUY2
それをVirtualDubModで.avs colorYUY2(true)
有効領域外のデータあるじゃん
MPEGエンコードでレンジオーバーするのか？
レンジが狭まるならわかるが・・・
コンポーネントマスターに有効領域外データはないってホントかよ

不浄

http://www.geocities.co.jp/SiliconValley-SantaClara/1673/

自作板のnVidiaスレでがんがってる人がいるんですが、
考え方は合っているのでしょうか？

上記サイトの推奨設定だと
BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
合っているとは思うのですが

詳しい人の意見も伺いたいです

Aviutl v0.99+CCE Basicを使って、DVD-VIDEOを作る場合、

キャプチャ(YUY2) huffyuv+cce patch(YUY2) ->
->Aviutlで、YUY2読み込み,出力にチェック、飽和をオフ -> 編集 ->
->huffyuv+cce patch(YUY2圧縮)
->CCE (YUY2読み込みを試みる)

でいいですか？　Aviutlとhuffyuvの関係が複雑化してきて、さっぱりですよ・・

>>863
MSの想定するYUVオーバーレイを基準にすればそれであってる。
ただし単純に
>BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
>合っている
とはならない
非圧縮YUVで比較しないとCODEC、再生アプリ側の色彩調整の影響があるからね。

>>864
ソース色空間および適用範囲を保持したいなら正解

>>861
撮影した素材そのまま持ってきたとしても、
カメラの輪郭補正とか、例えばDVの圧縮ノイズ、
ついでに編集かましたときにカラコレしたりで、
範囲外に出ることは多々ある。
あからさまに潜ってたり飛ぶようなことは無いけど。

>>865
thx!!

MSの想定（DirectDrowでYUV オーバレイ） = ITU-R BT.601

なんですよね？

YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
各ビデオボードごとに表示が違ってくる。

>>869
BSplayer等でオーバーレイを無効にした場合について書いたつもりだったのですが
どうでしょうか？

オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
ソフトウェアで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

また,”伸張変換はMS・IBM・Appleの想定する変換。 ”
なのでアメリカの規格にのっとっている。
NTSC-JにのっとればYUV-RGBへの伸張は

(16-235)->(0-255)ではなく

(16-254)->(0-254)になる

235以上が有効範囲外になるのはアメリカの話であって、
日本では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）”といった別々の表記がある。

>>873
チューナーの設定をNTSC-MからNTSC-Jに変えると
明るさがアップするけど、この理由は何？

>>876
>>875

http://pc.2ch.net/test/read.cgi/avi/993130983/555n

結局

アナログ輝度（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でも良いけど)はどのくらい伸張するの？

>>880
ん？？何番が対象の発言？
＋120というのはアナログの場合かコンポジットの場合でしょ。
民生用のアナログカメラは、120IREとか平気で出すインチキっぽいのがあって、
顰蹙かってたなぁ。
コンポジットの場合は色振幅の最高は理論上〜160IREくらい、日本の映像〜133IRE、
米or古い機器など〜120IREってのはあるけど。
何の話だろ・・・・？

＞また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
＞UV(IQでも良いけど)はどのくらい伸張するの？
この部分には俺も興味あるな？
計算式はどうなるの？

>>882
デジタルメディア上での計算式なんてないんでは？
ヘタに計算式作っても誤差がでるだけでしょ
どうせ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」に合わせるのは難しそう（というか不可能）だと感じました。

>>886
プロはストレート変換しか使わないよ。

>>887
民生テレビ自体を完全キャリブレートすることすら困難だよ。

>>889

>>889
失敗・・・２重投稿ｽﾏｿ

でもせめて出力側だけでも規格に合わせたいです

>>888
＞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 向け
業務用機器を触ったり、作ったりしたわけじゃないけど

>>893
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

NTSCビデオ信号タイミング規格(RS-170A)概要
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秒ロー。

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とか書いてる奴もあった。

>>892
再生環境のキャリブレートと中間処理のYUV>RGBは分けて考えるべき
大体、伸張変換公式だって本来は再生用（ただしアメリカ基準）
中間処理はストレートに決まってる(BT.601)
リンク先の”プロ”はプロ過ぎて”NTSC-J対応伸張公式”を実装したアプリがないことを
知らないんでしょ

>>899
あの”プロ”はあのスレで一番エバってるね。
なんか徹夜明けのハイテンション状態で一気呵成に書き込んでるような．．．
プロなんだから、もっと余裕をもった気持ちで書き込んでほしいものだな。

>>899
ピナクルのシステムは16-254のDV映像を、16-235で変換するよ。
これは235以上をクリップすると言うことではなく、
全体を圧縮する方式。したがって235の白は218になる。
ストレート変換だけじゃないよ。
でもって895〜898はなに？新手の荒らし？

>>901
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？

>>894
109IRE の 242 ってのは計算ミス。指摘ありがとう。
108IRE が 254 だった。

プロの書き込みにはイチイチ頷かされるんだが
実際問題我々下賎なキャプ厨には役にたたない

>>901
それって複数回通すとどんどん暗くなっていくような気がするけど大丈夫なの？

最初の１回のみ縮退。でもその後はストレート変換で処理。
だからどんどん〜ってことはないよ。
ストレート変換を基本にしながらも、
初回のレンダリング時は
メーカー独自の領域に丸めてしまうものが多いね。

でさぁ、902ってなに？なんか失礼なやつだなぁ！

自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？

なんかシッタカが闊歩しておるな。

>>901=>>906
＞でもって895〜898はなに？新手の荒らし？
これは>>894の「235を超えると線形性は崩れるの？」に対するレスだろ？
俺にとっては、895-898は非常に有益な情報だったよ。
もしこれが間違ってる／的外れってんなら、プロならプロらしくきちんと説明しろよ。
俺には、荒らし扱いする理由が全く見えないので、（895-898が全く意味無いと判断した）その理由が
非常に気に掛かる。
895-898への訂正意見とか反論とか、知識の出し惜しみせずに本当頼むよ。
（まさかレスする価値も無いスパムだとは言わないよね？）

ノウホワイは後回しにしてノウハウの伝授をーーーーーっ！

>>909って>>897とか>>907とか書いたやつだろうけど、
言語障害か何かだよな。まともなことばで返せない・・・

>>907
１行でやめときゃいいのに

>>901
>>906
>>911
┐(´〜｀)┌

おれにはチンプンカンプンだよ、って？
ごめんね、難しすぎて。

なんか>>907 ＝ >>913が糞スレに仕向けてるぞ。

>>901
>>906
>>911
>>915
┐(´〜｀)┌

>>913や>>916も　┐(´〜｀)┌

┐(´〜｀)┌ な病気が流行ってます。気をつけましょう！！

>>913
>>916
>>917
>>918
┐(´〜｀)┌

でさ、ここの住人の人、↑こういうヴァカ放置しとくわけ？
結構キチガイだね。それとも外人さんかな？（藁

煽りは無視しろよ。それで良い事だろ。
俺もだんだん、
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
と思えてきたよ。

＞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 まで使い切るのが正しいこと
だとか誤解しない方が良い。

>IRE100 を超える情報が放送局のマスターレベルで存在するって
>のは既出

え？そう？？
ガイシュツはMPEG2-TSしかないんでは？

自分にとって既出だったら価値が無いってわけか。プロって観点がやっぱ違うな。
それでスパム扱いするわけ？

言葉足らずだった。
俺は、スパム扱いするくらいだから、待ちかっとるよキミ。
ただしくはこうだ。とか説明があるもんだと思ってたよ。
>>895のpdfや>>896のリンクはスゲー良かったよ。

895-898も、もうちょっとまとめて書けば荒らし扱いされなかっただけの話だ。
以上。

>>897だって、俺には各色が何Vp-p(IRE)なのか判ってうれしい情報だったが？

素人が調べた情報を貶すより、玄人からきちんと情報だすのがプロの態度だと思う。
もうスパムだどうだって話はいいから、実際の話をだしてくれよ。
例えば、局に納品するものは、レベルをどの範囲で作っているのかとか。
（109IREとか出してるけど、こんなレベル許されないだろ？）

あと、カメラ撮りから編集時のレベル調整じゃなくて、
（歪み補正とか色々あるだろうから、ガンマやニーポイント、ショルダーポイントで複雑に補正するんだろうけど）
俺たち、キャプチャユーザーにとっては、補正後の完成された画像を取り扱うわけよ。
その場合、俺たちはなるべくレベルはオリジナルに近づけたいと思ってるわけ。
そういう観点からも、レクチャしてくれよ。

＞911 ：名無しさん＠編集中 ：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・

俺が909を書いたけど、897や907は書いてない。いったい何処の部分で一緒にされたんだ？
俺の書き方が言語障害だってのはどの部分？
あなたがまともなプロの方だったら、内容はともかく、言語障害と断定したことに
納得できる説明または謝罪を要求する。

だめだろう、あのプロは。

つーか私はプロじゃないのだがなぁ（少なくとも編集側の人間じゃない）
聞いた話レベルのことしかいえないけど、それでもいいわけ？

許容される輝度レベル：
・16 以下は絶対不可
・235-254 まではどこまで使っても OK

実際の輝度レベル：
・使ってる機材と使う人でピンキリ

というわけで、明確な基準はない。

あと、プロに過大な幻想を抱くのはどうかと思うぞ。ほんの１年前まで
当たり前のようにコンポジットマスターで DVD を作ってて、今なお HD
を D2 アプコンで放送してるような連中なんだから。

そういや、プロと自称しているヤシが NTSC-J (0IRE) と NTSC (7.5IRE) の違いが
デジタル段階でも現れると思いこんでいたりするのにはちと驚愕するね。

自分が舌足らずなのに相手の読解力のせいにするスレはここですか？

お前ら、そろそろ次ｽﾚのﾃﾝﾌﾟﾚとFAQを、まとめれ。

アプリごとの特性
codecごとの特性
ビデオカードごとの特性
フィルターごとの特性

誰か纏めてﾃﾝﾌﾟﾗにしてくらはい

＞納得できる説明または謝罪を要求する。

２ちゃんでそれを求めてもなぁ・・・・・・
909がマジで謝罪もとめてるとしたら、けっこうバカかも。
それとも「プロ」煽ってんのかな？
おーい、プロよー、出てこーい！

>>937
＞あなたがまともなプロの方だったら
と但し書きがあるので、出てきたら幸いだという思いがこもってると見た。

>>933
そういや、NTSC-Jだから0IRE=0なんて主張していたのもいたな。

出て来ないからまともじゃない、って釣ってもねぇ・・・・・
なんせ２ちゃんだから・・・・

要するにこのスレでボスを気取っていた907の前に
ある日突然プロを名乗るツワモノが現れ、
危機を感じた907が追い出そうと必死、ということでいいでつか？

>>941
ここのボスって誰？
907ってただの煽りじゃん。
釣り？

>>941
このスレ的には、プロ大歓迎だろ。
ただ、プロなら傍若無人な態度をとっても良いってことにはならいだけ。

>>939
NTSC-Jでは0IRE=16で、普通のNTSCでは7.5IRE=16ってこと?

AviutlのYC伸長の始点ってどうやって選べばいいのか分からない
readmeにはデッキ等の機種によりけりって書いてあるけど
自分のがどうなのかを調べる方法が・・・

>>945
ヒストグラム

>>944
そ。あくまでアナログ段階の黒レベルの問題であって、ITU-R BT.601に従って
デジタル化した場合は黒レベルはNTSC-JだろうがNTSC-USだろうがPALだろうが16。

匿名板には自称プロが多数生息しています。

>>932
許容される輝度レベル：
・16 以下は絶対不可(局によっては3IRE以上だったりする)
・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
　全体的に飛ぶと局に納品断られる。
これにクロマが絡んでくるとまた厄介なんだけど。

あと、BSデジタルは制作費があまりもらえないので、
全てのコンテンツをHDでやれないのね。
地上派デジタルになったって、
しばらくはSDのアプコン主流で行くし。

なんだ 結局キャプ厨的にはＹ（１６−２３５）を基準にすれば十分ってことじゃない。

＞・16 以下は絶対不可(局によっては3IRE以上だったりする)
＞・235-254 はオーバーシュートしたパルス部分が出てる分には許容。


普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね

>>951
そりゃ規格を知らん自称プロによる腐れオーサリングなソフトがあるってだけだ罠。

>>952
いや、クライアントが納得して報酬を支払ってるなら立派なプロだろう。

>>952
>>939ってことか。0IRE=0なんてオーサリングしてたら、そりゃ当然そういう
事態になるね。

15以下236以上の輝度レベルのピクセルこだわっていたslaveらアンチBT601派は
受信機によって歪まされた輝度レベルを「マスターに近い状態」と信じて有難がっていたわけだな。

>>953
そだね。規格を知っている/知らないのとプロ/アマかは無関係。

nyで落として焼いてヤフオクで捌いてるのもプロ

>>955
HEY!X3のスタジオライブはHDD収録なんだがiLinkキャプすると
範囲外とか言ってる236以上に諧調が存在する。
iLinkキャプは送信されたストリームを記録してるだけだよ。
MPEGエンコーダのせいにするのか？
MPEG圧縮でレンジが拡大するというのか？

そもそもマスターに近い状態って理解してるのか？
iLinkならまだしも民生レベルで地上波の16以下235以上をマスター同等のレンジでキャプできるのか？
おまいが16だって信じてるものがマスターの16である保障はないよ。

>>958
結局そうじゃない保障もない･･･という表現もヘンな気がするから
一般視聴者レベルでそんな保障を得る事は不可能に近いから
面白画質にならない範囲で好きなように補正すりゃいいって事じゃね？

>>958
マジレスすると
フジ、特にHEYは異常にYが高い

>>959
だよな。
iLINKキャプやDVDリップですら範囲外もへったくれもないんだから
規格そのものが現実にそってないんだよな。
それにしてもテレトのハロモニはなんとかして欲しいんだが。
範囲外とか色づけとか演出とかキャプ環境とか、
そういう問題じゃないくらい面白すぎる(泣

>>960
日テレはYどころか全部高い。
テレ朝もひどいし。
NHKに合わせてテレビをキャリブレートすると
Mステは目が痛い。
これが現実なのね。

>>961
ハロモニは輝度が高いとかそういう問題じゃないからな
どんなに輝度を低めにキャプしても飛んでる色は最初から飛んでる
放送する前から白飛びしてるってアホくさすぎ

で、再圧縮するときは（そういう人も少なくないでしょ？）
送り出し側を尊重して面白いままにしておくの？

>>964
>>963
白とびに関してはどーにもならないよ。
全体に薄暗くしたって意味ないし、
コントラスト下げれば不足気味の諧調が余計消えるし、
面白い物は面白いままなんだよ。

タイミングが悪かった。
ハロモニじゃなくてHEYみたいなものの話。

>>966
iLINK前提ならY値だけ下げれば諧調が破壊され
サチュレートすればソースが破壊される。
でもビットレート稼ぎたいからサチュレートしちゃうけどな。

ハロモニの白飛びに悩まされてるモヲタは多い

白飛びはモヲタ対策なんだよ。

ハロモニはたまにやたらと粒子の粗い？カメラがあって
肌が無茶苦茶汚く映るので萎える

>>961
規格が現実に沿っていないのではなく、プロでも規格をしらないバカが多いってこと
なんだけどね…

モーヲタ氏ねよ

次スレッド立てようぜ

>>946
ヒストグラムでどう判断するのか分からない・・・

そりゃ、きちんとカラーバー入れないと判断つかない罠。

>>951
DVDで白飛んで黒潜ってるとか言っとりますが、
マスターに入ってるカラーバーで校正した結果なら仕方ない。
そういうのは、マスター作ってきた制作会社が悪い。
漏れは客に判断仰ぐけどね。
おかしいカットだけカラコレかけられるけど、
そこはうちの責任じゃないので修正しない。

まあ、まともな作品で0IRE以下になることは無いけど。

>>951
ちょっと待てや。

＞普通にTV番組では使われてる領域だよ
＞映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ

0-15が普通にTV番組では使われてる・・・と読めるのだが、
使ってるわけねぇだろ。おまえはちゃんと波形モニで監視してるのか？
0は同期ワードで使用絶対NGだから存在しているわけないし、
1-15はカラリメトリでクリップされるから送出されるわけがない。
どこからこんないい加減な話が出てくるのか疑問。
あんたどの局？どの時点で監視してるの？
サブキャリアの話とか言うオチはなしにしてくれよ。

>>976-977
それは
>>201のコピペ

976や977のような話が201の後に出てこなかったことが、ちとカナスィ・・・

>>976
プロとしてなっちょらん

AviUtlサポート掲示板のYC伸張スレ
http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=res&no=4339

誰かいい感じのスレタイで次スレ立ててくれ
これは初心者が行き詰まったり気付かないで放置しちゃってる問題だから
誘導しやすいように最初のほうで（できればテンプレで）まとめてくれ
俺はよくわかってないから無理なんだが・・・

ここで熱心に虚しい議論してる連中、
脳内空回り的発言多すぎだぞ。
とりあえずハケモニは買ってくれ。
何事も目で確認するのが一番！

カラーバーとかキャプチャすると普通に0-15を使ってたりせんか？

セットアップバーの-4IREが使ってるだけ。

>>984
まず、キャプチャ時にゲインが正しく設定できているか確認したほうがいい。
あと、カラーバーは確かに16以下を使っているけど、それは-4IREの部分だけ
なので0-5は使っていないはずだぞ。

あ、いや全く無いみたいな話が上であったからさ
15以下が放送されることは普通にあると思うんだが違うの？

テスト信号以外、　な　　い　　。

>>987
サブキャリとか言うオチは、なしにしてくれよ。

映像製作時にあった場合は放送時に切られるってこと？
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど

>>990よ、
映像製作ではなく、映像制作だ。
プロに叱られるぞ

MPEG2を再生するときに、明るい部分が黒く再生されてしまうんですが、
これって伸張に間違いがあるということでしょうか？

＞明るい部分が黒く再生
それはネガポジ反転が掛かっているからです

>>987
アナログ信号だからデコード -> キャプチャしたときにリンギング等の影響で
0IRE以下の信号が出てくる場合はある。けど、これはあくまで受信環境の問題。

>>987
お前のキャプチャボードの設定を確認しろ。

>>993
馬鹿にしてますね。
それなら逆に暗い部分が明るく再生されるじゃないですか。
明るい部分が黒くなるだけです。

ないということは分かったのでできれば990に答えてもらえますか？
ただの確認なんですが

>>993
この板に常駐している連中って、皆、不親切だし、独り善がりだし、偉ぶってるし、ドケチだし、ひねくれてるし・・・
なんか実社会において著しく他人とのコミュニケーション能力に欠けてる社会生活不適応者の典型の集まりって感じがする
嫌われ者で笑い者で引き篭もり（若しくは、それに相当する）のヲタばっかなんだろうな、ｷﾓｯ!

＞馬鹿にしてますね。
うん。よくわかったね。
＞明るい部分が黒く（＝0IRE）なるだけです。
そりゃ故障だ。

やったあああああああああああああ！！！！！

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。