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

ループ上等。
フォーマットそのものや、YC伸張(スケール変換)、
オーバーレイやTV出力等々、総合的に議論するスレです。

過去ログ

YC伸張する？しない？総合ｽﾚｯﾄﾞ
http://pc8.2ch.net/test/read.cgi/avi/1050299614/

映像の【色】総合スレ
http://pc.2ch.net/test/read.cgi/avi/1062148940/

(ﾟ�听)ｲﾗﾈ

sRGBって色を赤くして濃くしてるだけなのですか？
もっともテレビに忠実だとか言われてるけど正気の沙汰とは思えない色合いです。

>>3
カラーマッチングの基礎概念が分ってないと思われ。

そもそも、ITU-R.BT601に合わせてキャリブレーションしてるのかと小一時間・・・

sRGBって緑とかの表現が・・・
AdobeRGBを擁護する訳じゃないけど、
sRGBが世界標準・標準環境になってしまうのにはギモンを感じる。

ここで注意しておきたいのが綺麗に見える色が自然界では必ずしも自然ではないということだ。

色スレ復活おめ！

D65光源+sRGB=ITU-R.BT-709=HDTV

ここが参考になる
ttp://jumper-x.hp.infoseek.co.jp/begin/status/2/

>>6
AdobeRGBはDTVには必要ありません

色が間引かれてる映像は、なぜ赤色系だけが大きく劣化するんですか？

>>12
劣化した信号をテレビで見るからです。

AviUtlで拡張色調補正フィルタと色域変換フィルタを使って
大雑把に再現してみましょう。

1) フィルタの順序を、拡張色調補正を上にする
2) 色域変換を「ITU-R BT.609」から「ITU-R BT.701」に設定する
3) 拡張色調補正で「Y(gain)」を下げる

赤色系って、DSフィルタやオーバーレイで劣化を補正しても
チープな感じが否めない(;´Д｀)

チープな感じって意味がわからないけど
色情報の補間なしじゃもっとチープ（？）じゃない？

動画データはYUV（NTSC）で編集・保存して、PCで見る時にsRGB変換ですよね。
でないと、ユニバーサルじゃなくなるから。

>>16
現在のWindowsでは動画に関するカラーマネジメントが存在していません。
ですので、何をどうするのも自己責任ということになります。

実際問題として商用ソフトウェアにAVIやWMVのデータが付いている場合、
たいていPCのディスプレイでそのまま再生して色が綺麗に再現されるように
作成されています。
ですので、AVIやWMVでは sRGB に変換しておいた方が無難だと思います。

ただ、データにカラープロファイルを付けられるなら利用した方がいいでしょう。
特にMPEG-2の場合、DVDはBT.601、デジタル放送はBT.709と分かれている
こともありますし、積極的に利用すべきだと思います。

とはいえ、NTSC(BT.601)に限って言えば、規格が古いため将来性は
かなり怪しくなっています。例えば、H.264 では NTSC が指定できません。

sRGBに変換って何？具体的にどうすること？

>>18
決まってるじゃないか！色を赤くして濃くする変換技術。

デジタル・リ・マスターとも言う。

代表例
千と千尋の神隠し
ttp://www.synapse.ne.jp/komurano/taiki/sen/

>>19
青いサングラスをかけて見る

ﾜﾛﾀ

>>19
犬の実験面白いね。しばらく白く見えた。徐々に回復して言ったけど…
網膜細胞が受け取った光を電気信号にして視覚分野で処理してるゆえの現象かな。
精神病患者は赤いりんごが青くみえるというのも頷ける。
色の見え方には個人差というものが存在するのかもしれない。

昔、NHK特集でやってた脳と心って番組の本だけど、面白い。
ttp://www1.odn.ne.jp/~aak41360/newnhkspecialzintai2.htm

紫色の不思議
http://science3.2ch.net/test/read.cgi/sci/1101166711/
【眼の科学】視覚についてもっと知ろう【目のスレ】
http://science3.2ch.net/test/read.cgi/life/1113846988/

視覚は曖昧ということか、ちゃんと波形表示見てつくらないと駄目だな…

千と千尋か、懐かしいな。
初めて地上放送でやったとき、実況板がとんでもないことになってたけど。

>>18
色温度とは何か？ということについて知らなくてはならない。

色に温度？不思議と思うかもしれないけど、宇宙には太陽のような恒星がいっぱいあるのって、
知ってるよね？
恒星は温度によって輝きが違う。表面温度が低いほど赤く高いほどくくなる。
例えばアンタレスは表面温度が3500℃だから赤く、リゲルは13000度だから青い。
太陽の表面温度は6500℃と言われてる。
つまりsRGBとは、我々の太陽から照らされる自然光ということになる。

質問に答えてもらってないような気が・・・
sRGBについて聞いてるわけではないんだけど・・・

いや、言葉の意味そのまんま、「変換」するわけだけど。。

たとえば、AviUtlのcgcnv2.aufでいうと、

γ関数をsRGB、色域はHDTV、YUVマトリクスは・・たとえばYCbCrへと。

http://www.geocities.jp/aji_0/colormetrix.html


自分事ですが、色域はAdobeRGBにするのが俺のジャスティス、と考えてた時期がありました。

AviUtlにそんなプラグインがあったのか
それは知らなかった

>>21
最近周りがブルーに見えるのはそのせいだったのか…
飯も喉を通らないほどの欝状態。
病院でカウンセリング受けるかな……

>>26
ハァ？
キャプチャ時にちゃんとキャリブレートされているという前提なら
色空間の変換はしないのが鉄則だろ。
再生時に、再生デバイスに対して「この映像の色は○○ですよ」という指定をしてやればよい。
または、手動でパラメータを適宜調整する。

世の中キャプチャソースだけではない

|∀・）つブルドッグ・ソース

ttp://www10.plala.or.jp/p205tb16/scale.txt

>>32
その情報はずいぶん古いな

そもそも、PCで再生する際に、俗に「YC伸長」と呼ばれる手法で変換してもダメ。
NTSCならNTSCで作られたソースを「YC伸長」してsRGBのモニターで表示しても色は合わない。

ちょっと難しい話ですけど、こちらに興味がある方が多そうなので転載します。

>--------------------------------------------------------------------------------
>
> 655．Re: NTSC to sRGB Directshow Filter ver2.4
>名前：AQ 日付：5月19日(木) 15時17分
>あじさん、はじめまして。
>
>不具合というわけではないのですが、このフィルタをかけると人物の肌色が赤みがかった色になります。
>上の方のコンテンツに小泉首相の画像がありますが、ああいう感じの色です。
>ちょっと赤っぽいですよね？
>
>私もM190ユーザー（sRGBモードで見ています）なので、多分あじさんと同じ環境だと思います。
>
>もう少し自然な感じの肌色になってくれると嬉しいのですが。
>
>ご無礼をお許しください。
>

>--------------------------------------------------------------------------------
>
> 656．Re: NTSC to sRGB Directshow Filter ver2.4
>名前：あじ 日付：5月19日(木) 18時23分
>NTSCのC光源は蛍光灯に近くて、sRGBのD65光源は電灯に近い色なので
>赤みを帯びるのは規格通りなんですよね...
>N2S DSFには光源を変換しない「Keep Illuminant」の設定があるので
>とりあえず使ってみてはどうでしょうか。
>
>--------------------------------------------------------------------------------
>
> 657．Re: NTSC to sRGB Directshow Filter ver2.4
>名前：あじ 日付：5月21日(土) 15時13分
>一応技術的な補足をしておくと、人間は可視光の範囲の色んな
>周波数分布の特徴を単純化して記憶します。これが「色」です。
>ただ、単純化してしまうため、全然違う周波数分布でも同じ色に
>見える場合があります。

>ここで光源が変わると周波数分布全体が変わるので、２つの物体が
>ある光源の下で同じ色に見えていても、光源が変われば違う色に
>見える場合があります。
>これは、２つの物体は反射率の周波数分布が異なっていたけど、
>最初の光源ではたまたま同じ色に見えるような光を反射していた
>わけです。(これを条件等色と言います)
>
>現実は上のように、光源ごとに同じ色に感じる組み合わせは
>変わるものなのですが、一旦物体の色をRGB値で表現してしまうと
>その色がどんな反射率の周波数分布に由来しているか分からなく
>なります。
>極端に言うと、赤色レーザーを照射してある物体を撮影すると
>当然RGB値のGとBは0なんですが、じゃあその物体に青色レーザーを
>照射して撮影してもBの値は0かというと、それはその物体次第
>なんですね。
>RGB色域の変換とは、これを「常にBの値を0にする」変換なのです。
>だから、何らかの副作用は存在します。
>

>一方、人間の脳味噌はもっと巧妙で、視界全体の色の傾向から
>過去に見たことのある光源を推定したり、見ているものの形の
>認識によって色の認識が左右されたりします。
>
>つまり、人間は光源別に顔の色はどんな周波数分布の特徴が
>あったか記憶しているわけで、これは光の周波数分布を
>RGB値という単純な数値に置き換えた時点でもう再現不可能です。
>
>要するに、色をRGB値で表すカラーシステムでは、RGB値に
>した後で何らかの変換をすれば必ず副作用を生じます。
>再現性を追及するなら、光→RGB値の変換(撮影)と
>RGB値→光の変換(ディスプレイ表示)で条件を一致させて、
>途中で変換が不要にするべきなのです。
>
>sRGBやデジタルTVのRGB値がディスプレイの色域に合わせた
>特徴を持っているのはそのためです。
>逆に言うと、NTSCのようにディスプレイの表現域を超えた
>範囲のRGB値は、必ずカラーコンバートが必要になるため
>色の再現性で不利なのです。
>

>前置きが長くなりましたが、
>>もう少し自然な感じの肌色になってくれると嬉しいのですが。
>これを実現するためには、厳密には
>・画面全体の特徴を認識して、光源を推定する
>・光源ごとの「肌色」データベースで色を変換する
>ことが必要です。
>まあ、さすがにこれは非現実的なので、実際にやるとなると
>RGB空間上に「ある光源での肌色」の範囲を決める感じで
>処理することになりますが...N2Sでこれをやるというのは
>正直無理があります。愚直にカラーコンバートするだけでも
>既に重すぎるくらいですし。
>
>まあ、そんなこんなで...
>NTSCというディスプレイの色再現とはかけはなれたパラメータで
>撮影されてしまった信号を、気合の入った色処理でディスプレイに
>写すならやっぱり高級家電TVを買うべきなんじゃないですかね。
>
>申し訳ないけど、物事には限界があります(汗

読み返すと若干不正確な表現がありますが...
概略と言うことでご容赦を

このスレってこういう感じなのか？
どういう人にとって必要な知識なのかが分からん
テレビキャプチャする人がsRGBなんて意識する必要ないんでしょ？

DTVってちゃんとノート取って勉強しないと地雷ファイルだらけになりそう
俺みたいに(^^

地雷処理はプラグイン作者の仕事。
一般エンコーダーは普通にエンコすればいい。
普通にエンコして地雷になるようならプラグイン作者の責任。

>>42
プラグイン作者といっても、プロからアマまでいるしな。
フリーのプラグインなら、それを選んだユーザの責任だろ。

勉強する気無いなら、家電でやればいい。

だな

結局家電ﾚｺ使ったほうが早いよな
ｷｬﾌﾟﾎﾞ、ｷｬﾌﾟｿﾌﾄ、ｴﾝｺｿﾌﾄでのRGB、YUVの色空間の違い
圧縮、伸長の方法やら素人には複雑すぎて手に負えない

もともと素人が適当にやってもうまくいくようになってたのに
YC伸長だなんだと素人を惑わせる人が出てきたからだよ

ヒストグラムを見れば、素人でもYC伸張の意味がわかるけどなｗ

>>45
というか、民生機器やPC周辺機器業者が色空間について理解した上で開発してるのか
不安になって来た…
ボードによっても色合いがまちまちだしなぁ。

>>48
色合いなんて個々のPC環境に依存するからな（グラボ、モニタ等）
ヒストグラム表示できるフロントエンドで逐一チェックしないとどうにもならん。

PCモニタに合わせて鮮やかな色にするって機能、
ありがた迷惑になってきたな。

>>48
AV機器のLSIには普通にカラーコンバータ入ってますよ。
通常は N2S と同じように ICC ワークフローのコンバートのはずです。
チューナー付きテレビだと色々工夫してるでしょうけど。

家電って、デフォでもかなり綺麗な色が出るような

もちろん機種や設定によって全然違うんだろうけど、家電は鮮やか杉の色と
NRを効かせすぎでノッペリした画質というイメージが全体的にある。

ビクターなんかは特にそうだね。

デジタイザの差もあるんだろうけど彩度とコントラストを上げて
意図的にメリハリのある画質にしてる

peg2ﾌｧｲﾙを作るときに　YC伸長ﾌｨﾙﾀで開始高輝度を16終了輝度を235に
設定すると　例えば人間の髪の毛なんかpcﾓﾆﾀｰ上では真黒になるけど
これでいいの？

>>56
よくないｗ

VMR9使いたくて、やっとDirextX 9対応のグラフィックボード
買ったのに、VMR9はYC伸張されない仕様なんですね。
ずっとオーバーレイでYC伸張された動画見てたから違和感がある。
このままオーバーレイ使ったほうがいいのかな。
念のためRADEON選んどいてよかった。

だから自前でYC伸張済みを渡してやるんだよ

>>59
それってタイミング的にはCodecのデコードが
終わったあとになりますよね。
なんかそこまでCPUでやってしまうと
VMR9使ってCPU負荷を下げたいという
当初の目的が満たせなくなってしまうような。

VMR9はゴミ。
さっさと死滅しろ。

ProcAmpで調節すればいいだけじゃん
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dxvaguide_c0890752-2fdc-4f74-a537-b5a56f9cdf16.xml.asp

>>60
ソフトウェア処理のVMR9の時点で負荷はVMR7よりも高い
CPU負荷下げたいなら素直にOverlayでも使っておけ

前使ってたのDirectX6世代のグラッフィクボードだから
一気に3世代通り越して浦島太郎状態なんだよね。
前のボード、オーバーレイくらいしか使えなかったから
ハードウェアデインターレースは普通に感動した。
とりあえず、やりたいことと現状の問題点を整理しとくと

・再生したいファイルは主にインタレ保持MPEG-2とWMV9(インタレ保持を含む)

・RADEON 9600の動画再生支援機能を出来るだけ使いたいが
前のボードのオーバーレイ(RADEONのデフォルト値と大差ないと思われる)と
同じような色で再生したい。

・MPEG-2はWinDVDのレジストリのDXVAを弄ってハードウェアデインタレースに
なっているようだが、どうも伸張されていないのが気になる

･RADEON友の会のスレを参考にCATALYSTのレジストリも弄ってみたけど元に戻したつもり

･久しぶりにffdshowをインストールした
デフォルトからあまり変更してないけどメリット値が〜〜〜

・WMV9のスレで紹介されていたWMP10のパッチを当てた。
なんか、WMV9 APのデインターレース再生が以前の環境で
再生していたものと違うように思えるけど詳細は調査中

・オーバーレイはふぬああの視聴時に使っている
録画時はプレビューにしているがふぬああの色と
エンコしたファイルを再生しているときの色が違うのは普通に困る
エクスプローラにオーバーレイを奪われるのも出来るだけ避けたい

>>62のProcAmpも弄ってみたい気がするけど、これ弄れるアプリとかあるの？ 作らなきゃだめ？
もうそろそろ弄りすぎてシステムがどうなってるのか把握できなくなって来た。
もうすぐクリーンインストールする予定だけど、それまでに設定決めたいよ。

何かVMR7でオーバーレイ使えばすべて解決するような気がしてきた。

WinDVDのレジストリ弄ったのとWMP10のパッチ入れたのが
システムにどう影響を及ぼしているかわからない。

レンダラによってはインタレ解除されてなかったり、
ピクセル比反映されてなかったりなんか怪しいぞ。

WMP10のパッチはレンダラの設定に関係なく
強制的にVMR9になってそうだ。どうも伸張されてなさげ。

>>66
WMP10はレジストリ直接弄らないとVMR7にはできないよ

>>67
ヘルプには

[ビデオ ミキシング レンダラを使う] → VMR7を使用
[高画質モードを使う] → VMR7 YUVミキシングレンダラを使用

とありますが、これが間違いということですか？
パッチ入れたせいで高画質モードがVMR9になったのかと思いました。

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |
　　　　　|　 　 　 　 | ∧＿∧　|　　 |
　　　　　|　 　 　 　 |（　´∀｀）つ ミ |
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 | 　VMR9
　 　 　 　￣￣￣￣'￣￣￣￣　 　 |

VMR9はマジでイラネ

>>48
色空間じゃないけど、ソフトも怪しいのありますよ。
どことは言わんけど、DVからは絶対にトップファーストのMPEG2を作ってくれないソフト。
CCEだと作ってくれるんだけど。

>>48
当然理解はしてると思いますが、
メーカーごとに味付けされてるんじゃないかな？
所詮素人向けの機器だし…

RADEONにおいて非オーバーレイのVMR（VMR9など）でYC伸張する方法発見
試したドライバはCatalyst5.6

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{YOUR GUID}\0000
に文字列のエントリ"UseBT601CSC"を新規作成
値を 1 にすると非オーバーレイのVMRでYC伸張するようになる
0 だと従来通りのストレート変換

レジストリ変更後は要再起動（または3Dタブのスライダなどを適当いじって戻る）

常時強制ハードウェアYC伸張みたいなものか？

スカパをアナログキャプなんですけど、
元はペグ2だから4:2:0だと思うけどアナログ
でとると4:4:4になってるの？
YUY2で撮ってるから4:2:2になるけどこれって
損失あるのかな？

ふぬああでhuffyuvS(CCE)YUY2キャプ。
aviutiで編集、再びhuffyuvS(CCE)YUY2で中間ファイルはいて
CCEBasicでMPEG2にしてます。

補完されたアナログ出力を｢4:4:4｣とは言わないよ。
普通のアナログを4:2:2でサンプルするなら実用上の｢損失｣は無いから大丈夫。

アナログ(NTSC)信号では、色はフィールドごとに市松模様になってるから
4:4:4でも4:2:2でもない。情報量的には4:2:2に近い。

キャプボはアナログ信号からITU-R BT.601って規格で4:2:2の
デジタルデータを作る。これがYUY2。

ペグ２はさらに縦の解像度を半分にした4:2:0。

だから、スカパぺぐ２→アナログでは縦横に、
アナログ→YUY2では横方向にサンプル形式の変化がある。

だけど、縦方向は解像度が上がる変換だし、横方向も解像度が
あまり変わらない変換なので、輪郭がぼけたりはするけど
情報量が半分になるような大きい損失はない。

NTSCの4:2:2の帯域の比率がまず先にあって、BT601やYUY2ってのは後付けの規格だよ。
市松模様だから4:2:2ではない、って訳じゃない。

でもNTSCのこの関係はもはや過去の遺物だから別にいいんだけどね。

帯域はY:I:Q=4:1.5:0.5

サンプル点は市松だけど、コンポジット信号を
そのまま保存するのでもない限りLPFに突っ込まれる

過去の遺物というのは、その通り

「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
受信機のNTSCデコーダではY:U:V=4:0.5:0.5で処理している。」
という記述をよく見るんだけど、やっぱり民生品では
Y:I:Qで色をデコードしてるのって存在しないんでしょうか？
コンポジット出力も同様なんですか？

>>80
放送はチャネルあたりの帯域自体が狭い
>「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
してない
でもスカパーには関係ない
放送信号とコンポジットとＳ端子とＤ端子では全部帯域が違う

YIQ、YCbCrと帯域は何の関連も無い
YIQとYCbCrなんて位相が違うだけで実質同じ
どういう理由で関連があると思ったんだ？

ちなみにNTSCの色差は離散アナログ値なんで、
サンプル位置と帯域も別の話な

4:2:2相当とかに無理にあてはめても混乱するだけだ

あの…
つまり今のままで大丈夫なんでしょうか…？(ﾋﾞｸﾋﾞｸｯ

>>83
大きな損失は無いから実用上問題ない

ソースがスカパーなのは大問題だけどな

Yは普通に範囲内に飽和させてますが
CbCrも飽和させるもんなのでしょうか？
濃過ぎません？

>>85
CbCrも範囲内に飽和させればいい
↓
元々範囲内に収まっているなら何もしなくていい

>>86
ありがとう！

AviUtlにYUY2〜飽和ってあるじゃないですか、
飽和の意味調べたらぎりぎりまでいっぱいに
するみたいな感じだったから疑問に思ってたんです。

つ飽和演算

ほわほわ

ほっちゃん、ほわほわ

ttp://sakots.pekori.jp/cgi/sn/src/up23955.jpg

ffdshow050711で確認したんだが、
YUY2,YV12で出力するとオーバーレイ、VMR9に限らずRGB32で出力したときより灰色っぽくなる。
結局どの色空間で動画見れば一番いいのかわかんなくなってきた

RGB32

>>92
とりあえず落ち着いて近所のカラスでも眺めてみなよ
そのカラスも灰色に見えてきたらそれは、眼科に( ry

あまりよく分かってないで質問するんだが・・・

通常のYUV色空間で飽和されたAVIファイルがあるんだけど
TV出力で見ると最適なんだけど、PCディスプレイで見ると
何か暗く見える。

で、PC以外では見ないことを前提にして、TVで見たときと
同じように適切な色がPCディスプレイで再現されるように
再エンコしたいんだけどどうすればいい？

違和感なく見えるようにオーバーレイで調整しろ

>>96
なるほど。

一部の公開ファイル（映画の予告編とか）で、PCディスプレイに
最適化してるのがあるけど、そんなのは、どうやって作るのかなって
思ったもんで・・・

msyuv.dllの減色問題ってXP SP1以降なら気にしなくて
いいんだよね？

>>98
msyuv.dllをhuffyuvdllなどに置き換えるのは、
DirectX8のmsyuv.dllのYUV->RGB変換が16bitという"仕様"のため。
DirectX9を入れてたら問題なし。

>>99
そうでしたか！
今DirectX9cなので大丈夫かな。(これはこれでどっか悪いらしいですが…色が大丈夫なら(・ε・)キニシナイ!! )
どうもありがとうございました。

あげ

age(ﾟдﾟ)age

テストチャート
http://www.belle-nuit.com/testchart.html

ダウンスキャンコンバータのような機器でWindows上のオーバーレイのみを
アスペクト比固定のままでS端子やD端子でTV出力出来る機器は有りますか？
もし有ればTV用の映像製作等でTV出力画面を見ながらPC側でメイクや調整が出来るのですが・・・。

hosyu

http://www.geocities.jp/aji_0/
↑にあるNTSC to sRGB Directshow Filterをつかって、
ふぬああで視聴時にリアルタイムに色域変換できないのでしょうか？
録画済のAVIファイルなら変換されるのですが、
ふぬああでリアルタイム視聴にも使いたいです。

>>106
ビデオフィルタの設定で「NTSC to sRGB」を接続した
プロファイルを作って、デバイスの設定→グラフの
ビデオフィルタにそのプロファイルを適用すればいいんじゃない。

返答ありがとうございます。
NTSC to sRGBという名前のフィルタが見当たらなく、
代わりにColorSpaceConverterというものとColorConverterというものがそれっぽいんですけど、
ColorConverterのほうは接続不可となって利用できないのでColorSpaceConverterだけ利用できるみたいで、
こちらを利用してフィルタで使ってもいまいち変化が見られないんですがこれくらいしかやれることはないものなのでしょうか？

つ regsvr32 ntsc2srgb.ax

よくわからないです・・

>>110
一覧に無いのはフィルターが登録されてないから｡
ふぬああのインスコ時にやった事をもう一回やればよい｡

そうだったんですか。
やってみます。
アンインストールしたくなったときはどうしたら元に戻せますか？

　　 ?? 　 ??　　　　　　　　　　　　　　　　　　　　　　??　　??
　 ??::　 ?　　　　　　　　　　　　　　　　　　　　　　　　　?　　::??
　??::　　　　　 　　　　　　　　? 　 　 　? 　 　　　　　　　　 　:::??
　 ??:: ::　　　　　●　　　 　?::　 　 ?　 ??　　 　 ●　　 　:: :::??
　????:: 　　　　　　　　 　 ?:::　 ??　::??　　　　　　　 　::::???
　 ?????:::: ::　　　　　 　　??:::? ?:::??　　　　　　　 :: ::::???
　　 ??????:::: ::　　　　　　 ??　　??　　　　　　　　:::????

　　　　　　　　　　　　知らんがな

レジストリに登録（？）するので元にはそう簡単には戻せないのかな？

>regsvr32 -h

を実行してみよ。

ntsc2srgbのアーカイブにインストール用と
アンインストール用ののバッチと入ってるがな

そのパッチ実行するとntsc2srgb.axもアンインストールされるんですか？

ちったあやってみてから聞け

やってみればすぐ分かる事を何で聞くかなぁ。
しかもよく分からないものに手を出すなんて。

よく分からないからきいたんです・・

>>120
＞やってみればすぐ分かる事を何で聞くかなぁ。

やると何がおきるか分からないからきいたんです・・

この先生きてて何があるかわからないので早く死んだ方がいいですよ。

地アナキャプったのってエンコる前にsRGBとかに変換した方がいいの？

なにごとも注意は必要ですから・・

No

インスコ
regsvr32 ntsc2srgb.ax

アンインスコ
regsvr32 /u ntsc2srgb.ax

流れﾜﾛｽ
やり方示したからさっさと死ねよ☆

一週間前の流れになに言ってんだか（　´,_ゝ`）ﾌﾟｯ

今さら過去ログを読みなおしてみたが、AviUtlの波形表示プラグインの見方を勘違いしている
奴がいて混乱させられたのを思い出した。

どういう勘違い？
俺もしてるかも。いまいちよくわからん。

上下の線は16,235(240)なのに0,255だと思っていたり、YUY2読み込みしつつCCIR601用の
補助線は意味がないと筋違いのことを言ったり、まあ理解が浅い者を惑わすようなことを
していた。

あー0.255だと思ってたわ・・
だってCCIR601補助線？をだすと16と235に線がでるよね？
255メーターをスライドすると一番上にあった線が一番下に来るよね？
だから0.255だと思ってたわ。

>>131も間違ってる希ガス
間違っているというか、常に正しいとは限らないというか

はっきり間違ってるって言っちゃえよｗ

そりゃあ上で書いたことは前提があるわけで。そういう些末なことでなく、
使い方を誤った上で波形表示プラグインは信用できない代物扱いしている
者がいたという話。

CCIR601補助線？をだすと16と235に線がでるのはなぜ？
255メーターをスライドすると一番上にあった線が一番下に来るのはなぜ？

>>136
CCIR601用の補助線だから。つまり、ストレート変換あるいはそれに相当する状態に
して使うべきもの。だからYUY2読込みのときは普通は用がない。それで補助線は
無意味だと言うのはそれこそ無意味。拡張色調補正でPC->TVスケール補正にチェックを
入れて、範囲外のデータの様子を見るのに使えないこともないが。

> 255メーターをスライドすると一番上にあった線が一番下に来るのはなぜ？
ごめん、意味がよくわからん。どういう操作をしたときの話?

拡張色調補正などでyoffを-256とかにすると
丁度一番上にあった輝度が一番下にこなかったっけ？
だから波形表示は0-255でやってるのかと思った

>>138
ああ、ようやくわかった。Y(offs)を-256にすると一番上の線にあったのが一番下に
行き、+256にするとその逆になるという話か。デフォルトだと幅は±256になるから
余り気にしたことがなかったな。

16とか235とか書いたが、正確には説明書に書いてある通り。
> 補助線はYCbCr/RGB表示時で、このチェックがOFFの時は
> 下又は左から0%（色の-100%）,50%（色の0%）,75%,100%（色の+100%）の
> 位置に線が引かれます。
> このチェックがONの時は、下又は左から0,0%,色の0%,75%,100%,4095
> の位置に線が引かれます。

4095は4096の間違いか。SDKにも間違ったコメントが一部残っているけど。

確認したいのですが
キャプチャしたmpeg2ファイルを
Aviutl0.99で編集、TMPGEnc3.0 XPressでmpeg2エンコード
色空間をYUVでファイルの受け渡しをしたい場合

1.Aviutl0.99
→m2v.aui経由でmpeg2よみこむ
2.編集後
Huffyuv(YUY2圧縮)でエンコード
3.TMPGEnc3.0 XPress
→aviよみこみ
4.mpeg2でエンコード

上記の手順であってますか？

ちなみに2と3を
2.プロジェクト(.aup)の保存
3.プロジェクトファイルよみこみ
に置き換えるとRGBで受け渡すことになるって認識でOKですか？

0.99の色情報バグは承知の上での発言だろうな？

>>140
その通りでVFAPI経由は全部RGBになるでやんす。
m2v.aui⇒Huffyuv⇒TMPGEnc3しかYUY2には出来ないでやんす。
ザッツオーライでやんす。

>>142
あってますか安心しました。

>>141
YUY2を読み込んだとき
4:2:2→4:4:4の補完がおかしいと捉えてます

YC伸張フィルタ
YUY2アップサンプリング

上記のプラグイン等を使用して回避するみたいですが
分からないのは
a.入力〜編集の間プラグインを有効にするのか
b.入力〜編集〜出力までプラグインを有効にしていいのか

たぶんbでいいと思うのですがどうでしょう？

readme読めYUY2アップサンプリングフィルタの優先度は最大だ

何でプレステとかのゲーム機って16777216色も使えるんだろう？
赤・緑・青それぞれの輝度が256段階だから、
256の3乗で16777216色なんでしょ？
パソコンは0-255だけど、テレビは16-235だから、
もっと少なくてもよくない？
ダメ？
俺、アホなこと言ってる？

>>145
技術的にリアルタイムA/Dコンバートが8ビットで限界だった時代に作られた規格だから
8ビット中の1ビットで表せられる以下の値は切り捨てているんだよ。
本当はもっと欲しかったんだろうよ。
DVDは10ビットだし、今の放送用機器はそれ以上だし。

>>146
せっかく解説してもらったのに、
ついてけない。orz
スマヌ。

>>146は間違ったことはいってないが>>145の答えになってない

>>145
作業はPC上でやるんだから256^3のほうが扱いやすい。
16-235のレンジにはゲーム機が出力時に変換することだし。

ヒント：アナログとデジタルの違い

デジタルのチューナーからＳ端子やＤ端子（D1)でＰＣでキャプチャして保存してるんですが、
色はCCIR601用の6角形にあわせるべきなんでしょうか？
それともチェックをなくした値にあわすべきですか？
MTVX2004HFというのを使っているんですが、これのデフォルトでカラーバーを録画すると、
CCIR601より色がすこし濃いのですが、デフォルトではダメですよね・・？

デジタルはBT701(?)というアナログとは違った規格ということですので、
アナログのときと同じように調整してよいのか迷い中です。

迷うくらいなら結果で判断すればいいと思う
キャプチャしたものをDVDして再度キャプチャ
明るさや色が変わらなければOK

>>151
チューナーによる
本来はNTSCで出力するときにBT.601(旧CCIR601)にするべきだが
そのまんまBT.709になってるほうが多いだろう
ただそれ以前の問題があって現状の地上波はデタラメになってる
地Dの擬似ハイビジョン番組がBT.601だったり
地アナのダウンコンバート番組がBT.701だったりメチャクチャ
カラーバ−キャプチャーはもはやなんの役にも立たない
なんかもう・・・オレスケールでいいやって気分だ

ちなみにハイビジョン放送の企画書だと
BT.709色空間を使うがチューナー側はBT.601でもいいことになってるので
相互変換せずとも一応それほどおかしなことにはならにようになっている
おかしなことになってるように見えるが

P.S.>>153でおれもミスってるがBT.701ではなくBT.709です

709と601では色の濃さがどう違うとかで判別できないもんでしょうか？
6角形の色の形は綺麗なので601なのかな？

>ただそれ以前の問題があって現状の地上波はデタラメになってる

どんな？
もしかして、チューナ側の問題？
GRTのオン・オフで明るさが変わったりするチューナがあるんだけど。

>>156
そのあとのを読んでくれ
局側がまともな変換して放送していないんだよ

あんたらどこでそんなの調べて来るんだよ。
もうキャプ暦5年になるが、ついていけない。orz
>>151なんて、当たり前のようにデジチューからD端子キャプなんて言ってるけど、
普通コピワンだろう。

151だけど、MTVX2004ＨＦとか2005HFはふぬああでも使えて、ふぬああならキャプできるんだすよ。
まあD1でしかキャプできないけど。
色がわかんない・・

>>156
ゴーストが乗った状態の明るさが異常なんだろうよ

昨日の紅白、荻野目洋子のドレスが白飛びしてたぞ。
数年前流した奴は普通だったのに。
色空間が変なのか？

それは色空間以前の問題じゃね？
アナログテープが劣化するのは当たり前でしょ

前回流してから3年くらいしか経ってないのに？
劣化するなら、初回の86年→前回の方が劣化するんじゃないか？

ちょっと不安になって、
前回のと今回のをパソコンに取り込んで見比べてみたら、
色空間どころじゃなかった。
明るさが全然違う。

あ、別に輝度変化を起こす糞キャプボで録ったんじゃないぞ。
両方パナレコ。

白側だけPCスケールなDVD多いな・・
色も濃い気がするけど変換式わからんし俺調整でいいや・・

白側だけPCスケールなDVDなんてないよ
RGB収録じゃないんだから

スケール、な

だからYUV>RGBにしたときにどっちのスケールを取るかってのが
TVスケール　PCスケール
逆はないんだよ
BT.601でも範囲外のデータが存在することが認められてるんだから
YUVのY235をオーバーしてるDVDがあってもいいの
目で見ておかしいなら
それが製作者の趣味としかいいようがないんだよ
そんなDVDモーヲタは腐るほど持ってるよ

ソースのYUVに手を入れずに、
再生時の変換で各自環境にあわせて独自にスケール設定する、でFA

アニメのフレームレートを報告するスレ
ていうのもあることだし

デジタル放送番組の色空間を報告するスレ
があってもいいかなと思った

よくねーよｗ
色空間の意味分かってるのか？

ts抜いても判別するのシンドイよそれ

色温度はけっこうめちゃくちゃじゃない？
ガンマは普通にとっただけで黒→白が直線だった。

YUV読み込みバグ改善したaviutl1.00まだー

>>174
YUY2アップサンプリングでとりあえず対処汁。

ほ

捕守

キャプ後単純にAviUtlではYC伸張フィルタをON、AviSynthではColorYUY2(,levels="TV->PC"）を加えるだけで、
とりあえずOKとしておいていいのでしょうか？

キャプぼによるからそれでいい世別に

な、なんのために？

xvYCCがこの先生きのこるには

　　　　　 _,,,......,,__
　　／_~　,,...:::＿::;; ~"'ヽ
　(,, '"ヾヽ　 i|i　//^''ヽ,,)
　 　^ :'⌒i　　　 i⌒"
　　　　　 | ( ﾟДﾟ)　　＜ xvYCCもきのこれ
　　　　　 |（ﾉ　　|）
　　　　　 | 　　　|
　　　　　 ヽ ＿ノ
　　　　　 　U"U

RGB24は1ピクセルあたり24bit。
yuv411は1ピクセルあたり12bit。
yv12は1ピクセルあたり9bit。

>183
YV12はYUV=4:2:0だから平均するとピクセルあたり12bit。
ピクセル当たり9bitなのはYUV9。

ほす

YUY2のplanarとinterleaveって何が違うんでしょうか

データのならべ方が違う

どもです

DVD2AVI

他スレからここを紹介されました

今更ながらmpeg読み込み用に使ってるDVD2AVIの
YUV→RGB変換にパソコン色調というのがあることを知りました
今まではAviUtlプラグインの拡張色補正にあるTV→PCのスケール補正でやってましたが
どっちの方が正解なのでしょうか？
個人的には前者の方が綺麗に見えます

綺麗に見えたほうが正解

>>190
d2vをどうやって読み込むかによって違う

YC伸長フィルタを使っておのれの感性を信じ
調整するのが正解。

サンクスですとりあえず前者でいくことにしました
DVD2AVIもDGIndexにバトンタッチして心機一転です
個人的には変換前に帯域を十分に使ってるからだと信じてます

波形表示とヒストグラムをにらめっこしならが頑張ることにします

でわでわ

>>191
ある意味正しい。

TMPGenc2.5でYC圧縮済みファイル作成可能？

意味分からん

RGB24しか入力できないリアルタイム映像処理ソフトが有るのですが、
それにYUY2出力のUSBカメラを繋いでリアルタイムでRGB24にフォーマット変換して
RGB24出力のデバイスとして認識させる方法って無いでしょうか？

そもそもそのソフトにどうやって映像を受け渡ししてるわけ?

普通のUSBカメラです。
YUY2でも写ることは写るのですが、RGB24でないとできない処理があります。
検索するとリアルタイムで色空間を変換してくれるソフトが有るみたいですね。

こう言うDirectShow Filterと言うのがあるのですが、対応ソフトでないとだめなのかな？
http://www.medialooks.com/products/directshow_filters/resizer.html
使い方が分かりませんorz

おい手前等！！

ピロ野球番組で、激闘何とか空間！ってあったじゃん。
それに倣って激闘色空間という番組をやるべきだ。
昨日クソしてたときに思いついたが、これはまさにビビビッときました。
たかじんのそこまで言って委員会のように、激論を戦わせるべきだ。
タイトルは「たかじんのそこまで激闘色空間で委員会」でよろしいとおもう。

グラサンかけてるたかじんに色空間は無理

前々スレは激しかったよ

グラボに金かけてるヒマじんに色空間は有利

Vista Ultimate買ってきた。MPEG2デコーダー入ってた。
で、色々弄ってみたけどEVRってやつがVMRとかオーバーレイの代わりに使われてるんだな。
でもEVRもTVスケールでYC伸張してくれないみたいで白っぽいのだが、これってバグ？
PCで再生するならYC伸張するべきだと思っていたのだが、ちがうの？
ゲフォとラデ両方試してもどちらもYC伸張してくれないみたい。。。

>>206
ラデなら最新の7.4ドライバー入れるとVistaでも伸張してくれるようになるぞ。

DGMPGDecってBT.601だけだけど、同じようなソフトでBT.709対応しているの知らない？

まるも
http://www.marumo.ne.jp/mpeg2/

AviSynthで使うときは、WarpSharpのLoadAviUtlInputPluginでロード

>>209
あんがと。丁度みたらDGMPGDecが1.49になっていてBT.709出力の問題が直っていた。

Vista+GeForceだけどどうやら最近の風潮ではYC伸張はしないってのがデフォなのかね？
オーバーレイがあった頃はYC伸張されているっぽい感じが主流だったと思ってたけど、
VistaになってすっかりYC伸張しなくなってきているね。
やっぱHDVとかHDTVとかが範囲を超えて使い始めたからかな？

　　　　　　　　|
　　　　　　　　|
　　　　　　　　し
　　　　　　　　　　 ﾊ_ﾊ
　　　　　　　　　('(ﾟ∀ﾟ∩.
　　　　　　　　　　ヽ　　〈.
　　　　　　　　　　　ヽヽ_)

マジなのか笑わせにかかってんのかよくわからんな

>>213
私は至ってマジです。

DVDなんかはほとんど16-235だったのでYC伸張はほとんどの場合でうまく機能したけど、
HDソース、特にHDVなんかだと16-255と上を目一杯使っているからそのままYC伸張で
235までで切ってしまうと明らかに明るい部分のディテールがギタギタになっちゃうんだよね。
だからSD素材は16-235と仮定して単に16-235→0-255とYC伸張できたけど、HD素材はそういかないかも。
それでVistaがYC伸張しなくなっているみたいなのはそういった時代背景がらみなのかと思って
ここの詳しい人なら分かるかと思いまして。

>>214
>168あたりを読んで納得できる？

ごめん。

>>214
やはり話がよく見えないな。YC伸張する云々はどの時点での話なんだ。

>>214
テレビのモニタなら自動でゲインを調整するからね。
多少明るくても問題ない。
グラでAGCを使うべきなのかもな。
SDだろうとHDだろうと100IRE以上の素材なんて腐るほどあるよ。

>>218
どうもあなただけは話の内容を理解しているようですね。

>>214
事実、確かに最近はほとんどのDVDは16-235の範囲内に入っている。
また、HDVなんかはSONY、Canon問わず、みんな235-255を普通に使っている。
だから盲目的に16-235を0-255にYC伸張すると、HDVなんかだと上が飛んでしまう。それは事実。
よって、>218が言うようにAGCみたいな機構で自動的にYC伸張をOn/Off出来ない限りどうしようもない。
あっち立てるとこっち立たずになってしまう。

>>214
ちなみに最初の質問はVistaがYC伸張しなくなったという話についてだが、
恐らくだが特に最近のHDコンテンツが16-235の範囲外を使い始めたという事実が
PCモニターでsRGBに最適化されているWindowsでどうしようもなくなってきたのではないかな？
結局、YC伸張しないようにすることで見た目は悪くなることがあっても、情報の欠落よりはマシだと思ってるんじゃないかな？

基本は伸張だと思うよ
範囲外を使っているソースがあったとして
＞明らかに明るい部分のディテールがギタギタになっちゃうんだよね
の問題があったとしても
これをストレート変換で見るとなると
他の部分は色がくすんで見える（sRGBの一般的なモニターならば）。

範囲外の値を使っていてストレート変換で
色がくすんで見えないって事は
とてつもなく広い色再現帯域を持ったディスプレイを所有している事が前提だよね
※NTSC比で90%超えているのもあるよね

HDVとかHDTVとかでそういうデーターが出始めているって事は
オマエラ、いつまでも古臭いｼｮﾎﾞモニター使ってないで
買い換えろって事じゃないか？（ゲイツもそれに賛同しているとか）

>>221
確かに基本は伸張だと思うが、特に235-255はHDになってからはまるで当たり前のように使ってるね。
それに最近のHDTVはこのあたりの値もちゃんと画面上に表示しているように見える。
xvYCCなんか特にそうだけど、もうRGB変換後に範囲外になるようなYUVデータは平気で使われつつあると感じる今日この頃。

>オマエラ、いつまでも古臭いｼｮﾎﾞモニター使ってないで
>買い換えろって事じゃないか？（ゲイツもそれに賛同しているとか）
家電業界は率先そうすることによりSD→HDで買い替え需要を狙っているように感じる。
ゲイツはPC業界で家電とは関係ないからただ単に事実としてそういったデータを現状のsRGB規格で受け止めるために
ストレート変換を使わざるを得ないという事じゃないかな？

http://www.avsforum.com/avs-vb/showthread.php?t=523614&page=1&pp=30

↑を読むと、VMR9（ストレート変換）、オーバーレイ（伸張変換）
好きなほうを使えと書いてある。


http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=494606

↑もなんかイロイロ書いてある。

>>223
思うに伸張変換もストレート変換も両方正しいと思う。問題は好きな方をどうやって使うか。
Vistaなんかだとメディアプレイヤーもメディアセンターもそれ選べるようには作られてない。
どうやらVistaだとVMR9の後継のEVRってのが使われていてそれがVMR9と同じようにストレート変換を使うようです。

↑のAVSフォーラムの記事を見るとビデオにうるさい人たちはストレート変換を好むようですが、
逆にモニターの調節等すらしない一般人は伸張変換を好むように思われます。

また、コンテンツにもよりますね。日本の最近のデジタル処理されたアニメ等はきっちり16-235になっているんで
伸張変換したほうが断然良いですし、HDVやフィルム映画などはストレート変換じゃないと上が切れちゃうみたいです。

結局、結論としてはソフト側では自動的に決められないのに、勝手にどちらかに決め込んでいることが問題かと。

そりゃ間違ってるなら規格にならないだろう。
どちらも正しいからこそ両方の規格があるわけで、
どちらを選ぶかは時と場合（と使用者の趣味）によるのは自明。

つーことで結論に同意。

実にフザケタ規格だ
なんかムカムカするよ
筋が通ってねえ

nVIDIAのドライバ開発が、糞なだけに一票。
規格とか実際の使いかってとか。どうせ、何も考えてないって。('A`)

>>227
君は今までの内容をまるで読んでいないだろ・・・
おじさんビックリだよ

ええ。
224氏が最後に記述した結論でいいでしょ。問題無い。
御免ね。「　nVIDIAのドライバ開発が糞　」って云いたかっただけなんだ。
「　nVIDIAが何も考えてないで、ドライバ開発してる　」とか云いたかっただけです。

9X系以降のnVIDIAドライバの迷走っぷりは、キツイDEATH。　orz

ドライバに不満あるようだけど
何に不満なんだ？
オーバーレイの色が標準でntscブラウン管向けになっていない点？
evrがストレートだから？
pcモニタで見るならRadeonだって正解ではないし
ソース時点でバラバラだから正解なんて無い
てのが結論でしよ

Vistaになったら昔の情報が適用できなくなったね。
VistaではビデオはDXVA2経由でD3D9を使うようになっているようで、
YC伸張する・しないがAPIレベルで指定できるように改良されている。
http://msdn2.microsoft.com/en-us/library/ms697036.aspx
DXVA2_NominalRange_0_255が伸張変換、DXVA2_NominalRange_16_235がストレート変換だと思う。
今はドライバーがこなれていないからだと思うが、MSの方針としては16_235を標準としたいみたいですな。

YC伸張を勉強中のものです。色々調べた挙句、どうすれば良いのか行き詰ってしまった。

YC伸張を行う場合、16-235は0-255に伸張される。このとき16以下が全て0に丸められるのは全く問題ないと言っても良さそう。
問題は、235以上の部分。やはり一部のDVDは使っているし、何よりもDVやHDVは完全に使ってしまっている。
よって235以上を255に丸めると白が完全にかっ飛んでしまう。

ではストレート変換の場合。235以上の部分はソースのまま残っているし、ちょっと暗めの白というのは人は気づきにくいから
235までしか使っていないような場合でもたいした問題にならない。
問題は、黒が16になってしまうという事と、人は黒の階調に敏感に察知するから白浮きした黒や、16未満の黒が見えてしまうと
とても気になってしまう。

よってどちらも問題があるからこの議論は終わりがない。

結局、問題は大きく分けると２つに分類されて、一つ目は黒が16だと浮いてしまう問題、二つ目は235以上の白が潰れてしまう問題。
この二つを解決するためには、YUVを16-235としてではなく16-255として扱い、それをRGBの0-255に伸張する必要があるみたい。
ただ単に16-255を0-255にストレートに伸張すると全体的に暗くなるので役に立たない。
よって、ガンマを適用しながら16-255を0-255に伸張する必要があるが、どういったガンマを適用すれば良いかと困っている。
きっとこのあたりの話って先駆者がいると思うのだが、こういった変換を取り扱っている話を聞いたことありませんか？

先駆者なんていないよ
制作側がPCで見る事を無視して
いるのだからどうしようもない　

>>233
16-255を0-255に伸張する時のガンマ値について検証したことがある人って意味で
先駆者じゃないか？ここにいたとしても家電メーカーとかに勤めている人で業務内容
に関わるだろうから難しいだろうけど。

>制作側がPCで見る事を無視して
それちょっと視野が狭いかも。

そもそも輝度が16以下、235以上はあくまでも存在しているだけで意味があるか
どうかは受け取り側次第という前提。PCではそれを0-255に伸張するか16-235に
ストレート変換するかはそれはPC側が自分の事情で決めただけ。
だって16-235が対応するアナログ範囲というのはアナログ時代に出来たもの
だからその時にデジタルRGBなんて考慮する必要なかったから。
235以上に関しては昔のデバイスの制限で表示することは無理だったから
問題なかったが、最近の技術革新で表示できるようになってきたという事実が
235以上のデータにも意味があるというようになったという事に過ぎない。
よって他方で見えるようになってきたデータを盲目的にカットしてきたPC側で
見た目の相違の問題が出てきたというわけ。
だから16-255を有効範囲としてみなさないと両者は異なって見えてしまうのが問題。
よって16-255を0-255に伸張しなければいけないがそのようなスタジオYUVを
デジタルRGBに変換する式が今のところ正式にはない。
間違いなく家電はそうやっているだろうけど、現状だと個々のメーカーのノウハウ段階だろうね。

アナログ時代に16-235なんて概念すらない。なぜならアナログだから。
数字に対応させたのはあくまでデジタル化のため。
PCは規格に従って16-235を有効範囲にしてるだけ。
盲目的とかいうわけではないし、デバイスの制限とかでもない。
BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
その値をどう表示するかは受け手次第。

実際のところは、多少白飛びさせるくらい明るい方が鮮やかに見えるってことだけな気がする。
それが多分メーカーのノウハウなんだろうね。

>>235
大筋は私が言っている通りだとは思うけど。

>実際のところは、多少白飛びさせるくらい明るい方が鮮やかに見えるってことだけな気がする。
つまりは16-235を0-255にYC伸張すれば、236-255はクリップされて白飛びしちゃうという事だよね？

厄介なのは最近のプラズマとかLEDバックライトの液晶だと236-255の領域でも見えるんだよね。
あと、ビデオカメラメーカーがわざと見栄えをよくするためにこの領域を平気で使ってるし。
それがPCで見たときに違いとして現れ始めたのが問題として浮上してきてるんだと思う。

>236
結局、
> BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
> その値をどう表示するかは受け手次第。
ってことだろ。
そこから先はもう宗教論争でしかないよ。

>>237
うーん、>232って宗教論争と関係ないような。フリーソフトの作者か何かじゃまいか？
その受け手次第の部分を>232がどうにかしようとして困っているんじゃまいか？
>ガンマを適用しながら16-255を0-255に伸張する
アイデアは良いと思うし多分今時のテレビもやってそうと思う。
漏れは頭良くないんで誰か頭いい人いたら>232を助けてやってくれ。
そしたらいいソフトが出てくるかもしれん。

ffdshowで入力を16-255にすればいいじゃん
ガンマは変更する必要ないと感じる

16-235を守ってるメーカーだってあるのに、規格を軽視してる一部メーカーのためだけに
自分も規格を無視するなんて普通はやらないとおもうが。

何とかする方法なんていくらでもあるじゃん。
ffdshow使ってもいい。
avisynth経由で再生したっていい。
適当なソフトで補正して再縁故することだってできる。
それらが求める物と違うならdirectshowフィルタとかを自作すればどうにでもなる。

てことで、いいアイディアだと思ってかつ専用にソフトが必要だと思う人がやればいいじゃない。

>>239
それ駄目だと思う。
入力を16-255で出力を0-255にすると、結果としては暗い方向にシフトするから画面が暗くなる。
だからガンマ掛けないと駄目だという話になるんだと思うよ。

>>240
俺もメーカーだけど、16-235はかなり微妙になってきている気がする。
試しに235-255のデータ作って最近のHDTVで表示してみな。
どれも結構けろっと表示すると思うよ。

>てことで、いいアイディアだと思ってかつ専用にソフトが必要だと思う人がやればいいじゃない。
その思っている人がやろうとしてヒントを探しているんだと見えるが。

>>232
俺はメーカーでも直接携わっているわけじゃないんで大丈夫だと思う。
細かくは計算してないけど、どんぶり勘定だとガンマ0.9位で良いかも。

何に悩んでるか理解できん
規則にあわせて作ってくれない物に対して
それを作者の意図する色を再現させようなんて無理
その素材を作った人が基礎となる色を示さない限り
見る側が調整するしか無いし、決め撃ちできない

>>244
残念ながらその信じている規格は特に絶対を定義しているわけじゃないんですよ。それが現実なんですよ。
無理と言われても製品作んないといけないし、大体はうまく行くような落としどころも探さないといけないし。
規格とか無理とか言ってると物は出てきませんよ。

>>245
私は244と違うけど
貴方が妥協点を見つけたいと考えるのは理解できるが
何を基準に決定するのですか？
そんなの無理じゃないの？

＞最近のプラズマとかLEDバックライトの液晶だと236-255の領域でも見えるんだよね。
＞あと、ビデオカメラメーカーがわざと見栄えをよくするためにこの領域を平気で使ってるし
例えばこの前提はストレートで変換した場合でしょ
伸張したらクリップするんだから。
固定画素の表示デバイスは駆動回路の手前ではデジタルRGBにしなくてはならない。
しかも255が上限だからコレよりも上の値はとれない（255を真白としている）。

固定画素の表示デバイスで
YUV236-255の領域を使うなら
YUV255を完全な白にしなくてはならず
YUV235は少し曇った白になる。
でもそれじゃクリップの問題は解決できても他の色に影響が出る。

ブラウン管のように入力信号をアナログで扱えるのであれば
RGB255をという上限値がないから
YUV236-255を使っても全く問題にならない。
アナログの表示デバイスだから、なんとか表示できちゃう。

固定画素の表示デバイスはデジタルだから
入力された値の何れかを真白、真黒に割り当てる必要があって
仮に製作側を規格を考慮しなかったとしたら
これはもう無理ですわ。

無理という言葉はよくないね。

・クリップをなくす
・他の色が少し曇った感じになる

どちらかを選べという事になる。

妥協点てその間で適当に見える場所を探すだけで。
そんなの個人の好み。

>>246
理論的には合っているけど現実はちょっと違う。

>固定画素の表示デバイスは駆動回路の手前ではデジタルRGBにしなくてはならない。
>しかも255が上限だからコレよりも上の値はとれない（255を真白としている）。
TVに限定すると最近のハイエンドのプラズマとかLEDバックライト液晶とかプロジェクターはちょっと違う。
それらだと235が十分に白で、235-255の間はさらに明るい光源を出すようにしてるんだよ。

問題は発光体や光源の改良の成果で従来よりもコントラストが高めにできるようになってきたので235を十分に
明るい白にしておきながらさらに今までよりも明るいコントラストを表現できるようにするため235-255の部分が使われている。

>>247
どちらかというのは0-255(16以下、235以上はクリップ)か16-235(曇った感じ)の事だと思うけど、それだとどちら問題ありなんだよね。
だから上のような話になっているんだよ。つまり16以下はクリップするけど、235以上はクリップしない方法。
もしそのあたりの技術に興味があるならSONYとかの技術資料に出てたりするよ。

>>248
表示デバイスの色域が
昔と変化したから
その帳尻合わせをデーター側で行おうという事ね。

でもそれならストレートで入力して表示デバイス側で
ガンマや黒レベルを変えるべきだと思うよ。
多くの固定画素表示ディスプレイは
明確にRGB値を変更する
独自のカラーコンバーターを内蔵しているから。

信号処理の中間部分でいくら弄っても解決しない。

ストレートで入力して
16を真黒
255を真白

>>232のケースで理論的に正しいのは、ガンマ変換を行わない事だよね。
Y 16-235から0-255への変換とY 16-255から0-255への変換では、
単に明るさが2割違うだけだから。(ガンマ 2.2の場合)

Ａ．Y=16を黒(0),Y=235を白(1)にとる ガンマ 2.2のグラフ
Ｂ．Y=16を黒(0),Y=255を白(1)にとる ガンマ 2.2のグラフ
Ｃ．Y=16を黒(0),Y=235を白''(0.82509)にとる ガンマ 2.2のグラフ
Ｄ．Y=16を黒(0),Y=255を白'(1.21988)にとる ガンマ 2.2のグラフ
を描くと一目瞭然。
ＢとＣ(ＡとＤ)は同じグラフになる。

アナログ時代には白が『基準の白』で、白'は『より明るい白』だった。
でも、デジタルは黒から白の範囲しか表現できない。
家電では白''を『基準の白』にする事で、白で『より明るい白』を表現してる。
でも、PCで白''を『基準の白』にすると、全体的に暗い映像になってしまう。
なぜなら、PCの標準では白が『基準の白』だから。
だから、『基準の白』を白''にするのが正攻法なんだけど、これが難しい。
もしも動画再生がオーバレイだけなら、通常画面をオーバレイより2割暗くして、
通常の白(1')とオーバレイの白''を同じ明るさにする方法が使えるかもしれない。

もし232が、『基準の白』を白(1)のまま16-255をフルに使い画面が暗くならない
方法を求めているなら、232自身の感性を信じて試行錯誤するのが良いと思う。
正しい映像だと「暗くて使い物にならない」のなら、後は好みの問題だから。

>>242
そのHDTVって16未満はそれ相応に表示されるの？
表示されるなら単にストレート変換になるけど。

てかさ、0-255じゃほんとはだめだよ。1-254でないと。

>>249
TVだと表示デバイス側で出来るけど、PCモニタだと無理だよね。250氏が的を得てる感じだな。

>>251
HDTVだろうがなんだろうが、基本的には16未満は表示されなくてOK。
0と255はアナログ時代だと同期信号だけど、デジタル時代だと問題ないよ。
デジタルで0と255入力しても内部で問題あるなら0と255は自動的にクリップされる。

>>250
>Y 16-235から0-255への変換とY 16-255から0-255への変換では、 単に明るさが2割違うだけだから。(ガンマ 2.2の場合)
つまり16-255から0-255変換の方が2割暗いって事だよね？2割明るくするってどのくらいのガンマなの？
ってことは、16-235から0-255のYC伸張と16-235のストレート変換でも明るさが違うって事？

>>253
＞つまり16-255から0-255変換の方が2割暗いって事だよね？
そう、最大輝度が2割違うだけ。
相対的な階調は正しく保たれている。(カラーの場合は、色相と彩度も)

＞2割明るくするってどのくらいのガンマなの？
そんなガンマは無いよ。
あえて答えるなら、1.0〜0.0のどこか。(元の映像によって異なる)

好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。


＞16-235から0-255のYC伸張と16-235のストレート変換でも明るさが違うって事？
それは当たり前の事かと。
ストレートだと暗い部分(Y 16-113)は明るくなるし、明るい部分(Y 114-255)は暗くなるのだから。
画像全体でどうなるかは画像次第。

>>254
＞＞好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
＞＞暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。
俺もガンマ0.9は結構悪くないかも。正確に計算する方法が分かればいいのだが。

＞＞画像全体でどうなるかは画像次第。
画像次第というのはどんな変換でも当たり前だけど、0-255変換と16-235変換は平均的には
画像全体で見た場合は同じ明るさじゃないか？

>>255
＞正確に計算する方法が分かればいいのだが。
白の輝度が480cd/m2の時と同じ画面を白の輝度を400cd/m2に落とした状態で出したい、
必要な補正はなに？
質問がこんなシロモノだと、幾つかの考え方を紹介するのが関の山かと。
ex. 何も補正しない
ex. ガンマ 0.9付近で補正
ex. 16-255ではなく16-245を採用する(暗くなる量を1割に減らす)
ex. 218-255を218-235に押しこんで16-235範囲を使う(Y 16-218を同じカーブに)

＞画像次第というのはどんな変換でも当たり前だけど、0-255変換と16-235変換は平均的には
＞画像全体で見た場合は同じ明るさじゃないか？
殆どの場合にそう扱って問題無いと思う。でも、今回は違う。
16-235範囲のみで構成される全ての画像は、16-255変換で16-235変換時より2割暗くなる。
全ての画像が必ず2割暗くなる。
この変換との比較だったので、画像次第で結果が変わるという答え。

>>256
なんかややこしくなっているだけの気が。

用はストレート変換の時の16-255の範囲のデータを0-255にリニア変換した場合、
黒の方向に引っ張られるから全体的に暗くなるのをガンマ補正で全体的に明るさを
引き上げて元の画面の明るさに近づけたいという趣旨なんでは？

＞16-235範囲のみで構成される全ての画像は、16-255変換で16-235変換時より2割暗くなる。
16-235範囲のみってのは今の話の筋からするとずれていると思うよ。
あくまでも16-235のストレート変換 + 236-255範囲をそのまま保持なんでは？
2割暗くなるっていう数字の出所が分からん。

>>257
2割という数字の出所か。それは気がつかなかった。
それじゃ、16-235範囲のみが話の筋からずれていると思うのも当然だね。

たぶんだけど、分らなくても特に問題は無いよ。
論理や計算で答えを求めるという選択肢が消える程度だから。

>>258
ストレート変換の状態16-235[0-15と236-255はクリップしない]と、
その内の16-255を0-255にリニア変換した場合の明るさの違いの話じゃないの？

>>259
なぜ、ストレート変換を16-235と表現するの？

きっと色空間って概念を全く理解してないからだよ。

>>260
慣例でしょ？ググってもストレート変換を16-235と表現している方が多いし。
それに259氏は実際に"[0-15と236-255はクリップしない]"と注釈まで付けているじゃん。
てか250氏、揚げ足取るよりも>259が指摘した16-255を0-255とした場合の明るさの違いという指摘の方が大事かと。

PS3とかXbox360の最新ファームで設定できるようになってるやつって16-235と0-255の切り替えだよね？
でもXbox360には3種類の設定があってその中間みたいなのが選べるみたいだけど、あれってなに？8-245とかには見えないけど。。。

すげえどうしようもない意見なんだけどいいかな。
0-255ストレート表示にして、16以下が真っ黒に見えるようディスプレイを調整すればいい。
たぶん、これがテレビの人の考え方だと思うんだ。
リビング視聴を考えると明るい部屋だから16以下の階調はわからないと思うんだよね。
今のテレビなら16以下でもちゃんと見えるはずなのに、235以上は使うけど
16以下は使ってないことの理由だとも考えてる。
んで、ホームシアターなんかの暗い環境で視聴する場合でもそういう調整にすれば見るだけなら問題ない。
問題になるのは視聴と作成を同じ機器で行おうとする場合と
視聴以外の用途で同じディスプレイを使用する場合。
つまりPCでの使用ね。
これの対策としてはディスプレイに16-255表示用、0-255表示用の二つのプロファイルを作って適宜切り替える。
16-235用のプロファイルも作ってもいいかもね。
んでPC内部では全て伸張無しの0-255ストレートで演算させる。

> PC内部では全て伸張無しの0-255ストレート
なんだこりゃ

γが1.0って事じゃねえの？

ああごめん、その部分は一切伸張等の変換処理をしないって意味で書いた。
改めて簡単に言い直すと、
今まではほとんど16-235の範囲内しか使われてなかったから当然のように0-255へ伸張してたけど、
それが16-255まで使われることもある現状では伸張は行わずに出口(ディスプレイ)で
辻褄を合わせたほうがいいんじゃないかってことね。

それはフルスクリーンで、かつ、ビデオ画面のみが表示される場合のみ使える方法。
例えば16-235のストレートを使う場合、ディスプレイで0-16を丸めるとすると、Windowsデスクトップ上の0-16はどうする？
さらにメディアセンターみたいにCGとビデオをミックスする場合はCG部分が0-255だからディスプレイ側で0-16を丸めるとCG部分がおかしくなる。
結論としてはディスプレイ側でどうにかするのが間違っている。ディスプレイはいつも0-255のフルスケールで設計されるべき。

ではどうするか？
ビデオ画面の16-255を0-255に変換し、WindowsデスクトップやCGの0-255とミックスしてから0-255に調節されたディスプレイに表示する。
これがベスト。

それまでは残念だけど16-235を伸張するのが無難。235-255は見えなくても文句を言う人は少ないけど黒が16になると文句を言う人が多いから。

>>268
これがこのスレのFA？もうこれ以上はこのスレで議論する話もないかな。。。

このスレでアニメの話して良いのかわかんないけど、
ウミショーって
>>221
に書いてある見たな、
２３５より上の輝度入ってる？

>>270
DVD?TV?何の話だ？
235より上が入っていても構わない、ただし、それを受け手が表示するかどうかは受け手次第。
逆に、16より下は入っていても構わないが、受けては表示しちゃだめ(もしくは見えないように調節する)。

>>250 くらい的確な説明が出来る人が理解してる人。

>>240
頭がかたい

16より下を表示しちゃいけない理由がわからないんだけど、
なにか規定があるのかな。

0と255は同期信号だから使っちゃ駄目ってのはどっかで読んだ

>>274
歴史的には、白黒テレビ放送の規格まで遡る。
モニタ調整用信号には黒の調整用に -4%,0%,4% IREの信号が含まれている。
表示側はこれを使い、-4%と0%が区別出来ない，0%と4%が区別出来るように調整した。

この-4%,0%,4%は、それぞれY 8,16,24に相当する。
だから、Y 8と16が区別できたり、Y 16と24が区別できなかったりするのは単なる調整不良。
12と16が区別できたり16と20が区別できない程度なら許容される誤差だけど、
厳密に調整した状態では16未満と16は区別出来ないのが正しい。

>>275
0-255を直接アナログに変換した場合の0と255にあたるアナログレベルの場合な。
デジタルでは0と255は存在しても構わないし、実際にPCでは表示する。

>>276 そんな古い慣習を今まで引きずってるのねえ。

その比率だと16-215が0-100%になるけど実際は16-235だから実際には
1%あたり2.2の計算になるのかな。
なので0-255だと-7.27%から109.09%までの範囲になるような。
んで現在はそのマイナス部分は表示しちゃいけないけどプラス部分は表示してもいいし、
実際に使われてるソースもあるってことなのね。

0-15はデータに入っててもいいけど、表示側は見えないように調節しておいて欲しい。
236-255はデータに入っててもいいし、表示側は出来れば見えるようにがんばって欲しい。
ってのが建前。
あとは結果は受け手次第のベストエフォート型。

質問なんですが、最近BDのAIRというアニメをリップしはじめたのですが
元々BT.601の480iのSDのアニメであり、これがBD収録時にBT.709の1080iのHDにアップコンバートされているのですが
もし、再エンコードで720pにする場合、ColorYUY2でBT.601に変換するのが正解なのでしょうか？
HDTVの規格では720p以上はBT.709が正解だとは思うのですが、
BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
BT.601に変換してからDVD版と色を比べるとDVD版に色が近いので、わからなくなっています。
現在はm2v.auiを使い、BT.709のままYUY2読み込みをしています。

それはもう、好きなほうをとしか言えない気がする。
HDデータはBT.709でしか再生できないってなら別だけども。
再生できないというか709として再生されてしまうということね。
なので601でエンコしてそれを709プロファイルで再生した場合にどうなるか
逆に709のものを601で再生した場合にどうなるか
ってのも考えに入れておいたほうがいいかもしれない。

んま、ソースが709なのが明らかなら709のままエンコしたほうがいいとは思う。
エンコ時と再生時で二重に変換されるのが防げるし、PC再生ならその差異を埋める設定もできるし。

もともとRGBのデータをBT.709のYUVで保存したものがあるのですが、これをできるかぎり
元のRGBに近い状態にするにはどのような変換式を使えば良いのでしょうか？

>>281
なるほど。
たしかに、BT.709でエンコードしたものをavsで読ませて
ColorYUY2(
\levels="709->601",
\opt="Y:16-235 UV:16-240",matrix="rec709s",
\debug=0, interlaced=false)
みたいにフィルタを通して変換させながら再生させる手もありますね。

でも、逆に601を709に変換して読ませる方法は何かありますか？
avisynthのフィルタに見あたらなくて…

あと、ソースがBT.709なのは明らかだと思います。
m2v.auiでソースを維持、BT.709、BT.601をそれぞれ選び、
それぞれAviUtlで読み込み、フレームをBMPで保存して見比べたところ
ソースを維持とBT.709はまったく同じ色でした。
他に方法があるのかもしれないですが、もっと楽なやり方があるなら笑ってやってください。

これでいけない？
ttp://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm
ファイルはこれね
ttp://avisynth.org/warpenterprises/files/colormatrix_25_dll_20050223.zip

再生確認だけならMediaPlayerClassic HomeCinemaとHaali Renderer(Haali Matroska Splitterに同梱)の
組み合わせで簡単に切り替えができるんだけどね。
Haali Rendererがデコーダを選り好みするからちとアレだけども。
ffdshowと組み合わせればまず再生はできるかと。

間違えた。
Haali Matroska SplitterじゃなくてHaali Media Splitterだった。

>>280
質問の中によく解らない部分がありましたので、よろしければ教えて下さい。

＞BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
＞BT.601に変換してからDVD版と色を比べるとDVD版に色が近いので、わからなくなっています。

の部分です。もしも、

１．BD版(BT.709)をBT.709用データとして色空間Xで再生
２．BD版(BT.709)をBT.601へ変換してからBT.601用データとして色空間Xで再生
３．DVD版(BT.601)をBT.601用データとして色空間Xで再生

を比較したならば、１と２は同じ色ですよね。(２と３が同じなら１と３も同じ筈)
そうなっていないという事は、

ａ．BD版(BT.709)を色空間X用データとして色空間Xで再生
ｂ．BD版(BT.709)をBT.601に変換してから色空間X用データとして色空間Xで再生
ｃ．DVD版(BT.601)を色空間X用データとして色空間Xで再生

のような条件で比較されたという事でしょうか？

>>285
colormatrix、いけそうですね。試してみます。
今初めて、HomeCinemaの存在を知りました
えーと切り替えとは709で再生するか、601で再生するかを選択できるということですか？
できたら説明お願いします。

>>287
あ、色々紛らわしくさせてしまったみたいですね。

基本的に再生時の色で見たのではなくて、
m2v.auiを通して変換させてAviUtlのプレビューを使っています。
ようするに、
まずDVDのVOBをm2vconf.exeを使いBT.601、BT.709、元データ維持を3回設定しなおして
AviUtlでYUY2で読み込み、それぞれの設定で３回読み込ませ、毎回同じフレームをBMPで保存して
すべてを比較します。
次にBDのm2tsをmpgとして同じように3回設定しなおして
AviUtlで３回読み込ませ、すべてBMPで保存して比較しました。
その結果、DVDのBT.601、元データ維持が同じに近い色でした。
ただ、これはBDのほうは変換していると思われ正確にイコールなのかはわかりませんでしたので、「に近い」と表記しました。
DVDのBT.709と、BDの元データ維持、BT.709もほぼ同じでした。
m2v.auiは指定した色空間行列と元データが同じならば何も変換しないそうなので、BDはBT.709と判断しました。
DVDのBT.709はBT.601から変換されているため「ほぼ」としました。

比較方法、間違っていましたか？なら正しい方法を教えていただければその方法で比較したいと思います。
少なくとも、BDソースはBT.709であり、DVDソースはBT.601であることは間違い無いと思うのですが。

>>288
切り替えはそれであってる。
参考用に画像撮ってみた。
ttp://www.uploda.net/cgi/uploader4/index.php?file_id=0000016720.png
ソースはここの動画。
ttp://www.gran-turismo.com/jp/gt5p/

赤はすげえ変わるねえ。
記憶色やシーンは冬ですと言われれば601が正しいように見えるし、
ナチュラルさやシーンは春夏ですと言われれば709が正しいように見える。

ああ、ここ直リンできないのか。
こっちで落として。
ttp://ud.gs/4072r

>>288
詳しい説明ありがとうございます。
＞BD版はBT.601のDVD版と色を比較した場合、あきらかに色が違い、
の「色が違う」は、「BT.709用の画像(BD)をBT.601プロファイルで表示したものと、
BT.601用の画像(DVD)をBT.601プロファイルで表示したもの」の色が違うだったのですね。

　・BDソースはBT.709，DVDソースはBT.601
　・m2v.auiはYUY2データを出力する、出力色空間はBT.601/BT.709を選択可能
　・AVIUTLはYUY2データを受け取るが、色空間は(常に)BT.601(準拠)として扱う

>>291
709は709で変換しないとおかしくなる。
SD時代の古めのソフトは601専用な事が多いからなHD時代だと基本は709だから量対応が必修。

>>289
設定画面が違うと思ったら
どうやらHaali Media Splitterが古すぎたようです
こんな便利な手段があるんですね。教えてくださって感謝です。

>>291
AviUtlってBT.601として扱っていたんですね…
一つ聞きたいのですが、例えばBT.709のままでAvisynthにてx264にエンコードをします。
それをMPCでVMR7とCoreAVC(YV12)で再生した場合、
BT.709として扱ってもらえているのでしょうか？
GPUのVMRCCCSStatusは3で伸張されていると思いますが、これがBT.601ならどうしようもないのかもしれませんが。
Media Splitterを使えば確かにBT.709で取り扱い、伸張もできますがオーバーレイと違い
モニタが正確にキャリプレーションされていないと確認する環境によって差が出てしまうと思うので
できればVMR7を使いBT.709のソースをBT.709として、扱い再生する環境を作りたいのですが
どのソフトを使えばよいでしょうか？

MPCはHomecinema 1.0.8.0です。

>>293
確かXPのVMRとかVMR9ってBT.601専用だったと思う。
VistaのEVRはBT.601とBT.709の両方対応していたと思うよ。

>>295
確かにVistaだとBT.601とBT.709に対応しているみたいだけど、まだドライバーが安定してないっぽい。

>>295
そうですか…XPだと駄目ですか。
XPでVMR7を使って再生するならBT.601に変換させてしまった方が正しい色でみれるのかもしれませんね。
vistaのEVRでは、XPのVMR7のようなオーバーレイの概念が無くなってしまったということは、
GPUのデスクトップの色設定などが、たとえ動画を伸張再生したとしても、VMR9と同じように動画の色にも連動してしまいますよね？
そうなると、動画再生するディスプレイでも常に正確な色設定をして、そのディスプレイを買い換える毎に正確な色設定をするしかないんでしょうね…
EVRはストレートで、RADEONならドライバで伸張できるみたいですが、
あれはレジストリの項目の通り、ソースに関係なくBT.601扱いで伸張しますよね？
だったらVistaだとドライバで伸張するより、どちらかの色空間行列のソースであるかが指定できて
それに合わせて伸張の有無を選択できるHaaliMediaSplitterのレンダラを使うほうが、
正確な色でみれるということになりますが正しいでしょうか？

>>297
うーん、正しそうなところもあるけどそうじゃなさそうなところもある。
私が知りうる限りを列挙すると、
XPドライバーやVMR7・VMR9の場合、BT.601かBT.709を決めるのはドライバー。
大抵のXPドライバーは画像の高さでBT.601かBT.709を決める。例えばHD解像度だとBT.709とか。
デスクトップの色設定するとVMR9やEVRの色も連動する。ただし、Vistaドライバーの場合はさらにそれとは別に色空間変換専用の色設定を持っていることが多い。
本来はBT.601とYC伸張はまったく別の話。
EVRはDXVA2を使い、DXVA2を見るとBT.601・BT.709、YC伸張あり・なしをパラメーターで渡せるようになっている。
アプリかEVRのどちらかでパラメーターを指定できるはずだけど、公開していなければお手上げ。

>>298
ドライバーとはGPUのドライバーのことですよね？XPドライバーとVistaドライバーとはオーバーレイとEVRのことですか？

>XPドライバーやVMR7・VMR9の場合、BT.601かBT.709を決めるのはドライバー。
>大抵のXPドライバーは画像の高さでBT.601かBT.709を決める。例えばHD解像度だとBT.709とか。

ということはXPでもBT.709がBT.709のまま再生できるということですよね。
となると、VMR7再生するならはBT.709ソースはBT.601へ変換しないほうがいいのかな…
XPだと標準状態でHDソースを見ると、強制的にBT601に変換されてYC伸張されて再生されるのかと、本気で落ち込んでいましたので助かりました。


>ただし、Vistaドライバーの場合はさらにそれとは別に色空間変換専用の色設定を持っていることが多い。

これは、オーバーレイ時のようにデスクトップ設定が反映されないわけではなく
デスクトップの色設定の環境に応じて、正確な色に変換する機能がある、ということで良いのでしょうか？

まとめると(再生色空間はソースと同じとする)
XPのオーバーレイ、VMR7
480pBT.601ソース→BT.601とドライバーが解像度にて判断→オーバーレイ伸張して表示
720pBT.601ソース→BT.709とドライバーが解像度にて判断→オーバーレイ伸張して表示

XPのVMR9
480pBT.601ソース→BT.601とドライバーが解像度にて判断→UseBT601CSC=0かゲフォなら伸張せずに表示
720pBT.601ソース→BT.709とドライバーが解像度にて判断→UseBT601CSC=0かゲフォなら伸張せずに表示

VistaのEVR
480pBT.601ソース→ユーザーがBT.601と伸張ありとアプリかEVRで指定→DXVA2にパラメータが渡される→EVRはその情報を元に表示
720pBT.601ソース→ユーザーがBT.601と伸張ありとアプリかEVRで指定→DXVA2にパラメータが渡される→EVRはその情報を元に表示

と、なると思うのですが、EVR自体に伸張する設定があるということは、
対応するアプリがあれば、GPU側は伸張しなくていいということですよね？

>>299

>ドライバーとはGPUのドライバーのことですよね？
そう、ビデオカードのドライバー。

>XPドライバーとVistaドライバーとはオーバーレイとEVRのことですか？
そうとは言い切れない。どっちのドライバーでもVMR7使えばオーバーレイを使えるし、XPドライバーでもEVRは使える。
ドライバーとレンダラーは別。実際にはレンダラーがドライバーの違いを吸収してくれる、が、完璧ではない。

>ということはXPでもBT.709がBT.709のまま再生できるということですよね。
出来るけど、デコーダーのBT.709の情報はドライバーには届かないからVMRを使ったときの動作は不定。

>となると、VMR7再生するならはBT.709ソースはBT.601へ変換しないほうがいいのかな…
将来的にVistaとかで同じファイルを再生したいのならそのままの方が良いだろうね。
XPだとドライバーの挙動に合わせて変換するしないが必要かも。ただし、それは保存用としてじゃなくて一時的な再生専用。

>デスクトップの色設定の環境に応じて、正確な色に変換する機能がある、ということで良いのでしょうか？
ちょっと違う。
XP : デスクトップ・オーバーレイは個別に設定。お互いに影響は受けない。
Vista : デスクトップ・オーバーレイ・DXVA2は個別に設定。ただし、DXVA2からの出力はさらにデスクトップの設定の影響を受ける。

>まとめると(再生色空間はソースと同じとする)
合ってそうだね。

>対応するアプリがあれば、GPU側は伸張しなくていいということですよね？
伸張する・しないはGPUが行う。それを指示するのはアプリ(EVR)の役目。

最近変なのが住み着いたんだね、このスレ

>>301
ん？>280のことか？

PCをHDMIでフルHDのTVにつなぐ場合、PCではYC伸張するべき？しないべき？
VistaにCatalyst 7.7入れたらYC伸張しなくなった、これはバグ？それとも仕様？

>>303
たぶんね、もうDisplayPortが出ないとどうにもならないかも。
HDMIって家電用のガチガチ企画っていうし。

709 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:48:02 ID:???0
704x396 24Bit DivX 5.x 23.98fps 34881f 750.63kb/s
704x396 12Bit XviD MPEG4(XviD0047) 119.89fps 174450f 722.59kb/s
^^^^^^^
の12・24Bitって、普通に違いは理解できるものなのか？

714 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:55:00 ID:???0
>>709
256色と6万色の差を見分けられるなら理解できると思う

717 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 01:56:42 ID:???0
やっぱ24Bitのほうがいいのか？てか、見れりゃあいいか。

721 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/08/08(水) 02:01:41 ID:???0
>>719
1677万色(24bit)
256色(8bit)

かｗｽﾏｿｗｗｗ

見慣れたYV12での24ビット騒動か

>>300
返信が遅れてしまって申し訳ありません。

>そうとは言い切れない。どっちのドライバーでもVMR7使えばオーバーレイを使えるし、XPドライバーでもEVRは使える。
>ドライバーとレンダラーは別。実際にはレンダラーがドライバーの違いを吸収してくれる、が、完璧ではない。
なるほど。

>出来るけど、デコーダーのBT.709の情報はドライバーには届かないからVMRを使ったときの動作は不定。
>将来的にVistaとかで同じファイルを再生したいのならそのままの方が良いだろうね。
>XPだとドライバーの挙動に合わせて変換するしないが必要かも。ただし、それは保存用としてじゃなくて一時的な再生専用。
うーん…結局は、気にする人は動画再生はVistaで、編集はXPと二台用意するのがベストで
作る動画は色空間行列がそのままのものと、変換したものを二種類作成しておくしかないようですね。

>ちょっと違う。
>ただし、DXVA2からの出力はさらにデスクトップの設定の影響を受ける。
なるほど。理解しました。

>伸張する・しないはGPUが行う。それを指示するのはアプリ(EVR)の役目。
なるほど。それはVMR9の伸張と同じくGPUのドライバが対応しなければ、不可能であり
ラデの最新ドライバは、Vista用のドライバでもVMR7、オーバーレイとVMR9の伸張にしか対応していないので伸張できていない、
ということでよろしいでしょうか？

>>307
ラデスレによるとラデの最新ドライバはかなりおかしいみたいだよ。
7.6まではオーバーレイ、VMR9とEVRは伸張ON。
7.7ではオーバーレイが伸張ON、VMR9とEVRは伸張OFF。

>>308
ラデスレより
http://pc11.2ch.net/test/read.cgi/jisaku/1186755639/337

>>309
ゲフォ用の設定もよろしこ

で、YC伸張するのしないのどっちよ、このスレ的には。

バカ来た

伸張するしないとは無縁の世界を構築せよという結論ですよ。

>>312
じゃああんたはどっち派よｗ

YC伸張する ノ

EVR DShow Vista
Vistaから使えるEVRですが、DirectShowから使う場合について少し調べてみました。
（EVRはXPでも.Net3.0を入れると、一応DLLが入りますが、登録しても使えません）

これまでのDShowでは、YUVからRGBに変換する場合のマトリクスや、伸張するかどうか、などを
明示的に設定する仕組みが標準では存在しませんでした。
EVRでは、このあたりをどうにかできるという噂を聞いたので、調査してみました。

まず、EVR自体とピンが提供するインターフェースを見てみましたが、
それらしきものはありませんでした。
そこで、ふと、VIDEOINFOHEADER2の解説を見てみると、変更点がありました。
（おそらく Windows SDK for Vista 以降）
予約領域の一部を DXVA_ExtendedFormat とみなすようにしたようです。

さて、実際にこの設定が反映されるかを試してみました。
Vista＋GF7300GS(v162.22)では、EVR使用時のみ効果があり、かつ変換マトリクス指定だけが
反映されているようです。
VMR7/VMR9（YUVミキシングモード含む）およびXPではまったく無視されるようです。

どいうわけで、DXVA2フィルタと同じく、Vistaでしかまともに使えないという感じです。
あと、この実験の過程でedvdec.axに上記のパラメータの追加機能を付けてみました。(v0.9.9)
デフォルト値は適当なので、いろいろ試してみてください。

>>315
GJ!

EVRはDXVA2を使うはずですからそのお陰でマトリックスや伸張を指定できるのではないでしょうか？
DXVA2はVistaドライバーでしかサポートされていないはずですからXPだと機能限定なのもうなずけます。
ところで当方だとXP上でEVRが使えました。

　　　　　　　　　ｨｸ
　　　　　　__,､　 | |　　　　　　　　くﾆ}　{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj
　　　　　i''i;｣. 'ヽｰ' ､
くﾆ}　{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj{fj
　　　　　　　//｀`ヽ／/｀`'''''''ヽ
　　　　　　 〈;i'　　　｀`> ヾ｀`i　l
　　　　　　　　　　 　/ ／　　{二)
　　　　　　　　　　　 ヾ_')

すいません少し疑問に思ったので質問させてください。
モンスター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を使用するかがある
でいいのですよね？