【YUY2 YV12】色空間スレ【RGB24 32】

すいません少し疑問に思ったので質問させてください。
モンスターXでキャプすると基本的にYが0％は0、100％は255でキャプされます。
さらに付属のPIC MJPEGだと0以下と255以上は完全にカットされます。
で、放送自体はY0％-100％は15-235+αなので、+α部分が255オーバーになってしまいます。
削られる上限域を残そうとマニュアルでYを0-235と言う変則調整を思いついたのですが
この場合、Pb、PrもYと同様に0-235へした方が良いのでしょうか？
それとも15-235もしくは0-255なのでしょうか？
それとも「おめーのやっていることは無意味だろ！！」なのでしょうか？

>>318
キャプチャー時に0-255に伸張されていて基準白が255になっているってこと？
それはキャプチャーデバイスがおかしいね。
基本はキャプチャー時は16-235で再生時に伸張して0-255。
0-235ってのもありだけど、ITUとかで定義されてないからあんまり誰もやりたがらないよね。
↑の方に色々とヒントになりそうなこと書いているけど。

>>319
レスありがとうございます。
モンスターXの画像がなぜかコントラストが強かったので波形プラグインで色々調べてたらそうなってました。
D3キャプという特殊性からくるためかな？しかもカラーバー入れてオートゲイン働かせるとYゲインが基準よりデカめに調整されるので
ここでもコントラストがでかくなる要因があった。PV3はどうなってるんだろう。

>>320
コンポジットだろうとコンポーネントだろうとHDMIであろうと、DVI以外のときは入力は16-235でキャプチャーされるべきだね。
一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。

>>321
＞一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。
モンスターXにおいてはこれはある意味仕方がないという気もするんだけど・・・
だってデコードの再チューナー側でYC伸張されたY0-255のアナログ信号をキャプるものなんだから、
素直ちゃ素直な仕様かなw
ただ後から加工や記録を前提にしているおいらたちから見れば、糞仕様と言われてもしょうがないんだよねぇ・・
とにかく、Pb Pr の答えも見つかりそうにないので0-235はやめて15-235でしばらくキャプって見ようと思います。

>>322
そもそもなんで途中か最後にRGBに変換してるんだろ？
ずっとYUVのままならYC伸張もなにもいらないのに。

>>323
それって出力までTVで見なさいよってこと？

グラボに直接YUVデータ流し込めば？

>>323
勉強不足でおっしゃる意味がわからんのですが ＾＾；
とうぜん、エンコ自体はYUV（YUY2）で通してます。
RGBへ変換しているのはチェックのためにAVIUTL+波形表示プラグインで開くときだけです。
>>323さんがおっしゃるのは、BT709のまますれば？って言ってるんですの？

ちなみに、うちのGF7300ではYUV入れてもYC伸張して表示してくれないので
15-235ものは再生時に補正してます。

波形表示はYC2のまま表示できるじゃん。

>>326
>とうぜん、エンコ自体はYUV（YUY2）で通してます。
ってことはどこで伸張されてるの？
だってYPbPr→YUY2なら伸張関係ないはず。
どこかにYUV→RGBがなければ輝度そのものはYPbPrのソースのままのはず。

書き方が悪いのかなぁ・・
キャプボのデフォが0-255でキャプされていて
それを変則Y0-235に調整した場合Pb、Prはどうしたら良いのかって事が元々の質問の趣旨だったんですが・・

色差も0-255でキャプされんの？

そうです

もうデフォで妥協したら？0-235と言ってもそのままじゃ使えないし、とは言え調整は容易ではないし。

調整自体は意外と簡単にできるので苦にはならないんですが ＾＾；
一応参考までに
http://www.borujoa.org/upload/source/upload14534.zip

>>329
>キャプボのデフォが0-255でキャプされていて
だからこれが糞だって。
IREレベルのYPbPrをデジタルのYCbCrにするときに白黒のリファレンスが16、235になるようにデジタル化するのが普通。
デジタル化されたときに既に0-255になってたら駄目駄目。

>>334
そうなんだけど、PV3のソース見たらこっちもデフォで0-255になってましたねぇ
モンスターXは一応プレビュー用と言うことで売ってますのでこれも仕様かとは思いますけどねw
ただ、モンスターXスレ見てても誰もこのことに言及してないのが不思議だな。

白黒リファレンスが16、235で調整されてて
それを超える範囲も一応記録してるんじゃまいか？

リファレンス以上の白黒範囲が存在して色がおかしくなる
機械やソフトは駆逐されたと思ったけど
古い物だと変な色に見えちゃう可能性があるかもしれん

あ、何か勘違いしてるかも
聞き流して下さいな

>>335
揚げ足取るつもりはないけど。
プレビュー時にYUV→RGB変換を行うのはモンスターX？それともビデオカード？
ビデオカードならYC伸張されているデータをさらにYC伸張されてしまって黒と白が飛んじゃうよ。
だから、記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。

>>338
YPbPr0-255での表示や記録をRGB変換というのが正しいのかというのはおいておいて、
（正確には色空間変換とかも絡んできますので）
プレビュー時のYC伸張はVGAの種類とドライバとレンダラによって変わってくるので一概には言えませんですし
何度も言うようですがモンスターXのデフォでは出力をYPbPr0-255を目標とした基準値になっているようです。
当然、キャプチャに回されるデータも0-255ですねぇ。

＞記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。
理想はそうかもしれませんが、現実再生時、VGAドライバレベルではYC伸張しないシステムも多数存在する訳なので
（うちのシステムそうです。たぶんこっちの方が多数派？でもそこから直せとは言わないでねw）
ケースバイケーかとは思いますけど・・・と言いつつ、今のうちの記録はHUFFYUV YPbPr 15-235 で記録してますけどね ＾＾；

>>339
でもDVD、HD DVD、Blu-ray、地デジ、一般に広まっているMPGファイル、WMVファイル、DivXファイル。
どれひとつとっても16-235に正規化された状態で記録されているけどな。
再生時のYC伸張するしないはオーバーレイと非オーバーレイの過度的な理由からでしょう。
Vistaでは伸張に関してもAPIで定義しているからドライバーが安定してくれば統一されてくるんのでは？

0-255だと当然、16-235より綺麗なグラデーションになるからね
再縁故前提な設定な気がしないでもない

>>341
は？取り込むときにソースが16-235に正規化されているんだから
それを変換するときに0-255に伸張したらグラデェーションは変わらないか、
変換誤差のために16-235に変換するより劣るぜ。
0-255にする利点は標準黒と白をRGBの黒と白にマッピングできるということだけなんだが。

MonXのフルスケールが気に入らないならキャプった後に編集段階で修正するんではダメなのか？
キャプ段階でやるのとどういう違いが出るかは分からないが。

楽しそうなので上げときますね

>>343
キャップした段階で伸張されてしまっていたら0-15と236-255のデータがなくなってしまっているのだが。
0-15はまあ良いとしてもハイデフソースとかだと236-255は普通に使っている。

それは分かってる。そういうことじゃなくてボードがデフォで伸張してしまうのだったら
いくらMonster-X Setting Utilityで16-235になるように設定調整しても意味ないんじゃね？ってこと。

もしPV3もそういう仕様だったならなんで今まで話題にならんかったのが不思議な感じだ。

>>346
意味はあるよ。ちゃんとモンXではY100％輝度以上も出力している。
モンX標準のPIC MJPEGの設定は100％以上と0以下は問答無用にカットされちゃうので
余計に意味が出てくる。

なるほど参考になった。内部的にはどうなってるんだろう。
一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･

>>348
もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
いずれにせよ0-255は取り込みようじゃなくてプレビュー用と思うけど。

>>348,349
内部的にも何もそもそものデータがアナログ信号なんだから
A/Dがどの範囲でデジタル化するかって事だけでしょう。

>>350
ずっとその話をしているんだがｗ

わかってないのがいるようだから
>>349
＞一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･
余計な工程なんてない。A/Dはただ単に決められた値と解像度で量子化しているだけ。
100％輝度が255と設定されたらそうしているだけ。235でも同じ。

>>349
＞もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
もともとのデータというのがTSデータのことならその通り。ただし一度アナログ変換されたものを戻すのにどこまで意味があるかは考え方次第。

>>352
A/Dで16-235と0-255に選択出来るやつもあるが何か？
ようはどうでもいい話で、取り込み時は16-235にするでFAなんだって。
で、再生時に必要に応じて16-235と0-255を切り替える。
普通はPCモニターだから0-255に伸張するで正解。

>>353
>>352が書いている事に対して全然かみ合ってない気がするがw
結局おまえの考え方を押しつけてるだけなのねw
記録時にどのスケールで記録するかは>>352が言っているように人それぞれだろう。
だいたい記録した物を放送に乗っける訳じゃないんだから規格がどうのとか言っている方が陳腐。
一例としては16-235をRGBに伸張した場合、システムによってはグラデーションにムラができることがある。
実写ではソリッドなバックの光量の差によるグラデーションとかで確認できる。
235を255に延ばすんだから当たり前なんだけど、その辺を嫌って0-255で最初から記録することもありだろう。
だいたい、基準白より明るい白は表示できてもよっぽどでないと視覚的に見えないしね。

ちょっとお聞きしたいのですが、Haali Video Renderer の Luma range の設定と効果は、
　TV ・・・ 素通し（無変換）、PC ・・・ 0-255 → 16-235 へ変換
でいいのでしょうか？ doom9 のフォーラムで書かれてたのとは違う結果なんですが・・・。
やりたいことは、データ（avi）の時点では 16-235 にしておいて、再生時に伸張したいんですが、
Haali だと伸張できてないっぽい（？）ので。（XP SP2、GeForece7600GT）

以下、やったこと。おかしいところがあったら指摘をお願いしたいです。長くてすみません。

1. MonsterX でカラーバーを MJPEG で録画（D3）して aviutl で読み込み。
2. YPｂPrゲイン調整フィルタで、output convert のみチェックを入れ、黒-白 を 0-255 に。
3. x264 で avi 出力。
4. 出力した avi を aviutl でフィルタなしで再度読み込み、黒-白 が 0-255 を確認。
5. Media Player Classic + Haali Video Renderer で再生。Luma rangeの設定を、
　TV にすると、再生画面の 黒-白 が 0-255
　PC にすると、再生画面の 黒-白 が 16-235　になる。Printscreen で確認。

ちなみに、aviutl で 黒-白 が 16-235 のファイルを作って同じように再生させると、
　TV にすると、再生画面の 黒-白 が 16-235
　PC にすると、再生画面の 黒-白 が 30-217　になります。

>>354
>0-255で最初から記録することもありだろう
ってことは基準黒のアナログレベルをデジタルの0、基準白のアナログレベルをデジタルの255にするって事？
つまり、16-235のデジタルを伸張して0-255にするんじゃなくて、アナログから一発で0-255のデジタルにするって事？
そんなのあんまり聞いたことないけど。。。

>>356
＞16-235のデジタルを伸張して0-255にするんじゃなくて
エンコ時に0-255に伸張する人なら最初から0-255へ伸張するのも有りではと言うこと。
別にそれを人に推奨するつもりはないが、自分のシステムがどういう挙動をするのかわかっている人なら、
おかしな考え方でもないと思うがね。

うちではMonsterXの初期設定＆オートゲイン、オートオフセットONにすると
0％が0、100％が235でキャプチャされる（PIC M-JPEGで）。100%を超えるのは
235-255の範囲に入ってる。100%が255にはなってないみたいだけど。

うちのもhuffyuvで、ほぼそんな感じ。1個前のドライバにて。

入力機器によって違うのかもね。
AG、AO入れてるとうちでは（RD-E300）Y-0%は0 Y-100%は255以上になるなぁ・・
少なくともゲインだけは弄らないとコントラストがつきすぎる。

>>358
AGとAOって結構賢いんだな。0-235なら完璧じゃね？

>>361
カラーバー入れている限りはAG,AFは結構かしこいよ。
ただ、普段の映像を入れてどうかは別問題。
つか、0-235で完璧って・・・・＾＾；

>>358,359にはその時のPbPrの色差100%と-100%の値はどうなっているか教えて欲しい。

>>362 カラーバーでなら、PbPrの色差100%と-100%の値は読めるかもですが
通常の映像ではどうやって読んだら良いですか？

通常の映像での Y100％ は番組提供のテロップとか、時刻表示の文字などが
該当するかと思うんですが、それらも概ね235に合っているようです。

ならカラーバー入れてみてくださいな。
オートだから当然入力画像によってゲインやオフセットが上下するんだからw
普通0%輝度がY0になってるんなら、100%輝度は255が標準ですよ。
上の方で意図的に0-235にするとどうなるかって事を言ってた人もいたけどね。

ttp://www11.axfc.net/uploader/20/so/He_34743.zip.html
monx

カラーバーの録画ファイルと MediaPlayerClassic で再生した画面を取り込んだものをアップしてみます。
MonsterX 標準ソフトで録画、オートゲイン、オートオフセットどちらもONです。

思うに、MonsterX では HD 映像で使われている範囲（0%〜100%+α）を 0-255 に割り当てているのかな、と。
それが正しいかどうかはともかく。

>>365
HD素材なら基準黒を0、基準白を235でαの部分のいわゆるスーパーホワイトを236-255にするのが良いかと。

>>366
なんで0-235なの？？
その際のPbPrはどっちに合わすの？

>>365
Y0-235になってるねぇ・・・うちではデフォのAG、AO入れてると
Yは0-255ちょいオーバーになるけどねぇ
個体差なのか、うちがおかしいだけなのか、入力機器によって違うのか・・・
PbPrは中間の±242あたりになってるね。

>0-235

普通にわからん。
16-235じゃないのか。
BT601と709の違い？

>>369
16-235と0-255は標準化されているけど、両方とも問題あり。
ようは0-16→0にしたいけど235-255は保持したいということで0-235。

ｘｖYCC規格とかが関係してるのかのう…

>>370
その考え方はおかしいよ。
100％以上0％以下をカットしないコーデックだっていっぱいあるんだから、気になるならそれ使えば良いだけだし
だいたいそれしちゃうと、思いっきり全体が暗くなるじゃん。
それでなくてもストレート変換された時点でＴＶよりずいぶん暗くなっているんだから。

>>372
もちろん、0-235に変換したときは全体が暗くならないようにある程度のガンマ補正は必要だろうね。
ちなみにストレート変換では暗くならないよ。上が暗くなる分、下が持ち上げられるから画面全体では明るさは保持されている。
考え方がおかしいって言うけど、これって家電に入っているビデオプロセッサーではかなり常識と思うよ。
PCでは標準化という名の下にあまりにもオリジナリティがなくなってきていると思うなー。

まぁ自分が0-235で良いって言うんだからそれはそれで良いとは思うけど
ここで断言的に書くのはよくないと思うな。
やっぱり基本は16-235なんだからね。
しかも、PCのVGAドライバもコーデックもすべて16-235を基準として設計されているわけで
独自設計された家電を持ち出されても説得力はないと思うよ。

>>374
基本は16-235ってそれってアナログのYPbPrをデジタルにそのまま変換した場合の話ね。
決してそのまま画面に出したら駄目なのは分かっているよね？
PCの画面はデジタルで0-255だから少なくともアナログの16はデジタルの0にしないといけないよ。
問題はアナログの235なんだよね。そのままデジタルの255にすると所謂YC伸張になる。
これだと最近のHDコンテンツが使っている235-255のスーパーホワイトに対応できない。
よって、アナログの16をデジタルの0にしつつ235-255のスーパーホワイトも保持して画面に出力したい。
これが0-235の所以なんだけど、理解できないかな？

だから、何をやりたいのかは理解できていますよ。w
そんなに挑戦的に書かれなくてもね ＾＾；
でもそれはあなたの考え方なんだから、あまり押しつけるのはよくないんでないの？って言っているだけ。
だいたい、YC伸張するドライバではそれしちゃうとダブル伸張になるでしょ？白側は良いとしても黒側が潰れちゃうよね？
YC伸張しない場合で、0-255で記録されていても、コーデックによっては255オーバーも記録できているわけだから
再生時の設定でもスパーホワイトの表示は可能だしね。
それぞれを理解できている人がやるのは別にかまわないけど、それが絶対とは言えないでしょ？環境にもよるでしょってこと。
わかってもらえたかな？

>>375
>>376
話がかみ合ってないだけだろ。
>375は変換そのものに関して話しているみたいだからドライバ伸張の話だろ？
>376はどうもコーデックとドライバーを混ぜくちゃにしているみたいだな。大体、今時はコーデックでは伸張なんかしないよ。コーデックはYUVカラースペースのままだから伸張は関係ない。コーデックがRGB変換するってかなり古い知識だと思うぞ。

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　 　 ,,..､､ri':'ﾞ/~ 　 ﾚ　　 　 '　 ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　 　 　 ＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　 　 '､
/ .） .l::::::::::!　　　　　　　　　　　 　 　 　 　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　 　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　 　 　 　 　 　 ,'
　 ﾞ　 　 ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　 　 ,.r,,iilll鬚髯ｦ 　　　そんなに何も見えてないんじゃ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　
￣￣￣￣￣￣~"''､' ‐ ､ 　 　 　 ー‐ノ 　　　　　生きてても面白くないでしょう
　　　　　　　　 　 　 ',　 ヽ　　　　 　 l
　　　　 　 　 　 　 　 ｌ　　 l　　 　 　 l
　　　　　　　 　 　 　 l　 　 l　　　　 ﾉ

何このマリオ

吉井さんだよ

ＶｉｓｔａＳＰ１＋ＮｖｉｄｉａドライバーでＹＣ伸張してくれるようになったお。

age

>>381
本当だ！試しにSP1の評価版と最新の169.25デトネイタを入れたらYC伸張する！

>>383
ラデオンだとSP1入れても未だYC伸張してくれない。ジーフォースに買い換えないと駄目？ラデオンは負け組みって事？

>>384
現状だとAMDが死に体だからATIは負け組みかもね。。。
今後はIntel vs NVidiaでATIはS3とかMatrox化していく気がする。。。

ここDTV板だろ・・・この期に及んでnVidiaがいいとか、ラデがYC伸張しないとかドンだけでたらめなんだよwwww

>>386
実際、YC伸張にすぐさま対応したのはnVidia、AMDはすでに会社そのものがヤバイだろｗ

>>387
おいおいwwww何言っても良いが嘘はいかんよ、嘘はwwww

>>388
誰も嘘言ってないけどな。。。
会社の時価総額でもAMD(ATIを含め)はnVidiaの数分の一になってるって知ってるか？
NASDAQで過去一年間くらいの株価見てみろ。

>>389
>>388がつついてるのはそこじゃないだろ
＞実際、YC伸張にすぐさま対応したのはnVidia
こっちだろ。どんな認識でこんな大嘘言えるのか俺も思うよ。

>>390
nvのVistaドライバースレで一ヶ月以上前に報告上がってたよ。
確か169.1xとVistaSP1 BetaでYC伸張がされるようになったとか。

俺の知っている限りでは
Radeonは7000番台の時代からYC伸張に対応している。
Gefoeceはドライバの84.21からYC伸張できるようになっている。
しかも動画に関してはつい最近までRadeonが2歩先を行っていた。
（ドライバの100番台に入ってやっとだいぶん追いついてきたようだけどまだまだだね。）
３Dに関しては逆の評価みたいだね。使い物にならんのがラデみたいだ。

( ﾟдﾟ )

>>392
君のは大昔のオーバーレイが全盛だったときの話じゃ。。。
Vistaの話題なんだから非オーバーレイについてに決まっていると思うが？

いまだにオーバーレイしてますが

Gefoeceで動画ってどんだけマゾいんだよｗ

>>396
オーバーレイの時代はかなり微妙だったけど、非オーバーレイのVistaになってからは下手するとATIよりも良いという評価も聞かれるけどな。

すまん便乗で。
XPのオーバーレイ環境下だと今でもnVidiaはいまいちくんなの？

>>394
大昔ってXPのVMR7もオーバーレイミキサ使っているし、だいたいEVRを使っているユーザーが今いくらくらいいるとお思ってるんだ？

>>398
いまいちどころか最悪でないかな
オーバーレイならあのS3の方が綺麗だしww

>>399
お前Vista使ってないのばればれ。
VistaのメディアプレイヤーとかメディアセンターはEVRだし、PowerDVD7もEVRだぞ。
いつまでも食わず嫌いだから遅れるんだよｗ

>>397
それはそうだね。
あとは色空間変換やCRT使いの人向けにDACの性能が良くなれば、
nVIDIAは駄目という声も減ると思うけど。

RADEONはとりあえず"UseBT601CSC"="1"つっこんどきゃY/C伸張するんじゃねーの
Vistaは知らんけど

XPでnvdiaグラうボ使ってる人向けの画質設定晒しとく
94.24で確認したから100以降のドライバは知らん

ffdshowの「レベル」を選択
モードはOriginal
フルレンジにチェック
入力16-235
出力0-255
ガンマ補正オフ
ポスタライズ255

これでまともな色になる

>>402
他スレで散々既出だがVistaにはそのレジストリは存在してないし、同様のNVidiaのやつもXPのみ。

>>403
ffdshowじゃあHD/BDは関係ないからなー。

Vista SP1+ゲフォ最新βドライバーだとPowerDVDなんかもYC伸張するようになるな。
いったいどれが今までバグってたのか、全くプンスカ。

nVIDIAチップ特有の白っぽくてパサパサした色合いがちょっと苦手
ゲームやるぶんにはnVIDIAが良いんだろうけど、ATIの色味に慣れちゃうとなかなか抜け出せないわ
そろそろ買い替え予定なんで、Vista環境も考えてみるか

nvidiaは9000番台の次から動画関連に大幅に手を入れるって言ってる
今うんこなのは当たり前ｗ

Friioを購入していろいろやってみましたので、結果を書いておきます。

ビデオカード：GeForce7600GS 93.71 VMRYC伸張有
OS：WindowsXPSP2
プレーヤー：MPC6.4.9.1
MPEG2デコーダ：MPC内蔵・YV12orYUV2出力

ソース：BT.709のカラーバーSD解像度
オーバーレイ・VMR7・VMR9：すべてBT.601として変換

ソース：BT.709のカラーバーHD解像度
オーバーレイ・VMR7W：BT.601として変換
VMR7R・VMR9W・VMR9R：BT.709として変換

上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
しかしBT.709の登場で面倒なことになりましたね。

余談すがデコーダをffdshowにして出力をRGB32にしてffdshow側でBT.709を指定すればどの解像度でも正しい色になります。

SDに変換する時はColormatrix等でBT.601にする必要があるな。

DVDもBT.601ですので、HDキャプチャしてDVD出力する場合も変換しないとおかしくなりますね。
DVDレコもちゃんと変換しているみたいです。
あとチューナーのコンポーネント出力はBT.709で出していますが、S端子はちゃんとBT.601に変換されていました。

家電って結構キッチリしているんですね、ずぼらなのはPCだけのようです…orz

>>408
>上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
Vista+EVRを使えばDXVA2経由でBT.601とBT.709をドライバーに指示できるみたいよ。

BT.709のカラーバーというものは存在しないんだけど・・・
色域がBT.709になるかBT.601になるかはRGBへマッピングするときに決めるだけ
よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど

>>412
>よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
これはちょっと誤解を生むよ。HD放送の合間のSDは解像度がHDじゃなくてもBT.709になっているのは常識。
アプリがコンテンツの状況に応じてドライバーに変換関数を知らせた方が正確。

私はFriioを持っていないから確認できませんが、日本のSDのデジタル放送のcolorimetryを
DGIndexはきちんとBT.709だと判定できるのだろうか。

SDってBS1,2か？教育も一部時間はSDか。

どっかで見たけど、NHKとかのデジタルSDはmatrix_coefficientが省略されてるみたい。
でもテレビだとBT.709として処理してるようだ。

ttp://www.marumo.ne.jp/db2002_5.htm
＞Digital BS では YUV データは全て ITU-R BT.709 形式で送り出すので、
＞matrix_coefficient が省略されている場合も ITU-R BT.709 が指定されたものとしてデコードするようにと規定されています。
＞HD 放送の場合だけでなく、SD 放送の場合もです。ARIB STD-B32 で確認しました。

DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
なので>>408のSDでmatrix_coefficientが省略されてた場合は、
matrix_coefficientを見てるのか、解像度で判断してるのかわからないな。
matrix_coefficientでBT.709を指定したSDファイルを作ってみれば分かるけど。

BT.601 = BT.470-2(DGIndexの自動判定) = SMPTE 170Mだから、それだったらやはり
ColorMatrix(mode="Rec.709->Rec.601",interlaced=true)とでも書いてBT.601に変換する必要があるな。

よくわからんけど、
CCEやTMPGで709→601にするときはどうすればいいの？
0-255か16-235しかないよ。

>>418
いいよおまいは話に参加しなくても

BT変換とTVスケールへの伸張はどっちを先にやったほうがいいのでしょうか

> DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
dgindex149のソースとかh.262とか読んだ感じ省略時は
mpeg2はRecommendation ITU-R BT.709
mpeg1はRecommendation ITU-R BT.470-2 System B, G
になりそうなんだけど>416はmpeg1の話をしてるの？

>>421
DGMPGDec 1.5.0では変更された。
http://forum.doom9.org/showthread.php?p=1084980#post1084980

へー、そーなんだ知らんかった。ゴメン

ついでに聴くけど
何で素直に2(Unspecified)を返すようにしないの？
はっきり言って紛らわしいと思うのは俺だけ？

DGDecodeの判定を読むColorMatrix(hints=true)の様にして使う事もあるし、その方が良いのだろう。
MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。

大した手間では無いのだから、最初にMPEG-2 Videoをエンコードする時、colorimetryにきちんと
SMPTE 170Mなりを指定していてくれたら良いのにとは常に思うが。

bt.709 and CCE
http://forum.doom9.org/showthread.php?t=131169

> MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
そんなにややこしいなら尚更Unspecifiedを返すべきなんじゃ？
DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい

不明な場合の動作をユーザー指定とかなら俺でもすぐ出来そうなんで
ColorMatrixの方はプラグイン側が対応すれば善いだけかと


まあPrimaries、Transferが違うって時点でMatrixだけ教えてくれてもしょうがないとも思うけど

>DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい

Colorimetry: BT.470-2 B,G*

ソースがUnspecifiedならこういう風に*が付くから、Informationやlogを見たらすぐに分かる。

TSソースで試したら、HDはBT.709になったがSDはBT.470-2 B,G*になった。
色見るとどちらもBT.709なのに、SDでは指定されてないのかな、謎だ。

PALなら5:1.5:1.5ですね。

　

亀だが誰か>>355の内容について教えてください
うちの環境がおかしいのか混乱してきた・・・

YC伸張していない動画(黒16-白235)を再生した時、
Luma rangeを「TV(16-235)」に設定すると黒0-白255で表示される(白が真っ白に見える)
「PC(0-255)」に設定すると白が灰色に見える、16-235より暗い感じだから、
>>355同様、16-235の状態を0-255と仮定して16-235へさらに変換しているように見える

これは表記ミスなのかな？
それともLuma rangeは入力ソースの種類という意味なのだろうか？

>>430
うちもそうなるよ

PC(0-255)ってことはストレート変換、つまり伸張しない。
TVなら黒を16、白を235としてPCスケールに伸張するっていう意味なんだが。
理解の仕方が反対だよ。

ちなみに>>355の最後は間違いでAviutlのプレビューは伸張してるから
たぶんY30-217のファイルを作ってる。

RGB24のソースをAVISynthを使ってカット編集して
YV12変換してx264でエンコードするのと
AVIUtlを編集に使ってRGB24→YUY2→YV12と変換するのでは
やはりAVIUｔｌ経由は劣化してしまいますか？

AviUtl本体にはYV12へ変換する機能は無い。

言葉足らずでした
AVIUtlの拡張x264出力プラグインに、
x264に渡す前にYV12に変換する機能がついてるんです

AviUtlでの編集は正確には
RGB24>YC48(これで編集）>YUY2>YV12
色変換だけ考えたらRGB24>YV12と違いはないので
同じだと思うけどAviUtlはフィルタ精度が12bitだから
劣化の具合で言ったら理論的にはUtlのほうが少ない。
つーても肉眼ではわからんだろ。

カット編集としか書いてないから、違いはないんじゃないか？

どうもありがとう
フィルタはかけないけど、かけた場合はフィルタの精度も重要ですね
回答してくれた人愛します<3

>>432
dgindex150を使用して、PC scaleで出力してエンコーダに渡せばストレート変換？
YV12ソース＞dgindex（PCscale）＞エンコーダ(YV12)出力
これで良いのでしょうか？

>>439
avisynth経由の話ならdgindexの設定は関係ない
その設定は使われないので意識する必要なし

dgindex のPC/TVscaleの設定はVFW経由の場合にのみ有効って認識でいい
たぶん。

今まで9600GT使っててHD 4850に交換したんだけど、RADEONってYC伸張しないんだな
WMV9でYC伸張でエンコした動画ずっと見てたからなんか変な感じ
OSはVistaSP1

>>442が今時まれに見る情報弱者だということは理解した

>>442
ATI HD Registry Tweaks

ビデオカードにYC伸張やらせるなんてアホらしい
動画側にやらせるべき

それだとTVに写すとき困るし〜！

>>445
データはストレート保存で再生時に伸張。これ常識。

>>445
DVDは伸張されてないんですが、それもアホらしんですね
もう何もPCでは見られませんね
伸張して保存するなんていつの時代の話だよ
変な流れを最初に作った諸悪の根源はnVIDIAなんだけどな

>>447氏も言ってるように再生時に伸張するのが常識です
なので動画保存時はストレート保存、伸張保存してたらﾌﾟｷﾞｬｰされるぞ

Haali's Video Rendererはとても優秀

NPC内臓のHaali使うと引き伸ばしの画像がおかしくなる。
おかしいというよりはリサイズが糞っぽい。
リサイズはffdshowに任せたほうがよさげ

NPCってなんれすか？

少し質問です。
まるも氏のm2vプラグインでストレート変換読み込みした場合と
DGIndexでPCスケールで読み込みをした場合に色合いがほぼ同じになります。

色々な記述を読む限りまるも氏のプラグイン設定でストレート変換を指定した場合
伸張しないと解釈しているのですが、なぜDGIndexのPCスケールと同じ色合いに
なるのか疑問で仕方ありません。
普通PCスケールじゃなくTVスケールと似た色合いになるんじゃ…。
それともDGの方がTV指定時にダウンスケールしてるだけのことですか？

VFAPIがややこしいのなら、DGDecode_mpeg2sourceでd2vを開けば、YV12のまま伸張も何もしない。

>>452
そもそもまるも氏のストレートとそうでないのとで色ちゃんと変わってる？
話を聞く限りまるも氏のプラグインでRGB展開してない気がするが

>>452
aviutlの仕様です

m2v.auiはYUY2読み込み
readme読め

超初心者なのですが、伸張するっていうのは0-255なのか16-235のどっちなんでしょうか？
0-255の方が範囲が広いのでこっちにしたいのですが、伸張されるっていうのがどっちなのかわからなくて・・・
ちなみにここの話題とは全然違ってPS3をつないだモニタの設定でどっちにしたらいいのか迷っているからなんで・・・・

16-235としてPCスケールに伸張(0-255)
上に何度も書いてあるけど「伸張保存はするな」
って言っても色空間から理解する必要があるからなあ・・・
伸張云々よりも先にそこから勉強したほうがいいよ

その前に8bit=255から理解する必要があるのでは？
そして次はYUVを勉強してBT.601を勉強してそれに今時はスーパーホワイト領域の事も考慮して・・・etc
最後は論文かけるようになるかもねw

エンコ時に伸張するほうが精度が高いって知ってた？

>>460
マジで？
エンコ時なら8bit演算でしか伸張できないけど。
ちゃんとディザリングとかかけたりしてくれるソフト有るの？

再生時なら今の世代だとRadeonもGeForceも10bit演算で伸張するし、
Radeonはちゃんとディザリングかけてから8bitに出力してくれるんだけど。
最新のRadeonHD4だと10bit対応モニタの場合そのまま10bitで出力してくれるし。

ホントにエンコ時に伸張する方が精度高いの？

>>460
どっちにしても大多数のコンテンツがストレート保存だから再生時に伸張するのがデファクトスタンダードである事に変わりない。
もはや精度がうんぬんという話は全く意味もないことだな。

昨今（と言っても相当昔から）の動画コーデックは、YUVも含めた上での圧縮。
エンコード時に伸張してやること自体がナンセンス。

伸張も圧縮もせず元のYUVをYUVのまま置いとくのが一番でしょ。

初心者でもしスレ違いだったらすみませんが、詳しい方教えて下さい。

DVDレコーダーと液晶テレビをHDMI接続し、解像度自動設定で強制的にHDで見ている状態です。
この場合に、SDソースのアナログ放送やDVDディスクはDVDレコーダー側でHDにアップコンバートされて出力されていますが、色空間の取扱はどうなっているのでしょうか。

うちはRD-S300だけどアナログでキャプチャしたカラーバーをHDMIでD3出力させてみたら
ちゃんとSMPTE 170M->BT.709変換が入ってるぽい。
どのメーカーにも信者はいるだろうからそういう変換が入ってなければ真っ先に苦情飛ぶだろうし
そんな初歩的な規格しらない開発者もいないだろうから問題ないんじゃね

465です。
>>466
早速のレス有難うございました。
うちもRDやスゴ録を某有名メーカーの液晶に接続していて、D1・D2とD3・D4で色が違うのが気になっていました。
レコーダーか液晶かどちらの問題か分からなくて困っていましたが、RD側でちゃんと変換しているとすると液晶側の問題のようですね。
でもそこまで変換するのであれば、やはりアップコンバートはテレビ側でした方が良いでしょうし、HDMI解像度自動設定もSDソースはSDのまま出力してくれないものでしょうかね。

>>467
液晶って家電のほうだよな？
家電でそういうミスはあんまり考えられない気もするんだけど･･･
うーむ、どうなんだろう。

>>468
勿論某超一流家電メーカーの液晶テレビで昨年のモデルです。
お騒がせしましたが、このメーカーのテレビ独特の問題がありそうです。
今気付きましたが、テレビのオンスクリーン表示も、解像度によって色か明るさか良く分かりませんが変ってしまうようです。
そういえばこの機種は、液晶のダイナミックコントラスト機能が強すぎて、明るさを調整しようとして画質調整のメニューを出すと、それに引っ張られてバックライトが変化してしまい、まともに調整できないという酷い仕様です。
どうもユーザーが触れないおせっかいな自動補正がありそうです。

元に居たにいたスレで話していましたがスレ違なのでこちらに来ました。
DGIndexをTVスケールでVFAPI経由読み込みした際にYUVデータを維持したまま
読み込んだ画像に比べて色がかなり薄くなり疑問に思いました。
以下の画像を参照して下さい。

■比較画像
http://www1.axfc.net/uploader/He/so/147533
■ヒストグラム
http://www1.axfc.net/uploader/He/so/147541
パスは両方ともyazawa

この比較からするとDGIndexではTVスケールを選択すると実際のトコロ
0-255を16-235に圧縮してるのではないかと思います。
なのでエンコに使う場合はPCスケールが正解なのかなぁと。

普段はm2v.aufの元のYUVを維持でエンコしてるのですが、どうしても気になって…

YCbCrはTVスケール、RGBはPCスケールにするのが普通のやり方。

だから、訳が分からないのなら、途中で変換が入るAviUtl等使わず、
変換の入らないAviSynthでx264に渡せば何も考える必要がない。

d2vファイルをAviUtlで編集する場合、avsから読み込めば問題無しで
VFAPIを用いる場合はPCスケールにすればOKということ？？

その場合二重伸張とかにはならない？

1. DGIndexでd2vを作って、それを入力にavsを作る。
2. "x264.exe" --crf 20.0 --output "output.mp4" "input.avs"

x264がYV12入力だからavsから直接やれば無問題ってことは解っていて
とても有りがたい返答ではあるのですが現在知りたいのは
DGIndexとAviUtlを用いた際の色の扱い方なので…。

一般的にYUV維持して読み込むか、TVスケールでVFAPI経由というのが良いという
ことになってますが、VFAPIでTVスケール使うと色縮んでるじゃん。なんで？
っていう所が疑問のスタートなんです。
いや、ホント説明とか出来ないバカですみません。

DGVfapi.vfpの色空間はRGB24で、RGBは一般的にPCスケールである事を前提として扱われる。

詳しい説明はDGVfapi.txtを読め。

あーなるほど。
漸く理解できました、本当ありがとう！

>>474
こっちに移ってたか。
キミがあげた比較画像だが、m2v.aufの伸張有りってのは
フィルタかなんかでさらにPCスケール変換してるっていう意味かね？
そういうことにしとくけど簡単に言うと

DGIndex(VFAPI)
PC Scale: Y: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換
TV Scale: YUV画像をそのままRGB: 0-255に変換

Aviutl
ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
ソースがRGB: プレビューはそのまま、出力はRGB: 0-255をY: 16-235, UV: 16-255に変換
AviutlでのYUV->RGB変換: DGIndexでいうPC Scaleとおなじ

これでわからんのならもうちょっと色空間勉強したほうがいいと思う。

おそかったorz

ご…ごめんなさい…。

YV12とRGBの変換は、TV/PCスケールに加えて、BT.601/BT.709、
インターレース/プログレッシブをきちんと把握しないと、変な色になるからとても面倒くさい。

やはりソースがYV12なら、YV12のままでエンコーダに直接渡すのがベスト。

俺みたないなお馬鹿はVFAPI経由させるなってことか

動画を扱うこと自体をやめるべきでは

自分で楽しむだけならいいんじゃね。

>>477
>ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
出力は変換なしってどういうことですか？
プレビュー（編集時）は伸張しているが、実際の出力は伸張していないという認識でいいのでしょうか？

まず477は間違い。初心者を陥れる罠。

伸張が関係するのは、YUV<->RGB変換になる場合だけ。
AviUtlは常にY16-235,UV16-240をRGB0,0,0-255,255,255として扱う。

まずソースがYUY2で展開される場合。
プレビューは、表示→オーバーレイ表示がoffならRGBで表示する。(WindowsGDIの仕様)
無圧縮(RGB)出力やコーデックにRGBで渡す時はプレビューと同じ変換でRGBにしてから出力される。
YUY2出力やコーデックにYUY2で渡す時は(フィルタで弄らない限り)ソースのスケールのまま。

実際は内部形式をはさむ変換なんだけど、16-235->0-255みたいにダイナミックレンジがつぶれたり
0-255->16-235みたいに諧調が失われたりする事の無い内部形式だから気にする必要はない。

AviutlのプレビューはBT.601だから、
デジタル放送だと色がおかしくなるので注意ね

かといってプレビューで正しく見えるように変換しちゃうと、
今度は出力されたファイルがおかしくなるので更に注意

HD->SDのエンコードにはBT.709->BT.601の変換が必須だけど、
UtlにはSynthのColorMatrixに相当するプラグインはあるの?

ttp://www.geocities.jp/aji_0/
あじさんとこの色域変換プラグインがそうじゃないかな

どうもありがとう。

詳しい説明をありがとうございます。

まだ混乱しているのですが、下のように理解しました。

ソースをYUY2で読み込んだ場合（YUVで取り扱う）の表示は、AviUtlの内部形式に変換する際16-235->0-255のように変換する為
プレビューは一見ストレートではなく、伸張(16-235->0-255の内部形式への変換)されたように見える。
　これをYUY2（YUV)としてそのまま出力すると内部形式は0-255->16-235として処理され、読み込んだときのスケールは保持（伸張されない）される。
しかし、これをRGB出力（VFAPIなど、プロファイルを渡す)した場合、内部形式16-235->0-255がRGBへの変換に適用されYUV->RGBの際に伸張された動画となる。

つまり、Aviutlで元のYUVデータを保持し、伸張は再生側にまかせた動画を作成する場合
rec.709やbt.601の変換を抜きにすれば、YUY2で動画を読み込み、フィルタなどはいじらずYUVでそのまま出力すればいいということでしょうか？

ROMってた初心者なんですが、検索して調べても混乱が増すばかり・・・

動画ファイルがTVorPCスケールか調べたくて
Aviutl0.99fで波形表示プラグインを使ってみたんですが
ソースがYUY2orRGBの展開の違いで波形表示が変わるのでしょうか？

自分のPC環境がVGAでYC伸張がされてるかも怪しくなってきて・・・
混乱しまくりで変な質問すいません。

>>490
utlのプレビューと出力は分けて考えたほうがいい。
utlの内部仕様はあまり公開されてないから想像だけど多分こんな感じになってる
ソース(YUY2/RGB) ─ コーデック設定によるYUY2/RGB変換 ─ 内部形式(YC48変換) ─
　　　─ フィルタ処理(YC48) ┬ 出力形式(YUY2/RGB変換) ─ コーデックへ
　　　　　 　 　 　 　 　 　 　 　 ├ (非ｵｰﾊﾞｰﾚｲ時)utlによるRGB変換 ─ GDI(ディスプレイ)へ
　　　　　 　 　 　 　 　 　 　 　 └ (ｵｰﾊﾞｰﾚｲ時)YUY2変換してOSに渡す ─ VGAによるRGB変換 ─ ディスプレイへ

YUY2/RGB -> YC48変換では伸張処理などなく、完全な無劣化変換。
コーデック設定によるYUY2/RGB変換っていうのは環境設定＞コーデックの設定のところで
YUY2で展開するっていうチェックのON/OFFのことね。OFFだとRGB変換が入る。
ソースがYUY2でかつRGBに変換するときだけYC伸張処理がされ、
ソースがRGBでかつYUY2に変換するときだけYC圧縮処理される。
VGAによるRGB変換は再生時と同じで環境依存。色伸張したりHDのとき自動でBT.709->BT.601変換が入ったりする。
文章下手で申し訳ない。ついでに間違ってる可能性も大いにあるので話半分で読んでくれ。

>>491
同じソースに対して展開方法を変えれば当然データ(波形)も変わるよ。YUV<->RGB変換は基本的にロッシー(劣化する)
ものだから色空間の変換は最小限にするべき。VGAがどういう動作をしているかはオーバーレイ表示にすればわかる。
非オーバーレイと同じになれば伸張してるしHD動画のときさらに色が変わればBT.709->BT.601変換も入ってる。
ただ実際動画をプレイヤーで再生するとき非オーバーレイモードであればまた環境によって違うからその辺気をつけて。

おや、Makki氏降臨？

>>492
レスありがとう。用事があってチェックが遅れてしまった。
非オーバーレイってことはMPCだとVMR9とかかな・・・

>>491のことですが
動画ファイルのスケールを知りたくて(PCかTVスケールかを)
波形表示のYgainとoffsetを見れば分からないのかなーと思ったんですが
AviUtlのプレビューがYUY2orRGBの展開の違いで
変化してしまうのではと混乱してしまって・・・
（例えば、展開でTVスケールがPCスケールへ変化することがあるかどうか）
うまく表現できなくてすいません・・・orz

逆に動画がPCスケールかTVスケールかを
調べるいい方法ってあるのでしょうか・・・慣れれば感覚で分かると思うのですが

＞展開でTVスケールがPCスケールへ変化することがあるかどうか
スケール自体はかわらんだろ

スケールだけの確認ならヒストグラムでYCbCr表示させて明暗のはっきりしてるシーン見れば
一瞬でわかる。縦の薄い線がTVスケールだから。かといってTVスケールでも若干
はみ出してることもなくはないけどな。

レスサンクス。
色空間は展開で要注意って認識でいいのかな。
いろいろごちゃごちゃしてしまって整理できず混乱してた。
ほんとありがとう。

自分はこれを使って確かめている。
http://www.avisynth.info/?Histogram

例:
ColorBars(960,720).KillAudio
ConvertToYV12(matrix="rec709")
Histogram("levels")
Info
ConvertToRGB24(matrix="rec709")

http://img380.imageshack.us/img380/2761/colorbarsjm5.png

今までヒストグラムはRGB表示してた・・・
というかRGなんてこった。

>>

ミスってしもたorz
今までヒストグラムはRGB表示してた・・・
というかYCbCr表示できたんだね、なんてこった。

>>497
うあ、コレも知らなかったよ。例まで張ってくれてアリガト！

今VMR9で伸張出来るのと出来ないのどっちの環境が多いんだろ

去年の5月頃の議論(>>232から)の中で
「最近は235以上のデータを使っているソースがちらほらあって困る」っていうのがあって、
結局グラボ側でオートゲイン的な処理をしてくれるのがいいんじゃね？
っていう意見があったけど
Radeonの4xxxシリーズに搭載されているダイナミックコントラストって機能がまさにこれだね。
結構複雑な演算を必要としているためGPGPUの機能を使っているらしく、
この機能をオンにするとRadeonのActivityが20%程増加する。

もう色がおかしかったことがばれちゃってるのに
まだRADEONの色が正しい色と盲信してんのか。
しかもUVD2のダイナミックコントラストは
マッハバンドが出る低画質フィルタｗ

カノープスの動画編集ワークステーションに
Nvidia製Quadroが使われてる現実をみろよ。


世論誘導のお仕事なんだろうけど、まるで三亀ボクシングだなｗ
工作すればするほど、なぜかスポンサーが追い詰められるあれ

つまり、プロだな
プロには、人と金は集まるモノ

いい加減に現実をみろよ、ビデオ編集ワークステーションはNVIDIA
http://www.thomson-canopus.jp/catalog/rexceed/rexceed_m500v_index.php

プロはNVIDIA
http://www.thomson-canopus.jp/catalog/rexceed/rexceed_m500v_s.htm

カノープスの技術者は才能あるからね。

そんな1企業の採用事例だけ示されてもな。
俺はどちらかに傾倒しているつもりはないが>>502>>504のほうがよっぽどnVIDIA信者に見える

Macは全部Geforceだし。

>>505
オレにもそう見える。
nVIDIAなら全ておk!! みたいな過度の依存スタンスが、己の目を曇らせ、自らの審美眼を閉ざす

>>506
さらっと嘘つくなよ。

最近あちこちで必死な書き込みよく見るし、NVIDIAも大変なんだな。

PCゲーがコピー多すぎて下火になってコンシューマに以降してるからな。
これからは動画再生に強くないと一般のPCに積む意味が無くなるし。

だが動画再生についてはPS3が断トツな状況。

消費電力ありえないから

Vistaから搭載されてるEVRを使ってセカンダリモニタで
再生させているけど、色変換がされないのは仕様？

>>513
色変換されなかったらテンでめちゃめちゃに見えると思うけど。
俺はGeForceだけどセカンダリモニタでメディアプレイヤー(EVRを使う)で再生しても問題なし。

>>514
色変換がされていないというより、無駄に明るくなってる感じ

MPC homecinemaだとEVR Custom Presで正しい色で表示できた
ただWMPでは相変わらずです

考えたらスレ違いじゃんorz

テスト

質問なんですが
DVD→DGindex→AVS（DGDecode）で24fps化→AviutlでCanopusDVコーデックに変換。
この手順だと余計なスケール変換を起こさずにストレート変換になっているのでしょうか。

AVSにConvertToYUY2を入れてあれば色空間の変換による劣化はないが

DGDecode_mpeg2source("DVD.d2v")
ConvertToYUY2(interlaced=true)
IT(fps = 24, ref = "TOP", diMode = 0)

こんな順番で並べてますが大丈夫でしょうか？

ffdshowでYC伸張
http://replaymugen.seesaa.net/article/108512661.html

>>517
AviUtlの入力プラグインがAviSynth Script File Readerとかならいいんじゃないか
DGMpgDec とかもAVS読み込みできるがVFAPI経由でRGBに変換されてるから注意な

最近エンコやりはじめたが、色空間難しいぜ。ちくしょう。

>>521
AviSynth Script File Readerを入れてなかったです。
これでようやくすっきりしました。

みなさまどうもありがとう。

実際にエンコしてみたら今までに比べてかなり満足のいくものができた。

重ね重ねありがとう。

YUY2で処理したBT.709のﾌｧｲﾙをavisyunthでConvertToYV12する場合
ConvertToYV12()じゃ駄目？

ConvertToYV12するんだからConvertToYV12()するんだろ？

判りづらくてすんまそん、ConvertToYV12(matrix="")で色空間指定しないと
bt601に変換されちゃうのかな？って事です。

YUY2→YV12なら関係ない。

BT.601やらBT.709ってのはYUV>RGB変換式の違いなだけでデータの並びとかの
差異はない。だから少なくともYUV色空間内でそのような変換は起こりえない。

なる程RGB変換を挟まない場合は気にしなくていいんですね、
ありがとうございます。

SD放送のTSもHDと同じくBT.709らしいけど、レコで出力したのをPV4でキャプった場合はどうなってるんだろうか。
レコがBT.601に変換したりしてるんだろうか。

レコによるんだろうが、
D1、D2出力するときはBT.601で
D3、D4出力するときはBT.709で
出力されるのが一般的だと思うが・・

そーなのかー�d

あと170M と601の違いがよくわからん。
ググったら同じものって書いてあるのが多いけど色域変換プラグインで170Mと601は全然色が違う。
SD放送のTSはどっちを指定すればいいの？

3原色のパラメータの違いだって色域変換のテキストに書いてあるじゃん

調べれば調べるほどわけわかめになってきた…
m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
されないならこの指定は何のためにあるのか？
元の YUV データを維持にして読み込んで色域変換で3原色を601にするのが正解？
AvisynthならColorMatrixでmode="Rec.709->Rec.601"？

日本のデジタル放送はどれもBT.709と言うことになっているから、HDならそのままで、
SDでエンコードする場合は、ColorMatrix(mode="Rec.709->Rec.601", interlaced=true) としておけば良い。
放送のMPEG-2 MPはYV12(YCbCr 4:2:0)だから、interlacedの指定は必要。

x264に　--colormatrix bt709(smpte170m)を付けておけば、デコードで間違える事もなくなる。

私はAviUtlを使わないので、それについてはコメントできない。

>>535
＞m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
そのくらい自分で試したらわかるだろ常考

普通のレコーダーならSDのTSだろうがアナログだろうがD1・D2ならBT.601に、D3・D4ならBT.709で出力される。
深夜にチャンネル片端から調べたらテストパターンいくらでも見つかるんだからHD、SD、地アナそれぞれ
録画して調べたらわかる。

じゃあ強引にBT709で作った規格外DVDはどうなるの？
(出来るのか？意味あるのか？というのは置いといて。)

>>538
おまえは何言ってるんだ？YUVデータにbt.709もbt.601もないだろがww

mp4の動画をffdshowで再生した時にオンスクリーンディスプレイで色空間を見たら
YV12,adjとなっていた。YV12は分かるとしてadjって何？

あじゃすとじゃね

>>520
ちょっと微妙だな。せめて、ディスプレイの色温度ぐらい考慮しろよ・・・
白を基準に判別するなら。

>>538
ないのじゃなくてどちらの色空間で記録されてるかはあるだろ。
むしろBT.601の色空間で強引に記録したHD放送が欲しい位。
HDがBT.709で記録されたら最後、撮影時の彩度の高い赤も
エメラルドグリーンもxvYCCを使わない限り切り捨てられる点を何故誰も
騒がない？
現時点でDVDの方がBDより色域は広い。特に赤と緑は。
BT.709をBT601にmatrix変換？したら似非色表示で意味がなくなる。
YC伸張や色温度の話も良いが、色空間というなら限りなく狭いHDTVの
色空間を元に広げるハリウッドリマスター機能をフィルターにつけるべき。
そうでないとPC再生は今後絶望的では？

んなキモい変換を前提にしたら互換性もなにもないし
素直に未使用領域使うxvYCCで収録しろ。未対応ならクリップされるから大丈夫だろ。
狭い空間の色を勝手に広帯域の範囲にまで拡張するのはカラーマネージメントを無視してるし
どの環境でもそれなりの色再現性があってこそだろ。
エメラルドグリーンを再現したければそれなりの色空間で近似色に変換させろ
RGBで再現不可能な領域は不可能のままで良い。

>>544
同意。

否定してもいいが、それなりの色空間なんてないから既に手遅れだよ。
xvYCC非対応のほとんど全てのBDやHD放送の存在は放置しろって言ってる
ことになる。クリップしてるからHD放送の色が酷いことに気づいていないの？

HD規格でエメラルドグリーンの海と真っ赤な花は表示不可能なんだよ。
既に表示できているように見える全TVメーカーは未公表で類推アルゴリズムを
入れて疑似色拡張して表示している訳。BT.609（sRGB)色域忠実再生じゃ一目
で他社に見劣りして誰も買ってくれないからね？SONYはちょっとやり過ぎだけど。
忠実にこだわってPCモニタでのHD再生だけ既に取り残されてる訳。
必ずxvYCC対応色拡張変換アルゴリズム込みのフィルターはでてくるだろうけど・・・。

色域ばっかり気にしているけど、まずは4:2:0から4:4:4の規格拡張が重要だろうな。

あとxvYCC対応色拡張変換アルゴリズムはないけど、色補正は今だってあるよ。
ワイドモードとかね。

SDTV/DVDもNTSC比70%程度しかない罠。
色域が広いNTSC(ITU-R BT.470-6 System Mになってる)は、今のSDTV/DVDの色じゃないよ。
SDTV(SMPTE-170M)もHDTV(SMPTE-240M)も色自体はSMPTE-Cで共通。
(1970年代には今の色)

ITU-T H.264 の仕様書が、各パラメーター(色,伝送,マトリクス)の違いが一覧になってて分かりやすい。
全体は英文で300ページ以上あるけど、色空間関係なら数ページで足りるので目を通すといいよ。

とりあえず、パナのハリウッドカラーリマスターとハリウッドクリアカラー
の相乗効果はすごいと思ったよ。

店頭で見た限りだけど。

>>548
まずはありがとう。ITU、有料だよね〜　日本語版JT-H264でもいいでしょ？
http://4megaupload.comって安そうだけど安全かしらん？
trial　5$　3日間で他のITUも落としまくるのがいいかしらん？

ITU-T H.264 最新の仕様書(2007-11月版)は全564ページだった。
pdf内を709で検索して出てくるのが殆ど該当箇所なのは一緒。

>>550
ITU-Rは有料(年3冊まで無料)で、ITU-TのPDFは無料だよ。
この手の文書は翻訳で駄目になる事も多いから、英文が殆ど読めない人が使う場合でも
英文資料の方がマシ。
今回は参考用に付いてくる一覧表が目当てだから、大丈夫だろうけど。

>>551
重ねゞゝ　ありがとう。　英文資料は問題ないです。手にしました。
なるほど翻訳で駄目になる・・・（笑）
PCモニタ表示域はNTSC(1953)比で書かれるし、NTSC（1953)とばかり思っていた。
これ見るとSMPTE-240Mは（1999）だし170Mは（2004）、どんどんアップデートされるとはいえ、
1970年代にこの色域に変更とは恐れ入るね。TVってめちゃくちゃ表示だったってことか？
と記憶をたぐり寄せて不思議な気がしてしまうのでした。

おっと、もう１点いや２点不思議
・標準CからD65光源って、1970年代にそれはないでしょ？変わった？
・xvYCCって自然界の網羅率は良い筈だけど、xy色度値が中途半端だね？
　現SMPTE-C？とやらと上位互換性とった筈じゃなかったっけ？

sRGB、AdobeRGB、x.v.colorのそれぞれの表現可能な色数をご存知の方
がいたら教えてくださいな。

色数じゃなくて表色域だろ。CIExyとかでググれば見つかるんじゃねーの

色域は分かるよ。

写真とか放送のキャプ取った時に色数も調べるけど
10万色とか5万とか色々ある。

で規格自体はどの程度まで表現可能とか思ったわけ。

色域であって分解能の規定はないのいづれも無限色を表現できるよ。

>>557
その理屈だと、規格を分ける必要なくね？
無限色を表現できるなら。

1から10までの間に数字はいくつありますか。
3から15までの間に数字はいくつありますか。
いづれも無限にあるだろう。

いやそれ有限・・・

では1から10までの間の数がいくつか答えてください
分解能の規定はありません

>560
整数は有限だけど、小数まで含めたらって話。

>>554
sRGB、AdobeRGBの理論上の色数はどちらも8bit^3
x.v.colorにおいては8bit以上が認められているのではっきりした数字は出ない

同じ色数だから必要ないというような馬鹿な返しはしないでね　＾＾；

PNGとかTIFFは16bit/chも使えるな

ID:irGSnl3X
ID:mPOA3JVd

何言っているんだこの馬鹿は。

>>563
説明できないなら勉強してこい。無知は。

>>554
sRGB、AdobeRGB、x.v.colorもそれぞれ8bitパネルでも対応できることから
1677万色の中で既定されている規格だと推測できる。

1677万色の範囲で色の範囲の幅が広いか狭いかだけ。
1677万色と言うのは赤・緑・青の３色を組み合わせて作り出せる色の数のこと。

勝手に変な解釈しないでください

スレが進んでると思ったら荒らしか・・・

分解能の説明でも納得せず
色域の話も納得せず
規格上の分解能含めても納得せず


放置しろ予w

お馬鹿なのに変に難しい話に首突っ込むなって感じだね

まあ、予備知識のない人には勘違いしやすいからね。
連投してファビョちゃったのはちょっとみっともないけどｗ

色数は、RGB16〜235だから219階調を３乗すればいい。

あとは、EBU 100%（NTSC 72％）≒sRGB、ITU-R BT.709＝sRGBだから
その法則にしたがって、割合を求めればいいだけ。

揚げ足とりだが、16と235も含むから220階調な。

sRGBは0-255だろ

また、バカが沸いてきた。調べもせずにに毎回よく恥じかけるよ。

自分が理解できないからひがんでいるとしか思えないぞw
つか、荒らし系の話題にはやっぱこんな馬鹿がよってくるんだから無視するに限るね

釣りか真性かよく分からんバカがいるな。扱いに困る＾＾

色空間wikiの一般的な色空間の所にRGBの項目があるってなんか変に感じる
コンピュータにおける表色系、と言った方があってる気がするんだが・・・
sRGBとかは色空間でいいんだろうけど・・・

>>574
お勉強してこい。面倒みきれん。

>>579
馬鹿は自分の面倒見ていろよ、別に頼んでないからw

何億色表現可能というTVの誇大宣伝について色彩学会に問い合わせた。答えは、
いたずらに色数がいくつあるかという議論は混乱を招くだけであり、
もはや研究対象にすらなっていない。と。
色相/彩度より輝度差に敏感な眼は同時256階調未満の識別しかできないが、暗視野での256階調とは
輝度値が異なるため、あらゆる環境照度での識別可能な輝度値となると確かに無限に増える。
しかし実際は見ている人に同じ印象の色に見えるものは一緒と考えれば
結局最初のRGBで256階調分、YUVで220階調分でも十分と言うのが定説。

その上でB〜BR〜Rは元々高彩度の最高輝度が低い色群
　　　　　　BG〜G〜Yは元々高彩度の最低輝度が高い色群で
　　　　　　最大256階調が必要なのは実は白〜黒無彩色グラデーションだったりする。　　　　　　
その結果、一般に十分明るい照度下で眼の良い人が見分けられる色数の限界は
1000万色（〜1500万色）と言われ、この500万色もある幅が最早、色数を数え上げることに
実用上意味がないことを示している。

実用上の色分布なら最近ならSOCS（約5万色）データベースを参照する方が建設的。

sRGBの色域なら8bitで十分だろうけどそれより広げると
8bitではトーンジャンプおこすからって10bitやら16bit採用している例が増えてきているよね
scRGBも16bitじゃなかったっけ？

ID変えている奴バレバレだな。これ以上まだ恥かくのか？ｗ
ネットで一生懸命探して間違いを2chで公表しなくていいから専門書を一つでも読みなさい（笑）

ちょっとググレば出て来るのにな。
なに的外れな勘違いしているのか。

馬鹿に生まれなくて本当によかった（笑）

トーンジャンプは色空間の変換や色調補正とかで最も起こりやすいから
その処理を10bitや12bitで処理するものは多いね。そういう部分を丁寧に行って
ディザリングを施して8bitに丸めればまず違和感は起こらんと思う。

人間の目は明るさにもっとも敏感で暗いと色の判別が困難になるし
もともと青の色覚が弱いからYUVってかなり合理的な色空間なんだよな。
赤は比較的敏感だからYUV420とかで劣化が目立つのが玉に瑕だけど

>>ID:ss1HR4fU
まぁ連投するやつにろくなのがいないのだが
ついでに俺にも説明してくれまいか
いつからsRGBの量子化の実行範囲が16-235になったんだ？
まさかsYCCと混同しているのか？

スレ違いとは思いますが、瞬間湯沸し器的に沸騰してしまい、つい書き込みしてしまいました。お許しください。
普段は決して沸点が低い物質ではないのです。わたしという人間は。
今更エンコードに興味を持ち、あちらこちらの先輩方のサイトを拝見させていただいておりました。

　なぜ、赤が観辛いか。
　mpg系圧縮は赤が強めにでて、既に赤っぽい場合が多い。それが赤いと、しつこく感じる。
　目が青い外人は、少し赤いほうが綺麗に観れるらしい(謎
　外人の家の明かりが、総じて暖色系なのは、そのためかも知れませんね。
　そんなワケで、しつこいから少しだけ赤を抑えてみる。(0)
　ちなみに、緑減らすと赤くなるのも覚えておこう。
　
　逆に、日本人のは青い色が綺麗に見える。蛍光灯とか少し青い方が、明るく見えるのは、そのため。
　∴すこしだけ青が強い方が、日本人には締まって見える。(1)

地デジの赤色がやけにどぎつく、滲んで見えるのはmpg2の仕様か！
千と千尋のＤＶＤが赤色っぽいのは海外販売に合わせたためか！
所詮白人の作った規格、利益の大きい海外市場戦略に合わせる必要性。
日本人にとって理不尽であろうとも、我慢や無駄な努力をしなければいけないのですな。
ふぅ、駄文失礼しました。

地デジでは当てはまりませんが従来のNTSCはもともとその伝送構造的に周波数の低い赤が苦手です
また、mpeg系の量子化形式も元々NTSCに従っているのでやはり赤の再現性は苦手なのが原因です

人間の色彩に対しての感度は人種により大きく異なることも事実ですが
（もともと人類の目は緑に対して感度が高いですが、アフリカ系の人は緑に対して異様に感度が高いとかetc）
同じ人種でも個人差もでかいですし、同じ個人でも年齢によって大きく異なってきます
一般的に年をとるにつれて周波数の高い色（濃いブルーなど）は非常に見えにくくなってきます
ただ、人間は脳内で色彩情報を補正して認識しているので目の機械的感度での論議は無意味とも言えます

また、目の色の差違で感度が違うとか、日本人が色温度が高いのを好むというのはオカルトです

糞スレになったな

>>589
お前がいるからな

>>578
こんなところで愚痴らないで、ノートページに書くか、
自分で直接書き換えろ。

まだ調べきれてなかったのか・・・せっかく宿題にしたのに。
やっぱり、ダメな子だな。

http://www.sony.co.jp/SonyInfo/technology/technology/theme/xvycc_01.html

>輝度、色度信号値の量子化において8ビットのとき、1から15と241から254も映像信号として使用して、
>定義式を定め広色域化を図る。また8ビット以上も定義して高階調化にも対応している。

ヒントというかもうこれは正解を教えてやったのと同じだな。俺もバカに優しすぎる。

おい>>586 >>574分かったか？頭悪い子には時間を置いて考えるくせをつけてやらないとな。

で、どこにsRGBが16-235だと書いてあるんだ？sRGBとBT.709がどっちも16-235だと思っちゃってるの？

>>594
例によってDQNはいつまでたってもDQNって事だろw
たしかにこういった技術系の板で>>594のようなやつがわいてくると困るよね
無視するに限るが無視すれば嘘八百書き込んだのが訂正されずにログに残るからねぇ

>>592 >>593 >>595
エイプリルフールは終わったぞ、さっさと訂正しろよな
sRGBの量子化は1ピクセルあたり24bitは常識中の常識だろ
どうやったら16-235みたいな中途半端な数字が出てくるんだよ宿題にしてやるから後で提出しろ

>>594 >>596みたいな素人がここにもいるとはね。春休みか。
とりあえず、ここは初心者スレじゃないので質問は他でやれ。

>>597
アホか？素人過ぎるのはおまえだろww
RGB各色の先頭2bitがヘッダとして使われているから実行6bitだとかの理由なら形式によってはあり得るかもしれんが
10進表記した上で16-235がどうとかって・・・あまりにも無知すぎる
これ以降反論があるならちゃんとそれなりの反論をしてくれよな・・・お馬鹿さん

連投ですまん

>>957
で、どこに>>952のHPにsRGBの量子化についての説明があるんだ？
おまえが示した箇所はYUVのスーパーホワイトとスーパーブラックの領域についての言及だけなんだが
ちょっと病院に行った方が良いかと思うぞwww

なぁ素人の俺様にもどっちが正しいかわかるように
まともな事書いてる奴は丁寧に煽らず
DQNはwとか連発していかにも低脳そうに書いてクレよ。
いまはどっちもアホにしか見えなくて困る。

BT.709
・Quantization levels
Black level　16
Nominal peak　235

・Quantization level assignment
Video data　1 through 254
Timing references　0 and 255

黒レベル16　白　235
データ範囲　1-254　0と255は同期信号
これだけしか規定されていない

1-15と235-254の扱いはご自由にどうぞ
表現できるならやってもいいんじゃないってレベルだな

×235-254
○236-254

>>600
sRGBが16-235と煽っている方がNG
そもそもYUV表記でもないのに16-235と言う数字が出るのもおかしいし
さらに>>601で示されたとおりYUVでも1-254も認められている

縦解像度540だとbt.709にすべき？bt.601？

SDでも縦は最高576(PAL)あるから、私だったらBT.601にするかな。

�d

>>604
再生システムによって変わると思うので
自分でCBでもエンコしてやってみるしかないんじゃないかな

ColorBars (720, 480)
Trim(0,29)
ConvertToYV12()
と
ColorBars (960, 540)
Trim(0,29)
ConvertToYV12()
と
ColorBars (1280, 720)
Trim(0,29)
ConvertToYV12()
でx264でエンコしてffdshowで再生したのを比べたら480=540だった。

ConvertToYV12()だとmatrix=Rec601だから、x264に--colormatrix smpte170mを付けておかないと、
一番下はおかしな色でRGBにデコードされる。

それは分かってて盾540の時はどうなるのか比較実験でやっただけだろ…

たぶんそれはハードとかデコーダーによると思う。
RADEONは縦720以上でHDと判定されてffdshowだと横1024以上がHDだったかな？

ffdshowは720pをSDと判定するってこと？
ffdsowの仕様はよく知らないけど、それはないんじゃないかなぁ

良く嫁

--corlormatrixをエンコ済のmp4/264ファイルに設定する方法ってあるの？

>>611
気になったんで調べたら、ffdshowは
width > 1024 or height >= 600: BT.709
width <=1024 and height < 600: BT.601
だって

シネスコだと600切ったりするから自分でいじれる方がいいなぁ〜

>>615は自動の場合の話
強制指定ももちろん可能

>>615
DXVAだと縦が576ラインを境にしてSDとHDを切り分けるみたいです。
NTSCだと縦480だけど、PALが縦576だからでしょうね。

http://msdn.microsoft.com/en-us/library/ms698715(VS.85).aspx

For standard-definition content, treat as DXVA2_VideoTransferMatrix_BT601.
For high-definition content, treat as DXVA2_VideoTransferMatrix_BT709.
(High-definition content is defined for this purpose as anything with a source height greater than 576 lines.)

ffdshowはエンコーダ(たとえばx264)側で指定しても615のようになるな
強制指定(RGB32出力のみ)だと毎回変えないとならないし

H.264の場合だとCoreAVCでRGB32で出力してあげると指示に従ってくれる

最近このスレ知って、avsをaviutlで開いてみたんだけど、
d2vを開いてYUVマトリクス変換2でYCbCr48(BT.601)→YPbPr48(BT.709)をオンにした時には見られなかった変な線が入るんだけど原因分かる人いる？
ttp://paint.s13.dxbeat.com/up/src/paint_16349.jpg

YV12＞RGBにプログレッシブで変換しているせい
avsの最後にConvertToYUY2(interlaced=true)をいれる

あるいはいっそAviutlで出力するなら
MPEG2SouceでupConv=1にすればYUY2にアップサンプルされる。
ただしavs内のフィルタ処理が全部YUY2になるので若干重くなったり
ほかの弊害が出る可能性はある。

>>621-622
ConvertToYUY2(interlaced=true)入れたら出なくなった。ありがとう。
upconvはいろいろ問題ありそうなのでやめときます。

avsでプログレッシブにしておいてから、最後にConvertToYUY2(interlaced=false)とするのがベスト。

>624
プログレッシブにするのはYV12→YUY2変換する際に、インターレスだと縞が消えたりするから
それを防ぐ意味で書いてるなら、ベストだと思うけど……

インターレースのまま変換したいなら
AutoYUY2を使うかこれ
http://pc11.2ch.net/test/read.cgi/avi/1238505263/16

もうわけわかめだから、一から勉強使用と思うんだけど
おすすめの本とかありますか？
カラーマネジメント技術って本ググって見つけたんだけど
これでも良さげでしょうか？

ググりながらこのスレを10回見直すといい

真面目にその辺の売ってる本よりこのスレ読んだほうがよっぽど詳しい

http://f61.aaa.livedoor.jp/~kasuga/images/hikaku.jpg

TV->PCｽｹｰﾙ補正をしたのですが
AviUtl（拡張色調補正TV->PC）とAviSynth（ColorYUY2 - V0.17-3）では違ったモノになります
AviSynthの方は緑がかったような感じ

これはやり方が間違ってるのでしょうか(´･ω･｀)

LoadAviUtlInputPlugin("D:\DTV Tools\AviUtl\m2v.vfp", "MPEG2VIDEO")
MPEG2VIDEO("R:\TEMP\Clipping 01.m2v")

ColorYUY2(levels="TV->PC",matrix="",interpolation = "411->422",interlaced = true)

return last

AviUtlで実際に出力した映像をキャプるとどうなる？

>>631
上の画像と同じです　出来上がったモノを比べるとやはり緑掛かって汚いような感じになります。
圧縮オプションも同じなのですがファイルサイズがAviSynth（ColorYUY2 - V0.17-3）の方が
小さくなります。

>>630
元ソースTSか？
AviUtlのプレビューは常にBT.601だ、プレビューを信用してはダメ、エンコしてみるべし
YUY2読み込みして一時的にプレビューを出力イメージに近づけたいなら
YUVマトリクス交換2のYCbCr48→YPbPr48にチェック、ただしエンコするときははずせ

元ソースTSじゃないならシラネ

>>633
ｿｰｽはTSです（1920x1080）

AviSynth（ColorYUY2 - V0.17-3）の方を使いたいと思い先にエンコードしたAviUtlの画像と比べると
こうなりました(´･ω･｀)

>>634
ミスった
AviUtlでプレビューをエンコ後のイメージに近づけるにはYPbPr48→YCbCr48にチェックだった
とりあえず、試してみたけど同じになった。

AviSynthもちゃんとエンコしたので試してる？
AvsPなんかのプレビューで再生時の色にしたい場合は
ConvertToRGB24(matrix="Rec709")
を追加しないといけない

て言うかよっぽど古いVGAとかSDにダウコンしない限りスケール補正やマトリックス変換なんて要らないんだけどな

あー、当然プレビューはそうとは限らないけど。
ちなみに、Aviutlならオーバーレイ表示に対応してるからそれ選択すれば
(おそらく)再生時と同じ色になる。おそらくってのは再生時のレンダラが
オーバーレイじゃなかったら違うかもしれないからな。

http://latoninf.free.fr/d9/SL/SmoothLevels.v1.02.avsi

TVスケール<->PCスケールをするなら、こう言うスクリプトを使って慎重にやらないとグラデーションが崩れる。

TV->PCの例:
MPEG2Source("input.d2v")
SmoothLevels(preset="tv2pc",chroma=2)

ﾚｽtyです。

何か話がAviUtlのﾌﾟﾚﾋﾞｭｰの方向へそれていますが
AviUtlの拡張色調補正TV->PC）を使いたい訳ではありません

AviSynth（ColorYUY2 - V0.17-3）と比較した場合出力ｲﾒｰｼﾞが、かなり異なるので
これは何事かと悩んでいた訳です

>>638
なるほど、グラデーションが崩れることあるんですね、試してみます


一応、大きめの画像貼っておきます。
http://f61.aaa.livedoor.jp/~kasuga/images/01.jpg
AviUtl（拡張色調補正TV->PC
http://f61.aaa.livedoor.jp/~kasuga/images/02.jpg
AviSynth 2.5（ColorYUY2 - V0.17-3）TV->PC
http://f61.aaa.livedoor.jp/~kasuga/images/03.jpg

間違えました

無
http://f61.aaa.livedoor.jp/~kasuga/images/00.jpg

AviUtl
http://f61.aaa.livedoor.jp/~kasuga/images/01.jpg

AviSynth 2.5
http://f61.aaa.livedoor.jp/~kasuga/images/02.jpg

いや、だからAviSynthもエンコして試してる？
AvsPのプレビューで00.jpg読み込んでみると
ImageReader("00.jpg")
ConvertToYUY2(matrix="Rec709", interlaced=false)
ColorYUY2(levels="TV->PC",matrix="",interpolation = "411->422",interlaced = true)
ConvertToRGB(matrix="Rec709", interlaced=false)
これで01.jpgの色になるし

ImageReader("00.jpg")
ConvertToYUY2(matrix="Rec709", interlaced=false)
ColorYUY2(levels="TV->PC",matrix="",interpolation = "411->422",interlaced = true)
これだと02.jpgの色になる

エンコしたのも同様におかしいならエンコード設定やデコーダー見直したほうが良い

http://pc11.2ch.net/test/read.cgi/avi/1221494912/671-674

671 ：名無しさん＠編集中 [sage] ：2009/05/12(火) 22:52:35 ID:7x49t78M
>>669
＞LagarithでYV12変換
この過程でどういう変換なのかによるけど特に指定する項目が無ければBT.601だろうな

エンコ後の解像度がSDならsmpte170mで良い
字幕編集というと、ニコニコやyoutubeへの投稿を連想するが
フラッシュプレイヤーはundefだとBT.709で伸張されるのでundefはお勧めしない


672 ：名無しさん＠編集中 [sage] ：2009/05/12(火) 23:56:11 ID:Y0SHl5Jo
>>671
情報が少ない中、わざわざありがとうございます
変換する際にも特に設定は見当たらず・・・
「Lagarith　YV12」などで検索してみてもなかなかそれらしき情報に出会えず・・・
これ以上はスレチになるので、この辺で終わりにしたいと思います

フラッシュプレイヤーの挙動は非常にありがたい情報です
ローカルで見る場合とフラッシュプレイヤーで見る場合で異なってくることは頭に入れておこうと思います
長々と失礼しました


673 ：名無しさん＠編集中 [sage] ：2009/05/13(水) 00:12:38 ID:91xujQaf
clormatrixは、特にSDの場合は明示しといた方が安全ってことですかね


674 ：名無しさん＠編集中 [sage] ：2009/05/13(水) 01:03:07 ID:jo2Mm3P7
FlashplayerがデフォルトでBT.709で伸張するってはじめて知った・・・orz

ID:なんかどうでもいいよ
暇な人がいるな

ID:BhVjMRFl = ID:VTXhiy+Q

馬鹿晒しage

しっかりしろ大丈夫か

ヘルプミー

TSファイルをSDサイズにしてAviUtlでエンコしたいんだけど、
入力はBT.709で出力はBT.601でいいんだよね？

これをやるとffdshow（rev.2984）でRGB変換するかYV12、YUY2で出力したのと色は一致するんだけど、
PowerDVD 9のフィルタでTSファイルを再生すると一致しない。ffdshowでNV12で出力したのとと多分同じ色。
どっちを信じたらいいの？

GPUはRadeon 4670でドライバは9.4、UseBT601CSCのレジストリは1にしてある。

最近のradeonはレジストリ弄っても伸張してくれないよ。

え？伸張されるのは確認済みなんだけど。

AviUtlは何経由で読み込んでんの？
読み込み時一回RGBになってる落ちは無いよな

m2v.auiっす。

UseBT601CSCはレジストリに有っても無くても結果は同じ
だいぶ前のドライバからそうなってる
ちゃんと有無の度に再起動して自分で比較して見れば判る

じゃあ最近のは何もしなくても伸張してくれるのか。知らなかった。

要するにTSをffdshowで再生したのとPowerDVD 9のフィルタで再生したのとで色が違うんだけどどっちが正しいのかを聞きたい。
それとも正しい色なんてなくてffdshowとm2v.auiが同じ色でデコードするってだけ？

ffdshowが709で伸張しててPDVDは601で伸張してるとかじゃないの

ffdshowの伸張設定を601と709それぞれ固定で再生してみたら
どっちかがPDVDと同じになりませんか

どっちもPDVDとは違った。うーん…

レンダラは同じなの？
別のレンダラ使っててレンダラ側で色調整してるとか

レンダラは全部VMR9 (Renderless)

あっPDVDだとYC伸張されてないっぽい。同時に両方表示させたら一目瞭然だった。
シェーダでYC伸張してみるとほぼ一致した。

なんでPDVDだけ伸張されないんだ？

あほすぎてつきあってられん

放置しれ。

>>651
家X1950proだけどUseBT601CSCを1にしないとVMR9で伸張されない
オーバーレイは関係なく伸張されるけど。

ちなみに自分は646じゃない

aviutl0.99h2の「色変換の設定」でBT.709>BT.709にチェックしたら
TSをDGINDEXでd2v出力したd2vもきちんとBT.709でエンコ出来るの？
これでもうavs通さなくてもいい？

d2vで読むならどっちにしろavisynth通したほうがいいんじゃないの

>>660
マニュアル読め
txtにYUY2入出力時にって書いてるんだからd2vじゃダメだろ
あとスレ違いだな

色域変換プラグインの使い方
DVD
IN YCbCr 601 170M 65000
OUT(PC YCbCr sRGB 709 65000

PT1（ＨＤ+ＳＤ
IN YPbPr 601 709 65000
OUT(PC YCbCr sRGB 709 65000

フィルタ順序は、一番最後に（他の色系はこいつの下に持ってくるように

注意！
99h2では「フィルタ設定」の欄に 色変換あるけどタグ付けだけなので！

なにが言いたいのかサッパリ分からん

http://ruru2.net/jlab-ruru/s/ruru1245095978036.jpg

此方に誘導されてきました。
colormatrixについて、勉強していますが深みにはまって訳が分からなくなりました。orz
AviUtl使用で、ソースは地上波TSで現在、まるも氏のMPEG-2 VIDEO VFAPI Pluginで
m2v.vfpファイルをm2v.auiにリネームして、YUY2色空間行列の設定を「元のYUVデータを維持」
にて読み込んだいます。
エンコードは、seraphy氏の拡張 x264 出力(GUI)のCLIモードでエンコしています。
現状はcolormatrixの指定はせずにしています。
目標サイズは、1280x720と1920x1080の二種類でエンコしてます。
この場合はx264のオプション指定で
--videoformat ntsc --nal-hrd --colorprim bt709 --transfer bt709 --colormatrix bt709
で指定してあげるのが正しのでしょうか？
自分でやってみたのですが、特にカラー変化してないように見えるのですが、
自分の目が節穴なだけでしょうか？
何処のスレにレスするか迷ったのですが、とりあえず此処で質問させていただきます。
スレチでしたら謝ります。

1月ぶりの書き込みだお＾＾
ここの過疎っぷりははんぱないおっおっ＾＾

>>666
自分はそこまで詳しくないんでほとんど答えられないんですけど、
その前に、
＞自分でやってみたのですが、特にカラー変化してないように見えるのですが、
というのは何のソフトで再生しての話？　flashplayer？
再生環境もわからないと答えにくいかと…。

>>666
デコーダーでRGB変換させないとそのオプションは反映されないよ。
あとその解像度なら大半のレンダラはBT.709>BT.601変換を行うので
どっちにせよ色は変わらんと思う

>>668
MPC-HC +CoreAVC VMR7(windowed)
Radeon4670 Catalyst8.10
LCDはｓRGBモードあと、ビデオオーバーレイでREGZA 37Z2000で見ています。
AviUtl内の色変換モードは入力出力とも自動です
こんなところです。
あとコンテナはmp4です

連投すいません。
>>669
と言う事はオプション気にしなくていいと言う事ですか？
う〜ん！皆さんのレスが宇宙語に見えます
自分の勉強不足を痛感しております

ffdshowとかCoreAVCとか出力色空間指定できるやつを使え

PV4キャプをHDエンコードするときは、
「入力　BT.601、出力　BT.709」で合っていますか？
最近この設定項目に気づいて、それまで601-601のままやってた＼(^o^)／
確かに、601-709と601-601はエンコ後は異なっているようでした（x264 r1181）

超初歩で申し訳ありませんが・・・

>>673
間違ってる

>>673
OK

>>674-675
レスありがとうございます。
あれ・・・どっちなんでしょうｗ

どこかのサイトで、「PV4はSD・HD問わずBT.601でキャプチャされる。
HD解像度でのエンコはBT.709に変換」とあったのですが、これは
x264GUIの拡張設定にある「YUY2->YV12変換」のことを言っているのでしょうか。

AVIUTLでの話なら、
PT1のtsを709-709と
PV4のdvを601-709が同じ色になった

質問する前に少しは用語をググってみましょう

>>677
ありがとうございます。
使用しているのはAviUtlのh4です（書き忘れすみません）

やはり601-709が正解のようですね。。。
レコに残っている分エンコし直しますｗ

ありがとう。とんでもないことに気付いてくれましたね・・・・orz

. ... ....:: ::: ::::;;;*。+ _、_ﾟ ＋　･
　　 Λ＿Λ＿・.（<_,` ）_ﾟ ･　 やあ数ヶ月前の私
　　/,'≡ヽ::）m)V _ n 　 ｌ 　*
￣ﾞ-'￣`--´￣￣E_ ）.ノ￣￣

自分は使ってないけど上で質問してるこのx264のオプション
--videoformat ntsc --nal-hrd --colorprim bt709 --transfer bt709 --colormatrix bt709

これはBT.601-BT.709変換をして収納してくれるのかな
それとも BT.709のフラグを付けるだけで実際は BT.601のままなのですか？

>>682
>それとも BT.709のフラグを付けるだけで実際は BT.601のままなのですか？

そう。 BT.709だと解釈されて、RGBにデコードされるのでおかしな色になる。

>>683
すきりしました
ありがとう。

遅くなりました。皆さんありがとうございます。
以上をまとめると、「AviUtl Version h4」における「色変換の設定」の項目は

【PV4】 入力 BT.601　出力 BT.709（HDのとき）
【PT1その他TS系】 入力 BT.709　出力 BT.709

という設定でよろしいでしょうか。

>>685
自分はaviutl使わないけどココは参考にはなる
http://resic.laburec.net/
ここの下のほうね

すきりとすっきり間違えたアルヨ

フラグを付けるだけってことは--fullrangeも2重に伸張するかもだから
分からない奴は（自分）使わない方がいいてことか

>>686
難しいですね…
わからないから、もうこのままデフォルト（601-601）放置してしまっていいかな、と
思っている自分がいます。。。

このスレ、奥が深くて私にはとても追いつけません><
AviUtlとx264(GUI)入れ替えたので、7月開始のアニメは全部エンコし直すつもりです。
正体不明のプリセット機能があってびっくりしました（スレ違いですが・・・）

皆さんおつきあいありがとう！

>>685
そういう覚え方するとあとでまた質問する羽目になるよ

上の例で、入力 BT.601　出力 BT601でも--colormatrixで601で出力した事を付け加えれば
HDサイズでもプレイヤーが対応してれば正確な色で再生されるという事？
709で出力するのは安全策？

入力も出力もBT.601にしてたら色は変化しないよ。HDソース(PVのぞく)ならBT.709のままだ。
だからその場合は--colormatrix bt709じゃないとおかしな色になる

誘導されて来ました。
PV4で録画したものって、PVで再生するときと、Aviutl等で読み込んだときとでなんで色が違うんですかね？
かなめもとか特に酷いんだけど･･･。読み込むときに伸張されてんのかな。

tsだとまるもさんのm2vconf.exeで伸張の変更できるけど、dvは伸張の変更出来ないんですか？
ググったんですが、良い情報が全く得られなくってorz

PV3/PV4の1080iは601で記録される
再生の時に709に伸張する(グラボで709でRGBに戻されるため)

とかだったような・・・

BT.601<->BT.709フィルタあったような気がするからそれで試してみるといいかも

月曜未明に放送される（かもしればい）カラーバーを録って比べると判りやすいかも。

>>691-692
aviutlの0.99hから、読込601、出力709って指定できるようになったよ。
あと基本的な事だが、PV.txtでオーバーレイ設定だと、ビデオカード側でオーバーレイ専用のカラーテーブルになる。
ATiもnVidiaもドライバのバージョンによってはデフォルトでTV>PC伸張分ガンマカーブが調整されてるから、そのせいもあるかもな。

>>692-694
レスありがとう！
>あと基本的な事だが、PV.txtでオーバーレイ設定だと、ビデオカード側でオーバーレイ専用のカラーテーブルになる。
これでオーバーレイ切ったら、色がPVでプレビュー時と、Aviutlで編集してるときとで色が近くなりました。
601,709の違いじゃなくて、TVスケールかPCスケールかのような気がするんだよね･･･。

http://toku.xdisc.net/cgi/up2/oiu/xs10946.png
↑こんな感じで、キャラが日の下に出ると皆おかめ納豆みたいな肌になっちゃうんですよorz
PC→TVスケール補正すると肌色がちゃんと出てくるんですが...全体が灰色っぽくなるんです。
ビデオカードの問題ですかね？

色伸張について調べてください

これでTVスケール伸張したらハイライト飛びまくりでしょ

↑間違えますた。忘れて下さい（汗

>>690
上の例ってのはそのPVで撮った時の事ね

>>695
PVフォーマットはスケール変換しなくて大丈夫だよ。
とりあえずビデオカードのコンパネで、「オーバーレイ」又は「ビデオカラー」みたいな項目があるはずだから、そこのガンマカーブを補正0に直せ。
その上で違いを見比べなきゃどこでどんなスケール変換が掛っているか原因を突き止められんだろ。
あとPC>TV変換したら灰色っぽくなるのは当然。
つかビデオカード何使ってるんだよ。

>>700
詳しくアドバイス有難う。ビデオカードは7600GSです。
ガンマカーブは補正0、ってかデフォにしましたが、改善無しでしたorz
PC>TVして、YC伸張使って誤魔化してますが･･･('A｀)

ちゅーか、最新ドライバじゃgeforceもradeonも伸張しないよ。
再生側で何とかする。

>>702はSDの時ね。
HDなら何もしなくても伸張してくれるはず。

いやいや、最近のは「ソフトウェアの設定を使用する」とかになってるだろ。
つまりプレイヤーが補正してるかどうかだな。

ついでに>>695のアニメ、新聞配達のやつだろ？
あれ元が白飛び気味だからそんなもんだろ。

早朝のカラーバー録画して検証してみなよ。

ttp://toku.xdisc.net/cgi/up2/oiu/xs10972.png
たぶんこれで正しいはず。TSからソフトウェアでBT.709>BT.601変換して
PCスケールに伸張

でこれからさらに伸張（要するに二重伸張）するとこうなる
ttp://toku.xdisc.net/cgi/up2/oiu/xs10973.png

>>695のはさらにもう1段くらい飛んでるような白さだね

>>695は単にガンマ補正がかかってるだけみたいだな。BT.609にもなってるみたいだし

ごめんヒストグラム見たらやっぱ飛んでる

モニタとかのキャリブレーションしてないから、いくら調整しても変なんじゃね？
正しく色が表示されてないのに、見た目だけで調整すると、こういう事になりやすいし

まずは705の書いたとおりPV4の色調整からだな。
カラーバーはNHK EかBS JAPANが毎日早朝にやってる。

MonsterX版で申し訳ないが
http://karinto2.mine.nu/?MonsterXColor
こんなような調整のこと。
PV4の調整方法は知らないのでググるか識者に任せる。

PV4側が正しく調整できてからグラボやモニタ側をやらないと堂々巡りだ。

送り出しがレコならタイマー録画しとくといいかも
俺は調整で時々使う事あるから消さずに残してる

アースソフトにあるカラーバーをレコに読み込ませるのはだめなの？

AviSynthでカラーバー作ってmpeg2エンコではだめ？

間違いなく正しいサンプリングになってる自信があるなら問題ない

本物の放送映像使った方が間違えが少ないよ。番組も放送に乗っかってくるわけだからな。
自作はどこに罠があるかわからんよ。

>>711
水曜から昨日まで早朝にNHK E録画したけど全然無かったよ。
ウソツキorz

毎日だっけ？月曜朝だと思ったが
PT1使ってるから放送ないときに録画すると不安定になりそうで怖いんだよな…
チーズスイートホームを失敗したら…！

>>717
NHK-Eにとらわれずに狙うべし。休止が多い日曜深夜〜月曜朝が狙い目。
俺が以前月曜朝に狙った時はNHK-E/TBS/テレビ東京/テレビ埼玉がいっぺんに録れてた。
NHK-G/フジ/NTVはこの日休止しなかったので予約しなかった。

>>717
俺がやったときは去年の8/21(木曜)の早朝5時前で当時は毎日やっていたが
今はもうやってないのか。すまんな。
地域にもよるのかな？

ちなみに東京JOAB-DTVの場合EPGによると今晩も2:25〜5:00まで放送休止だ。
4:30くらいから30分の間のどこかで多分流れると思われ。

>>666
よく解らないので勉強ついでにOPTIONの意味調べてみた。
でも解らない部分多すぎorz

--videoformat ntsc
　エンコードでデジタル化する前の“ソース”がどんな種類のものだったかを説明するらしい。
　元が何かを説明するだけでエンコされた映像には使い道がまるでない…らしい。
　指定するだけ無駄っぽい？

--nal-hrd
　これ何のオプション？
　具体的な効果を示す説明見つけられなかった。
　誰か教えてください＞＜

--colorprim bt709
　CIE 1931 xy 色度図における赤・青・緑・白の位置をデコーダに指定するらしい。
　概ねHD解像度なら bt709、SD解像度なら smpte170mを指定する感じ？

--transfer bt709
　ガンマ特性を指定するらしい。
　確かデジタル放送波のガンマはBT.601指定されてるはずなので smpte170mが正しい？
　一部情報で bt709指定と smpte170m指定は同じ効果と書いてあるので好きなほうで。

--colormatrix bt709
　RGB<->YUV 変換式の係数をデコーダに指定するらしい。
　基本的にHDは bt709指定、SDには smpte170mを指定すればOKとのこと。
　ただ厳密に使い分けされていない場合もあるのでソースの情報を確認する方が吉。
　最近はffdshowやCoreAVCが対応してきたので指定する価値大いにあり。

てな感じかな？
colormatrix以外は別に指定しなくても国内でのソースならば問題は出なさそう。
間違ってる部分あったら誰か訂正してください＞＜

MPEGのヘッダについて調べるべきだな。

まあ、--colormatrix指定してもそれを読みとる環境じゃないと色変わんないすけどね

逆に読み取られて反映されたら困ることもあるしね

TV放送をPT1でTS録画したのを、dgindexでd2vにしたら一度RGBになってしまうから、d2vにしないほうがいいということだよね？
いつもはm2vファイルをm2v.aui経由でaviutlに入れてます。
どうしてもd2v使う時は、avsにconvertToYUY2()記述すればOK？

YV12

>>725
単にConvertToYUY2()としただけでは、縞が崩れてしまうから、デインターレースまでをavsでやっておけばよい。

例:
MPEG2Source("input.d2v")

(デインターレース, IVTC)

ConvertToYUY2

MPEG2SourceでupConv=trueとするかAutoYUY2を使うのがよい。
ConvertToYUY2(interlaced=true)でもいいけどあまり品質は良くない。
ベターなのは>>727だけど場合によっては先にYUY2化したほうがいい事もある

>>725
ていうかなんか勘違いしてるみたいだけどd2vがRGBになるのはVFAPI経由のときであって
MPEG2Source使えばYV12でロードできるぞ

みなさん回答ありがとう
ただ問題がでた。d2vをavs経由でYUY2かYV12を試そうとしたんだけど、aviutlで開けなくなった。
MPEG2Source(hogs.d2v)でエラーでるんだが、ちゃんと指定している
Dgindexでやってるから、DgDecode.dllはもちろんある
avisinp.auiもaviutlに入れてるし、問題ないと思うんだけどな。
スレ違いになるから、自分でがんばります

若干ｽﾚﾁな内容かもしれんが
DGVfapi には
VFAPI経由でAVSを読み込む機能がある

VFAPIはRGBな色空間なわけだからDGVfapi経由したAVSには
スクリプトの最後でconvertToRGB24()を自動的に追加した形で読み込まれる

たとえばAviUtlとかでAviSynthスクリプトを読みこむプラグインはいくつかある
みたいだけど、入力プラグインの「DGMPGDec *** D2V/AVS Reader」が他の
AviSynthスクリプトを読み込むプラグインより優先度が高ければいくらYUY2で
読み込ませようとしたってRGBで展開される

YUY2で読み込ませたいなら
AVISynth Script File Reader　とかで読み込むといい
どの入力プラグインでファイル読み込んでどんな色空間で展開されてるかは
メニューのその他→ファイル情報　から見るとわかるよ


ああ、俺も昔は知らずにsynthスクリプトをVFAPI経由で読み込んでいたさorz

>>730です
どうやら、Dgdecode.dllがうまく働いてなかったみたいです
手動で指定してあげたらうまく開けました
>>729の言うとおり、何もしないでもYUY2で読み込めました。
とりあえずテストは出来たのでよかったです。
助言くださった方々、ありがとうございました。
プラグインは全部avsに記述するのが、無難なのでそうすることにします

今更だけどupConvはbool型じゃなくてint型で0-2を指定するんだった。

ちょと聞きたいんだけど

色域については
1.NTSC比72%≒sRGB≒BT.709
2.NTSC比100%≒AdobeRGB≒xvYCC

色数については
sRGBだろうがなんだろうが10bitになりゃDeepColorって認識でおｋ？

>>734
1.従来色域≒sRGB＝BT.709
2.広色域≒AdobeRGB≠xvYCC

NTSC比〜%ってのはあくまで面積比なので、
sRGBやAdobeRGBとずれている場合もあるので適切じゃない

> 色数については
> sRGBだろうがなんだろうが10bitになりゃDeepColorって認識でおｋ？
OK（DeepColorには12bitと16bitもある）

xvYCCについては下のサイトを参照
色域の話で良く持ち出されるRGB原色点はBT.709と同じ
ttp://www.sony.co.jp/SonyInfo/technology/technology/theme/xvycc_01.html
図1.2がわかりやすいと思うんだけど、
例えば今までRGB(0,255,255)は水色（シアン）の色になったわけだが、
ここでRGBを（-127,255,255）と入れることを許可する
そうすると今までの明るい水色からより深い水色になる
しかし対応していないディスプレイではマイナスの値は入らないので、
0に切り上げられて従来の水色になる

よって、対応しているデバイスではより広い色域を再現出来るが、
対応していないデバイスでは従来の色域になって色がおかしくなったりはしない
だから一見面倒なやり方だが、互換性を維持することが出来るのが特徴

いわゆる後方互換ってヤツか

なに言ってんだ前方互換だorz

>>735
詳しくありがとう。
xvYCCってなんだかまだ理論上のものでしかない感じなんだね。
互換性を保つために便宜上RGB(255,255,-127)って書き方だけども
内部的には0-512かもっとなのかわからんけどそういう数字に割り振る、
もしくは計算結果として帰結するはずだし。
これだけの色が出せます！ってのじゃなくて、こういう考え方をすれば色を増やせるよね
ってとこで止まってる気がする。
色空間のxy座標表でRGBのベクトル矢印を遊ばせてるだけというか。
RGB(-255,255,-255)がありえるのかとか規格上限が固まらんとどうしようもないし、
なんともうやむやなんだなあ。

ｘｖYCCてYが大きいまたは小さいときにCbCrの値が大きいと
結果が0-255を超える範囲になるのを利用してるから
RGB(-255,255,-255)とかは完全に範囲外だと思われる。

放送波は視聴者の反応が怖くてまだ採用できないだろうけど、
BT.709の色域は狭すぎ。
標準規格なのだから、ライブカラーでもハリウッドカラーリマスターでも
HDMIでxvYCCフラグ立てて出力するレコーダー、プレーヤー、ブルーレイが出てきたとき、
表示できない高彩度領域は色潰れするだけでエラーとなる訳ではない。

TVは既に色域をもてあまし気味だから、
普及し始めると加速度的に広まる可能性を持っている。

海のエメラルドグリーン、蛍光色には各社差がでそう。
パネルの持っている限界色域で表示できるようになる訳で、各社の色作りやLED液晶やらに
一層拍車がかかる。
目下adobeRGB拡張派：SONY　XR
　　　SOCCS（自然界の色域包含）派：SHARP　XS
　　　デジタルシネマ規格派：PANA　プラズマ
でどれが正解かは送り出し側にかかっているが、
それぞれかなり色域が違うので、放っておくとシアン〜緑〜黄緑系の色相シフトが危ぶまれる。
すでに同一ソースで3社で色の出方はかなり違っている。

>>727
ちょっとまて。
ConvertToYUY2(interlaced=true)
こうしておけばインタレ問題ないんだが。

>>741
>>727の人はあちこちでそれでは少々問題ありと言ってまわってる人だよ
まあ、たしかにそれで問題なければドナルドもAutoYUY2なんてわざわざ作らんと思う

問題あるかないかで言えばないけどよりよい方法が他にあるのは確か。
要するにベストではない

720x480(Bt.601)の動画を960x720にリサイズしてColorMatrix(mode="Rec.601->Rec.709")した動画と
元動画って同じ色で表示されるはずだよね？

再生環境によって変わってくんじゃねえの？

>>744
縦720以上はBT.709としてRGBにデコードする環境が多いだろうから、それで問題は無いと思う。
x264だったら、--colormatrix bt709 と指定しておけば間違いない。

>>745-746
サンクス
うちの環境がおかしいだけなのか縦横比が4:3だと縦720以上でもBt.601の変換係数を使って伸張しているようなんだ
1440x1080や1280x720だと正常（元ソースと同じ色になる）だけど960x720や1024x768や1280x960だと駄目
ｘ264のcolormatrixで指定しても駄目だった
GeForce7800みたいな化石ビデオで伸張させてるのが間違いなんだろうか

Radeon買うかffdshowでRGBに変換すればいい

ffdshowやCoreAVCを使ってRGBで出力すれば、ビデオカードに関係なく、
H.264のmatrix_coefficientsに従った正しい色でデコードされる。

http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion
http://www.coreavc.com/index.php?option=com_content&task=view&id=42&Itemid=1

RGBで出力させることが前提だけどね

>>747
よくわからないけど、特定の解像度じゃないとbt.709にならないとか
試しに1440x1080や1280x720の縦や横を少し伸ばした変態解像度だとどうなる？

あ、AR4:3の時なんですね。すまん、よく読んでなかった（汗
GF7800はbt.709の変換条件にARも見てるんですかね。
（16:9になるよう--sarを調整するとbt.709になったりするのかな？）

>>748-750
レスどうもです
ffdshowで出力するようにして解決しました
昔はCoreAVCで伸張してたんですが誤変換することがあったのでビデオで伸張するようにしてたのですが
>>752
960x720 sar11520:8640でdar16:9にしてやっても誤変換するようです

>>753
どうでも良いけど960*720でDAR16：9ならsar4：3だよ

xvYCC色空間なんだけど理論的にはこれでおｋなのかな？

ttp://kuronuko.up-ch.com/uploader/sn/upload.cgi?mode=dl&file=10226
DLKeyはxvYCC

まずsRGB空間を基にしてて、
RGBのうちひとつの値だけマイナスになれるってんならこれでいいんだよね。
いかにも理論上って感じなんだけどもｗ

>>755
LabじゃないそれはCIExy色度図。だから空間とは呼ばない。
その推定図も輝度値が考慮できていないため間違っている。

そんなあなたに
http://www.jstage.jst.go.jp/article/itej/60/11/1749/_pdf/-char/ja/

後ろから2ページ目にxvYCC色空間がYxy空間にマッピングされた図がある。
BT.709（＝sRGB）も併せて載っている。

(1)4章にも書いてあるように、RGBモニタのようにY値によって彩度が変化しない場合は色空間を
xｙ色度図にプロットしても意味があるが、Y値により彩度の変化するxvYCC空間をxy色度図
にプロットすることは誤解を招くため一般的にはやってはならない。
同様にプリンタの色域などは誤解を期待してやってはならないことを堂々とやっている
ものもあるのが現状。

(2)xy色度図の馬蹄形は眼の生理的限界線を表しているので、はみ出す領域は数学的には
扱っても良いが、実際には存在しない。
計算上はみ出す筈のXYZ刺激値の光源は実は存在している。例えばレーザ光などは
x=0.001、y=0.999位に計算上なるはずだが実際にはx=0.17,y=0.80位にしかならない。
何故ならこれを人が見た場合、眼が色飽和を起こして結局境界線上の色と同じ色にしか
見えないから。
よってこの意味でも馬蹄形の外にプロット図を書くことは誤解を招くので不適当。

>>756
おお詳しくありがとう。
確かにこの図だとRGB(0,0,0)とかどこにもないから変なのよねｗ
それを描いたのが挙げてくれたグラフになるのか。
(1)についてはなるほどすぎる。自分の参考にしてたもの自体が間違った使い方してたんだなあ。
(2)についてはその通りだと思うけど数値としてってことで。
紫外線や赤外線は視認できないし太陽も直視できないのと同じようなことだと思っとくｗ

>>757
(1)xy色度図のダークな面　BT.709の色立体図が宙に浮いている点に注目。
この図だと読み取れないけど、どんな規格や光源を持ってこようとも、
RGB=（0,0,0)、Y=0の黒は定義上x,y=(0.333,0.333)です。

ところが、xy色度図は正規化をしてあるので、Y値が小さい程本来の色立体の
大きさを拡大して表示するという致命的な欠点がある。
例えば、XYZ=（0.0008、0.0001、0.0001)となる限りなく黒の色刺激はどんな
色域の小さいモニタでも数値的には表示できる筈。
そして定義上x,y=（0.8,0.1）なんてとんでもない座標値となり(0.333,0.333)に収束しない。

つまり完全な黒以外の黒は馬蹄形全体を覆って末広がりに発散する立体図が本来は正しい。
ところが実際問題として眼の感度や黒つぶれの精度の問題があるためこれを避けている。
よってY≒0付近の図は描かないのが業界のお約束となっている。
ほとんど何処を探してもYxy色立体図が載っていないのはこれが理由。
ソニーは判ってて反則技を使ったということ。

(2)xy色度図は380〜780nmの波長の光だけを対象に定義した空間。
それ以外はどこに有るかではなく意味をなさないと理解して欲しい。
強いていうなら380〜780nmの成分のない紫外線も赤外線もｘ,ｙ=（0.333,0.333)。
一方輝度飽和する太陽光は直視できなくても無問題。
普通に5000kのD50付近の白の色度として表せる。夕日なら3000Kを切る。
発光色には輝度の限界がないということも実はxy色度図のダークな面の一つ。

色度図に何故見慣れた絵の具の色が表示されていないか。
それは最明色だけを表示している発光色の図だからいう点もご理解下さいませ。

4. Full Range

＊なにこれ？
　アナログ映像のデジタル化におけるもう一つの遺物だ。アナログ映像をデジタル化する場合は、
輝度と色差のレベルをデジタルで表現するならそれぞれ 16 〜 235 、 16 〜 240 の範囲内に
収めなければいけない。再生機器は通常、全てのデジタル標本がこの範囲内に収まっているものと
決めてかかっている。しかし、ほとんどの DVD は輝度と色差の信号に 0 〜 255 のフルレンジを使っていて、
　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
たぶんその機器で再生したときにオーバーサチュレーションをもたらしている。
これを避けるにはレンジ補正が必要となる。


これ本当？

うそ

大抵16-235より多少はみ出しているけどな。
それをもってフルレンジ使っていると表現するのはどうかと。

>>749
CoreAVCのRGB出力って
Input ColorspaceのAuto設定にしたらcolormatrix(matrix_coefficients)でしか判断してないんだな

ffdshow
width > 1024 or height >= 600: BT.709
width <=1024 and height < 600: BT.601

Haali Media Splitter
BT.709 when video width is 1024 or more

ラデは720p以上？
720p以上はBT.709にしてx264だとcolormatrix指定するのがベストか
>>747と同様、7000番台ゲホ使いの俺はHaali Media Splitter使ってる
ffdshowのRGB変換はHaali以上に重い
それと960x720にエンコすると間違うから1024x768でエンコしてるよ

456 名前：名無しさん＠編集中[sage] 投稿日：2009/09/05(土) 06:48:47 ID:UNt/b8gi
BT.709の放送をSDするったって、わざわざBT.601にする必要はないんじゃない。
そっちの方が色が好みならしてもいいだろうけどさ。
↑
こういう勘違いしてる人は再生環境が劣悪なのもあるんだろうな
色が変わって見えないようにするための処置なのに

なんでわざわざデコーダでRGB変換してるの？
その後の経路が重くてしょうがないだろうに。。。

>>747からの流れを見る限り古いゲホは正しく伸張してくれないからだろ

Avisynthを絶讃ιょぅょ Part27
ttp://pc11.2ch.net/test/read.cgi/avi/1246414384/564-570
から誘導されて来ました。
このスレをぱっと見ただけでもまだまだ学ぶことは多いと実感しました・・・。

もし、解決方法がわかる方いらっしゃいましたらアドバイスお願いします。

>>766
同じ要領でソースのtsもキャプチャしないとどっちがどっちとも言えない

PT1持ってないから知らないけど>>685のことからBT.709になってるのかな
DGIndexでプロジェクトを開いてPreview[F5キー]するとInformationウィンドウが出て
そこにColorimetryの項目があるからそれを見てみ
多分、BT.709と表示されているはず
Aviutlでエンコする時は[設定]→[色変換の設定]を入力BT.709、出力BT.709になってるか確認
自動でもOKだと思う
それとDGIndexの設定は[Video]→[YUV->RGB]をTV Scaleにしてからプロジェクトを保存すること

色が変わって見えてる件は多分Avisynthでエンコしたキャプチャの方が合ってる
というか何も間違ってない

>>766
Avisynthスレから追っかけて来たよ。
向こう>>565-566で伸張の違いと言われてたけど、それは関係ない。
BT.601かBT.709かの違いだよ。 その動画の実際の色空間と、デコーダーの判断が違うと色が変わってしまう。
解決策は767氏の言うとおり。　それと>>746かな。

>>767
お手数をおかけしてすみません。
ソースです
ttp://nagamochi.info/src/up35899.jpg
仰るとおり、Avisynthでエンコしたものとほとんど変わっていないのが確認できました。

結局、私は今までAviUｔｌでのエンコの仕方を間違っていたようです。
AviUtlでエンコしてたときはMPEG-2 VIDEO VFAPI Plug-Inを利用していたのですが
色空間関係のところは変更してないので適切に処理されていたのかどうか・・・。

>それとDGIndexの設定は[Video]→[YUV->RGB]をTV Scaleにしてからプロジェクトを保存すること
これはあちらのスレで仰っていたように、Avisynthだと気にしなくても問題ないんですよね？

x264を使うならば、最終的に色空間をYV12にしないといけないみたいなのでDGIndexを使っているのですが
MPEG-2 VIDEO VFAPI Plug-InとDGIndexのどちらを使うのが良いのかなどもう少しスレを読んで勉強しようと思います。

>>768
レスありがとうございます。
これを機に色空間について色々調べたいと思います。

日本の放送はTVスケールのBT.709だから、SDにリサイズしないのなら、色は一切いじらずに、
x264で、--colormatrix bt709とだけ付けておけば良い。

RGBを経由するとすこしややこしいが、DGDecodeでYV12で読み込んだ場合は、ソースの色は元のままなので大丈夫。

>>769
>それとDGIndexの設定は[Video]→[YUV->RGB]をTV Scaleにしてからプロジェクトを保存すること
あっちで教わったことはほとんど間違ってるから忘れた方がいい。
AvisynthでもTV Scaleに設定しなければいけない。

MPEG-2 VIDEO VFAPI Plug-InかDGIndexかなら、断然DGIndexがお勧め。
前者はVFAPIという仕組みを使うために、一旦YUV->RGB変換する必要があり、普通あまりよろしくない。
DGIndexのTV Scaleなら、何もせずそのまま読み込んでくれるのでそちらが良い。

完全にAvisynthスレの範囲でスマン。

自己レス
AvisynthではDGIndexの設定は関係無かった。　申し訳ない。吊ってくるorz

>>771
まるもをVFAPI経由でAviUtlで使うやつなんているのか？

ID:qgF4Uefaみたいなのが勢い余って変なこと書くから初心者が混乱するんだよな

AvisynthでDGDecode_MPEG2Sourceを使って読む込む限りは>>767,>>770で間違いない
DGIndexのYUV->RGBの設定は無視される
しかしAviutlも併用することを考えればTV Scaleにしておけば間違うこともない

>>771
DGIndexもVFAPI経由な訳だが（DGVfapi.vfpは）

アドバイスをくださった皆さん、どうもありがとうございました。
皆さんのおかげで問題が無事解決できただけでなく、
今まで気にしていなかった色空間のことを調べるきっかけを得ることが出来ました。
今後のエンコライフに役立てたいと思います。本当にありがとうございました。

VFAPI経由するのは*.vfp経由で読み込んだときだ。m2v.auiならYV12から補間つきで
変換したYUY2で読み込む。あとDGIndexのスケールの設定はVFAPIのときに影響するから
MPEG2Sourceでd2v読んだ場合は関係ないよ。
でたぶん>>766でAviutlのプレビューだけBT.709>BT.601変換はいってるのはm2vconfで
そういう設定にでもなってるんじゃないか。きちんと設定していればAvisynthだろうとAviutlだろうと
同じカラーサンプリングになるから見た目に違いは出ない

>>777
最新のaviutlにはデフォルトで色変換の設定がある
旧バージョンから上書きインストールした場合、入力BT.601、出力BT.601になってる

>>778
入力と出力が同じ設定なら色空間のリサンプルは行われないよ。
だから設定がその状態でBT.709の動画を読み込んでもBT.709のままで吐き出される。

え

プレビュー画面の色がおかしくなるだけで出力には影響ないね

だなｗ　最初それで戸惑った

RGB値を入力したら、何色か文字で表示されるサイトとかないでしょうか？

そういうプログラムソフトはあったんですが、webサイトでそういった
ものはありませんでしょうか？

当方色弱者です。

マルチすいません

敢えて文字で表現しようとする意味が解らない。
例えばRとGだけの変化で、どこからどこまでが黄色で、どこから山吹色で、どこからオレンジかなんて決まりは無いだろ？

>>783
富士通アクセシビリティ・アシスタンス
ttp://jp.fujitsu.com/about/design/ud/assistance/
> ColorSelectorなど

↑でRGB値なりスポイト機能なりで色を指定
16進数のカラーコードを↓のサイトなどで検索してみりゃいいんじゃね？

WEB色見本
ttp://www.colordic.org/
> 原色大辞典、和色大辞典、洋色大辞典など

>>783
色名からRGB値をだすのなら
http://ja.wikipedia.org/wiki/%E8%89%B2%E5%90%8D%E4%B8%80%E8%A6%A7
とかがあるけど・・・

>>784
おまえが知弱なことはよくわかったから一生ロムってろ

WEBカラーやJIS慣用色名やDICなどそれぞれでちゃんとRGB値に応じた決まった名前がある
ただ、すべてを統一した色名がないだけ

次の手順でDVDをH264にエンコードした場合、DVD2AVIの設定でYC伸張が行われた事になるのでしょうか。
それともaviutl側でフィルタを通さなければ駄目なのでしょうか。

1 リッパーでISO作成。
2 DVD2AVIでプロジェクト作成。(YUV4:2:2、パソコン色調 を指定)
3 aviutlでx264guiでエンコード (入力、出力共にBT.601 を指定)

うる覚えだがパソコン色調だと伸張されるんじゃなかったかな

DGIndexでd2vを作成(4:2:0) -> それをソースにavsを作成 -> そのavsをx264でエンコード

こうすれば、途中で余計な色変換は入らない。

>>787
エンコ時に伸張したいのか？
dvd2aviのvfapi経由ならそれでおｋ
つか入力プラグインはどれ使ってるのよ？
x264のオプションに--fullrange onを忘れずに設定
しかしデコーダがほとんど対応してないので色がおかしくなるぞ
エンコ時に伸張しない方がいい
aviutlでd2vを扱う場合はこの2行を適当なファイル.avsに保存してavisynth経由で読み込むと間違いが無い
DGDecode_MPEG2Source("source.d2v")
last
もっといい方法があるのかもしれんがaviutlに詳しくないので知らん

>>787
aviutlならMPEG-2 VIDEO VFAPI Plug-In(m2v.aui)で読み込んでYC伸張フィルターでも
使った方が良いんじゃないか。
その質問だとYC伸張のままエンコしたいって読めるけど、その理由も書いた方が良い。

DVDの色空間はYV12なのにDVD2AVI / DGIndexを使いaviutlで
直接読み込むとVFAPI経由でRGB入力になるので使用しない方が良い。

下らない話なんだけど、Avisynth使ってエンコしたのに色がおかしい！
と思ったら、MPCを複数起動すると1枚目だけちょっと赤っぽくなるだけだった
これってなんで？

>>789
DGindexはブルーレイにも対応していてヨサゲですね。
さっそく試してみます。

>>788
>>789
有難うございます。
DVD2AVIでYC伸張を行いたい場合にPC設定を使うようにします。

>しかしデコーダがほとんど対応してないので色がおかしくなるぞ
>エンコ時に伸張しない方がいい
YC伸張を行うのなら再生ソフトかコーデック、あるいはビデオドライバに任せるべきだということでしょうか。

エンコード時にYC伸張を行う事にこだわりはありませんが。
OSインストール後に動画を再生させた場合、YC伸張をどこかでしないと色がおかしくなるので、エンコード時にしようかなと思っただけです。

YUV420の地デジTSをaviutlでm2v.aui入力→拡張x264出力を使って出力しています。
どうしてか色が薄いのですが正しい色空間で出力するするにはどうしたらいいでしょうか？
色変換は入出BT.709にしています。
エンコのオプションでは訳もわからず--colormatrix bt709つけてるんですがこれは余計なのでしょか？

>>792
使ってるレンダラによって違う
オーバーレイ表示になってるんだろ
>>793
よほど古いビデオを使っていない限りはドライバ入れたら伸張されるので
エンコード時に伸張するとおかしくなると思うんだが・・・
まあ好きにすればいいよ

元のTSから色を一切いじらず、x264で --fullrange off --colormatrix bt709 と付けておけば、
これらのVUIを読むデコーダ(ffdshow, CoreAVC等)なら、正しい色のRGBを出力できる。

途中でPCスケールにしたなら、--fullrange onが必要になる。
TVスケール->PCスケールは、再生時にやる方が良いと私は思うけれど。

色々と教えてくださって有難うございます。
YC伸張は再生側に任せるようにして、余計な色変換は行わないようにします。

>>796
ありがとうございます

>>795
最近のゲフォは伸張されないよ

GeForceは最近のドライバなら
「プレーヤーに任せる・限定レンジ・フルレンジ」を
コンパネから指定できるけど。

>>800
レンダラがVMR7などでオーバーレイミキサを使用している場合はコンパネで指定しても適用されない
XPでMPCなどレンダラが指定できるプレーヤーならレンダラをVMR9などに変えれば回避できるが
PowerDVDなどの市販DVDプレーヤーなどではYC伸張されない
以前は上記の場合はちゃんとYC伸張してたんだけどね
まぁもうXPなんてかまってられないというところなんだろうがあまりにもお粗末だとは思う

>>794
m2v.aui 0.6.57はYUV出力時の色空間指定が入れ違ってない？
色空間指定の無いソースではBT.709がBT.601になるようだ。

ちゃんとm2vconf実行しているのか？

>>800
Windows 7使ってるけど、プレイヤーに任せるってやると、
メディアプレイヤー　： フルレンジ（伸張あり）
メディアセンター　：　限定レンジ（伸張なし）
ってなってるみたい。
コンパネで設定すると確かにプレイヤーに関わらず指定できるようになるね。
これは良い！

>>802-803
m2vconf.exeで元のYUVデータを維持に設定するとだめなんですか？BT.709を選択すべきでしょうか？
アチャーあれからテスト用に何本かエンコ、比較してそれなりに好い感触は得ていたのですがやっちまいましたね。
また何本かテスト用動画作って比較してみます。

改めてreadme読んでみたんですが元データを維持以外を選んだ場合に
matrix_coefficient指定が明記されていないソース(今回使ったソース:ただし、MediaInfo情報)が
どのように変換されるか明記されていませんでした
これは自分なりに検証してみるべきなのかもしれませんね

>>806
matrix_coefficientはその動画のカラーマトリックスが何なのかわかるようにするための御呪いみたいなものだよ
デコーダが対応してなきゃ意味ない
殆どの場合、設定してようがしてまいがデフォルトの動作をする（通常は720p以上はbt.709、それ以下はbt.601と判断）

>>807
ありがとうございます。
m2v.vfp入力の自動認識と同じ様に判断されるということですね。
BT.709と判断されているようで出力結果も合わせて納得しました。

>>806
matrix_coefficient が設定されていない場合、その上の
「色空間行列(省略時)」に従って入力カラーマトリックスを
決定します。

「自動認識（解像度から）」を指定した場合、入力映像の
幅 x 高さ x フレームレートが 12000000 未満であれば
BT.601 と判定して、それ以上であれば BT.709 と判定します。

「自動認識（解像度から）」以外を指定した場合は、入力映像
の大きさに左右されずに指定されたマトリックスで変換されて
いると判定します。

>>まるもさん
たまたま正しい選択をしていただけで色々と勘違いしていたようです。
私のような初心者の頓珍漢な質問にお答えいただき恐縮です。

あれから調べてみた所、AviUtilでYUY2モードと通常のモード間を移行すると
必ず色空間がBT.601に設定されてしまうのが原因だと気づきました。

どうもお騒がせいたしました。

注意点として、AviUtilのYUY2モードはBT.601なので、YUY2モードを使用する場合はm2v.auiの
YUY出力をBT.601にしないと色が変わってしまうのと、AviUtilを通常モードに変更すると
AviUtilの色空間がBT.601に固定されているので変更する必要があります。

ところで、色空間の自動認識の基準はAviUtilとm2vとで同じなんでしょうか？

ところでPCでエンコモノ再生させるにしてもRADEONやGeForceなら縦720px以上の
動画はBT.709と判断してRGB展開させるから無理にエンコ時に変換する必要もないんだけどな

>>811
バカだよポップさん Log 2009/06
http://resic.laburec.net/log/2009_06.html#20090604

>>812
縦解像度でBT.601/BT.709を判断するのはDXVA1(VMR)を使うときだけで
DXVA2(EVR)やDXVA-HDの場合はAPI経由で指定するようになってるよ。

>>767 >>774 >>787-788 >>790
亀レスだけど再生時に伸張する場合はTV scaleではなくPC scaleだよね？
ttp://neuron2.net/dgmpgdec/DGIndexManual.html#YUVtoRGB

>>815
質問の意味がいまいちわからんが
再生時にYUV [16, 235(Y)/240(UV)] → RGB [0, 255](PC Scale) の変換(伸張)を行う
エンコ時は弄らずTV Scaleのままね
その辺がややこしいからエンコ時にはRGB変換をかまさないように意識するといい

ついでに説明しておくと
BT.601やBT.709の係数を使って伸張するわけだけどどのカラーマトリクスなのかをビデオかAPIが判別するわけだ
720ｐ以上はBT.709と判別された場合は当然ソースもBT.709にしておかないと色がおかしくなる
その判別は上に書いてあるように環境によってまちまち
なので通常は
SDからHDの場合、ColorMatrix(mode="Rec.609->Rec.709",interlaced=false)
HDからSDの場合、ColorMatrix(mode="Rec.709->Rec.601",interlaced=false)
とする必要がある
その上でx264のオプションに --colormatrix bt.709 または --colormatrix smpte170m としておけば
より多くの環境で正しい色で再生されるようになる

横からすまんけど
x264で色空間指定しておかないといけない再生環境ってどんな場合があるの？

>>817
>>814のような環境やCoreAVCのRGB変換
--colormatrixは指定しておいて損はない
将来的なことも考えて指定しておくべき
逆に指定しておかないと後から見てカラーマトリクスに何を使ってるのかがわからなくなる

話題ぶったぎり？で悪いが、ひさびさにMediainfo更新したらmatrix_coefficientsなる項目が追加されていた

いつの間に…っつーか、もっとマメに更新しとくんだったなぁ

>>816
分かりにくくてスミマセン。
エンコ時に色を弄らずにRGBに変換するというのは、
DGIndexのYUV->RGBをPC scaleに設定するはずなのに、
何故か少し上のレスではTV scaleに設定しろと書いてあるのが気になったので。

VFAPI経由で読み込むと無駄な色域変換が入るので、
使わない方が良いことは分かっているつもりです。

VFAPI経由ってコトはaviutl？

>エンコ時に色を弄らずにRGBに変換するというのは、
DGDecode_MPEG2Source()ならその設定は関係ない。

>>818
うちは今Win7ｘ64　ラデHD4830の環境なんだけど
別にcolormatrix指定していなくてもSDでもHVでもEVRでそれぞれ正しく色空間変換されるよ
これって>>814の環境じゃないのかなぁ
つまりそこまでcolormatrixをうるさく言う必要性をあまり感じないんだけど・・・

>>821
そうです。

>>820続き
自分が確認する際に試した方法

1. ソース(地デジ ts bt.709)をDGIndexのYUV->RGBをPC scale(src1.d2v)、TV scale(src2.d2v)でそれぞれd2vを作製

2. DGDecode_MPEG2Source("src1.d2v")をx264でsrc1a.mp4を作製(src2a.mp4も同様の手順)

3. AviUtlにsrc1.d2vをD&D(VFAPI読み込み)
色変換の設定を入出力共にBT.709に設定する
拡張x264出力でsrc1b.mp4を作製(src2b.mp4も同様)

4. 以下のavsからsrc1c.mp4を作製(src2c.mp4も同様)
LoadVFAPIPlugin("DGVfapi.vfp", "VFAPISource")
VFAPISource("src1.d2v")
AssumeFrameBased().ComplementParity()
FlipVertical()
Crop(0,0,-0,-8)
ConvertToYV12(matrix="rec709")

src1a.mp4、src2a.mp4と同じ色になるのはsrc1b.mp4とsrc1c.mp4。
src2b.mp4とsrc2c.mp4はsrc1a.mp4より色が薄暗くなる。

TV scaleに設定した場合でも手順4のavsで最後をConvertToYV12(matrix="PC.709")※とすれば同じ色になります。
※ConvertToYV12(matrix="rec709").ColorYUV(levels="TV->PC")でも可能。

ちなみにVFAPI経由の方がバンディングが明らかに酷くなっていたのでやはり使わない方が良いです。

http://latoninf.free.fr/d9/SL/SmoothLevels.v1.02.avsi

TVスケール->PCスケールをするのなら、これの様なちゃんとした物を使わないと、
グラデーションが崩れてバンディングになる。

すみません確認なのですが、地デジやBS,CSの場合はSD放送であっても
「ITU-R BT.701」ですよね？

地デジでSD放送はあまりありませんね。
たとえばBS2などです。

ISDBは、SD/HDの両方とも、ITU-R BT.701になっている。

>地デジでSD放送はあまりありませんね。
NHK教育ではSDも結構ある。

>827

早速のお答えありがとうございます。

BT.709

質問するほうも答えるほうも709を701と間違っていると、さすがに釣られたくなるな

つられて間違えた。やはり、コピペなんてするものじゃないな。

放送大学のカラーバーもSDでBT.709だったよ

ISDBでは解像度に関係なくBT.709が指定されてたはず

うろ覚えでググってひっぱてきたら・・・。
609&709
ですよね。

601&709

もうボロボロっすね・・・

fack you

色々調べていると混乱してしまいました。
どなたか自分の認識の確認お願いします。

TSソースをAviSynthとx264を使ってエンコードするのに
DGDecode_MPEG2Source()でソースを読み込んで

1) 途中で色空間を変換しない＆HD→HDのままの場合
x264のオプションに--fullrange off --colormatrix bt709 をつける。

2) 途中にYV12 (a)→ YUY2 (b)→ YV12の変換あり&HD→HDのままの場合
(a)の変換に ConvertToYUY2()
(b)の変換に ConvertToYV12()
x264のオプションに --fullrange off --colormatrix bt709 をつける。
（プログレ化した後に変換しているとしてください）

3) SD⇔HDのリサイズがある場合
>>816のように最終的に
> SDからHDの場合、ColorMatrix(mode="Rec.609->Rec.709",interlaced=false)
> HDからSDの場合、ColorMatrix(mode="Rec.709->Rec.601",interlaced=false)
を使い、x264のオプションに --fullrange off --colormatrix bt709 をつける。
（途中の色空間の扱いは1)または2)のいずれか）

以上、3つともう1つ話が変わるのですが

4) 再生時にTVスケール->PCスケールしたい場合
nvidiaのコントロールパネルで再生時の伸張の設定ができるのすが
デコーダにCoreAVCを使っているの時はnvidiaの方はプレイヤーに任す
CoreAVCの方はInputでTVまたはAuto、OutputでPCまたはAutoにする。

の確認をどなたかよろしくお願いします。

> HDからSDの場合、ColorMatrix(mode="Rec.709->Rec.601",interlaced=false)
>を使い、x264のオプションに --fullrange off --colormatrix bt709 をつける。

HD->SDなら、avsはそれでいいがｘ264のほうは--colormatrix smpte170mになる
ゲフォはもう2年以上使ってないから知らん

>>839
> HD->SDなら、avsはそれでいいがｘ264のほうは--colormatrix smpte170mになる
やはり間違えてましたか。ご指摘ありがとうございます。
avsはそれでいいというのは、1)と2)は正しいと解釈してもよかったですか？

> SDからHDの場合、ColorMatrix(mode="Rec.601->Rec.709",interlaced=false)

DVD-VideoはSMPTE 170M(BT.601)だけど、日本の放送はSDでもBT.709だから、
これだけは注意する必要がある。

BT.701吹いたｗ
601なんだか709なんだかマジ分からんｗ

BS1、2もBT.709？

>>838
TSがソースなら2)はConvertToYUY2(matrix="rec709")、ConvertToYV12(matrix="rec709")
だと思うのだが、正しいかどうかは自信ないから保証しない。
あと4)はCoreAVCスレで聞いた方がいい。

ConvertToYUY2やConvertToYV12のマトリクス指定はRGB->YUVのときだけ
YUY2<->YV12でマトリクス指定するとエラーになる
自信がないなら書くなよ

レス遅くなってすみません。
>>840,>>841

間違って送信してしましました。

>>839,>>841
指摘部分以外はどうやらあっていたようですね。

また、間違えてしまいました。
これを最後のレスとします。

>>839,>>841
ありがとうございましたm(_ _)m

>>844
4)はもう少し調べてみることにします。

デジタル放送はYUV420だから、YV12読み込みで劣化なしと考えていいのかしら?

wiki色空間によるとDVDも4：2：0だから、これまで4：2：2でアナログキャプチャしてたのは
オーバーサンプリング状態だったということ?

キャプチャ時の422のメリットはインターレースを考慮しなくてもいいという点

放送やDVDと言ったMPEG-2 Video Main Profileをソースにする場合は、DGIndexでd2vを作って、
MPEG2Source("input.d2v, upConv=0)として読み込めば、リサンプリングによる劣化はしない。

MPEG2Source("input.d2v, upConv=0) -> MPEG2Source("input.d2v", upConv=0)

>>850
なるほど上のほうで出てる話だね

>>851
avisynth初めてで戸惑ったけどできたよ
ffdshowでYV12有効にしたら読めた

そろそろBCTV9 で Huffvuv YUV アナログキャプチャ マルモaui　読みから移行するよ

Helix YV12 / I420 VFW Codecs
http://forum.doom9.org/showthread.php?t=56972

YV12だけが必要なら、ffdshowよりも、これを入れるのがお薦め。

やっと分かりかけてきたのですが、AVIUTLでYUY2入力したかったら
まるもm2vか、DGDecodeとAVSを使用するかがある
でいいのですよね？

>>855
何の話？
mpeg2なら別にDirectShowFileReaderでも入力はYUY2になるが

>>813
このテスト内容ＡとＢってさ実はソースコピーしてるだけじゃないの？

AviUtlのBT.601色域入力→フィルタ適応→AviUtlのBT.601色域出力
AviUtlのBT.709色域入力→フィルタ適応→AviUtlのBT.709色域出力

すると結果が変わるんじゃないのかい？

>>779

>>858
てことは、フィルタ使うと色域のリサンプリングが行われて
同じフィルタを同じ設定で使っても違うファイルが出来るの？

プレビュー比較
.ts->m2v.aui
709->709
ttp://uproda.2ch-library.com/1918742ib/lib191874.png
601->601
ttp://uproda.2ch-library.com/191875sdZ/lib191875.png
.dv->EARTH SOFT DV.aui
601->709
ttp://uproda.2ch-library.com/191879zdz/lib191879.png

あくまでプレビューなんで、エンコーダ等に渡すデータはまた違うかも知れません

>>860
.ts->m2v.aui
m2vconf.exeでYUY2色空間行列を BT601にして
709->709と601->601 の画像お願い

Qonohaでキャプ
色変換を間違えてRGB表示すると
http://toku.xdisc.net/cgi/up/qqq/nm19106.jpg

正しい色の場合
http://toku.xdisc.net/cgi/up/qqq/nm19107.jpg

>>813のＣの実験もYUY2だけで処理してるんだから本来同じファイルじゃないとおかしくないの？

どこかでYUY2→RGB→YUY2変換してるってことだよね？

>>862
SMPTE 170M
601
ttp://uproda.2ch-library.com/191892Xxk/lib191892.png
709
ttp://uproda.2ch-library.com/191894StN/lib191894.png

>>865
お手数かけて悪いけど
m2vconf.exeの一番右下にある設定のほうです
YUY2色空間行列　（m2v.aui用）って項目
そこにBT601があるんで

ｽﾏｿ
709
ttp://uproda.2ch-library.com/191899zkG/lib191899.png
601
http://uproda.2ch-library.com/1919001Lj/lib191900.png

601->601と元のYUV維持(恐らく709)->709は同じっていうことでいいのかな

.ts->m2v.aui bt709
709->709
ttp://uproda.2ch-library.com/1918742ib/lib191874.png

ts->m2v.aui bt601
601->601
http://uproda.2ch-library.com/1919001Lj/lib191900.png

この２枚が同じになるということは・・・

ts->m2v.aui bt601
601->709
ts->m2v.aui bt709
601->709

これらと
.dv->EARTH SOFT DV.aui
601->709
ttp://uproda.2ch-library.com/191879zdz/lib191879.png
を比較しないと駄目なのね

俺はバカだ

プレビュー変わるのは入力だけ

>>871
だよね

.dv->EARTH SOFT DV.aui
601->709
これって
601->601でも全く同じになるような・・・

なんで
.dv->EARTH SOFT DV.aui
601->709　が正しい設定になってるの？

>>872
PV4は仕様上BT.601で取り込んでいるので、AviUtlの入力をBT.601とするとプレビューまでは正しくなる
m2vconfの色空間行列ををBT.601、AviUtlの入力をBT.601にしたときと一緒
出力はHDならBT.709にしておけばよい
って感じでいいのかな

>>873
出力ってどっちにしても同じファイルが出来上がらない？

>>874
変わることは変わるけど、なんか俺が思ってたのと違うことになってる
もうよくわからんので、カラーバー置いときます
ttp://www1.axfc.net/uploader/Li/so/52015.zip

>>875
↓みたいに、パートで分けて考えると判りやすいかも
　ts(bt.709)→再生機器─→PV4→.dv(bt.601)┐
┌──────────────────┘
└→EARTH SOFT DV.aui→入力色変換(bt.601→RGB)aviutlコア(RGB)→出力色変換(RGB→bt.709)→出力 ┐
┌────────────────────────────────────────────┘
└→デコーダ+レンダラ+グラボ(HD動画はbt.709→RGB)→モニタ再生(RGB) *注)RADEON DXVAの場合
間違ってたらごめんｗ

>>876
出力の方はよく分からなかったんだけど、
ts(709)->m2v.aui(709)->AviUtl(入力: 709, 出力: 709)->無圧縮AVI
上で出来たAVIをAVI->AviUtl(入力: 709）とすると、プレビューの色が元と変わってしまう
出力をBT.601にして
ts(709)->m2v.aui(709)->AviUtl(入力: 709, 出力: 601)->無圧縮AVI
AVI->AviUtl(入力: 709）とすると、合っている
で、考え方が間違ってるのか、コーデックのせいなのか、もうよく分かんないやと

aviutlの出力がおかしいんじゃないの

AviUtlプラグインの波形表示の最新版が709のベクトル表示付いてるから
それ使って調べればいいんじゃね

>>876
Aviutl内部はRGBではなくYC48(YCbCr各12bit)

入力と出力で使う色空間(YUVかRGBか)によってAviutlの挙動は変わるよ。

入力がRGBのときは入力の色変換の設定は無視される。出力もRGBのときは同じように出力の設定も関係ない。
出力がYUVなら出力の色変換の設定に応じてRGB>YUV変換して出力される。

入力がYUVだとまず入力の色変換の設定に応じてYC48へのアップサンプリングが行われる。BT.601だと従来どおり
のアップサンプリングでBT.709だとおそらく709 > 601の変換が入る。それからフィルタ処理を行うから当然入力の設定によって
処理するデータが変わることになるから出力も変わる可能性があるな。
で出力がRGBならやっぱり出力の色変換設定は関係ない。YUV出力だと入力と同じようにBT.601とBT.709とで違う計算式で
ダウンサンプリングして出力をする。

アップサンプリング時に601に再サンプリングを行うのは精度的にどうなんでしょうかね。

あちょっと訂正

入力がRGBのときは入力設定に関係なくBT.601としてYC48に変換される(と思う)ので
×出力がYUVなら出力の色変換の設定に応じてRGB>YUV変換して出力される。
○出力がYUVなら出力の色変換の設定に応じてYC48>YUV変換して出力される。

まあまとめると

　　　　　色変換設定(入力)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　色変換設定(出力)
RGB. ─── (無視) ─── .RGB>YC48(BT.601). ───┐　　 　 　 　 　 　 　 　 　 　 ┌─ (無視) ── .YC48(BT.601)>RGB. ────── .RGB
　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 │　　 　 　 　 　 　 　 　 　 　 │
YUV ─┬─ (BT.601) ─ YUY2(BT.601)>YC48(BT.601) ─┼─ フィルタ処理(YC48) ─┼─ (BT.601) ─ YC48(BT.601)>YUY2(BT.601) ─┬─ YUV
..　　　　│　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 │　　 　 　 　 　 　 　 　 　 　 │　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 │
..　　　　└─ (BT.709) ─ YUY2(BT.709)>YC48(BT.601) ─┘　　 　 　 　 　 　 　 　 　 　 └─ (BT.709) ─ YC48(BT.601)>YUY2(BT.709) ─┘

多分に俺の妄想が入ってるから盛大に間違ってる可能性が高いｗ

ちょっと気になったんだけど
入力時と出力時の色空間が違っても
(出力時に)勝手にyc圧縮/伸張はされたりはしないよね？

普段はd2v読み込み -> xvid出力
大事なソースのときはm2v.aui読み込み -> mp4出力って
使い分けてるんだけど大丈夫だよね？

>>882
ちなみにソースはTVスケールのmpeg2で
出力もTVスケールでやってます

d2v作成時の設定と読み込み設定による。
d2vで読み込むとMPEG2でフラグが正しくないとインターレース壊れるぞ。RGBだし

せっかくd2vを作るのなら、avsを読めるxvid_encrawやx264(CLI)を使えばいい。
自分でColorMatrix等を使わない限りは元のままなので、色空間で悩む必要もなくなる。

>>880
YC48、そうだった。すまん勘違いしてた。
すると無圧縮aviの中間ファイルを介してx264で出力する場合は、
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┌→プレビュー1
・ts(YV12/bt.709)→m2v.aui(YUY2/bt.709)→入力色変換(YC48/bt601)→aviutlコア+フィルタ(YC48/bt.601)→YC48toRGB→無圧縮avi(RGB)
・無圧縮avi(RGB)→RGBtoYC48(YC48/bt.601)→aviutlコア+フィルタ(YC48/bt.601)→出力色変換(YUY2/bt.709)→x264gui→.h264(YV12/bt.709)
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　└→プレビュー2
って流れになるのかな。うちでやってみたら、プレビュー1とプレビュー2は同じ色調だし、
avi入出力の色変換設定を変えてもプレビューの色調は変わらない。YUVじゃないしな。
（>>877の状況は再現せず。）

>>884
DVD2AVIで
「色空間指定」を“YUV4:2:2”
「YUV->RGB変換」を“テレビ色調”
にしてプロジェクト経由です。

>>885
親のパソコンなので勝手に入れないし
いまだにソースがアナログ録画なので明るさが
異様に低い（カラーバーの一番明るいところで170あたり）
チャンネルもあり、波形を見ながら調整できるAviutlが一番かなって。

ん〜、どうもこの"YUY"ってコーデックかAVI Readerの挙動かな･･･
多分、>>813と>>881が正解だと思うので、かき乱してすみません
ttp://uproda.2ch-library.com/192198UlD/lib192198.jpg
ttp://uproda.2ch-library.com/192199StP/lib192199.jpg
ttp://uproda.2ch-library.com/192200e9b/lib192200.jpg

AVCなら問題ありませんでした
ttp://kissho.xii.jp/1/src/1jyou97837.jpg

バカだよポップさん Log 2009/05
http://resic.laburec.net/log/2009_05.html

>>888
「AVI File Reader（Video for Windows）」は、YUY2形式のコーデックだろうがなんだろうが
RGB展開になるから、「AVI/AVI2 File Reader」の優先度を上げとくといいと思うんだ。

>>891
ご指摘どおりでした
結局、最初の>>873の考えでOKです
ttp://uproda.2ch-library.com/192261P54/lib192261.jpg

>>881
YC48(BT.601).なんて概念は無いでしょと言うのは置いといて

書くとするなら、最後の段は

..　　　　└─ (BT.709) ─ YUY2(BT.709)>YC48(BT.709) ─┘　　 　 　 　 　 　 　 　 　 　 └─ (BT.709) ─ YC48(BT.709)>YUY2(BT.709) ─┘

入力切替すると見た目が変わるんだからこうじゃないかな

>>893
見た目が変わるからBT.709>BT.601って書いてんじゃないかな

YC48はBT.601変換式（＋スケール変換）でRGBと相互変換できる形式みたいだから
便宜的にそう書かれたのでは、とエスパーしてみた

>>893
YC48(BT.601)はそのままの意味で書いたつもりではなくてようするにBT.601に準じたカラーマトリクスを用いた値に
変換されてるだろうということです。つかバカポさんのところのほうがわかりやすいです(´･ω･`)

------------------------------------------------------
http://resic.laburec.net/log/2008_12.html#20081228 より引用
------------------------------------------------------
　　＊ＫＥＮくん氏のコメント（一部引用）
　　BT.709 の対応についてですが、今後対応しようと考えていまして、
　　内部形式(YC48)は基本的に BT.601 としておいて YUY2->YC48、YC48->YUY2 変換での
　　YUY2 の色空間を設定するような形を考えています。

------------------------------------------------------
http://resic.laburec.net/log/2009_05.html#20090530 より引用
------------------------------------------------------
　　新たに実装されたBT.709モードは、入力時にYUY2（BT.709）→YC48（BT.601ベース）変換、
　　出力時はYC48（BT.601ベース）→YUY2（BT.709）変換として機能しますので（以下略）

色々議論中に話の腰を折るようで悪いのだが・・・>>838ってあってる？
DestripeやBCSInterlacedResize使って縦を縮めたときって
直後でColorMatrixを使ってやらないとサイズ戻すときにおかしなことにならない？

最終的にSDにするのなら、IVTCの後にColorMatrixを付けたらいい。
縦720以上なら、ソースのまま(BT.709)にしておく。

>>899
レスどうもです。
エンコ初めたばかりでわからないことが多く助かりました。

PT2で録画した地デジTSをVLCでPS変換し、aviutlでm2v.aui経由で読み込み、
WMVやxvidなどでD4〜D5エンコする場合
m2vconf.exeでの設定はどうするのが正しいんでしょうか
・YUV→RGB変換はどちらにチェックを？
・色空間行列（省略時）とYUY2色空間行列(m2v.aui用)は何を指定すれば良いのでしょう

何を今更、と思われるかもしれませんが、ぐぐって調べても
ここを具体的に指摘してくれてるページに出会えなかったもので…
どなたかご教示願えませんでしょうか

Utl使って再エンコするのになぜPS変換?

TSは激しく分散して記録されており、その後の作業にも影響があるので
デフラグをかねて変換するらしい

http://www.up-cat.net/CBR%25A4%25CE%25B8%25B8%25C1%25DB.html
>このため、放送用のコンテナ(例えば.ts：MPEG-2 Transport Stream)のデータをそのまま記録し、
>後ほど再生する場合には、'シークの基準は時間ではなく、データ量になる。
>つまり1時間の動画の50%部分にシークをしても、30分の部分に当たるとは限らない。
>これが30分に当たることがあるとすれば、それは擬製的なCBR（ヌルパケットやパディングなどの
>無駄なデータが含まれる）であるか、偶然前半も後半も平均すれば同じビットレートであったというだけである。…

こういうのも関係あるかもね

いや、その部分はTSでもPSでも同じじゃね？

>>809あたり？

地デジのtsストリームをTSmemoryで伸張された色はITU-R BT.601 という規格に沿っています。
映像信号の規格にはいろいろあり、コレを調べれば調べるほど本当の色ってなんだろう？って思います。
地デジはHDTVのITU-R BT.601 であるのでコレをPCの静止画の標準（？）であるsRGBに変換します。
元の色差信号がYPbPrであるので、YCbCrに変換する事も必要でしょう。

http://areya777.blog123.fc2.com/blog-entry-44.html

日本の放送はBT.709

単にBT.601って言っても、
色空間の方の「BT.601(YCbCr)」・「BT.709(YPbPr)」で使ったり、
YC量子化レベルの方の「BT.601(16-235/16-240)」・「フルスケール(0-255)」
で使ったりしてるが、どっちか分かりづらい。
BT.709でもYC量子化の部分はBT.601なんだし。

なんか屁理屈っぽいぞw
色空間スレなんだし、BT.601のサンプリング周波数が13.5MHzとかいう話なんて誰もしてないだろ。
それともMPEG2だったらITU-R BT.470-2 System B, Gと言う方が正しいとつっこんだ方がいいのか

>>907
ブログのコメントの指摘を完全スルーしててわろたｗｗｗ

大前提として色なんかだいたい合ってりゃいい

って人だからね。スルーしてもしょうがないｗｗ

最初から正しい色で読み込むか、変な色で読み込んで正しく補正するかの違いだからね
どっちでもいいんじゃない

>>907
ありやがでたらめなだけだよ
TSmemoryはまるものm2vconf.exeの設定が反映されるから
その設定次第でAviutlは601でも709でも表示できる

>>907
この人、アースソフトのPVでのキャプがメインらしいから
それ用にAviUtl本体の「色変換の設定」の「入力」をBT.601にしたままで検証やってるんじゃないかな

でも最終的に間違ってないんだろ？

>>916
そもそも正解が無いからな
sRGBの問題点はこのスレの最初のほうで語られている

ただでたらめな点がちらほらあるなーって思われるだけで
＞地デジのtsストリームをTSmemoryで伸張された色はITU-R BT.601 という規格に沿っています。
＞地デジはHDTVのITU-R BT.601

揚げ足取りとまでは言わないけど
目くじら立てるほどでもないな
コメント無視しているんじゃなくて気がついてないんじゃないの？

>>915
半年前くらいからTSmemoryが主みたいよ

まあ基本的に色空間とかどうでもいい人なんだろｗ
ttp://long.2chan.tv/jlab-long/10/s/long73846.jpg
ttp://long.2chan.tv/jlab-long/10/s/long73847.jpg

その画像はなに？

サービスです。

Liveムービーメーカーでデジカメ動画編集すると色空間が勝手に変換されて
白っぽくなってしまいますが、無変換にはできないものでしょうか？

YC伸長しないクズVGAなんだろ

>>907
わろたｗ

AとBは同じ色
http://img.f.hatena.ne.jp/images/fotolife/a/apollo440/20070624/20070624230539.jpg

これ判らない奴は色空間なんて気にするな

http://img4.imageshack.us/img4/7774/bt601.png
http://img706.imageshack.us/img706/239/bt709.png

普通の映像で、違いが分からない人は居ないだろう。

何でその映像なんだｗ

じゃあ何ならいいんだよｗ

そりゃ女の裸だろ
二次元か三次元かで別の文句が出そうだが

正座で待機

三次元TSでBT601にしたとき、肌が桃色っぽくなるのも捨てがたい。
長年アナログで植え付けられた呪縛かもしれんが・・・

BS2アナログキャプチャをデジタルに移行しようと比べてみたが
デジタルはやはり緑が弱い
avisynthのフィルタで変換しても肌色がピンクなんだな
停波までアナログでがんばることにした

アナログキャプチャがフィリップスチップだったから
最初は「ナメック病」かと思った

AviUtlの色調補正で

明るさ 20
コントラスト 46
輝度 -47
色の濃さ -36

にしてぱっと見で元との違いがすぐわからないなら色盲だから考えるだけ無駄

>>925＝>>933かね。
こないだから何がしたいんだこのバカは。

>>934
お前は一体誰と戦ってんの？w

色空間と戦ってるんだろ

マクー空間に引きずり込め!

BT.709のRGB⇔YUV変換の式を調べていたのですが、
まるもさんの2002年5月15日の記事によると、以下のようになっています。
　　Y = 0.2125 × R ＋ 0.7154 × G ＋ 0.0721 × B
　　U = − 0.115 × R − 0.386 × G ＋ 0.500 × B
　　V = 0.500 × R − 0.454 × G − 0.046 × B
一方、色空間のWikiなどを見ると、
　　Y = 0.2126 × R + 0.7152 × G + 0.0722 × B
　　U = -0.1146 × R - 0.3854 × G + 0.5000 × B
　　V = 0.50000 × R - 0.4542 × G - 0.0458 × B
となっており、微妙にパラメータが異なっているようです。
更にググったところ、
　　ttp://koujinz.cocolog-nifty.com/blog/2009/03/rgbycbcr-5d00.html
の記事に、
　　「BT.709 に関する係数値が MPEG2,MPEG4 と H.264 では異なります。（中略）
　　　どうやら BT.709 の古い規格では係数値が異なるようです。(←未確認)」
とあったのですが、この記事にあるようにBT.709の変換係数には新旧の２種類があり、
MPEG2とMPEG4では古いほう(まるもさんの記事の数値)、
H.264では新しいほう（Wikiとかの数値）を採用していると考えればよいのでしょうか？
また、Avisynthなどではどちらの変換式を採用しているか、ご存知の方はいらっしゃいますでしょうか？
（微妙な違いなので実質的にはほぼ変わらないとは思いますが）

>>938
avisynthの場合
http://avisynth.org/mediawiki/Color_conversions

>>939
ありがとうございます。英語Wikiにそんなページがあったのですね・・・失礼しました。orz

その後また調べていたのですが、
　　ttp://developer.apple.com/quicktime/icefloe/dispatch019.html
を見ると、Avisynthやまるもさんの式はBT.709-1で規定された式で、
色空間Wikiなどの式はBT.709-2から変更された式のようですね。
なんだかややこしいのですね・・・。

まあ8ビットはもちろん12ビットでもめったに違いはでないと思うけどな

>>940
CIE1988で青色側の視感度曲線の修正案が承認された。
但し、xy色度図を変更することは避け、あくまでも参考値とされた。
しかし、多くの実用上での眼の特性はこの方が忠実であることは判っていた。

従って1990年以降の規定は有効数字が3桁しかないXYZ系に従わず、
その後の精度面での成果を組み込んで4桁以上の規定がされていったということ。
尚、Y値だけはもともと7桁精度がある。それまでのuvの4桁は単なる補間値。

Y値のBの係数が相対的に大きくなる方向に修正されている。

あれっまた間違えた
誤：有効数字が3桁しかないXYZ系
正：有効数字が3桁しかないxy色度図（厳密には1桁とも言えるが）

現在、勉強中の素人ですけど教えてください。
先日某実況スレでキャプ職人さんがUPした画像を見て
「色空間が変だぞ」、違うスレでは「二重伸張だ」と言ってる人が居たんですが
素人の自分には全く分かりませんでした。玄人になると見ただけで分かる物なのでしょうか？
または、調べる方法やソフトなどが有るのでしょうか？
宜しくお願いします。

素人なら気にするな

>「色空間が変だぞ」、違うスレでは「二重伸張だ」と言ってる人が居たんですが
ダウソ板でやれ

色空間が変といえばGM1ziAg9V9

>>944
玄人になると雰囲気でわかるよ、マジでｗ
色空間、おそらくカラーマトリクスの事だと思うが、雰囲気で間違ってるってわかるようになる。
二重伸張、おそらくYC伸張を二回かけてる事だと思うが、こっちはすぐわかるようになるよ。

>>945
確かにその通りなんですが好奇心て奴が…
>>946
ダウソ板で質問するべきでしたか、板違い失礼しました。
>>947
鳥は付いてなかったので、その人かは分かりませんが…
>>948
やっぱり分かる人には分かる物なんですね
知識と経験って奴ですかね　奥が深い…

皆さん、レスどうも有難う御座いました。

ああああああああ
ずっとtsのHDソースエンコしてたから
tsのSDソースでBT.709>BT.601に変換すんの忘れてソース消してしまったｗ
一応--colormatrix "bt709"指定してるけど704x396だから複雑な気分だｗ

そんなに外れるわけじゃないから気にするなｗ

MonsterTV HDUSで抜いたTSなんですが、
これってYUY色空間は飽和レンジになってるはずですよね？
FFdshowのヒストグラムで確認したところ、
アニメ番組だとそのようになっているようですが、
NHK「MUSIC JAPAN」のライブ映像だと、
シャドーだけ圧縮されてハイライトはフルレンジめいっぱい使ってるようなのです。
これはどのような意図で作られているのでしょうか？
テレビでも問題なく視聴できて、
PCとかフルレンジ対応の機器ではハイライトの諧調を残せるとか？

235-255はよくスーパーホワイトって言われてる。実写では割とよくある。
家電テレビならダイナミックコントラストで調整してくれるだろうしPCでは
デコーダーかビデオカード次第だろう

Radeonならダイナミックコントラストを有効にするとスーパーホワイトも飛ばないようになる
家電より反応が遅くて、シーンチェンジでちょっと輝度が不安定になったりするが

>>953
>>954
ありがとうございました。スーパーホワイﾄでググって理解しました。
放送でも100IRE以上を含む可能性があるということですね。

輝度が236-255のスーパーホワイトまで使われてる映像というのは
CbCrについてはどういう扱いになってるんだろう？
色も16-255 or 0-255のように広く取られてるのか、それとも16-240に収まってるのか…

難しすぎ(；´∀｀)

>>953
空を飛ばしてでも顔を明るくしたかったりするからな。

>>956
スーパーホワイト部分はあくまでもオプション扱いなので
Yが16-235（+20）でCbCrもしくはPbPrは16-240

m2v.auiで読み込んで地デジTSをAviUtlでエンコする場合、m2vconf.exeの設定を
・YUV→RGB変換 をストレート変換
・色空間行列（省略時） を自動認識（解像度から）
・YUY2 色空間行列（m2v.aui 用） 元のYUVデータを維持
に設定した場合、YC伸張フィルタを使うと2重伸張になる、であってますか？

TSはBonTsDemuxでm2vにしてあります

>>960
m2v.auiならVFAPIじゃないんで、YUY2読みになるから、
・YUV→RGB変換 をストレート変換
・色空間行列（省略時） を自動認識（解像度から）
これ関係ないんじゃね？

で、そこでYC伸張フィルタ入れるだけなら、
単にフルレンジのデータになる。

ただし、今の一般的な再生環境だと、再生時に伸張するのが多いから、
そういう時は、再生結果は2重伸張になる。

>>961
レスありがとうございます
なるほど、再生時に伸張してくれるんですか
て事は、一般的にはYC伸張フィルタは掛けなくても良いって事ですね

僕　インタレ解除時と中間ファイル完成時に
両方ＹＣ伸張かけてzoomeに投稿した動画の色が好きなんだけど
これってwebプレイヤーでもＹＣ伸張かかってるだろうから３重伸張になるの？

わろたｗ

>>963
うん？俺間違った解釈しちゃった？
詳しそうだから是非>>961をもう少し分かりやすく答えてほしい・・・

僕完全に横槍レスだから気にしないで
自分が好きな色で良いんじゃねってことでｗ

それ、このスレにいる必要なくね？ｗ　いや、まあどうでもいいんだけどｗ

PCとTVの規格が違うから面倒だよねｗ

ん〜、質問の仕方が悪いのかそれとも
質問スレじゃないから質問スレ行けってこと？

>>969
いや、だから>>963は関係ないって言ってるじゃん。
再生時に[16-235/240]から[0-255]に伸張してるなら要らない。
そっちの再生環境が伸張するのかどうかは知らんけどさ。

>>970
そうですかありがとうございます
>>963読んだらやたらと気になったので。

>>971
もう2度とくんなよｗ
うざいからｗ

つーかここ質問スレじゃないぞ

　よ　ほ　う　診　 医　精　一　忠　は　あ　ま
　さ　 う　け　察　.者　神　度　告　て　き　さ
　そ　が .た　を　 の　科　　　　す　た　れ　し
　う　　　　　　　　　　　の　　　　る　な　　 　 く
　だ　　　　　　　　　　　　　　　　が　 ：
､＿__　　　　　　　　　 ＿__　　　　 　 ：
　　 (＿＿＿＿＿,／::::::::::::｀ヽ、
　　　　　　　　　 /::rー‐-ｰ-､:::l＿＿, 　 , -─
　　　　　　　 　 _|:lr_‐､￣-=､l:::|　　 /／
　　　　　　　　/)Y ´ﾟ｀ri　､'ﾟﾞ' |/,〉 /´
　　　　　　　　|｀ |l　/ヽ _,ノｌ　|ﾉ|
　　　　　　　　ヽ_|　'-=ニ=-l　!/
　　　　　　　　 /|ﾊ　　-‐　　/＼
　　　＿,. -ｰ'`´ l l ＼　 　 /'/!　l`ー-､＿

>>974
自覚してるなら早く行ってこいｗ

ここまで俺の自演

　

DVDの色ってBT.601って規格ですよね？
DVDをアプコンしようと思ってるのですがあってるかどうか不安なのでちょっと質問です。
Avisynth→Aviutl→x264でエンコしようと思ってます。リサイズは780x420→1280x720。


まずリッピングしたVOBをDGindexでd2v+wavにする。

d2vをAvisynthにDGDecode経由で読み込み。

インタレ解除やノイズ除去等の処理後にConvertToYUY2で"YV12"を"YUY2"へ変換。

AvitulにAvisynth Script File Reader経由で"YUY2"読み込み。(サイズは720x480のまま)

AviutlでYUY2を読み込ませる場合、入出力でBT.601とBT.709の二種類あるんですけど
この場合はどっちにチェック入れればいいのでしょうか？

BT.601とBT.709はYUV2→RGB変換でしか関係ない？

マルチ乙
しかも他のスレで質問した方で答え出てるのに
何しに来たんだ？

僕　色変換の設定は自動でやるのが好きなんだけどこれってまずいの？
YUV2→RGB変換じゃないから関係ないんですかー？

愛があれば大丈夫さ。ちょっと色が変わったって愛がカバーしてくれる。だから大丈夫さ。