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)
デフォルト値は適当なので、いろいろ試してみてください。
316:名無しさん＠編集中
07/09/09 17:17:44 +XcDO3KJ
>>315
GJ!
EVRはDXVA2を使うはずですからそのお陰でマトリックスや伸張を指定できるのではないでしょうか？
DXVA2はVistaドライバーでしかサポートされていないはずですからXPだと機能限定なのもうなずけます。
ところで当方だとXP上でEVRが使えました。
317:名無しさん＠編集中
07/09/09 18:43:27 ivsYzh/O
ｨｸ
__,､ | | くﾆ} {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
/ ／ {二)
ヾ_')
318:名無しさん＠編集中
07/09/12 06:20:20 h+jsmPMQ
すいません少し疑問に思ったので質問させてください。
モンスター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なのでしょうか？
それとも「おめーのやっていることは無意味だろ！！」なのでしょうか？
319:名無しさん＠編集中
07/09/12 18:26:35 7UEThZyN
>>318
キャプチャー時に0-255に伸張されていて基準白が255になっているってこと？
それはキャプチャーデバイスがおかしいね。
基本はキャプチャー時は16-235で再生時に伸張して0-255。
0-235ってのもありだけど、ITUとかで定義されてないからあんまり誰もやりたがらないよね。
↑の方に色々とヒントになりそうなこと書いているけど。
320:名無しさん＠編集中
07/09/12 19:23:47 h+jsmPMQ
>>319
レスありがとうございます。
モンスターXの画像がなぜかコントラストが強かったので波形プラグインで色々調べてたらそうなってました。
D3キャプという特殊性からくるためかな？しかもカラーバー入れてオートゲイン働かせるとYゲインが基準よりデカめに調整されるので
ここでもコントラストがでかくなる要因があった。PV3はどうなってるんだろう。
321:名無しさん＠編集中
07/09/13 01:24:23 GUwd5cmM
>>320
コンポジットだろうとコンポーネントだろうとHDMIであろうと、DVI以外のときは入力は16-235でキャプチャーされるべきだね。
一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。
322:名無しさん＠編集中
07/09/13 02:05:52 8ugE1STt
>>321
＞一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。
モンスターXにおいてはこれはある意味仕方がないという気もするんだけど・・・
だってデコードの再チューナー側でYC伸張されたY0-255のアナログ信号をキャプるものなんだから、
素直ちゃ素直な仕様かなw
ただ後から加工や記録を前提にしているおいらたちから見れば、糞仕様と言われてもしょうがないんだよねぇ・・
とにかく、Pb Pr の答えも見つかりそうにないので0-235はやめて15-235でしばらくキャプって見ようと思います。
323:名無しさん＠編集中
07/09/13 14:45:34 GUwd5cmM
>>322
そもそもなんで途中か最後にRGBに変換してるんだろ？
ずっとYUVのままならYC伸張もなにもいらないのに。
324:名無しさん＠編集中
07/09/13 18:54:41 8ugE1STt
>>323
それって出力までTVで見なさいよってこと？
325:名無しさん＠編集中
07/09/13 21:24:44 /NoMQh50
グラボに直接YUVデータ流し込めば？
326:名無しさん＠編集中
07/09/13 21:50:24 uoV1Y7YI
>>323
勉強不足でおっしゃる意味がわからんのですが ＾＾；
とうぜん、エンコ自体はYUV（YUY2）で通してます。
RGBへ変換しているのはチェックのためにAVIUTL+波形表示プラグインで開くときだけです。
>>323さんがおっしゃるのは、BT709のまますれば？って言ってるんですの？
ちなみに、うちのGF7300ではYUV入れてもYC伸張して表示してくれないので
15-235ものは再生時に補正してます。
327:名無しさん＠編集中
07/09/14 00:42:13 0L3PidzA
波形表示はYC2のまま表示できるじゃん。
328:名無しさん＠編集中
07/09/14 00:51:18 Gooqaxlg
>>326
>とうぜん、エンコ自体はYUV（YUY2）で通してます。
ってことはどこで伸張されてるの？
だってYPbPr→YUY2なら伸張関係ないはず。
どこかにYUV→RGBがなければ輝度そのものはYPbPrのソースのままのはず。
329:名無しさん＠編集中
07/09/14 01:15:25 4FkTMcTk
書き方が悪いのかなぁ・・
キャプボのデフォが0-255でキャプされていて
それを変則Y0-235に調整した場合Pb、Prはどうしたら良いのかって事が元々の質問の趣旨だったんですが・・
330:名無しさん＠編集中
07/09/14 01:19:25 /oxrRaau
色差も0-255でキャプされんの？
331:名無しさん＠編集中
07/09/14 01:20:51 4FkTMcTk
そうです
332:名無しさん＠編集中
07/09/14 01:30:30 /oxrRaau
もうデフォで妥協したら？0-235と言ってもそのままじゃ使えないし、とは言え調整は容易ではないし。
333:名無しさん＠編集中
07/09/14 01:50:44 4FkTMcTk
調整自体は意外と簡単にできるので苦にはならないんですが ＾＾；
一応参考までに
URLﾘﾝｸ(www.borujoa.org)
334:名無しさん＠編集中
07/09/14 16:26:43 Gooqaxlg
>>329
>キャプボのデフォが0-255でキャプされていて
だからこれが糞だって。
IREレベルのYPbPrをデジタルのYCbCrにするときに白黒のリファレンスが16、235になるようにデジタル化するのが普通。
デジタル化されたときに既に0-255になってたら駄目駄目。
335:名無しさん＠編集中
07/09/15 02:08:22 nHDpgRGI
>>334
そうなんだけど、PV3のソース見たらこっちもデフォで0-255になってましたねぇ
モンスターXは一応プレビュー用と言うことで売ってますのでこれも仕様かとは思いますけどねw
ただ、モンスターXスレ見てても誰もこのことに言及してないのが不思議だな。
336:名無しさん＠編集中
07/09/15 03:15:50 qjkrcvQt
白黒リファレンスが16、235で調整されてて
それを超える範囲も一応記録してるんじゃまいか？
リファレンス以上の白黒範囲が存在して色がおかしくなる
機械やソフトは駆逐されたと思ったけど
古い物だと変な色に見えちゃう可能性があるかもしれん
337:336
07/09/15 03:21:00 qjkrcvQt
あ、何か勘違いしてるかも
聞き流して下さいな
338:名無しさん＠編集中
07/09/15 17:36:02 ZK57mHoD
>>335
揚げ足取るつもりはないけど。
プレビュー時にYUV→RGB変換を行うのはモンスターX？それともビデオカード？
ビデオカードならYC伸張されているデータをさらにYC伸張されてしまって黒と白が飛んじゃうよ。
だから、記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。
339:名無しさん＠編集中
07/09/15 19:06:15 +fRPOju3
>>338
YPbPr0-255での表示や記録をRGB変換というのが正しいのかというのはおいておいて、
（正確には色空間変換とかも絡んできますので）
プレビュー時のYC伸張はVGAの種類とドライバとレンダラによって変わってくるので一概には言えませんですし
何度も言うようですがモンスターXのデフォでは出力をYPbPr0-255を目標とした基準値になっているようです。
当然、キャプチャに回されるデータも0-255ですねぇ。
＞記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。
理想はそうかもしれませんが、現実再生時、VGAドライバレベルではYC伸張しないシステムも多数存在する訳なので
（うちのシステムそうです。たぶんこっちの方が多数派？でもそこから直せとは言わないでねw）
ケースバイケーかとは思いますけど・・・と言いつつ、今のうちの記録はHUFFYUV YPbPr 15-235 で記録してますけどね ＾＾；
340:名無しさん＠編集中
07/09/16 03:02:02 YFlcdrm9
>>339
でもDVD、HD DVD、Blu-ray、地デジ、一般に広まっているMPGファイル、WMVファイル、DivXファイル。
どれひとつとっても16-235に正規化された状態で記録されているけどな。
再生時のYC伸張するしないはオーバーレイと非オーバーレイの過度的な理由からでしょう。
Vistaでは伸張に関してもAPIで定義しているからドライバーが安定してくれば統一されてくるんのでは？
341:名無しさん＠編集中
07/09/16 07:57:46 Xe+cQNMU
0-255だと当然、16-235より綺麗なグラデーションになるからね
再縁故前提な設定な気がしないでもない
342:名無しさん＠編集中
07/09/16 12:41:51 YFlcdrm9
>>341
は？取り込むときにソースが16-235に正規化されているんだから
それを変換するときに0-255に伸張したらグラデェーションは変わらないか、
変換誤差のために16-235に変換するより劣るぜ。
0-255にする利点は標準黒と白をRGBの黒と白にマッピングできるということだけなんだが。
343:名無しさん＠編集中
07/09/16 15:50:57 QzOecP32
MonXのフルスケールが気に入らないならキャプった後に編集段階で修正するんではダメなのか？
キャプ段階でやるのとどういう違いが出るかは分からないが。
344:名無しさん＠編集中
07/09/16 18:13:15 uvDRGnda
楽しそうなので上げときますね
345:名無しさん＠編集中
07/09/17 03:03:05 RM/ZqUvR
>>343
キャップした段階で伸張されてしまっていたら0-15と236-255のデータがなくなってしまっているのだが。
0-15はまあ良いとしてもハイデフソースとかだと236-255は普通に使っている。
346:343
07/09/17 03:10:15 09CdCSIN
それは分かってる。そういうことじゃなくてボードがデフォで伸張してしまうのだったら
いくらMonster-X Setting Utilityで16-235になるように設定調整しても意味ないんじゃね？ってこと。
もしPV3もそういう仕様だったならなんで今まで話題にならんかったのが不思議な感じだ。
347:名無しさん＠編集中
07/09/17 09:16:33 vU02pj/E
>>346
意味はあるよ。ちゃんとモンXではY100％輝度以上も出力している。
モンX標準のPIC MJPEGの設定は100％以上と0以下は問答無用にカットされちゃうので
余計に意味が出てくる。
348:名無しさん＠編集中
07/09/17 14:56:35 09CdCSIN
なるほど参考になった。内部的にはどうなってるんだろう。
一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･
349:名無しさん＠編集中
07/09/17 15:51:26 RM/ZqUvR
>>348
もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
いずれにせよ0-255は取り込みようじゃなくてプレビュー用と思うけど。
350:名無しさん＠編集中
07/09/17 20:53:46 kX/QPJjZ
>>348,349
内部的にも何もそもそものデータがアナログ信号なんだから
A/Dがどの範囲でデジタル化するかって事だけでしょう。
351:名無しさん＠編集中
07/09/18 01:42:36 ZHyG5t9G
>>350
ずっとその話をしているんだがｗ
352:名無しさん＠編集中
07/09/18 02:22:13 X+S8a+zv
わかってないのがいるようだから
>>349
＞一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか･･･
余計な工程なんてない。A/Dはただ単に決められた値と解像度で量子化しているだけ。
100％輝度が255と設定されたらそうしているだけ。235でも同じ。
>>349
＞もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね？
もともとのデータというのがTSデータのことならその通り。ただし一度アナログ変換されたものを戻すのにどこまで意味があるかは考え方次第。
353:名無しさん＠編集中
07/09/18 16:02:19 ZHyG5t9G
>>352
A/Dで16-235と0-255に選択出来るやつもあるが何か？
ようはどうでもいい話で、取り込み時は16-235にするでFAなんだって。
で、再生時に必要に応じて16-235と0-255を切り替える。
普通はPCモニターだから0-255に伸張するで正解。
354:名無しさん＠編集中
07/09/19 01:05:44 +0lVWOJu
>>353
>>352が書いている事に対して全然かみ合ってない気がするがw
結局おまえの考え方を押しつけてるだけなのねw
記録時にどのスケールで記録するかは>>352が言っているように人それぞれだろう。
だいたい記録した物を放送に乗っける訳じゃないんだから規格がどうのとか言っている方が陳腐。
一例としては16-235をRGBに伸張した場合、システムによってはグラデーションにムラができることがある。
実写ではソリッドなバックの光量の差によるグラデーションとかで確認できる。
235を255に延ばすんだから当たり前なんだけど、その辺を嫌って0-255で最初から記録することもありだろう。
だいたい、基準白より明るい白は表示できてもよっぽどでないと視覚的に見えないしね。
355:名無しさん＠編集中
07/09/19 06:09:31 0wjpfMMy
ちょっとお聞きしたいのですが、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 になります。
356:名無しさん＠編集中
07/09/19 17:55:27 Wtwyot7W
>>354
>0-255で最初から記録することもありだろう
ってことは基準黒のアナログレベルをデジタルの0、基準白のアナログレベルをデジタルの255にするって事？
つまり、16-235のデジタルを伸張して0-255にするんじゃなくて、アナログから一発で0-255のデジタルにするって事？
そんなのあんまり聞いたことないけど。。。
357:名無しさん＠編集中
07/09/20 03:15:46 fRgafxj8
>>356
＞16-235のデジタルを伸張して0-255にするんじゃなくて
エンコ時に0-255に伸張する人なら最初から0-255へ伸張するのも有りではと言うこと。
別にそれを人に推奨するつもりはないが、自分のシステムがどういう挙動をするのかわかっている人なら、
おかしな考え方でもないと思うがね。
358:名無しさん＠編集中
07/09/20 03:39:49 ptE2UkfB
うちではMonsterXの初期設定＆オートゲイン、オートオフセットONにすると
0％が0、100％が235でキャプチャされる（PIC M-JPEGで）。100%を超えるのは
235-255の範囲に入ってる。100%が255にはなってないみたいだけど。
359:名無しさん＠編集中
07/09/20 04:10:13 Xs8FzPgb
うちのもhuffyuvで、ほぼそんな感じ。1個前のドライバにて。
360:名無しさん＠編集中
07/09/20 06:08:48 2d42orMe
入力機器によって違うのかもね。
AG、AO入れてるとうちでは（RD-E300）Y-0%は0 Y-100%は255以上になるなぁ・・
少なくともゲインだけは弄らないとコントラストがつきすぎる。
361:名無しさん＠編集中
07/09/20 14:12:29 c/y0B0Ek
>>358
AGとAOって結構賢いんだな。0-235なら完璧じゃね？
362:名無しさん＠編集中
07/09/20 19:23:18 A9uhv/26
>>361
カラーバー入れている限りはAG,AFは結構かしこいよ。
ただ、普段の映像を入れてどうかは別問題。
つか、0-235で完璧って・・・・＾＾；
>>358,359にはその時のPbPrの色差100%と-100%の値はどうなっているか教えて欲しい。
363:358
07/09/20 19:38:38 lWsziCi4
>>362 カラーバーでなら、PbPrの色差100%と-100%の値は読めるかもですが
通常の映像ではどうやって読んだら良いですか？
通常の映像での Y100％ は番組提供のテロップとか、時刻表示の文字などが
該当するかと思うんですが、それらも概ね235に合っているようです。
364:名無しさん＠編集中
07/09/20 21:34:33 1UPYTeI8
ならカラーバー入れてみてくださいな。
オートだから当然入力画像によってゲインやオフセットが上下するんだからw
普通0%輝度がY0になってるんなら、100%輝度は255が標準ですよ。
上の方で意図的に0-235にするとどうなるかって事を言ってた人もいたけどね。
365:358
07/09/20 22:10:08 ptE2UkfB
URLﾘﾝｸ(www11.axfc.net)
monx
カラーバーの録画ファイルと MediaPlayerClassic で再生した画面を取り込んだものをアップしてみます。
MonsterX 標準ソフトで録画、オートゲイン、オートオフセットどちらもONです。
思うに、MonsterX では HD 映像で使われている範囲（0%～100%+α）を 0-255 に割り当てているのかな、と。
それが正しいかどうかはともかく。
366:名無しさん＠編集中
07/09/21 02:16:17 K8jsJkUS
>>365
HD素材なら基準黒を0、基準白を235でαの部分のいわゆるスーパーホワイトを236-255にするのが良いかと。
367:名無しさん＠編集中
07/09/21 06:53:58 oDo/VOx9
>>366
なんで0-235なの？？
その際のPbPrはどっちに合わすの？
368:名無しさん＠編集中
07/09/21 07:11:16 oDo/VOx9
>>365
Y0-235になってるねぇ・・・うちではデフォのAG、AO入れてると
Yは0-255ちょいオーバーになるけどねぇ
個体差なのか、うちがおかしいだけなのか、入力機器によって違うのか・・・
PbPrは中間の±242あたりになってるね。
369:名無しさん＠編集中
07/09/25 00:05:04 qT59KP4m
>0-235
普通にわからん。
16-235じゃないのか。
BT601と709の違い？
370:名無しさん＠編集中
07/09/25 00:47:10 uWE59oxC
>>369
16-235と0-255は標準化されているけど、両方とも問題あり。
ようは0-16→0にしたいけど235-255は保持したいということで0-235。
371:名無しさん＠編集中
07/09/25 02:50:03 Czk3k+G9
ｘｖYCC規格とかが関係してるのかのう…
372:名無しさん＠編集中
07/09/25 11:47:42 3du+U6wn
>>370
その考え方はおかしいよ。
100％以上0％以下をカットしないコーデックだっていっぱいあるんだから、気になるならそれ使えば良いだけだし
だいたいそれしちゃうと、思いっきり全体が暗くなるじゃん。
それでなくてもストレート変換された時点でＴＶよりずいぶん暗くなっているんだから。
373:名無しさん＠編集中
07/09/25 16:45:50 uWE59oxC
>>372
もちろん、0-235に変換したときは全体が暗くならないようにある程度のガンマ補正は必要だろうね。
ちなみにストレート変換では暗くならないよ。上が暗くなる分、下が持ち上げられるから画面全体では明るさは保持されている。
考え方がおかしいって言うけど、これって家電に入っているビデオプロセッサーではかなり常識と思うよ。
PCでは標準化という名の下にあまりにもオリジナリティがなくなってきていると思うなー。
374:名無しさん＠編集中
07/09/25 17:34:28 peFtJ/TZ
まぁ自分が0-235で良いって言うんだからそれはそれで良いとは思うけど
ここで断言的に書くのはよくないと思うな。
やっぱり基本は16-235なんだからね。
しかも、PCのVGAドライバもコーデックもすべて16-235を基準として設計されているわけで
独自設計された家電を持ち出されても説得力はないと思うよ。
375:名無しさん＠編集中
07/09/25 18:24:46 uWE59oxC
>>374
基本は16-235ってそれってアナログのYPbPrをデジタルにそのまま変換した場合の話ね。
決してそのまま画面に出したら駄目なのは分かっているよね？
PCの画面はデジタルで0-255だから少なくともアナログの16はデジタルの0にしないといけないよ。
問題はアナログの235なんだよね。そのままデジタルの255にすると所謂YC伸張になる。
これだと最近のHDコンテンツが使っている235-255のスーパーホワイトに対応できない。
よって、アナログの16をデジタルの0にしつつ235-255のスーパーホワイトも保持して画面に出力したい。
これが0-235の所以なんだけど、理解できないかな？
376:名無しさん＠編集中
07/09/25 18:49:34 peFtJ/TZ
だから、何をやりたいのかは理解できていますよ。w
そんなに挑戦的に書かれなくてもね ＾＾；
でもそれはあなたの考え方なんだから、あまり押しつけるのはよくないんでないの？って言っているだけ。
だいたい、YC伸張するドライバではそれしちゃうとダブル伸張になるでしょ？白側は良いとしても黒側が潰れちゃうよね？
YC伸張しない場合で、0-255で記録されていても、コーデックによっては255オーバーも記録できているわけだから
再生時の設定でもスパーホワイトの表示は可能だしね。
それぞれを理解できている人がやるのは別にかまわないけど、それが絶対とは言えないでしょ？環境にもよるでしょってこと。
わかってもらえたかな？
377:名無しさん＠編集中
07/09/26 02:38:59 Vc7YBhsu
>>375
>>376
話がかみ合ってないだけだろ。
>375は変換そのものに関して話しているみたいだからドライバ伸張の話だろ？
>376はどうもコーデックとドライバーを混ぜくちゃにしているみたいだな。大体、今時はコーデックでは伸張なんかしないよ。コーデックはYUVカラースペースのままだから伸張は関係ない。コーデックがRGB変換するってかなり古い知識だと思うぞ。
378:名無しさん＠編集中
07/09/28 15:26:08 gKqKMB5N
ヽ
_,,.,､､,.ｨ-- 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 ﾉ
379:名無しさん＠編集中
07/10/08 08:37:53 7U//T957
何このマリオ
380:名無しさん＠編集中
07/11/06 19:03:56 7MSa3azk
吉井さんだよ
381:名無しさん＠編集中
07/12/17 09:10:54 r6k/Mv7w
ＶｉｓｔａＳＰ１＋ＮｖｉｄｉａドライバーでＹＣ伸張してくれるようになったお。
382:名無しさん＠編集中
08/01/03 09:33:36 kUstuUcA
age
383:名無しさん＠編集中
08/01/07 15:26:39 jatr8V+y
>>381
本当だ！試しにSP1の評価版と最新の169.25デトネイタを入れたらYC伸張する！
384:名無しさん＠編集中
08/01/18 19:13:18 dIqZ1VjC
>>383
ラデオンだとSP1入れても未だYC伸張してくれない。ジーフォースに買い換えないと駄目？ラデオンは負け組みって事？
385:名無しさん＠編集中
08/01/20 06:30:50 qKn4NFML
>>384
現状だとAMDが死に体だからATIは負け組みかもね。。。
今後はIntel vs NVidiaでATIはS3とかMatrox化していく気がする。。。
386:名無しさん＠編集中
08/01/20 16:55:32 UGOZQUm7
ここDTV板だろ・・・この期に及んでnVidiaがいいとか、ラデがYC伸張しないとかドンだけでたらめなんだよwwww
387:名無しさん＠編集中
08/01/21 14:43:08 7nQnxAf7
>>386
実際、YC伸張にすぐさま対応したのはnVidia、AMDはすでに会社そのものがヤバイだろｗ
388:名無しさん＠編集中
08/01/21 16:38:11 3bbyPTda
>>387
おいおいwwww何言っても良いが嘘はいかんよ、嘘はwwww
389:名無しさん＠編集中
08/01/22 03:41:52 /zpg/jzB
>>388
誰も嘘言ってないけどな。。。
会社の時価総額でもAMD(ATIを含め)はnVidiaの数分の一になってるって知ってるか？
NASDAQで過去一年間くらいの株価見てみろ。
390:名無しさん＠編集中
08/01/22 04:06:29 Fxbgf48Q
>>389
>>388がつついてるのはそこじゃないだろ
＞実際、YC伸張にすぐさま対応したのはnVidia
こっちだろ。どんな認識でこんな大嘘言えるのか俺も思うよ。
391:名無しさん＠編集中
08/01/22 16:56:09 /zpg/jzB
>>390
nvのVistaドライバースレで一ヶ月以上前に報告上がってたよ。
確か169.1xとVistaSP1 BetaでYC伸張がされるようになったとか。
392:名無しさん＠編集中
08/01/22 17:24:39 kxE/tNIn
俺の知っている限りでは
Radeonは7000番台の時代からYC伸張に対応している。
Gefoeceはドライバの84.21からYC伸張できるようになっている。
しかも動画に関してはつい最近までRadeonが2歩先を行っていた。
（ドライバの100番台に入ってやっとだいぶん追いついてきたようだけどまだまだだね。）
３Dに関しては逆の評価みたいだね。使い物にならんのがラデみたいだ。
393:名無しさん＠編集中
08/01/22 17:26:09 CkEl96Ph
( ﾟдﾟ )
394:名無しさん＠編集中
08/01/23 03:01:22 9vQAApKT
>>392
君のは大昔のオーバーレイが全盛だったときの話じゃ。。。
Vistaの話題なんだから非オーバーレイについてに決まっていると思うが？