05/05/17 02:12:46 zdeFJ2Fu
(ﾟ⊿ﾟ)ｲﾗﾈ
3:名無しさん＠編集中
05/05/17 03:34:50 jMUq6Xcq
sRGBって色を赤くして濃くしてるだけなのですか？
もっともテレビに忠実だとか言われてるけど正気の沙汰とは思えない色合いです。
4:名無しさん＠編集中
05/05/17 07:36:06 Ujki+ecm
>>3
カラーマッチングの基礎概念が分ってないと思われ。
5:名無しさん＠編集中
05/05/17 09:30:13 xUWkp07B
そもそも、ITU-R.BT601に合わせてキャリブレーションしてるのかと小一時間・・・
6:名無しさん＠編集中
05/05/17 11:54:01 rCi9I/eS
sRGBって緑とかの表現が・・・
AdobeRGBを擁護する訳じゃないけど、
sRGBが世界標準・標準環境になってしまうのにはギモンを感じる。
7:名無しさん＠編集中
05/05/17 12:14:06 t9oeNBRf
ここで注意しておきたいのが綺麗に見える色が自然界では必ずしも自然ではないということだ。
8:名無しさん＠編集中
05/05/17 12:34:48 Sssh8YtA
色スレ復活おめ！
9:名無しさん＠編集中
05/05/17 14:29:12 xUWkp07B
D65光源+sRGB=ITU-R.BT-709=HDTV
10:名無しさん＠編集中
05/05/17 14:59:56 xUWkp07B
ここが参考になる
URLﾘﾝｸ(jumper-x.hp.infoseek.co.jp)
11:名無しさん＠編集中
05/05/17 20:08:04 lm52QAqp
>>6
AdobeRGBはDTVには必要ありません
12:名無しさん＠編集中
05/05/18 06:23:45 Z0kgbogH
色が間引かれてる映像は、なぜ赤色系だけが大きく劣化するんですか？
13:691 ◆AFS777vyz.
05/05/18 07:03:17 ydQaMEh1
>>12
劣化した信号をテレビで見るからです。
AviUtlで拡張色調補正フィルタと色域変換フィルタを使って
大雑把に再現してみましょう。
1) フィルタの順序を、拡張色調補正を上にする
2) 色域変換を「ITU-R BT.609」から「ITU-R BT.701」に設定する
3) 拡張色調補正で「Y(gain)」を下げる
14:名無しさん＠編集中
05/05/18 13:57:10 xb/s2qEk
赤色系って、DSフィルタやオーバーレイで劣化を補正しても
チープな感じが否めない(;´Д｀)
15:名無しさん＠編集中
05/05/19 04:22:05 g3lVhGcB
チープな感じって意味がわからないけど
色情報の補間なしじゃもっとチープ（？）じゃない？
16:名無しさん＠編集中
05/05/19 04:48:21 xz3FiY/i
動画データはYUV（NTSC）で編集・保存して、PCで見る時にsRGB変換ですよね。
でないと、ユニバーサルじゃなくなるから。
17:691 ◆AFS777vyz.
05/05/19 12:56:26 8Gysnl8p
>>16
現在のWindowsでは動画に関するカラーマネジメントが存在していません。
ですので、何をどうするのも自己責任ということになります。
実際問題として商用ソフトウェアにAVIやWMVのデータが付いている場合、
たいていPCのディスプレイでそのまま再生して色が綺麗に再現されるように
作成されています。
ですので、AVIやWMVでは sRGB に変換しておいた方が無難だと思います。
ただ、データにカラープロファイルを付けられるなら利用した方がいいでしょう。
特にMPEG-2の場合、DVDはBT.601、デジタル放送はBT.709と分かれている
こともありますし、積極的に利用すべきだと思います。
とはいえ、NTSC(BT.601)に限って言えば、規格が古いため将来性は
かなり怪しくなっています。例えば、H.264 では NTSC が指定できません。
18:名無しさん＠編集中
05/05/19 13:01:03 Kgw5XwWQ
sRGBに変換って何？具体的にどうすること？
19:名無しさん＠編集中
05/05/19 13:23:18 QDuXOfKr
>>18
決まってるじゃないか！色を赤くして濃くする変換技術。
デジタル・リ・マスターとも言う。
代表例
千と千尋の神隠し
URLﾘﾝｸ(www.synapse.ne.jp)
20:名無しさん＠編集中
05/05/19 13:36:55 P1xg4AU9
>>19
青いサングラスをかけて見る
ﾜﾛﾀ
21:名無しさん＠編集中
05/05/19 13:56:18 P1xg4AU9
>>19
犬の実験面白いね。しばらく白く見えた。徐々に回復して言ったけど…
網膜細胞が受け取った光を電気信号にして視覚分野で処理してるゆえの現象かな。
精神病患者は赤いりんごが青くみえるというのも頷ける。
色の見え方には個人差というものが存在するのかもしれない。
昔、NHK特集でやってた脳と心って番組の本だけど、面白い。
URLﾘﾝｸ(www1.odn.ne.jp)
22:名無しさん＠編集中
05/05/19 14:15:28 GgwrAn93
紫色の不思議
ｽﾚﾘﾝｸ(sci板)
【眼の科学】視覚についてもっと知ろう【目のスレ】
ｽﾚﾘﾝｸ(life板)
視覚は曖昧ということか、ちゃんと波形表示見てつくらないと駄目だな…
23:名無しさん＠編集中
05/05/19 14:47:25 R5M4rZ4l
千と千尋か、懐かしいな。
初めて地上放送でやったとき、実況板がとんでもないことになってたけど。
24:名無しさん＠編集中
05/05/19 14:49:02 xqKlNUUr
>>18
色温度とは何か？ということについて知らなくてはならない。
色に温度？不思議と思うかもしれないけど、宇宙には太陽のような恒星がいっぱいあるのって、
知ってるよね？
恒星は温度によって輝きが違う。表面温度が低いほど赤く高いほどくくなる。
例えばアンタレスは表面温度が3500℃だから赤く、リゲルは13000度だから青い。
太陽の表面温度は6500℃と言われてる。
つまりsRGBとは、我々の太陽から照らされる自然光ということになる。
25:名無しさん＠編集中
05/05/19 16:24:19 Kgw5XwWQ
質問に答えてもらってないような気が・・・
sRGBについて聞いてるわけではないんだけど・・・
26:名無しさん＠編集中
05/05/19 17:04:57 R5M4rZ4l
いや、言葉の意味そのまんま、「変換」するわけだけど。。
たとえば、AviUtlのcgcnv2.aufでいうと、
γ関数をsRGB、色域はHDTV、YUVマトリクスは・・たとえばYCbCrへと。
URLﾘﾝｸ(www.geocities.jp)
自分事ですが、色域はAdobeRGBにするのが俺のジャスティス、と考えてた時期がありました。
27:名無しさん＠編集中
05/05/19 17:14:40 Kgw5XwWQ
AviUtlにそんなプラグインがあったのか
それは知らなかった
28:名無しさん＠編集中
05/05/20 00:22:20 KN70UjDW
>>21
最近周りがブルーに見えるのはそのせいだったのか…
飯も喉を通らないほどの欝状態。
病院でカウンセリング受けるかな……
29:名無しさん＠編集中
05/05/20 02:45:01 CCBZ4xuv
>>26
ハァ？
キャプチャ時にちゃんとキャリブレートされているという前提なら
色空間の変換はしないのが鉄則だろ。
再生時に、再生デバイスに対して「この映像の色は○○ですよ」という指定をしてやればよい。
または、手動でパラメータを適宜調整する。
30:名無しさん＠編集中
05/05/20 05:07:18 Uy/lgTI3
世の中キャプチャソースだけではない
31:名無しさん＠編集中
05/05/20 06:51:25 SiBhdRoK
|∀・）つブルドッグ・ソース
32:名無しさん＠編集中
05/05/21 01:16:40 PD4v2/3Y
URLﾘﾝｸ(www10.plala.or.jp)
33:名無しさん＠編集中
05/05/21 01:35:01 bxkQE+X0
>>32
その情報はずいぶん古いな
そもそも、PCで再生する際に、俗に「YC伸長」と呼ばれる手法で変換してもダメ。
NTSCならNTSCで作られたソースを「YC伸長」してsRGBのモニターで表示しても色は合わない。
34:691 ◆AFS777vyz.
05/05/21 15:20:35 R2b+QCEe
ちょっと難しい話ですけど、こちらに興味がある方が多そうなので転載します。
>--------------------------------------------------------------------------------
>
> 655．Re: NTSC to sRGB Directshow Filter ver2.4
>名前：AQ 日付：5月19日(木) 15時17分
>あじさん、はじめまして。
>
>不具合というわけではないのですが、このフィルタをかけると人物の肌色が赤みがかった色になります。
>上の方のコンテンツに小泉首相の画像がありますが、ああいう感じの色です。
>ちょっと赤っぽいですよね？
>
>私もM190ユーザー（sRGBモードで見ています）なので、多分あじさんと同じ環境だと思います。
>
>もう少し自然な感じの肌色になってくれると嬉しいのですが。
>
>ご無礼をお許しください。
>
35:691 ◆AFS777vyz.
05/05/21 15:21:24 R2b+QCEe
>--------------------------------------------------------------------------------
>
> 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分
>一応技術的な補足をしておくと、人間は可視光の範囲の色んな
>周波数分布の特徴を単純化して記憶します。これが「色」です。
>ただ、単純化してしまうため、全然違う周波数分布でも同じ色に
>見える場合があります。
36:691 ◆AFS777vyz.
05/05/21 15:22:05 R2b+QCEe
>ここで光源が変わると周波数分布全体が変わるので、２つの物体が
>ある光源の下で同じ色に見えていても、光源が変われば違う色に
>見える場合があります。
>これは、２つの物体は反射率の周波数分布が異なっていたけど、
>最初の光源ではたまたま同じ色に見えるような光を反射していた
>わけです。(これを条件等色と言います)
>
>現実は上のように、光源ごとに同じ色に感じる組み合わせは
>変わるものなのですが、一旦物体の色をRGB値で表現してしまうと
>その色がどんな反射率の周波数分布に由来しているか分からなく
>なります。
>極端に言うと、赤色レーザーを照射してある物体を撮影すると
>当然RGB値のGとBは0なんですが、じゃあその物体に青色レーザーを
>照射して撮影してもBの値は0かというと、それはその物体次第
>なんですね。
>RGB色域の変換とは、これを「常にBの値を0にする」変換なのです。
>だから、何らかの副作用は存在します。
>
37:691 ◆AFS777vyz.
05/05/21 15:22:26 R2b+QCEe
>一方、人間の脳味噌はもっと巧妙で、視界全体の色の傾向から
>過去に見たことのある光源を推定したり、見ているものの形の
>認識によって色の認識が左右されたりします。
>
>つまり、人間は光源別に顔の色はどんな周波数分布の特徴が
>あったか記憶しているわけで、これは光の周波数分布を
>RGB値という単純な数値に置き換えた時点でもう再現不可能です。
>
>要するに、色をRGB値で表すカラーシステムでは、RGB値に
>した後で何らかの変換をすれば必ず副作用を生じます。
>再現性を追及するなら、光→RGB値の変換(撮影)と
>RGB値→光の変換(ディスプレイ表示)で条件を一致させて、
>途中で変換が不要にするべきなのです。
>
>sRGBやデジタルTVのRGB値がディスプレイの色域に合わせた
>特徴を持っているのはそのためです。
>逆に言うと、NTSCのようにディスプレイの表現域を超えた
>範囲のRGB値は、必ずカラーコンバートが必要になるため
>色の再現性で不利なのです。
>
38:691 ◆AFS777vyz.
05/05/21 15:22:52 R2b+QCEe
>前置きが長くなりましたが、
>>もう少し自然な感じの肌色になってくれると嬉しいのですが。
>これを実現するためには、厳密には
>・画面全体の特徴を認識して、光源を推定する
>・光源ごとの「肌色」データベースで色を変換する
>ことが必要です。
>まあ、さすがにこれは非現実的なので、実際にやるとなると
>RGB空間上に「ある光源での肌色」の範囲を決める感じで
>処理することになりますが...N2Sでこれをやるというのは
>正直無理があります。愚直にカラーコンバートするだけでも
>既に重すぎるくらいですし。
>
>まあ、そんなこんなで...
>NTSCというディスプレイの色再現とはかけはなれたパラメータで
>撮影されてしまった信号を、気合の入った色処理でディスプレイに
>写すならやっぱり高級家電TVを買うべきなんじゃないですかね。
>
>申し訳ないけど、物事には限界があります(汗
39:691 ◆AFS777vyz.
05/05/21 15:24:50 R2b+QCEe
読み返すと若干不正確な表現がありますが...
概略と言うことでご容赦を
40:名無しさん＠編集中
05/05/21 15:48:51 dnBz8m9D
このスレってこういう感じなのか？
どういう人にとって必要な知識なのかが分からん
テレビキャプチャする人がsRGBなんて意識する必要ないんでしょ？
41:名無しさん＠編集中
05/05/21 16:25:43 i9aLeUmn
DTVってちゃんとノート取って勉強しないと地雷ファイルだらけになりそう
俺みたいに(^^
42:名無しさん＠編集中
05/05/21 16:58:34 uhX9ZnjB
地雷処理はプラグイン作者の仕事。
一般エンコーダーは普通にエンコすればいい。
普通にエンコして地雷になるようならプラグイン作者の責任。
43:名無しさん＠編集中
05/05/21 18:48:01 lJqrZ116
>>42
プラグイン作者といっても、プロからアマまでいるしな。
フリーのプラグインなら、それを選んだユーザの責任だろ。
勉強する気無いなら、家電でやればいい。
44:名無しさん＠編集中
05/05/21 22:36:25 gCiPf9m8
だな
45:名無しさん＠編集中
05/05/23 11:14:44 aZxNbooi
結局家電ﾚｺ使ったほうが早いよな
ｷｬﾌﾟﾎﾞ、ｷｬﾌﾟｿﾌﾄ、ｴﾝｺｿﾌﾄでのRGB、YUVの色空間の違い
圧縮、伸長の方法やら素人には複雑すぎて手に負えない
46:名無し募集中。。。
05/05/23 11:28:16 63W+AFi6
もともと素人が適当にやってもうまくいくようになってたのに
YC伸長だなんだと素人を惑わせる人が出てきたからだよ
47:名無しさん＠編集中
05/05/23 12:23:45 rmBMYpac
ヒストグラムを見れば、素人でもYC伸張の意味がわかるけどなｗ
48:名無しさん＠編集中
05/05/23 12:28:14 Gowu1WAP
>>45
というか、民生機器やPC周辺機器業者が色空間について理解した上で開発してるのか
不安になって来た…
ボードによっても色合いがまちまちだしなぁ。
49:名無しさん＠編集中
05/05/23 12:32:30 rmBMYpac
>>48
色合いなんて個々のPC環境に依存するからな（グラボ、モニタ等）
ヒストグラム表示できるフロントエンドで逐一チェックしないとどうにもならん。
50:名無しさん＠編集中
05/05/23 14:14:01 lEzx/RML
PCモニタに合わせて鮮やかな色にするって機能、
ありがた迷惑になってきたな。
51:691 ◆AFS777vyz.
05/05/23 20:04:17 J3aMVn7a
>>48
AV機器のLSIには普通にカラーコンバータ入ってますよ。
通常は N2S と同じように ICC ワークフローのコンバートのはずです。
チューナー付きテレビだと色々工夫してるでしょうけど。
52:名無しさん＠編集中
05/05/23 21:07:02 pWgyMq9z
家電って、デフォでもかなり綺麗な色が出るような
53:名無しさん＠編集中
05/05/24 03:04:42 W1nxhqZX
もちろん機種や設定によって全然違うんだろうけど、家電は鮮やか杉の色と
NRを効かせすぎでノッペリした画質というイメージが全体的にある。
54:名無しさん＠編集中
05/05/24 03:07:42 bkQcT+3I
ビクターなんかは特にそうだね。
55:名無しさん＠編集中
05/05/24 05:20:24 e0YQU8Qt
デジタイザの差もあるんだろうけど彩度とコントラストを上げて
意図的にメリハリのある画質にしてる
56:名無しさん＠編集中
05/05/24 13:31:25 EOyvljSq
peg2ﾌｧｲﾙを作るときに YC伸長ﾌｨﾙﾀで開始高輝度を16終了輝度を235に
設定すると 例えば人間の髪の毛なんかpcﾓﾆﾀｰ上では真黒になるけど
これでいいの？
57:名無しさん＠編集中
05/05/24 13:47:07 Y732FBcD
>>56
よくないｗ
58:名無しさん＠編集中
05/05/31 01:07:52 wmKwE28D
VMR9使いたくて、やっとDirextX 9対応のグラフィックボード
買ったのに、VMR9はYC伸張されない仕様なんですね。
ずっとオーバーレイでYC伸張された動画見てたから違和感がある。
このままオーバーレイ使ったほうがいいのかな。
念のためRADEON選んどいてよかった。
59:名無しさん＠編集中
05/05/31 02:43:35 cE2VQZpO
だから自前でYC伸張済みを渡してやるんだよ
60:名無しさん＠編集中
05/05/31 10:35:38 wmKwE28D
>>59
それってタイミング的にはCodecのデコードが
終わったあとになりますよね。
なんかそこまでCPUでやってしまうと
VMR9使ってCPU負荷を下げたいという
当初の目的が満たせなくなってしまうような。
61:名無しさん＠編集中
05/05/31 12:37:52 Pe29Le77
VMR9はゴミ。
さっさと死滅しろ。
62:名無しさん＠編集中
05/05/31 13:43:00 S214bBiT
ProcAmpで調節すればいいだけじゃん
URLﾘﾝｸ(msdn.microsoft.com)
63:名無しさん＠編集中
05/05/31 17:30:17 cE2VQZpO
>>60
ソフトウェア処理のVMR9の時点で負荷はVMR7よりも高い
CPU負荷下げたいなら素直にOverlayでも使っておけ
64:名無しさん＠編集中
05/05/31 23:11:14 wmKwE28D
前使ってたのDirectX6世代のグラッフィクボードだから
一気に3世代通り越して浦島太郎状態なんだよね。
前のボード、オーバーレイくらいしか使えなかったから
ハードウェアデインターレースは普通に感動した。
とりあえず、やりたいことと現状の問題点を整理しとくと
・再生したいファイルは主にインタレ保持MPEG-2とWMV9(インタレ保持を含む)
・RADEON 9600の動画再生支援機能を出来るだけ使いたいが
前のボードのオーバーレイ(RADEONのデフォルト値と大差ないと思われる)と
同じような色で再生したい。
・MPEG-2はWinDVDのレジストリのDXVAを弄ってハードウェアデインタレースに
なっているようだが、どうも伸張されていないのが気になる
･RADEON友の会のスレを参考にCATALYSTのレジストリも弄ってみたけど元に戻したつもり
･久しぶりにffdshowをインストールした
デフォルトからあまり変更してないけどメリット値が～～～
・WMV9のスレで紹介されていたWMP10のパッチを当てた。
なんか、WMV9 APのデインターレース再生が以前の環境で
再生していたものと違うように思えるけど詳細は調査中
・オーバーレイはふぬああの視聴時に使っている
録画時はプレビューにしているがふぬああの色と
エンコしたファイルを再生しているときの色が違うのは普通に困る
エクスプローラにオーバーレイを奪われるのも出来るだけ避けたい
>>62のProcAmpも弄ってみたい気がするけど、これ弄れるアプリとかあるの？ 作らなきゃだめ？
もうそろそろ弄りすぎてシステムがどうなってるのか把握できなくなって来た。
もうすぐクリーンインストールする予定だけど、それまでに設定決めたいよ。
65:名無しさん＠編集中
05/06/01 00:20:16 YqHQr0hP
何かVMR7でオーバーレイ使えばすべて解決するような気がしてきた。
WinDVDのレジストリ弄ったのとWMP10のパッチ入れたのが
システムにどう影響を及ぼしているかわからない。
レンダラによってはインタレ解除されてなかったり、
ピクセル比反映されてなかったりなんか怪しいぞ。
66:名無しさん＠編集中
05/06/01 00:35:40 YqHQr0hP
WMP10のパッチはレンダラの設定に関係なく
強制的にVMR9になってそうだ。どうも伸張されてなさげ。
67:名無しさん＠編集中
05/06/01 02:40:51 6EKlFLxM
>>66
WMP10はレジストリ直接弄らないとVMR7にはできないよ
68:名無しさん＠編集中
05/06/01 03:02:21 YqHQr0hP
>>67
ヘルプには
[ビデオ ミキシング レンダラを使う] → VMR7を使用
[高画質モードを使う] → VMR7 YUVミキシングレンダラを使用
とありますが、これが間違いということですか？
パッチ入れたせいで高画質モードがVMR9になったのかと思いました。
69:名無しさん＠編集中
05/06/01 07:08:38 KKmuiGYm
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ |
| | | |
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ |
| |/ ⊃ ﾉ | | VMR9
￣￣￣￣'￣￣￣￣ |
70:名無しさん＠編集中
05/06/01 12:58:03 5bJHTvmx
VMR9はマジでイラネ
71:名無しさん＠編集中
05/06/04 22:59:24 6gfEZDub
>>48
色空間じゃないけど、ソフトも怪しいのありますよ。
どことは言わんけど、DVからは絶対にトップファーストのMPEG2を作ってくれないソフト。
CCEだと作ってくれるんだけど。
72:名無しさん＠編集中
05/06/06 01:51:00 KJUwEFMM
>>48
当然理解はしてると思いますが、
メーカーごとに味付けされてるんじゃないかな？
所詮素人向けの機器だし…
73:名無しさん＠編集中
05/06/12 16:23:20 u9MPTwvw
RADEONにおいて非オーバーレイのVMR（VMR9など）でYC伸張する方法発見
試したドライバはCatalyst5.6
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{YOUR GUID}\0000
に文字列のエントリ"UseBT601CSC"を新規作成
値を 1 にすると非オーバーレイのVMRでYC伸張するようになる
0 だと従来通りのストレート変換
レジストリ変更後は要再起動（または3Dタブのスライダなどを適当いじって戻る）
74:名無しさん＠編集中
05/06/12 19:38:08 GuuXFQDI
常時強制ハードウェアYC伸張みたいなものか？
75:名無しさん＠編集中
05/06/15 07:04:37 U4Q7WQy1
スカパをアナログキャプなんですけど、
元はペグ2だから4:2:0だと思うけどアナログ
でとると4:4:4になってるの？
YUY2で撮ってるから4:2:2になるけどこれって
損失あるのかな？
ふぬああでhuffyuvS(CCE)YUY2キャプ。
aviutiで編集、再びhuffyuvS(CCE)YUY2で中間ファイルはいて
CCEBasicでMPEG2にしてます。
76:名無しさん＠編集中
05/06/15 14:49:15 LAIXrAm7
補完されたアナログ出力を｢4:4:4｣とは言わないよ。
普通のアナログを4:2:2でサンプルするなら実用上の｢損失｣は無いから大丈夫。
77:名無しさん＠編集中
05/06/15 15:25:16 9zIsKKj4
アナログ(NTSC)信号では、色はフィールドごとに市松模様になってるから
4:4:4でも4:2:2でもない。情報量的には4:2:2に近い。
キャプボはアナログ信号からITU-R BT.601って規格で4:2:2の
デジタルデータを作る。これがYUY2。
ペグ２はさらに縦の解像度を半分にした4:2:0。
だから、スカパぺぐ２→アナログでは縦横に、
アナログ→YUY2では横方向にサンプル形式の変化がある。
だけど、縦方向は解像度が上がる変換だし、横方向も解像度が
あまり変わらない変換なので、輪郭がぼけたりはするけど
情報量が半分になるような大きい損失はない。
78:名無しさん＠編集中
05/06/15 15:59:09 ysaCKcj7
NTSCの4:2:2の帯域の比率がまず先にあって、BT601やYUY2ってのは後付けの規格だよ。
市松模様だから4:2:2ではない、って訳じゃない。
でもNTSCのこの関係はもはや過去の遺物だから別にいいんだけどね。
79:名無しさん＠編集中
05/06/15 17:24:21 9zIsKKj4
帯域はY:I:Q=4:1.5:0.5
サンプル点は市松だけど、コンポジット信号を
そのまま保存するのでもない限りLPFに突っ込まれる
過去の遺物というのは、その通り
80:名無しさん＠編集中
05/06/15 21:06:34 h3HL/SGR
「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
受信機のNTSCデコーダではY:U:V=4:0.5:0.5で処理している。」
という記述をよく見るんだけど、やっぱり民生品では
Y:I:Qで色をデコードしてるのって存在しないんでしょうか？
コンポジット出力も同様なんですか？
81:名無しさん＠編集中
05/06/15 22:27:59 9zIsKKj4
>>80
放送はチャネルあたりの帯域自体が狭い
>「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
してない
でもスカパーには関係ない
放送信号とコンポジットとＳ端子とＤ端子では全部帯域が違う
YIQ、YCbCrと帯域は何の関連も無い
YIQとYCbCrなんて位相が違うだけで実質同じ
どういう理由で関連があると思ったんだ？
82:名無しさん＠編集中
05/06/15 22:57:30 9zIsKKj4
ちなみにNTSCの色差は離散アナログ値なんで、
サンプル位置と帯域も別の話な
4:2:2相当とかに無理にあてはめても混乱するだけだ
83:75
05/06/17 02:32:14 UnRyHKBJ
あの…
つまり今のままで大丈夫なんでしょうか…？(ﾋﾞｸﾋﾞｸｯ
84:名無しさん＠編集中
05/06/17 19:40:02 pufw26Nu
>>83
大きな損失は無いから実用上問題ない
ソースがスカパーなのは大問題だけどな
85:名無しさん＠編集中
05/06/29 01:31:35 qTP2Zkhm
Yは普通に範囲内に飽和させてますが
CbCrも飽和させるもんなのでしょうか？
濃過ぎません？
86:名無しさん＠編集中
05/06/29 12:29:16 ubYKEIvC
>>85
CbCrも範囲内に飽和させればいい
↓
元々範囲内に収まっているなら何もしなくていい
87:名無しさん＠編集中
05/07/02 00:21:09 tcso3n9Z
>>86
ありがとう！
AviUtlにYUY2～飽和ってあるじゃないですか、
飽和の意味調べたらぎりぎりまでいっぱいに
するみたいな感じだったから疑問に思ってたんです。
88:名無しさん＠編集中
05/07/02 09:27:02 wdfsasf3
つ飽和演算
89:名無しさん＠編集中
05/07/02 13:28:09 UkmcXytg
ほわほわ
90:名無しさん＠編集中
05/07/02 13:48:04 kyHLlvhB
ほっちゃん、ほわほわ
91:名無しさん＠編集中
05/07/08 22:29:00 nuaw2rUr
URLﾘﾝｸ(sakots.pekori.jp)
92:名無しさん＠編集中
05/07/19 05:49:46 TcNYDJuR
ffdshow050711で確認したんだが、
YUY2,YV12で出力するとオーバーレイ、VMR9に限らずRGB32で出力したときより灰色っぽくなる。
結局どの色空間で動画見れば一番いいのかわかんなくなってきた
93:名無しさん＠編集中
05/07/19 13:00:58 0Qb7yKV5
RGB32
94:名無しさん＠編集中
05/07/19 13:46:06 wZrVIFTo
>>92
とりあえず落ち着いて近所のカラスでも眺めてみなよ
そのカラスも灰色に見えてきたらそれは、眼科に( ry
95:名無しさん＠編集中
05/07/26 01:28:37 /V6HwuuE
あまりよく分かってないで質問するんだが・・・
通常のYUV色空間で飽和されたAVIファイルがあるんだけど
TV出力で見ると最適なんだけど、PCディスプレイで見ると
何か暗く見える。
で、PC以外では見ないことを前提にして、TVで見たときと
同じように適切な色がPCディスプレイで再現されるように
再エンコしたいんだけどどうすればいい？
96:名無しさん＠編集中
05/07/26 01:43:12 +USFhy7M
違和感なく見えるようにオーバーレイで調整しろ
97:名無しさん＠編集中
05/07/26 02:52:54 /V6HwuuE
>>96
なるほど。
一部の公開ファイル（映画の予告編とか）で、PCディスプレイに
最適化してるのがあるけど、そんなのは、どうやって作るのかなって
思ったもんで・・・
98:名無しさん＠編集中
05/08/25 23:11:54 5AytfZ+B
msyuv.dllの減色問題ってXP SP1以降なら気にしなくて
いいんだよね？
99:名無しさん＠編集中
05/08/26 20:14:29 CDD28cNr
>>98
msyuv.dllをhuffyuvdllなどに置き換えるのは、
DirectX8のmsyuv.dllのYUV->RGB変換が16bitという"仕様"のため。
DirectX9を入れてたら問題なし。
100:名無しさん＠編集中
05/08/26 22:53:28 wZfOxUWq
>>99
そうでしたか！
今DirectX9cなので大丈夫かな。(これはこれでどっか悪いらしいですが…色が大丈夫なら(・ε・)キニシナイ!! )
どうもありがとうございました。
101:名無しさん＠編集中
05/09/14 20:51:48 Km3X/gE8
あげ
102:名無しさん＠編集中
05/10/11 12:18:41 QGBzZFc8
age(ﾟдﾟ)age
103:名無しさん＠編集中
05/10/20 11:04:38 qtau/VEU
テストチャート
URLﾘﾝｸ(www.belle-nuit.com)
104:名無しさん＠編集中
05/10/29 07:30:16 86eAfRNt
ダウンスキャンコンバータのような機器でWindows上のオーバーレイのみを
アスペクト比固定のままでS端子やD端子でTV出力出来る機器は有りますか？
もし有ればTV用の映像製作等でTV出力画面を見ながらPC側でメイクや調整が出来るのですが・・・。
105:名無しさん＠編集中
05/11/12 16:20:16 x/xlkAiF
hosyu
106:名無しさん＠編集中
05/11/17 18:42:38 xNQvQB2J
URLﾘﾝｸ(www.geocities.jp)
↑にあるNTSC to sRGB Directshow Filterをつかって、
ふぬああで視聴時にリアルタイムに色域変換できないのでしょうか？
録画済のAVIファイルなら変換されるのですが、
ふぬああでリアルタイム視聴にも使いたいです。
107:名無しさん＠編集中
05/11/17 20:42:33 FvVHW1cb
>>106
ビデオフィルタの設定で「NTSC to sRGB」を接続した
プロファイルを作って、デバイスの設定→グラフの
ビデオフィルタにそのプロファイルを適用すればいいんじゃない。
108:名無しさん＠編集中
05/11/18 14:32:08 07dYi81R
返答ありがとうございます。
NTSC to sRGBという名前のフィルタが見当たらなく、
代わりにColorSpaceConverterというものとColorConverterというものがそれっぽいんですけど、
ColorConverterのほうは接続不可となって利用できないのでColorSpaceConverterだけ利用できるみたいで、
こちらを利用してフィルタで使ってもいまいち変化が見られないんですがこれくらいしかやれることはないものなのでしょうか？
109:名無しさん＠編集中
05/11/20 13:07:21 lH1Dgt7C
つ regsvr32 ntsc2srgb.ax
110:名無しさん＠編集中
05/11/20 17:48:14 00xj7OTn
よくわからないです・・
111:名無しさん＠編集中
05/11/20 19:00:28 lH1Dgt7C
>>110
一覧に無いのはフィルターが登録されてないから｡
ふぬああのインスコ時にやった事をもう一回やればよい｡
112:名無しさん＠編集中
05/11/20 20:57:57 00xj7OTn
そうだったんですか。
やってみます。
アンインストールしたくなったときはどうしたら元に戻せますか？
113:名無しさん＠編集中
05/11/20 21:02:09 P82v53lv
?? ?? ?? ??
??:: ? ? ::??
??:: ? ? :::??
??:: :: ● ?:: ? ?? ● :: :::??
????:: ?::: ?? ::?? ::::???
?????:::: :: ??:::? ?:::?? :: ::::???
??????:::: :: ?? ?? :::????
知らんがな
114:名無しさん＠編集中
05/11/20 23:17:14 00xj7OTn
レジストリに登録（？）するので元にはそう簡単には戻せないのかな？
115:名無しさん＠編集中
05/11/21 00:01:59 UWmbZlnf
>regsvr32 -h
を実行してみよ。
116:名無しさん＠編集中
05/11/21 00:16:32 H6Yoxxh5
ntsc2srgbのアーカイブにインストール用と
アンインストール用ののバッチと入ってるがな
117:名無しさん＠編集中
05/11/21 01:31:35 qpqf8fwT
そのパッチ実行するとntsc2srgb.axもアンインストールされるんですか？
118:名無しさん＠編集中
05/11/21 11:16:26 M4lzHsIf
ちったあやってみてから聞け
119:名無しさん＠編集中
05/11/21 12:27:56 aizuJhG9
やってみればすぐ分かる事を何で聞くかなぁ。
しかもよく分からないものに手を出すなんて。
120:名無しさん＠編集中
05/11/21 17:56:24 qpqf8fwT
よく分からないからきいたんです・・
121:名無しさん＠編集中
05/11/21 20:00:14 aizuJhG9
>>120
＞やってみればすぐ分かる事を何で聞くかなぁ。
122:名無しさん＠編集中
05/11/21 21:15:24 qpqf8fwT
やると何がおきるか分からないからきいたんです・・
123:名無しさん＠編集中
05/11/21 21:18:54 wbTcogo/
この先生きてて何があるかわからないので早く死んだ方がいいですよ。
124:名無しさん＠編集中
05/11/21 21:28:54 v/HgjyuE
地アナキャプったのってエンコる前にsRGBとかに変換した方がいいの？
125:名無しさん＠編集中
05/11/21 21:55:15 qpqf8fwT
なにごとも注意は必要ですから・・
126:名無しさん＠編集中
05/11/23 13:02:20 lWHjWUua
No
127:名無しさん＠編集中
05/11/28 21:56:58 O6zWJGFD
インスコ
regsvr32 ntsc2srgb.ax
アンインスコ
regsvr32 /u ntsc2srgb.ax
流れﾜﾛｽ
やり方示したからさっさと死ねよ☆
128:名無しさん＠編集中
05/11/28 23:06:32 7dRXQWCx
一週間前の流れになに言ってんだか（ ´,_ゝ`）ﾌﾟｯ
129:名無しさん＠編集中
05/12/11 13:07:47 Xp/PjcdW
今さら過去ログを読みなおしてみたが、AviUtlの波形表示プラグインの見方を勘違いしている
奴がいて混乱させられたのを思い出した。
130:名無しさん＠編集中
05/12/11 13:36:44 Vvt59utv
どういう勘違い？
俺もしてるかも。いまいちよくわからん。
131:名無しさん＠編集中
05/12/11 19:14:52 Xp/PjcdW
上下の線は16,235(240)なのに0,255だと思っていたり、YUY2読み込みしつつCCIR601用の
補助線は意味がないと筋違いのことを言ったり、まあ理解が浅い者を惑わすようなことを
していた。
132:名無しさん＠編集中
05/12/12 01:36:40 qYdivUMw
あー0.255だと思ってたわ・・
だってCCIR601補助線？をだすと16と235に線がでるよね？
255メーターをスライドすると一番上にあった線が一番下に来るよね？
だから0.255だと思ってたわ。
133:名無しさん＠編集中
05/12/12 01:53:32 0Cj/DrUZ
>>131も間違ってる希ガス
間違っているというか、常に正しいとは限らないというか
134:名無しさん＠編集中
05/12/12 03:30:00 Dg6Kx4oJ
はっきり間違ってるって言っちゃえよｗ
135:名無しさん＠編集中
05/12/12 05:41:09 yMjndqPb
そりゃあ上で書いたことは前提があるわけで。そういう些末なことでなく、
使い方を誤った上で波形表示プラグインは信用できない代物扱いしている
者がいたという話。
136:名無しさん＠編集中
05/12/12 07:10:58 qYdivUMw
CCIR601補助線？をだすと16と235に線がでるのはなぜ？
255メーターをスライドすると一番上にあった線が一番下に来るのはなぜ？
137:名無しさん＠編集中
05/12/12 15:06:31 yMjndqPb
>>136
CCIR601用の補助線だから。つまり、ストレート変換あるいはそれに相当する状態に
して使うべきもの。だからYUY2読込みのときは普通は用がない。それで補助線は
無意味だと言うのはそれこそ無意味。拡張色調補正でPC->TVスケール補正にチェックを
入れて、範囲外のデータの様子を見るのに使えないこともないが。
> 255メーターをスライドすると一番上にあった線が一番下に来るのはなぜ？
ごめん、意味がよくわからん。どういう操作をしたときの話?
138:名無しさん＠編集中
05/12/12 22:40:43 qYdivUMw
拡張色調補正などでyoffを-256とかにすると
丁度一番上にあった輝度が一番下にこなかったっけ？
だから波形表示は0-255でやってるのかと思った
139:名無しさん＠編集中
05/12/13 10:08:44 ypw+zd3F
>>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にも間違ったコメントが一部残っているけど。
140:名無しさん＠編集中
05/12/15 13:08:08 nXZgaJPk
確認したいのですが
キャプチャした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ですか？
141:名無しさん＠編集中
05/12/15 13:13:36 XY/E7Tjs
0.99の色情報バグは承知の上での発言だろうな？
142:名無しさん＠編集中
05/12/15 13:29:12 4v+i7ZSe
>>140
その通りでVFAPI経由は全部RGBになるでやんす。
m2v.aui⇒Huffyuv⇒TMPGEnc3しかYUY2には出来ないでやんす。
ザッツオーライでやんす。
143:名無しさん＠編集中
05/12/15 15:25:30 nXZgaJPk
>>142
あってますか安心しました。
>>141
YUY2を読み込んだとき
4:2:2→4:4:4の補完がおかしいと捉えてます
YC伸張フィルタ
YUY2アップサンプリング
上記のプラグイン等を使用して回避するみたいですが
分からないのは
a.入力～編集の間プラグインを有効にするのか
b.入力～編集～出力までプラグインを有効にしていいのか
たぶんbでいいと思うのですがどうでしょう？
144:名無しさん＠編集中
05/12/17 13:09:37 1PudFZMd
readme読めYUY2アップサンプリングフィルタの優先度は最大だ
145:名無しさん＠編集中
05/12/18 14:43:31 SZVU2JPM
何でプレステとかのゲーム機って16777216色も使えるんだろう？
赤・緑・青それぞれの輝度が256段階だから、
256の3乗で16777216色なんでしょ？
パソコンは0-255だけど、テレビは16-235だから、
もっと少なくてもよくない？
ダメ？
俺、アホなこと言ってる？
146:名無しさん＠編集中
05/12/18 17:15:49 lxFMBKlv
>>145
技術的にリアルタイムA/Dコンバートが8ビットで限界だった時代に作られた規格だから
8ビット中の1ビットで表せられる以下の値は切り捨てているんだよ。
本当はもっと欲しかったんだろうよ。
DVDは10ビットだし、今の放送用機器はそれ以上だし。
147:名無しさん＠編集中
05/12/18 22:51:09 SZVU2JPM
>>146
せっかく解説してもらったのに、
ついてけない。orz
スマヌ。
148:名無しさん＠編集中
05/12/18 23:50:48 nrTJ9nY3
>>146は間違ったことはいってないが>>145の答えになってない
149: ◆.WcbPIljrw
05/12/19 00:16:27 t3U52JI9
>>145
作業はPC上でやるんだから256^3のほうが扱いやすい。
16-235のレンジにはゲーム機が出力時に変換することだし。
150:名無しさん＠編集中
05/12/19 00:59:47 Kz7CRruJ
ヒント：アナログとデジタルの違い
151:名無しさん＠編集中
05/12/23 15:16:38 J4aN7rjc
デジタルのチューナーからＳ端子やＤ端子（D1)でＰＣでキャプチャして保存してるんですが、
色はCCIR601用の6角形にあわせるべきなんでしょうか？
それともチェックをなくした値にあわすべきですか？
MTVX2004HFというのを使っているんですが、これのデフォルトでカラーバーを録画すると、
CCIR601より色がすこし濃いのですが、デフォルトではダメですよね・・？
デジタルはBT701(?)というアナログとは違った規格ということですので、
アナログのときと同じように調整してよいのか迷い中です。
152:名無しさん＠編集中
05/12/23 22:24:53 BY+QkJWf
迷うくらいなら結果で判断すればいいと思う
キャプチャしたものをDVDして再度キャプチャ
明るさや色が変わらなければOK
153:名無しさん＠編集中
05/12/23 22:34:57 M6j5OgDC
>>151
チューナーによる
本来はNTSCで出力するときにBT.601(旧CCIR601)にするべきだが
そのまんまBT.709になってるほうが多いだろう
ただそれ以前の問題があって現状の地上波はデタラメになってる
地Dの擬似ハイビジョン番組がBT.601だったり
地アナのダウンコンバート番組がBT.701だったりメチャクチャ
カラーバ－キャプチャーはもはやなんの役にも立たない
なんかもう・・・オレスケールでいいやって気分だ
154:名無しさん＠編集中
05/12/23 22:38:14 M6j5OgDC
ちなみにハイビジョン放送の企画書だと
BT.709色空間を使うがチューナー側はBT.601でもいいことになってるので
相互変換せずとも一応それほどおかしなことにはならにようになっている
おかしなことになってるように見えるが
P.S.>>153でおれもミスってるがBT.701ではなくBT.709です
155:名無しさん＠編集中
05/12/23 23:28:02 J4aN7rjc
709と601では色の濃さがどう違うとかで判別できないもんでしょうか？
6角形の色の形は綺麗なので601なのかな？
156:名無しさん＠編集中
05/12/23 23:33:47 i2xPfkki
>ただそれ以前の問題があって現状の地上波はデタラメになってる
どんな？
もしかして、チューナ側の問題？
GRTのオン・オフで明るさが変わったりするチューナがあるんだけど。
157:名無しさん＠編集中
05/12/24 00:05:27 M6j5OgDC
>>156
そのあとのを読んでくれ
局側がまともな変換して放送していないんだよ
158:名無しさん＠編集中
05/12/24 11:03:23 UI+j1ItE
あんたらどこでそんなの調べて来るんだよ。
もうキャプ暦5年になるが、ついていけない。orz
>>151なんて、当たり前のようにデジチューからD端子キャプなんて言ってるけど、
普通コピワンだろう。
159:名無しさん＠編集中
05/12/24 11:17:29 PAvYBQZ1
151だけど、MTVX2004ＨＦとか2005HFはふぬああでも使えて、ふぬああならキャプできるんだすよ。
まあD1でしかキャプできないけど。
色がわかんない・・
160:名無しさん＠編集中
05/12/24 16:53:45 QhiXkkkE
>>156
ゴーストが乗った状態の明るさが異常なんだろうよ
161:名無しさん＠編集中
05/12/30 16:54:57 3zZ2o1h2
昨日の紅白、荻野目洋子のドレスが白飛びしてたぞ。
数年前流した奴は普通だったのに。
色空間が変なのか？
162:名無しさん＠編集中
05/12/30 17:05:40 iGqHZWeB
それは色空間以前の問題じゃね？
アナログテープが劣化するのは当たり前でしょ
163:名無しさん＠編集中
05/12/31 01:53:33 6jCcsghu
前回流してから3年くらいしか経ってないのに？
劣化するなら、初回の86年→前回の方が劣化するんじゃないか？
164:名無しさん＠編集中
05/12/31 02:48:58 6jCcsghu
ちょっと不安になって、
前回のと今回のをパソコンに取り込んで見比べてみたら、
色空間どころじゃなかった。
明るさが全然違う。
あ、別に輝度変化を起こす糞キャプボで録ったんじゃないぞ。
両方パナレコ。
165:名無しさん＠編集中
06/01/05 23:25:29 XaogePmj
白側だけPCスケールなDVD多いな・・
色も濃い気がするけど変換式わからんし俺調整でいいや・・
166:名無しさん＠編集中
06/01/05 23:29:03 os1DNs3D
白側だけPCスケールなDVDなんてないよ
RGB収録じゃないんだから
167:名無しさん＠編集中
06/01/05 23:43:04 XaogePmj
スケール、な
168:名無しさん＠編集中
06/01/05 23:47:22 os1DNs3D
だからYUV>RGBにしたときにどっちのスケールを取るかってのが
TVスケール PCスケール
逆はないんだよ
BT.601でも範囲外のデータが存在することが認められてるんだから
YUVのY235をオーバーしてるDVDがあってもいいの
目で見ておかしいなら
それが製作者の趣味としかいいようがないんだよ
そんなDVDモーヲタは腐るほど持ってるよ
169:名無しさん＠編集中
06/01/06 01:40:06 seorVa/v
ソースのYUVに手を入れずに、
再生時の変換で各自環境にあわせて独自にスケール設定する、でFA
170:名無しさん＠編集中
06/01/09 05:25:41 pAG59LDu
アニメのフレームレートを報告するスレ
ていうのもあることだし
デジタル放送番組の色空間を報告するスレ
があってもいいかなと思った
171:名無しさん＠編集中
06/01/09 05:45:36 2jZtSUi7
よくねーよｗ
色空間の意味分かってるのか？
172:名無しさん＠編集中
06/01/09 05:47:34 m/9P09dN
ts抜いても判別するのシンドイよそれ
173:名無しさん＠編集中
06/01/09 06:24:36 jT8TEXiC
色温度はけっこうめちゃくちゃじゃない？
ガンマは普通にとっただけで黒→白が直線だった。
174:名無しさん◎編集中
06/03/15 00:33:42 BZUboBef
YUV読み込みバグ改善したaviutl1.00まだー
175:名無しさん＠編集中
06/03/16 07:39:47 0Fi1jfXS
>>174
YUY2アップサンプリングでとりあえず対処汁。
176:名無しさん＠編集中
06/06/24 05:26:16 oLoqeDzv
ほ
177:名無しさん＠編集中
06/08/29 11:36:43 7zhaEaEv
捕守
178:名無しさん＠編集中
06/09/13 03:18:43 uNV8LL0J
キャプ後単純にAviUtlではYC伸張フィルタをON、AviSynthではColorYUY2(,levels="TV->PC"）を加えるだけで、
とりあえずOKとしておいていいのでしょうか？
179:名無しさん＠編集中
06/09/13 23:41:20 UaqMYGD2
キャプぼによるからそれでいい世別に
180:名無しさん＠編集中
06/10/02 22:51:05 9y4GEzpU
な、なんのために？
181:名無しさん＠編集中
06/10/31 14:49:56 8tH8dcPo
xvYCCがこの先生きのこるには
182:名無しさん＠編集中
06/11/01 00:03:00 y9zE+ZjK
_,,,......,,__
／_~ ,,...:::＿::;; ~"'ヽ
(,, '"ヾヽ i|i //^''ヽ,,)
^ :'⌒i i⌒"
| ( ﾟДﾟ) ＜ xvYCCもきのこれ
|（ﾉ |）
| |
ヽ ＿ノ
U"U
183:名無しさん＠編集中
06/12/28 09:55:28 7t5vCKgd
RGB24は1ピクセルあたり24bit。
yuv411は1ピクセルあたり12bit。
yv12は1ピクセルあたり9bit。
184:名無しさん＠編集中
06/12/28 16:09:34 Ay0x59Nq
>183
YV12はYUV=4:2:0だから平均するとピクセルあたり12bit。
ピクセル当たり9bitなのはYUV9。
185:名無しさん＠編集中
07/01/27 23:44:41 Axr80zLU
ほす
186:名無しさん＠編集中
07/02/06 03:43:53 R+eFn8hQ
YUY2のplanarとinterleaveって何が違うんでしょうか
187:名無しさん＠編集中
07/02/06 04:06:14 M8EDPCKc
データのならべ方が違う
188:名無しさん＠編集中
07/02/06 20:44:08 p0LMrJTX
どもです
189:名無しさん＠編集中
07/02/19 23:13:43 aEdql+0K
DVD2AVI
190:名無しさん＠編集中
07/02/19 23:21:54 aEdql+0K
他スレからここを紹介されました
今更ながらmpeg読み込み用に使ってるDVD2AVIの
YUV→RGB変換にパソコン色調というのがあることを知りました
今まではAviUtlプラグインの拡張色補正にあるTV→PCのスケール補正でやってましたが
どっちの方が正解なのでしょうか？
個人的には前者の方が綺麗に見えます
191:名無しさん＠編集中
07/02/19 23:39:22 wz6b04WH
綺麗に見えたほうが正解
192:名無しさん＠編集中
07/02/20 01:38:05 q1Y9nnwJ
>>190
d2vをどうやって読み込むかによって違う
193:名無しさん＠編集中
07/02/20 15:26:56 7oMn6iAj
YC伸長フィルタを使っておのれの感性を信じ
調整するのが正解。
194:190
07/02/21 01:03:40 EYB5pI5b
サンクスですとりあえず前者でいくことにしました
DVD2AVIもDGIndexにバトンタッチして心機一転です
個人的には変換前に帯域を十分に使ってるからだと信じてます
波形表示とヒストグラムをにらめっこしならが頑張ることにします
でわでわ
195:名無しさん＠編集中
07/02/26 02:37:32 DjxyUoq5
>>191
ある意味正しい。
196:名無しさん＠編集中
07/03/10 10:42:59 vpNP6lA7
TMPGenc2.5でYC圧縮済みファイル作成可能？
197:名無しさん＠編集中
07/03/11 00:07:25 D/PyMUuG
意味分からん
198:名無しさん＠編集中
07/04/25 20:27:25 gx2mBUZi
RGB24しか入力できないリアルタイム映像処理ソフトが有るのですが、
それにYUY2出力のUSBカメラを繋いでリアルタイムでRGB24にフォーマット変換して
RGB24出力のデバイスとして認識させる方法って無いでしょうか？
199:名無しさん＠編集中
07/04/25 23:51:02 L8S2tmlH
そもそもそのソフトにどうやって映像を受け渡ししてるわけ?
200:名無しさん＠編集中
07/04/26 10:45:24 3m61xA3h
普通のUSBカメラです。
YUY2でも写ることは写るのですが、RGB24でないとできない処理があります。
検索するとリアルタイムで色空間を変換してくれるソフトが有るみたいですね。
201:200
07/04/26 14:06:31 3m61xA3h
こう言うDirectShow Filterと言うのがあるのですが、対応ソフトでないとだめなのかな？
URLﾘﾝｸ(www.medialooks.com)
使い方が分かりませんorz
202:名無しさん＠編集中
07/04/26 14:48:57 HrUsUqgy
おい手前等！！
ピロ野球番組で、激闘何とか空間！ってあったじゃん。
それに倣って激闘色空間という番組をやるべきだ。
昨日クソしてたときに思いついたが、これはまさにビビビッときました。
たかじんのそこまで言って委員会のように、激論を戦わせるべきだ。
タイトルは「たかじんのそこまで激闘色空間で委員会」でよろしいとおもう。
203:名無しさん＠編集中
07/04/26 15:49:23 QYZvbHiU
グラサンかけてるたかじんに色空間は無理
204:名無しさん＠編集中
07/04/26 15:58:25 fdYtFTZ1
前々スレは激しかったよ
205:名無しさん＠編集中
07/04/27 09:15:52 ely+IcWK
グラボに金かけてるヒマじんに色空間は有利
206:名無しさん＠編集中
07/05/01 18:08:54 IeEDGuKg
Vista Ultimate買ってきた。MPEG2デコーダー入ってた。
で、色々弄ってみたけどEVRってやつがVMRとかオーバーレイの代わりに使われてるんだな。
でもEVRもTVスケールでYC伸張してくれないみたいで白っぽいのだが、これってバグ？
PCで再生するならYC伸張するべきだと思っていたのだが、ちがうの？
ゲフォとラデ両方試してもどちらもYC伸張してくれないみたい。。。
207:名無しさん＠編集中
07/05/05 10:55:45 QK7qRbPj
>>206
ラデなら最新の7.4ドライバー入れるとVistaでも伸張してくれるようになるぞ。
208:名無しさん＠編集中
07/05/13 04:53:53 /l8P16+Y
DGMPGDecってBT.601だけだけど、同じようなソフトでBT.709対応しているの知らない？
209:名無しさん＠編集中
07/05/13 05:34:21 uZxa7KW4
まるも
URLﾘﾝｸ(www.marumo.ne.jp)
AviSynthで使うときは、WarpSharpのLoadAviUtlInputPluginでロード
210:名無しさん＠編集中
07/05/13 06:27:32 /l8P16+Y
>>209
あんがと。丁度みたらDGMPGDecが1.49になっていてBT.709出力の問題が直っていた。
211:名無しさん＠編集中
07/05/20 04:54:31 21QP2V1W
Vista+GeForceだけどどうやら最近の風潮ではYC伸張はしないってのがデフォなのかね？
オーバーレイがあった頃はYC伸張されているっぽい感じが主流だったと思ってたけど、
VistaになってすっかりYC伸張しなくなってきているね。
やっぱHDVとかHDTVとかが範囲を超えて使い始めたからかな？
212:名無しさん＠編集中
07/05/20 04:56:05 /kqyXlc3
|
|
し
ﾊ_ﾊ
('(ﾟ∀ﾟ∩.
ヽ 〈.
ヽヽ_)
213:名無しさん＠編集中
07/05/20 18:26:17 ELpAuxLi
マジなのか笑わせにかかってんのかよくわからんな
214:211
07/05/20 19:34:37 21QP2V1W
>>213
私は至ってマジです。
DVDなんかはほとんど16-235だったのでYC伸張はほとんどの場合でうまく機能したけど、
HDソース、特にHDVなんかだと16-255と上を目一杯使っているからそのままYC伸張で
235までで切ってしまうと明らかに明るい部分のディテールがギタギタになっちゃうんだよね。
だからSD素材は16-235と仮定して単に16-235→0-255とYC伸張できたけど、HD素材はそういかないかも。
それでVistaがYC伸張しなくなっているみたいなのはそういった時代背景がらみなのかと思って
ここの詳しい人なら分かるかと思いまして。
215:名無しさん＠編集中
07/05/20 20:25:51 R795EJOs
>>214
>168あたりを読んで納得できる？
216:名無しさん＠編集中
07/05/20 20:28:23 R795EJOs
ごめん。
217:名無しさん＠編集中
07/05/20 22:26:18 ELpAuxLi
>>214
やはり話がよく見えないな。YC伸張する云々はどの時点での話なんだ。
218:名無しさん＠編集中
07/05/20 23:03:34 d66fujsT
>>214
テレビのモニタなら自動でゲインを調整するからね。
多少明るくても問題ない。
グラでAGCを使うべきなのかもな。
SDだろうとHDだろうと100IRE以上の素材なんて腐るほどあるよ。
219:名無しさん＠編集中
07/05/21 09:45:25 MGT2U7ZD
>>218
どうもあなただけは話の内容を理解しているようですね。
>>214
事実、確かに最近はほとんどのDVDは16-235の範囲内に入っている。
また、HDVなんかはSONY、Canon問わず、みんな235-255を普通に使っている。
だから盲目的に16-235を0-255にYC伸張すると、HDVなんかだと上が飛んでしまう。それは事実。
よって、>218が言うようにAGCみたいな機構で自動的にYC伸張をOn/Off出来ない限りどうしようもない。
あっち立てるとこっち立たずになってしまう。
220:名無しさん＠編集中
07/05/21 10:14:52 MGT2U7ZD
>>214
ちなみに最初の質問はVistaがYC伸張しなくなったという話についてだが、
恐らくだが特に最近のHDコンテンツが16-235の範囲外を使い始めたという事実が
PCモニターでsRGBに最適化されているWindowsでどうしようもなくなってきたのではないかな？
結局、YC伸張しないようにすることで見た目は悪くなることがあっても、情報の欠落よりはマシだと思ってるんじゃないかな？
221:名無しさん＠編集中
07/05/21 23:33:53 PIe4n1OH
基本は伸張だと思うよ
範囲外を使っているソースがあったとして
＞明らかに明るい部分のディテールがギタギタになっちゃうんだよね
の問題があったとしても
これをストレート変換で見るとなると
他の部分は色がくすんで見える（sRGBの一般的なモニターならば）。
範囲外の値を使っていてストレート変換で
色がくすんで見えないって事は
とてつもなく広い色再現帯域を持ったディスプレイを所有している事が前提だよね
※NTSC比で90%超えているのもあるよね
HDVとかHDTVとかでそういうデーターが出始めているって事は
オマエラ、いつまでも古臭いｼｮﾎﾞモニター使ってないで
買い換えろって事じゃないか？（ゲイツもそれに賛同しているとか）
222:名無しさん＠編集中
07/05/22 00:23:50 uizLjBzr
>>221
確かに基本は伸張だと思うが、特に235-255はHDになってからはまるで当たり前のように使ってるね。
それに最近のHDTVはこのあたりの値もちゃんと画面上に表示しているように見える。
xvYCCなんか特にそうだけど、もうRGB変換後に範囲外になるようなYUVデータは平気で使われつつあると感じる今日この頃。
>オマエラ、いつまでも古臭いｼｮﾎﾞモニター使ってないで
>買い換えろって事じゃないか？（ゲイツもそれに賛同しているとか）
家電業界は率先そうすることによりSD→HDで買い替え需要を狙っているように感じる。
ゲイツはPC業界で家電とは関係ないからただ単に事実としてそういったデータを現状のsRGB規格で受け止めるために
ストレート変換を使わざるを得ないという事じゃないかな？
223:名無しさん＠編集中
07/05/22 00:41:59 qVsgX0nD
URLﾘﾝｸ(www.avsforum.com)
↑を読むと、VMR9（ストレート変換）、オーバーレイ（伸張変換）
好きなほうを使えと書いてある。
URLﾘﾝｸ(www.avsforum.com)
↑もなんかイロイロ書いてある。
224:名無しさん＠編集中
07/05/22 04:07:12 uizLjBzr
>>223
思うに伸張変換もストレート変換も両方正しいと思う。問題は好きな方をどうやって使うか。
Vistaなんかだとメディアプレイヤーもメディアセンターもそれ選べるようには作られてない。
どうやらVistaだとVMR9の後継のEVRってのが使われていてそれがVMR9と同じようにストレート変換を使うようです。
↑のAVSフォーラムの記事を見るとビデオにうるさい人たちはストレート変換を好むようですが、
逆にモニターの調節等すらしない一般人は伸張変換を好むように思われます。
また、コンテンツにもよりますね。日本の最近のデジタル処理されたアニメ等はきっちり16-235になっているんで
伸張変換したほうが断然良いですし、HDVやフィルム映画などはストレート変換じゃないと上が切れちゃうみたいです。
結局、結論としてはソフト側では自動的に決められないのに、勝手にどちらかに決め込んでいることが問題かと。
225:名無しさん＠編集中
07/05/22 18:45:38 Q1n9cdXS
そりゃ間違ってるなら規格にならないだろう。
どちらも正しいからこそ両方の規格があるわけで、
どちらを選ぶかは時と場合（と使用者の趣味）によるのは自明。
つーことで結論に同意。
226:名無しさん＠編集中
07/05/22 22:23:05 rrTNAVnB
実にフザケタ規格だ
なんかムカムカするよ
筋が通ってねえ
227:名無しさん＠編集中
07/05/23 00:01:19 +4PXH4t1
nVIDIAのドライバ開発が、糞なだけに一票。
規格とか実際の使いかってとか。どうせ、何も考えてないって。('A`)
228:名無しさん＠編集中
07/05/23 01:05:18 m/7ZVbLP
>>227
君は今までの内容をまるで読んでいないだろ・・・
おじさんビックリだよ
229:名無しさん＠編集中
07/05/23 02:53:46 +4PXH4t1
ええ。
224氏が最後に記述した結論でいいでしょ。問題無い。
御免ね。「 nVIDIAのドライバ開発が糞 」って云いたかっただけなんだ。
「 nVIDIAが何も考えてないで、ドライバ開発してる 」とか云いたかっただけです。
9X系以降のnVIDIAドライバの迷走っぷりは、キツイDEATH。 orz
230:名無しさん＠編集中
07/05/23 08:09:12 FQyq0JCt
ドライバに不満あるようだけど
何に不満なんだ？
オーバーレイの色が標準でntscブラウン管向けになっていない点？
evrがストレートだから？
pcモニタで見るならRadeonだって正解ではないし
ソース時点でバラバラだから正解なんて無い
てのが結論でしよ
231:名無しさん＠編集中
07/05/23 10:50:11 LFJp5CPa
Vistaになったら昔の情報が適用できなくなったね。
VistaではビデオはDXVA2経由でD3D9を使うようになっているようで、
YC伸張する・しないがAPIレベルで指定できるように改良されている。
URLﾘﾝｸ(msdn2.microsoft.com)
DXVA2_NominalRange_0_255が伸張変換、DXVA2_NominalRange_16_235がストレート変換だと思う。
今はドライバーがこなれていないからだと思うが、MSの方針としては16_235を標準としたいみたいですな。
232:名無しさん＠編集中
07/05/25 19:08:52 DMXx3JvV
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に伸張する必要があるが、どういったガンマを適用すれば良いかと困っている。
きっとこのあたりの話って先駆者がいると思うのだが、こういった変換を取り扱っている話を聞いたことありませんか？
233:名無しさん＠編集中
07/05/25 21:49:13 Qmri8tz6
先駆者なんていないよ
制作側がPCで見る事を無視して
いるのだからどうしようもない
234:名無しさん＠編集中
07/05/26 01:36:12 IKNN1LT+
>>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に変換する式が今のところ正式にはない。
間違いなく家電はそうやっているだろうけど、現状だと個々のメーカーのノウハウ段階だろうね。
235:名無しさん＠編集中
07/05/26 06:32:10 Nf9jHvew
アナログ時代に16-235なんて概念すらない。なぜならアナログだから。
数字に対応させたのはあくまでデジタル化のため。
PCは規格に従って16-235を有効範囲にしてるだけ。
盲目的とかいうわけではないし、デバイスの制限とかでもない。
BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
その値をどう表示するかは受け手次第。
実際のところは、多少白飛びさせるくらい明るい方が鮮やかに見えるってことだけな気がする。
それが多分メーカーのノウハウなんだろうね。
236:234
07/05/26 14:58:45 IKNN1LT+
>>235
大筋は私が言っている通りだとは思うけど。
>実際のところは、多少白飛びさせるくらい明るい方が鮮やかに見えるってことだけな気がする。
つまりは16-235を0-255にYC伸張すれば、236-255はクリップされて白飛びしちゃうという事だよね？
厄介なのは最近のプラズマとかLEDバックライトの液晶だと236-255の領域でも見えるんだよね。
あと、ビデオカメラメーカーがわざと見栄えをよくするためにこの領域を平気で使ってるし。
それがPCで見たときに違いとして現れ始めたのが問題として浮上してきてるんだと思う。
237:名無しさん＠編集中
07/05/27 10:22:42 SuU4v6cz
>236
結局、
> BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
> その値をどう表示するかは受け手次第。
ってことだろ。
そこから先はもう宗教論争でしかないよ。
238:名無しさん＠編集中
07/05/27 15:01:32 IVs/+CUP
>>237
うーん、>232って宗教論争と関係ないような。フリーソフトの作者か何かじゃまいか？
その受け手次第の部分を>232がどうにかしようとして困っているんじゃまいか？
>ガンマを適用しながら16-255を0-255に伸張する
アイデアは良いと思うし多分今時のテレビもやってそうと思う。
漏れは頭良くないんで誰か頭いい人いたら>232を助けてやってくれ。
そしたらいいソフトが出てくるかもしれん。
239:名無しさん＠編集中
07/05/27 19:51:49 phyEHhl3
ffdshowで入力を16-255にすればいいじゃん
ガンマは変更する必要ないと感じる
240:名無しさん＠編集中
07/05/28 00:34:09 bf/dY99X
16-235を守ってるメーカーだってあるのに、規格を軽視してる一部メーカーのためだけに
自分も規格を無視するなんて普通はやらないとおもうが。
何とかする方法なんていくらでもあるじゃん。
ffdshow使ってもいい。
avisynth経由で再生したっていい。
適当なソフトで補正して再縁故することだってできる。
それらが求める物と違うならdirectshowフィルタとかを自作すればどうにでもなる。
てことで、いいアイディアだと思ってかつ専用にソフトが必要だと思う人がやればいいじゃない。
241:名無しさん＠編集中
07/05/28 03:54:26 X+udwO24
>>239
それ駄目だと思う。
入力を16-255で出力を0-255にすると、結果としては暗い方向にシフトするから画面が暗くなる。
だからガンマ掛けないと駄目だという話になるんだと思うよ。
242:名無しさん＠編集中
07/05/28 03:58:28 X+udwO24
>>240
俺もメーカーだけど、16-235はかなり微妙になってきている気がする。
試しに235-255のデータ作って最近のHDTVで表示してみな。
どれも結構けろっと表示すると思うよ。
>てことで、いいアイディアだと思ってかつ専用にソフトが必要だと思う人がやればいいじゃない。
その思っている人がやろうとしてヒントを探しているんだと見えるが。
243:名無しさん＠編集中
07/05/28 04:02:32 X+udwO24
>>232
俺はメーカーでも直接携わっているわけじゃないんで大丈夫だと思う。
細かくは計算してないけど、どんぶり勘定だとガンマ0.9位で良いかも。
244:名無しさん＠編集中
07/05/28 15:37:26 yP1g2Co7
何に悩んでるか理解できん
規則にあわせて作ってくれない物に対して
それを作者の意図する色を再現させようなんて無理
その素材を作った人が基礎となる色を示さない限り
見る側が調整するしか無いし、決め撃ちできない
245:名無しさん＠編集中
07/05/28 16:01:16 X+udwO24
>>244
残念ながらその信じている規格は特に絶対を定義しているわけじゃないんですよ。それが現実なんですよ。
無理と言われても製品作んないといけないし、大体はうまく行くような落としどころも探さないといけないし。
規格とか無理とか言ってると物は出てきませんよ。
246:名無しさん＠編集中
07/05/28 16:39:51 Wh0vqJJt
>>245
私は244と違うけど
貴方が妥協点を見つけたいと考えるのは理解できるが
何を基準に決定するのですか？
そんなの無理じゃないの？
＞最近のプラズマとかLEDバックライトの液晶だと236-255の領域でも見えるんだよね。
＞あと、ビデオカメラメーカーがわざと見栄えをよくするためにこの領域を平気で使ってるし
例えばこの前提はストレートで変換した場合でしょ
伸張したらクリップするんだから。
固定画素の表示デバイスは駆動回路の手前ではデジタルRGBにしなくてはならない。
しかも255が上限だからコレよりも上の値はとれない（255を真白としている）。
固定画素の表示デバイスで
YUV236-255の領域を使うなら
YUV255を完全な白にしなくてはならず
YUV235は少し曇った白になる。
でもそれじゃクリップの問題は解決できても他の色に影響が出る。
ブラウン管のように入力信号をアナログで扱えるのであれば
RGB255をという上限値がないから
YUV236-255を使っても全く問題にならない。
アナログの表示デバイスだから、なんとか表示できちゃう。
固定画素の表示デバイスはデジタルだから
入力された値の何れかを真白、真黒に割り当てる必要があって
仮に製作側を規格を考慮しなかったとしたら
これはもう無理ですわ。
247:名無しさん＠編集中
07/05/28 16:42:55 Wh0vqJJt
無理という言葉はよくないね。
・クリップをなくす
・他の色が少し曇った感じになる
どちらかを選べという事になる。
妥協点てその間で適当に見える場所を探すだけで。
そんなの個人の好み。
248:名無しさん＠編集中
07/05/28 17:42:06 X+udwO24
>>246
理論的には合っているけど現実はちょっと違う。
>固定画素の表示デバイスは駆動回路の手前ではデジタルRGBにしなくてはならない。
>しかも255が上限だからコレよりも上の値はとれない（255を真白としている）。
TVに限定すると最近のハイエンドのプラズマとかLEDバックライト液晶とかプロジェクターはちょっと違う。
それらだと235が十分に白で、235-255の間はさらに明るい光源を出すようにしてるんだよ。
問題は発光体や光源の改良の成果で従来よりもコントラストが高めにできるようになってきたので235を十分に
明るい白にしておきながらさらに今までよりも明るいコントラストを表現できるようにするため235-255の部分が使われている。
>>247
どちらかというのは0-255(16以下、235以上はクリップ)か16-235(曇った感じ)の事だと思うけど、それだとどちら問題ありなんだよね。
だから上のような話になっているんだよ。つまり16以下はクリップするけど、235以上はクリップしない方法。
もしそのあたりの技術に興味があるならSONYとかの技術資料に出てたりするよ。
249:名無しさん＠編集中
07/05/28 18:08:54 Wh0vqJJt
>>248
表示デバイスの色域が
昔と変化したから
その帳尻合わせをデーター側で行おうという事ね。
でもそれならストレートで入力して表示デバイス側で
ガンマや黒レベルを変えるべきだと思うよ。
多くの固定画素表示ディスプレイは
明確にRGB値を変更する
独自のカラーコンバーターを内蔵しているから。
信号処理の中間部分でいくら弄っても解決しない。
ストレートで入力して
16を真黒
255を真白
250:名無しさん＠編集中
07/05/28 22:21:20 ytNPdy9C
>>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自身の感性を信じて試行錯誤するのが良いと思う。
正しい映像だと「暗くて使い物にならない」のなら、後は好みの問題だから。
251:名無しさん＠編集中
07/05/29 00:39:04 JTzPshyt
>>242
そのHDTVって16未満はそれ相応に表示されるの？
表示されるなら単にストレート変換になるけど。
てかさ、0-255じゃほんとはだめだよ。1-254でないと。
252:名無しさん＠編集中
07/05/29 02:08:48 FHHidpBJ
>>249
TVだと表示デバイス側で出来るけど、PCモニタだと無理だよね。250氏が的を得てる感じだな。
>>251
HDTVだろうがなんだろうが、基本的には16未満は表示されなくてOK。
0と255はアナログ時代だと同期信号だけど、デジタル時代だと問題ないよ。
デジタルで0と255入力しても内部で問題あるなら0と255は自動的にクリップされる。
253:名無しさん＠編集中
07/05/29 02:24:57 FHHidpBJ
>>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のストレート変換でも明るさが違うって事？
254:250
07/05/29 22:51:44 OSQe9dkn
>>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)は暗くなるのだから。
画像全体でどうなるかは画像次第。
255:名無しさん＠編集中
07/05/30 02:24:25 ftvRBIkp
>>254
＞＞好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
＞＞暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。
俺もガンマ0.9は結構悪くないかも。正確に計算する方法が分かればいいのだが。
＞＞画像全体でどうなるかは画像次第。
画像次第というのはどんな変換でも当たり前だけど、0-255変換と16-235変換は平均的には
画像全体で見た場合は同じ明るさじゃないか？
256:250
07/05/31 00:56:15 RTVARtYE
>>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割暗くなる。
この変換との比較だったので、画像次第で結果が変わるという答え。
257:名無しさん＠編集中
07/05/31 15:51:56 TgR+YRvz
>>256
なんかややこしくなっているだけの気が。
用はストレート変換の時の16-255の範囲のデータを0-255にリニア変換した場合、
黒の方向に引っ張られるから全体的に暗くなるのをガンマ補正で全体的に明るさを
引き上げて元の画面の明るさに近づけたいという趣旨なんでは？
＞16-235範囲のみで構成される全ての画像は、16-255変換で16-235変換時より2割暗くなる。
16-235範囲のみってのは今の話の筋からするとずれていると思うよ。
あくまでも16-235のストレート変換 + 236-255範囲をそのまま保持なんでは？
2割暗くなるっていう数字の出所が分からん。
258:250
07/06/01 23:35:42 0L7wCrzw
>>257
2割という数字の出所か。それは気がつかなかった。
それじゃ、16-235範囲のみが話の筋からずれていると思うのも当然だね。
たぶんだけど、分らなくても特に問題は無いよ。
論理や計算で答えを求めるという選択肢が消える程度だから。
259:名無しさん＠編集中
07/06/02 04:05:02 kvVZTR3G
>>258
ストレート変換の状態16-235[0-15と236-255はクリップしない]と、
その内の16-255を0-255にリニア変換した場合の明るさの違いの話じゃないの？
260:250
07/06/03 12:22:53 sQJkgEcx
>>259
なぜ、ストレート変換を16-235と表現するの？
261:名無しさん＠編集中
07/06/03 12:43:23 gJ8zyvVr
きっと色空間って概念を全く理解してないからだよ。
262:名無しさん＠編集中
07/06/04 15:15:44 hSQLv5Js
>>260
慣例でしょ？ググってもストレート変換を16-235と表現している方が多いし。
それに259氏は実際に"[0-15と236-255はクリップしない]"と注釈まで付けているじゃん。
てか250氏、揚げ足取るよりも>259が指摘した16-255を0-255とした場合の明るさの違いという指摘の方が大事かと。
263:名無しさん＠編集中
07/06/25 14:12:49 Nq6UpP7a
PS3とかXbox360の最新ファームで設定できるようになってるやつって16-235と0-255の切り替えだよね？
でもXbox360には3種類の設定があってその中間みたいなのが選べるみたいだけど、あれってなに？8-245とかには見えないけど。。。
264:名無しさん＠編集中
07/07/04 15:59:13 +Vx8B1ax
すげえどうしようもない意見なんだけどいいかな。
0-255ストレート表示にして、16以下が真っ黒に見えるようディスプレイを調整すればいい。
たぶん、これがテレビの人の考え方だと思うんだ。
リビング視聴を考えると明るい部屋だから16以下の階調はわからないと思うんだよね。
今のテレビなら16以下でもちゃんと見えるはずなのに、235以上は使うけど
16以下は使ってないことの理由だとも考えてる。
んで、ホームシアターなんかの暗い環境で視聴する場合でもそういう調整にすれば見るだけなら問題ない。
問題になるのは視聴と作成を同じ機器で行おうとする場合と
視聴以外の用途で同じディスプレイを使用する場合。
つまりPCでの使用ね。
これの対策としてはディスプレイに16-255表示用、0-255表示用の二つのプロファイルを作って適宜切り替える。
16-235用のプロファイルも作ってもいいかもね。
んでPC内部では全て伸張無しの0-255ストレートで演算させる。
265:名無しさん＠編集中
07/07/04 20:57:11 wTmbV+oG
> PC内部では全て伸張無しの0-255ストレート
なんだこりゃ
266:名無しさん＠編集中
07/07/04 21:26:18 AHrIg2p1
γが1.0って事じゃねえの？
267:264
07/07/04 22:33:10 HCA1FGWW
ああごめん、その部分は一切伸張等の変換処理をしないって意味で書いた。
改めて簡単に言い直すと、
今まではほとんど16-235の範囲内しか使われてなかったから当然のように0-255へ伸張してたけど、
それが16-255まで使われることもある現状では伸張は行わずに出口(ディスプレイ)で
辻褄を合わせたほうがいいんじゃないかってことね。
268:名無しさん＠編集中
07/07/05 05:02:09 ZZqUKEfW
それはフルスクリーンで、かつ、ビデオ画面のみが表示される場合のみ使える方法。
例えば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になると文句を言う人が多いから。
269:名無しさん＠編集中
07/07/06 01:35:49 mFQXzn6S
>>268
これがこのスレのFA？もうこれ以上はこのスレで議論する話もないかな。。。
270:名無しさん＠編集中
07/07/08 07:01:08 wBtlNGR6
このスレでアニメの話して良いのかわかんないけど、
ウミショーって
>>221
に書いてある見たな、
２３５より上の輝度入ってる？
271:名無しさん＠編集中
07/07/09 17:35:39 ZUP50VT4
>>270
DVD?TV?何の話だ？
235より上が入っていても構わない、ただし、それを受け手が表示するかどうかは受け手次第。
逆に、16より下は入っていても構わないが、受けては表示しちゃだめ(もしくは見えないように調節する)。
272:名無しさん＠編集中
07/07/14 21:49:39 cJSPtMDN
>>250 くらい的確な説明が出来る人が理解してる人。
273:名無しさん＠編集中
07/07/14 21:50:51 cJSPtMDN
>>240
頭がかたい
274:名無しさん＠編集中
07/07/15 00:47:00 pI+Mwr6R
16より下を表示しちゃいけない理由がわからないんだけど、
なにか規定があるのかな。
275:名無しさん＠編集中
07/07/15 00:55:40 0Y65Ku51
0と255は同期信号だから使っちゃ駄目ってのはどっかで読んだ
276:名無しさん＠編集中
07/07/15 02:49:12 lN1LHNiQ
>>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は区別出来ないのが正しい。
277:名無しさん＠編集中
07/07/15 11:53:31 p9uHdJj3
>>275
0-255を直接アナログに変換した場合の0と255にあたるアナログレベルの場合な。
デジタルでは0と255は存在しても構わないし、実際にPCでは表示する。
278:名無しさん＠編集中
07/07/15 14:18:31 pI+Mwr6R
>>276 そんな古い慣習を今まで引きずってるのねえ。
その比率だと16-215が0-100%になるけど実際は16-235だから実際には
1%あたり2.2の計算になるのかな。
なので0-255だと-7.27%から109.09%までの範囲になるような。
んで現在はそのマイナス部分は表示しちゃいけないけどプラス部分は表示してもいいし、
実際に使われてるソースもあるってことなのね。
279:名無しさん＠編集中
07/07/16 14:57:15 4aVb+cno
0-15はデータに入っててもいいけど、表示側は見えないように調節しておいて欲しい。
236-255はデータに入っててもいいし、表示側は出来れば見えるようにがんばって欲しい。
ってのが建前。
あとは結果は受け手次第のベストエフォート型。
280:名無しさん＠編集中
07/07/19 21:24:24 bEE+yokE
質問なんですが、最近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読み込みをしています。
281:名無しさん＠編集中
07/07/19 22:41:47 0DeyL2E3
それはもう、好きなほうをとしか言えない気がする。
HDデータはBT.709でしか再生できないってなら別だけども。
再生できないというか709として再生されてしまうということね。
なので601でエンコしてそれを709プロファイルで再生した場合にどうなるか
逆に709のものを601で再生した場合にどうなるか
ってのも考えに入れておいたほうがいいかもしれない。
んま、ソースが709なのが明らかなら709のままエンコしたほうがいいとは思う。
エンコ時と再生時で二重に変換されるのが防げるし、PC再生ならその差異を埋める設定もできるし。
282:名無しさん＠編集中
07/07/19 23:04:36 dRxMo2eW
もともとRGBのデータをBT.709のYUVで保存したものがあるのですが、これをできるかぎり
元のRGBに近い状態にするにはどのような変換式を使えば良いのでしょうか？
283:名無しさん＠編集中
07/07/19 23:20:19 bEE+yokE
>>281
なるほど。
たしかに、BT.709でエンコードしたものをavsで読ませて
ColorYUY2(
\levels="709->601",
\opt="Y:16-235 UV:16-240",matrix="rec709s",
\debug=0, interlaced=false)
みたいにフィルタを通して変換させながら再生させる手もありますね。
でも、逆に601を709に変換して読ませる方法は何かありますか？
avisynthのフィルタに見あたらなくて…
284:283
07/07/19 23:28:07 bEE+yokE
あと、ソースがBT.709なのは明らかだと思います。
m2v.auiでソースを維持、BT.709、BT.601をそれぞれ選び、
それぞれAviUtlで読み込み、フレームをBMPで保存して見比べたところ
ソースを維持とBT.709はまったく同じ色でした。
他に方法があるのかもしれないですが、もっと楽なやり方があるなら笑ってやってください。
285:名無しさん＠編集中
07/07/20 00:06:15 0DeyL2E3
これでいけない？
URLﾘﾝｸ(avisynth.org.ru)
ファイルはこれね
URLﾘﾝｸ(avisynth.org)
再生確認だけならMediaPlayerClassic HomeCinemaとHaali Renderer(Haali Matroska Splitterに同梱)の
組み合わせで簡単に切り替えができるんだけどね。
Haali Rendererがデコーダを選り好みするからちとアレだけども。
ffdshowと組み合わせればまず再生はできるかと。
286:名無しさん＠編集中
07/07/20 00:07:35 0DeyL2E3
間違えた。
Haali Matroska SplitterじゃなくてHaali Media Splitterだった。
287:名無しさん＠編集中
07/07/20 00:14:37 ddO/yq+C
>>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で再生
のような条件で比較されたという事でしょうか？
288:283
07/07/20 01:34:28 hMZV6A4v
>>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であることは間違い無いと思うのですが。
289:名無しさん＠編集中
07/07/20 20:07:19 X60N8DXO
>>288
切り替えはそれであってる。
参考用に画像撮ってみた。
URLﾘﾝｸ(www.uploda.net)
ソースはここの動画。
URLﾘﾝｸ(www.gran-turismo.com)
赤はすげえ変わるねえ。
記憶色やシーンは冬ですと言われれば601が正しいように見えるし、
ナチュラルさやシーンは春夏ですと言われれば709が正しいように見える。
290:名無しさん＠編集中
07/07/20 20:09:49 X60N8DXO
ああ、ここ直リンできないのか。
こっちで落として。
URLﾘﾝｸ(ud.gs)
291:287
07/07/20 21:52:33 ddO/yq+C
>>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(準拠)として扱う
292:名無しさん＠編集中
07/07/21 01:11:04 X9tNrxTT
>>291
709は709で変換しないとおかしくなる。
SD時代の古めのソフトは601専用な事が多いからなHD時代だと基本は709だから量対応が必修。
293:288
07/07/21 02:48:01 /2A9wEhM
>>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として、扱い再生する環境を作りたいのですが
どのソフトを使えばよいでしょうか？
294:288
07/07/21 02:52:13 /2A9wEhM
MPCはHomecinema 1.0.8.0です。
295:名無しさん＠編集中
07/07/21 17:00:44 X9tNrxTT
>>293
確かXPのVMRとかVMR9ってBT.601専用だったと思う。
VistaのEVRはBT.601とBT.709の両方対応していたと思うよ。
296:名無しさん＠編集中
07/07/22 12:44:58 o66TfgWH
>>295
確かにVistaだとBT.601とBT.709に対応しているみたいだけど、まだドライバーが安定してないっぽい。
297:288
07/07/24 21:39:06 7OcExHVO
>>295
そうですか…XPだと駄目ですか。
XPでVMR7を使って再生するならBT.601に変換させてしまった方が正しい色でみれるのかもしれませんね。
vistaのEVRでは、XPのVMR7のようなオーバーレイの概念が無くなってしまったということは、
GPUのデスクトップの色設定などが、たとえ動画を伸張再生したとしても、VMR9と同じように動画の色にも連動してしまいますよね？
そうなると、動画再生するディスプレイでも常に正確な色設定をして、そのディスプレイを買い換える毎に正確な色設定をするしかないんでしょうね…
EVRはストレートで、RADEONならドライバで伸張できるみたいですが、
あれはレジストリの項目の通り、ソースに関係なくBT.601扱いで伸張しますよね？
だったらVistaだとドライバで伸張するより、どちらかの色空間行列のソースであるかが指定できて
それに合わせて伸張の有無を選択できるHaaliMediaSplitterのレンダラを使うほうが、
正確な色でみれるということになりますが正しいでしょうか？
298:名無しさん＠編集中
07/07/25 16:48:59 w2mWqxNb
>>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のどちらかでパラメーターを指定できるはずだけど、公開していなければお手上げ。
299:名無しさん＠編集中
07/07/26 22:10:33 MZsf6d0Q
>>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側は伸張しなくていいということですよね？
300:名無しさん＠編集中
07/07/27 02:46:34 SSg9HlZy
>>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:名無しさん＠編集中
07/07/27 05:29:16 VbhM82UL
最近変なのが住み着いたんだね、このスレ
302:名無しさん＠編集中
07/07/28 02:06:51 kpavWSQ5
>>301
ん？>280のことか？
303:名無しさん＠編集中
07/08/03 16:05:35 Nzw2XfB2
PCをHDMIでフルHDのTVにつなぐ場合、PCではYC伸張するべき？しないべき？
VistaにCatalyst 7.7入れたらYC伸張しなくなった、これはバグ？それとも仕様？
304:名無しさん＠編集中
07/08/06 13:00:24 CbFoNtus
>>303
たぶんね、もうDisplayPortが出ないとどうにもならないかも。
HDMIって家電用のガチガチ企画っていうし。
305:名無しさん＠編集中
07/08/08 02:28:08 YNaqckaG
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)
かｗｽﾏｿｗｗｗ
306:名無しさん＠編集中
07/08/08 03:25:49 D2kdxwUa
見慣れたYV12での24ビット騒動か
307:299
07/08/09 18:41:00 z8uLSEhi
>>300
返信が遅れてしまって申し訳ありません。
>そうとは言い切れない。どっちのドライバーでもVMR7使えばオーバーレイを使えるし、XPドライバーでもEVRは使える。
>ドライバーとレンダラーは別。実際にはレンダラーがドライバーの違いを吸収してくれる、が、完璧ではない。
なるほど。
>出来るけど、デコーダーのBT.709の情報はドライバーには届かないからVMRを使ったときの動作は不定。
>将来的にVistaとかで同じファイルを再生したいのならそのままの方が良いだろうね。
>XPだとドライバーの挙動に合わせて変換するしないが必要かも。ただし、それは保存用としてじゃなくて一時的な再生専用。
うーん…結局は、気にする人は動画再生はVistaで、編集はXPと二台用意するのがベストで
作る動画は色空間行列がそのままのものと、変換したものを二種類作成しておくしかないようですね。
>ちょっと違う。
>ただし、DXVA2からの出力はさらにデスクトップの設定の影響を受ける。
なるほど。理解しました。
>伸張する・しないはGPUが行う。それを指示するのはアプリ(EVR)の役目。
なるほど。それはVMR9の伸張と同じくGPUのドライバが対応しなければ、不可能であり
ラデの最新ドライバは、Vista用のドライバでもVMR7、オーバーレイとVMR9の伸張にしか対応していないので伸張できていない、
ということでよろしいでしょうか？
308:名無しさん＠編集中
07/08/10 01:53:43 BNucx8Ny
>>307
ラデスレによるとラデの最新ドライバはかなりおかしいみたいだよ。
7.6まではオーバーレイ、VMR9とEVRは伸張ON。
7.7ではオーバーレイが伸張ON、VMR9とEVRは伸張OFF。
309:名無しさん＠編集中
07/08/16 16:17:10 +STcBzPQ
>>308
ラデスレより
ｽﾚﾘﾝｸ(jisaku板:337番)
310:名無しさん＠編集中
07/08/22 00:47:30 Tr6RwzoJ
>>309
ゲフォ用の設定もよろしこ
311:名無しさん＠編集中
07/08/29 17:48:43 or3/ZWgR
で、YC伸張するのしないのどっちよ、このスレ的には。
312:名無しさん＠編集中
07/08/29 18:05:40 87P8S1R8
バカ来た
313:名無しさん＠編集中
07/08/30 00:02:16 ZMFJt0vs
伸張するしないとは無縁の世界を構築せよという結論ですよ。
314:名無しさん＠編集中
07/08/30 17:12:54 G2FzpI0C
>>312
じゃああんたはどっち派よｗ
YC伸張する ノ
315:名無しさん＠編集中
07/09/09 07:15:43 P4fPphGz
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)
デフォルト値は適当なので、いろいろ試してみてください。