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の話題なんだから非オーバーレイについてに決まっていると思うが？
395:名無しさん＠編集中
08/01/27 18:35:51 zFIAvNr0
いまだにオーバーレイしてますが
396:名無しさん＠編集中
08/02/03 19:10:02 Z+V8klSw
Gefoeceで動画ってどんだけマゾいんだよｗ
397:名無しさん＠編集中
08/02/05 15:18:27 hZhMjXov
>>396
オーバーレイの時代はかなり微妙だったけど、非オーバーレイのVistaになってからは下手するとATIよりも良いという評価も聞かれるけどな。
398:名無しさん＠編集中
08/02/05 22:56:31 7FvsqN7X
すまん便乗で。
XPのオーバーレイ環境下だと今でもnVidiaはいまいちくんなの？
399:名無しさん＠編集中
08/02/06 03:41:07 MlrDLIgF
>>394
大昔ってXPのVMR7もオーバーレイミキサ使っているし、だいたいEVRを使っているユーザーが今いくらくらいいるとお思ってるんだ？
>>398
いまいちどころか最悪でないかな
オーバーレイならあのS3の方が綺麗だしww
400:名無しさん＠編集中
08/02/06 17:55:38 VbrsKj9X
>>399
お前Vista使ってないのばればれ。
VistaのメディアプレイヤーとかメディアセンターはEVRだし、PowerDVD7もEVRだぞ。
いつまでも食わず嫌いだから遅れるんだよｗ
401:名無しさん＠編集中
08/02/09 10:17:23 I/YvmMW0
>>397
それはそうだね。
あとは色空間変換やCRT使いの人向けにDACの性能が良くなれば、
nVIDIAは駄目という声も減ると思うけど。
402:名無しさん＠編集中
08/02/09 13:23:00 HbQT2ot8
RADEONはとりあえず"UseBT601CSC"="1"つっこんどきゃY/C伸張するんじゃねーの
Vistaは知らんけど
403:名無しさん＠編集中
08/02/10 06:19:16 6OTEFHQO
XPでnvdiaグラうボ使ってる人向けの画質設定晒しとく
94.24で確認したから100以降のドライバは知らん
ffdshowの「レベル」を選択
モードはOriginal
フルレンジにチェック
入力16-235
出力0-255
ガンマ補正オフ
ポスタライズ255
これでまともな色になる
404:名無しさん＠編集中
08/02/10 14:30:56 Y3N12W/F
>>402
他スレで散々既出だがVistaにはそのレジストリは存在してないし、同様のNVidiaのやつもXPのみ。
>>403
ffdshowじゃあHD/BDは関係ないからなー。
405:名無しさん＠編集中
08/02/14 17:19:11 7GXiyzhX
Vista SP1+ゲフォ最新βドライバーだとPowerDVDなんかもYC伸張するようになるな。
いったいどれが今までバグってたのか、全くプンスカ。
406:名無しさん＠編集中
08/03/04 10:33:49 abB8HAgX
nVIDIAチップ特有の白っぽくてパサパサした色合いがちょっと苦手
ゲームやるぶんにはnVIDIAが良いんだろうけど、ATIの色味に慣れちゃうとなかなか抜け出せないわ
そろそろ買い替え予定なんで、Vista環境も考えてみるか
407:名無しさん＠編集中
08/03/04 11:05:55 xYUVKfTT
nvidiaは9000番台の次から動画関連に大幅に手を入れるって言ってる
今うんこなのは当たり前ｗ
408:名無しさん＠編集中
08/03/26 15:39:58 0JfwX7St
Friioを購入していろいろやってみましたので、結果を書いておきます。
ビデオカード：GeForce7600GS 93.71 VMRYC伸張有
OS：WindowsXPSP2
プレーヤー：MPC6.4.9.1
MPEG2デコーダ：MPC内蔵・YV12orYUV2出力
ソース：BT.709のカラーバーSD解像度
オーバーレイ・VMR7・VMR9：すべてBT.601として変換
ソース：BT.709のカラーバーHD解像度
オーバーレイ・VMR7W：BT.601として変換
VMR7R・VMR9W・VMR9R：BT.709として変換
上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
しかしBT.709の登場で面倒なことになりましたね。
余談すがデコーダをffdshowにして出力をRGB32にしてffdshow側でBT.709を指定すればどの解像度でも正しい色になります。
409:名無しさん＠編集中
08/03/26 16:37:00 Z2J+WSKO
SDに変換する時はColormatrix等でBT.601にする必要があるな。
410:名無しさん＠編集中
08/03/26 16:51:59 0JfwX7St
DVDもBT.601ですので、HDキャプチャしてDVD出力する場合も変換しないとおかしくなりますね。
DVDレコもちゃんと変換しているみたいです。
あとチューナーのコンポーネント出力はBT.709で出していますが、S端子はちゃんとBT.601に変換されていました。
家電って結構キッチリしているんですね、ずぼらなのはPCだけのようです…orz
411:名無しさん＠編集中
08/03/28 03:49:08 DL/Lx8g8
>>408
>上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
Vista+EVRを使えばDXVA2経由でBT.601とBT.709をドライバーに指示できるみたいよ。
412:名無しさん＠編集中
08/03/28 04:14:15 qRjTrz58
BT.709のカラーバーというものは存在しないんだけど・・・
色域がBT.709になるかBT.601になるかはRGBへマッピングするときに決めるだけ
よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
413:名無しさん＠編集中
08/03/28 18:10:59 DL/Lx8g8
>>412
>よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
これはちょっと誤解を生むよ。HD放送の合間のSDは解像度がHDじゃなくてもBT.709になっているのは常識。
アプリがコンテンツの状況に応じてドライバーに変換関数を知らせた方が正確。
414:名無しさん＠編集中
08/03/28 18:13:58 TXNosBRg
私はFriioを持っていないから確認できませんが、日本のSDのデジタル放送のcolorimetryを
DGIndexはきちんとBT.709だと判定できるのだろうか。
415:名無しさん＠編集中
08/03/28 19:10:24 wG38zexJ
SDってBS1,2か？教育も一部時間はSDか。
416:名無しさん＠編集中
08/03/31 07:45:51 ZNpWyTs8
どっかで見たけど、NHKとかのデジタルSDはmatrix_coefficientが省略されてるみたい。
でもテレビだとBT.709として処理してるようだ。
URLﾘﾝｸ(www.marumo.ne.jp)
＞Digital BS では YUV データは全て ITU-R BT.709 形式で送り出すので、
＞matrix_coefficient が省略されている場合も ITU-R BT.709 が指定されたものとしてデコードするようにと規定されています。
＞HD 放送の場合だけでなく、SD 放送の場合もです。ARIB STD-B32 で確認しました。
DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
なので>>408のSDでmatrix_coefficientが省略されてた場合は、
matrix_coefficientを見てるのか、解像度で判断してるのかわからないな。
matrix_coefficientでBT.709を指定したSDファイルを作ってみれば分かるけど。
417:名無しさん＠編集中
08/03/31 07:57:55 byVcSBaz
BT.601 = BT.470-2(DGIndexの自動判定) = SMPTE 170Mだから、それだったらやはり
ColorMatrix(mode="Rec.709->Rec.601",interlaced=true)とでも書いてBT.601に変換する必要があるな。
418:名無しさん＠編集中
08/04/04 21:51:39 59KSVULO
よくわからんけど、
CCEやTMPGで709→601にするときはどうすればいいの？
0-255か16-235しかないよ。
419:名無しさん＠編集中
08/04/05 02:52:17 fbi2C0NX
>>418
いいよおまいは話に参加しなくても
420:名無しさん＠編集中
08/04/21 15:26:15 gMV7SetX
BT変換とTVスケールへの伸張はどっちを先にやったほうがいいのでしょうか
421:名無しさん＠編集中
08/05/24 20:32:12 EW5fNDtN
> DGIndexだとmatrix_coefficientが埋め込まれてないとBT.470-2 B,Gになる。
dgindex149のソースとかh.262とか読んだ感じ省略時は
mpeg2はRecommendation ITU-R BT.709
mpeg1はRecommendation ITU-R BT.470-2 System B, G
になりそうなんだけど>416はmpeg1の話をしてるの？
422:名無しさん＠編集中
08/05/24 20:49:02 si+3EZcc
>>421
DGMPGDec 1.5.0では変更された。
URLﾘﾝｸ(forum.doom9.org)
423:名無しさん＠編集中
08/05/24 21:06:55 EW5fNDtN
へー、そーなんだ知らんかった。ゴメン
ついでに聴くけど
何で素直に2(Unspecified)を返すようにしないの？
はっきり言って紛らわしいと思うのは俺だけ？
424:名無しさん＠編集中
08/05/24 21:24:16 si+3EZcc
DGDecodeの判定を読むColorMatrix(hints=true)の様にして使う事もあるし、その方が良いのだろう。
MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
大した手間では無いのだから、最初にMPEG-2 Videoをエンコードする時、colorimetryにきちんと
SMPTE 170Mなりを指定していてくれたら良いのにとは常に思うが。
bt.709 and CCE
URLﾘﾝｸ(forum.doom9.org)
425:名無しさん＠編集中
08/05/24 22:31:12 EW5fNDtN
> MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
そんなにややこしいなら尚更Unspecifiedを返すべきなんじゃ？
DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい
不明な場合の動作をユーザー指定とかなら俺でもすぐ出来そうなんで
ColorMatrixの方はプラグイン側が対応すれば善いだけかと
まあPrimaries、Transferが違うって時点でMatrixだけ教えてくれてもしょうがないとも思うけど
426:名無しさん＠編集中
08/05/24 22:41:27 si+3EZcc
>DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい
Colorimetry: BT.470-2 B,G*
ソースがUnspecifiedならこういう風に*が付くから、Informationやlogを見たらすぐに分かる。
427:名無しさん＠編集中
08/05/24 23:40:16 KJ5Y8Mo3
TSソースで試したら、HDはBT.709になったがSDはBT.470-2 B,G*になった。
色見るとどちらもBT.709なのに、SDでは指定されてないのかな、謎だ。
428:名無しさん＠編集中
08/08/09 22:53:47 rSmXo3C9
PALなら5:1.5:1.5ですね。
429:名無しさん＠編集中
08/08/28 17:54:22 DplL5tuS
430:名無しさん＠編集中
08/08/31 04:04:32 tO/J3aLd
亀だが誰か>>355の内容について教えてください
うちの環境がおかしいのか混乱してきた・・・
YC伸張していない動画(黒16-白235)を再生した時、
Luma rangeを「TV(16-235)」に設定すると黒0-白255で表示される(白が真っ白に見える)
「PC(0-255)」に設定すると白が灰色に見える、16-235より暗い感じだから、
>>355同様、16-235の状態を0-255と仮定して16-235へさらに変換しているように見える
これは表記ミスなのかな？
それともLuma rangeは入力ソースの種類という意味なのだろうか？
431:名無しさん＠編集中
08/08/31 09:50:22 VJQGf6bX
>>430
うちもそうなるよ
432:名無しさん＠編集中
08/08/31 11:56:42 apcIcXt4
PC(0-255)ってことはストレート変換、つまり伸張しない。
TVなら黒を16、白を235としてPCスケールに伸張するっていう意味なんだが。
理解の仕方が反対だよ。
ちなみに>>355の最後は間違いでAviutlのプレビューは伸張してるから
たぶんY30-217のファイルを作ってる。
433:名無しさん＠編集中
08/09/04 18:49:30 qGh5AYHA
RGB24のソースをAVISynthを使ってカット編集して
YV12変換してx264でエンコードするのと
AVIUtlを編集に使ってRGB24→YUY2→YV12と変換するのでは
やはりAVIUｔｌ経由は劣化してしまいますか？
434:名無しさん＠編集中
08/09/04 19:20:34 Ot5eU7BW
AviUtl本体にはYV12へ変換する機能は無い。
435:名無しさん＠編集中
08/09/04 19:43:56 qGh5AYHA
言葉足らずでした
AVIUtlの拡張x264出力プラグインに、
x264に渡す前にYV12に変換する機能がついてるんです
436:名無しさん＠編集中
08/09/04 23:59:11 R68KTdq0
AviUtlでの編集は正確には
RGB24>YC48(これで編集）>YUY2>YV12
色変換だけ考えたらRGB24>YV12と違いはないので
同じだと思うけどAviUtlはフィルタ精度が12bitだから
劣化の具合で言ったら理論的にはUtlのほうが少ない。
つーても肉眼ではわからんだろ。
437:名無しさん＠編集中
08/09/05 02:49:56 Gk5w7tAl
カット編集としか書いてないから、違いはないんじゃないか？
438:435
08/09/05 04:13:38 TbXX27C5
どうもありがとう
フィルタはかけないけど、かけた場合はフィルタの精度も重要ですね
回答してくれた人愛します<3
439:名無しさん＠編集中
08/09/13 14:13:01 21caLQWg
>>432
dgindex150を使用して、PC scaleで出力してエンコーダに渡せばストレート変換？
YV12ソース＞dgindex（PCscale）＞エンコーダ(YV12)出力
これで良いのでしょうか？
440:名無しさん＠編集中
08/09/19 05:24:40 KHzW8kGD
>>439
avisynth経由の話ならdgindexの設定は関係ない
その設定は使われないので意識する必要なし
441:名無しさん＠編集中
08/09/19 10:21:34 E9nS3Lq4
dgindex のPC/TVscaleの設定はVFW経由の場合にのみ有効って認識でいい
たぶん。
442:名無しさん＠編集中
08/09/20 21:14:25 fAg2w24o
今まで9600GT使っててHD 4850に交換したんだけど、RADEONってYC伸張しないんだな
WMV9でYC伸張でエンコした動画ずっと見てたからなんか変な感じ
OSはVistaSP1
443:名無しさん＠編集中
08/09/20 21:59:27 CNZMlSyU
>>442が今時まれに見る情報弱者だということは理解した
444:sage
08/09/20 21:59:58 SyoX7pM0
>>442
ATI HD Registry Tweaks
445:名無しさん＠編集中
08/09/21 14:02:39 LTBBnYvd
ビデオカードにYC伸張やらせるなんてアホらしい
動画側にやらせるべき
446:名無しさん＠編集中
08/09/21 14:05:56 Ro0+EH/h
それだとTVに写すとき困るし～！
447:名無しさん＠編集中
08/09/21 17:57:54 g12aJ8Ao
>>445
データはストレート保存で再生時に伸張。これ常識。
448:名無しさん＠編集中
08/09/21 20:51:09 WS3/bMbQ
>>445
DVDは伸張されてないんですが、それもアホらしんですね
もう何もPCでは見られませんね
伸張して保存するなんていつの時代の話だよ
変な流れを最初に作った諸悪の根源はnVIDIAなんだけどな
>>447氏も言ってるように再生時に伸張するのが常識です
なので動画保存時はストレート保存、伸張保存してたらﾌﾟｷﾞｬｰされるぞ
449:名無しさん＠編集中
08/09/22 02:37:13 vL6DAe5x
Haali's Video Rendererはとても優秀
450:名無しさん＠編集中
08/09/22 21:48:39 /OoVLfz9
NPC内臓のHaali使うと引き伸ばしの画像がおかしくなる。
おかしいというよりはリサイズが糞っぽい。
リサイズはffdshowに任せたほうがよさげ
451:名無しさん＠編集中
08/09/22 21:57:34 /VyuUluT
NPCってなんれすか？
452:名無しさん＠編集中
08/09/22 23:17:29 1A0Ol3pO
少し質問です。
まるも氏のm2vプラグインでストレート変換読み込みした場合と
DGIndexでPCスケールで読み込みをした場合に色合いがほぼ同じになります。
色々な記述を読む限りまるも氏のプラグイン設定でストレート変換を指定した場合
伸張しないと解釈しているのですが、なぜDGIndexのPCスケールと同じ色合いに
なるのか疑問で仕方ありません。
普通PCスケールじゃなくTVスケールと似た色合いになるんじゃ…。
それともDGの方がTV指定時にダウンスケールしてるだけのことですか？
453:名無しさん＠編集中
08/09/22 23:27:35 vL6DAe5x
VFAPIがややこしいのなら、DGDecode_mpeg2sourceでd2vを開けば、YV12のまま伸張も何もしない。
454:名無しさん＠編集中
08/09/22 23:43:43 DIJGvtux
>>452
そもそもまるも氏のストレートとそうでないのとで色ちゃんと変わってる？
話を聞く限りまるも氏のプラグインでRGB展開してない気がするが
455:名無しさん＠編集中
08/09/22 23:57:35 ARySuTFW
>>452
aviutlの仕様です
456:名無しさん＠編集中
08/09/23 08:33:42 t2QFmLhW
m2v.auiはYUY2読み込み
readme読め
457:名無しさん＠編集中
08/09/23 17:12:30 D66+eWYE
超初心者なのですが、伸張するっていうのは0-255なのか16-235のどっちなんでしょうか？
0-255の方が範囲が広いのでこっちにしたいのですが、伸張されるっていうのがどっちなのかわからなくて・・・
ちなみにここの話題とは全然違ってPS3をつないだモニタの設定でどっちにしたらいいのか迷っているからなんで・・・・
458:名無しさん＠編集中
08/09/24 02:27:37 toi/BNHh
16-235としてPCスケールに伸張(0-255)
上に何度も書いてあるけど「伸張保存はするな」
って言っても色空間から理解する必要があるからなあ・・・
伸張云々よりも先にそこから勉強したほうがいいよ
459:名無しさん＠編集中
08/09/26 09:47:47 d9xJhVIR
その前に8bit=255から理解する必要があるのでは？
そして次はYUVを勉強してBT.601を勉強してそれに今時はスーパーホワイト領域の事も考慮して・・・etc
最後は論文かけるようになるかもねw
460:名無しさん＠編集中
08/09/26 14:03:09 EPyHUXU0
エンコ時に伸張するほうが精度が高いって知ってた？
461:名無しさん＠編集中
08/09/26 14:23:46 mjIORAaH
>>460
マジで？
エンコ時なら8bit演算でしか伸張できないけど。
ちゃんとディザリングとかかけたりしてくれるソフト有るの？
再生時なら今の世代だとRadeonもGeForceも10bit演算で伸張するし、
Radeonはちゃんとディザリングかけてから8bitに出力してくれるんだけど。
最新のRadeonHD4だと10bit対応モニタの場合そのまま10bitで出力してくれるし。
ホントにエンコ時に伸張する方が精度高いの？
462:名無しさん＠編集中
08/09/26 15:46:04 Ux/K698u
>>460
どっちにしても大多数のコンテンツがストレート保存だから再生時に伸張するのがデファクトスタンダードである事に変わりない。
もはや精度がうんぬんという話は全く意味もないことだな。
463:名無しさん＠編集中
08/09/26 15:53:29 gIV7Ydpv
昨今（と言っても相当昔から）の動画コーデックは、YUVも含めた上での圧縮。
エンコード時に伸張してやること自体がナンセンス。
464:名無しさん＠編集中
08/09/26 22:49:49 pYp5CLLQ
伸張も圧縮もせず元のYUVをYUVのまま置いとくのが一番でしょ。
465:名無しさん＠編集中
08/09/28 19:29:53 yzQFyw3r
初心者でもしスレ違いだったらすみませんが、詳しい方教えて下さい。
DVDレコーダーと液晶テレビをHDMI接続し、解像度自動設定で強制的にHDで見ている状態です。
この場合に、SDソースのアナログ放送やDVDディスクはDVDレコーダー側でHDにアップコンバートされて出力されていますが、色空間の取扱はどうなっているのでしょうか。
466:名無しさん＠編集中
08/09/28 20:48:43 oGMa9b6c
うちはRD-S300だけどアナログでキャプチャしたカラーバーをHDMIでD3出力させてみたら
ちゃんとSMPTE 170M->BT.709変換が入ってるぽい。
どのメーカーにも信者はいるだろうからそういう変換が入ってなければ真っ先に苦情飛ぶだろうし
そんな初歩的な規格しらない開発者もいないだろうから問題ないんじゃね
467:名無しさん＠編集中
08/09/28 21:53:50 yzQFyw3r
465です。
>>466
早速のレス有難うございました。
うちもRDやスゴ録を某有名メーカーの液晶に接続していて、D1・D2とD3・D4で色が違うのが気になっていました。
レコーダーか液晶かどちらの問題か分からなくて困っていましたが、RD側でちゃんと変換しているとすると液晶側の問題のようですね。
でもそこまで変換するのであれば、やはりアップコンバートはテレビ側でした方が良いでしょうし、HDMI解像度自動設定もSDソースはSDのまま出力してくれないものでしょうかね。
468:名無しさん＠編集中
08/09/28 22:15:57 oGMa9b6c
>>467
液晶って家電のほうだよな？
家電でそういうミスはあんまり考えられない気もするんだけど･･･
うーむ、どうなんだろう。
469:名無しさん＠編集中
08/09/28 22:36:46 yzQFyw3r
>>468
勿論某超一流家電メーカーの液晶テレビで昨年のモデルです。
お騒がせしましたが、このメーカーのテレビ独特の問題がありそうです。
今気付きましたが、テレビのオンスクリーン表示も、解像度によって色か明るさか良く分かりませんが変ってしまうようです。
そういえばこの機種は、液晶のダイナミックコントラスト機能が強すぎて、明るさを調整しようとして画質調整のメニューを出すと、それに引っ張られてバックライトが変化してしまい、まともに調整できないという酷い仕様です。
どうもユーザーが触れないおせっかいな自動補正がありそうです。
470:名無しさん＠編集中
08/10/14 14:05:57 v+GfvfiY
元に居たにいたスレで話していましたがスレ違なのでこちらに来ました。
DGIndexをTVスケールでVFAPI経由読み込みした際にYUVデータを維持したまま
読み込んだ画像に比べて色がかなり薄くなり疑問に思いました。
以下の画像を参照して下さい。
■比較画像
URLﾘﾝｸ(www1.axfc.net)
■ヒストグラム
URLﾘﾝｸ(www1.axfc.net)
パスは両方ともyazawa
この比較からするとDGIndexではTVスケールを選択すると実際のトコロ
0-255を16-235に圧縮してるのではないかと思います。
なのでエンコに使う場合はPCスケールが正解なのかなぁと。
普段はm2v.aufの元のYUVを維持でエンコしてるのですが、どうしても気になって…
471:名無しさん＠編集中
08/10/14 14:09:39 1ThNXYmm
YCbCrはTVスケール、RGBはPCスケールにするのが普通のやり方。
だから、訳が分からないのなら、途中で変換が入るAviUtl等使わず、
変換の入らないAviSynthでx264に渡せば何も考える必要がない。
472:名無しさん＠編集中
08/10/14 14:30:31 v+GfvfiY
d2vファイルをAviUtlで編集する場合、avsから読み込めば問題無しで
VFAPIを用いる場合はPCスケールにすればOKということ？？
その場合二重伸張とかにはならない？
473:名無しさん＠編集中
08/10/14 14:36:09 1ThNXYmm
1. DGIndexでd2vを作って、それを入力にavsを作る。
2. "x264.exe" --crf 20.0 --output "output.mp4" "input.avs"
474:名無しさん＠編集中
08/10/14 14:42:41 v+GfvfiY
x264がYV12入力だからavsから直接やれば無問題ってことは解っていて
とても有りがたい返答ではあるのですが現在知りたいのは
DGIndexとAviUtlを用いた際の色の扱い方なので…。
一般的にYUV維持して読み込むか、TVスケールでVFAPI経由というのが良いという
ことになってますが、VFAPIでTVスケール使うと色縮んでるじゃん。なんで？
っていう所が疑問のスタートなんです。
いや、ホント説明とか出来ないバカですみません。
475:名無しさん＠編集中
08/10/14 14:52:26 1ThNXYmm
DGVfapi.vfpの色空間はRGB24で、RGBは一般的にPCスケールである事を前提として扱われる。
詳しい説明はDGVfapi.txtを読め。
476:名無しさん＠編集中
08/10/14 17:50:08 v+GfvfiY
あーなるほど。
漸く理解できました、本当ありがとう！
477:名無しさん＠編集中
08/10/14 18:04:11 ULjBfQ5G
>>474
こっちに移ってたか。
キミがあげた比較画像だが、m2v.aufの伸張有りってのは
フィルタかなんかでさらにPCスケール変換してるっていう意味かね？
そういうことにしとくけど簡単に言うと
DGIndex(VFAPI)
PC Scale: Y: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換
TV Scale: YUV画像をそのままRGB: 0-255に変換
Aviutl
ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
ソースがRGB: プレビューはそのまま、出力はRGB: 0-255をY: 16-235, UV: 16-255に変換
AviutlでのYUV->RGB変換: DGIndexでいうPC Scaleとおなじ
これでわからんのならもうちょっと色空間勉強したほうがいいと思う。
478:名無しさん＠編集中
08/10/14 18:04:43 ULjBfQ5G
おそかったorz
479:名無しさん＠編集中
08/10/14 18:09:12 v+GfvfiY
ご…ごめんなさい…。
480:名無しさん＠編集中
08/10/14 18:25:18 1ThNXYmm
YV12とRGBの変換は、TV/PCスケールに加えて、BT.601/BT.709、
インターレース/プログレッシブをきちんと把握しないと、変な色になるからとても面倒くさい。
やはりソースがYV12なら、YV12のままでエンコーダに直接渡すのがベスト。
481:名無しさん＠編集中
08/10/14 19:52:24 wMQpUmr7
俺みたないなお馬鹿はVFAPI経由させるなってことか
482:名無しさん＠編集中
08/10/14 22:56:39 VCoPi0+g
動画を扱うこと自体をやめるべきでは
483:名無しさん＠編集中
08/10/14 23:10:23 M0RbEkyM
自分で楽しむだけならいいんじゃね。
484:名無しさん＠編集中
08/10/17 08:25:45 EbrZG3U2
>>477
>ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
出力は変換なしってどういうことですか？
プレビュー（編集時）は伸張しているが、実際の出力は伸張していないという認識でいいのでしょうか？
485:名無しさん＠編集中
08/10/17 10:35:58 G3nEAXVQ
まず477は間違い。初心者を陥れる罠。
伸張が関係するのは、YUV<->RGB変換になる場合だけ。
AviUtlは常にY16-235,UV16-240をRGB0,0,0-255,255,255として扱う。
まずソースがYUY2で展開される場合。
プレビューは、表示→オーバーレイ表示がoffならRGBで表示する。(WindowsGDIの仕様)
無圧縮(RGB)出力やコーデックにRGBで渡す時はプレビューと同じ変換でRGBにしてから出力される。
YUY2出力やコーデックにYUY2で渡す時は(フィルタで弄らない限り)ソースのスケールのまま。
実際は内部形式をはさむ変換なんだけど、16-235->0-255みたいにダイナミックレンジがつぶれたり
0-255->16-235みたいに諧調が失われたりする事の無い内部形式だから気にする必要はない。
486:名無しさん＠編集中
08/10/17 10:38:38 2z8ZQ3vU
AviutlのプレビューはBT.601だから、
デジタル放送だと色がおかしくなるので注意ね
かといってプレビューで正しく見えるように変換しちゃうと、
今度は出力されたファイルがおかしくなるので更に注意
487:名無しさん＠編集中
08/10/17 10:56:02 xMb2oRTj
HD->SDのエンコードにはBT.709->BT.601の変換が必須だけど、
UtlにはSynthのColorMatrixに相当するプラグインはあるの?
488:名無しさん＠編集中
08/10/17 11:00:34 XaaXSGaQ
URLﾘﾝｸ(www.geocities.jp)
あじさんとこの色域変換プラグインがそうじゃないかな
489:名無しさん＠編集中
08/10/17 11:07:25 xMb2oRTj
どうもありがとう。
490:名無しさん＠編集中
08/10/17 13:16:20 EbrZG3U2
詳しい説明をありがとうございます。
まだ混乱しているのですが、下のように理解しました。
ソースをYUY2で読み込んだ場合（YUVで取り扱う）の表示は、AviUtlの内部形式に変換する際16-235->0-255のように変換する為
プレビューは一見ストレートではなく、伸張(16-235->0-255の内部形式への変換)されたように見える。
これをYUY2（YUV)としてそのまま出力すると内部形式は0-255->16-235として処理され、読み込んだときのスケールは保持（伸張されない）される。
しかし、これをRGB出力（VFAPIなど、プロファイルを渡す)した場合、内部形式16-235->0-255がRGBへの変換に適用されYUV->RGBの際に伸張された動画となる。
つまり、Aviutlで元のYUVデータを保持し、伸張は再生側にまかせた動画を作成する場合
rec.709やbt.601の変換を抜きにすれば、YUY2で動画を読み込み、フィルタなどはいじらずYUVでそのまま出力すればいいということでしょうか？
491:名無しさん＠編集中
08/10/17 18:34:24 MRiUv4La
ROMってた初心者なんですが、検索して調べても混乱が増すばかり・・・
動画ファイルがTVorPCスケールか調べたくて
Aviutl0.99fで波形表示プラグインを使ってみたんですが
ソースがYUY2orRGBの展開の違いで波形表示が変わるのでしょうか？
自分のPC環境がVGAでYC伸張がされてるかも怪しくなってきて・・・
混乱しまくりで変な質問すいません。
492:名無しさん＠編集中
08/10/17 20:09:27 ExayxBeC
>>490
utlのプレビューと出力は分けて考えたほうがいい。
utlの内部仕様はあまり公開されてないから想像だけど多分こんな感じになってる
ソース(YUY2/RGB) ─ コーデック設定によるYUY2/RGB変換 ─ 内部形式(YC48変換) ─
─ フィルタ処理(YC48) ┬ 出力形式(YUY2/RGB変換) ─ コーデックへ
├ (非ｵｰﾊﾞｰﾚｲ時)utlによるRGB変換 ─ GDI(ディスプレイ)へ
└ (ｵｰﾊﾞｰﾚｲ時)YUY2変換してOSに渡す ─ VGAによるRGB変換 ─ ディスプレイへ
YUY2/RGB -> YC48変換では伸張処理などなく、完全な無劣化変換。
コーデック設定によるYUY2/RGB変換っていうのは環境設定＞コーデックの設定のところで
YUY2で展開するっていうチェックのON/OFFのことね。OFFだとRGB変換が入る。
ソースがYUY2でかつRGBに変換するときだけYC伸張処理がされ、
ソースがRGBでかつYUY2に変換するときだけYC圧縮処理される。
VGAによるRGB変換は再生時と同じで環境依存。色伸張したりHDのとき自動でBT.709->BT.601変換が入ったりする。
文章下手で申し訳ない。ついでに間違ってる可能性も大いにあるので話半分で読んでくれ。
>>491
同じソースに対して展開方法を変えれば当然データ(波形)も変わるよ。YUV<->RGB変換は基本的にロッシー(劣化する)
ものだから色空間の変換は最小限にするべき。VGAがどういう動作をしているかはオーバーレイ表示にすればわかる。
非オーバーレイと同じになれば伸張してるしHD動画のときさらに色が変わればBT.709->BT.601変換も入ってる。
ただ実際動画をプレイヤーで再生するとき非オーバーレイモードであればまた環境によって違うからその辺気をつけて。
493:名無しさん＠編集中
08/10/17 20:23:21 PpIpzRbE
おや、Makki氏降臨？
494:491
08/10/18 02:13:30 jPlvR2xo
>>492
レスありがとう。用事があってチェックが遅れてしまった。
非オーバーレイってことはMPCだとVMR9とかかな・・・
>>491のことですが
動画ファイルのスケールを知りたくて(PCかTVスケールかを)
波形表示のYgainとoffsetを見れば分からないのかなーと思ったんですが
AviUtlのプレビューがYUY2orRGBの展開の違いで
変化してしまうのではと混乱してしまって・・・
（例えば、展開でTVスケールがPCスケールへ変化することがあるかどうか）
うまく表現できなくてすいません・・・orz
逆に動画がPCスケールかTVスケールかを
調べるいい方法ってあるのでしょうか・・・慣れれば感覚で分かると思うのですが
495:名無しさん＠編集中
08/10/18 02:20:58 fL9tI0O9
＞展開でTVスケールがPCスケールへ変化することがあるかどうか
スケール自体はかわらんだろ
スケールだけの確認ならヒストグラムでYCbCr表示させて明暗のはっきりしてるシーン見れば
一瞬でわかる。縦の薄い線がTVスケールだから。かといってTVスケールでも若干
はみ出してることもなくはないけどな。
496:491
08/10/18 02:29:11 jPlvR2xo
レスサンクス。
色空間は展開で要注意って認識でいいのかな。
いろいろごちゃごちゃしてしまって整理できず混乱してた。
ほんとありがとう。
497:名無しさん＠編集中
08/10/18 02:46:40 HhiL0M+6
自分はこれを使って確かめている。
URLﾘﾝｸ(www.avisynth.info)
例:
ColorBars(960,720).KillAudio
ConvertToYV12(matrix="rec709")
Histogram("levels")
Info
ConvertToRGB24(matrix="rec709")
URLﾘﾝｸ(img380.imageshack.us)
498:491
08/10/18 02:59:03 jPlvR2xo
今までヒストグラムはRGB表示してた・・・
というかRGなんてこった。
>>
499:491
08/10/18 03:01:32 jPlvR2xo
ミスってしもたorz
今までヒストグラムはRGB表示してた・・・
というかYCbCr表示できたんだね、なんてこった。
>>497
うあ、コレも知らなかったよ。例まで張ってくれてアリガト！
500:名無しさん＠編集中
08/10/31 17:11:30 yOSQ1IfA
今VMR9で伸張出来るのと出来ないのどっちの環境が多いんだろ
501:名無しさん＠編集中
08/11/04 23:33:48 Q7hblQOA
去年の5月頃の議論(>>232から)の中で
「最近は235以上のデータを使っているソースがちらほらあって困る」っていうのがあって、
結局グラボ側でオートゲイン的な処理をしてくれるのがいいんじゃね？
っていう意見があったけど
Radeonの4xxxシリーズに搭載されているダイナミックコントラストって機能がまさにこれだね。
結構複雑な演算を必要としているためGPGPUの機能を使っているらしく、
この機能をオンにするとRadeonのActivityが20%程増加する。
502:名無しさん＠編集中
08/11/04 23:40:56 gfCUEmdh
もう色がおかしかったことがばれちゃってるのに
まだRADEONの色が正しい色と盲信してんのか。
しかもUVD2のダイナミックコントラストは
マッハバンドが出る低画質フィルタｗ
カノープスの動画編集ワークステーションに
Nvidia製Quadroが使われてる現実をみろよ。
世論誘導のお仕事なんだろうけど、まるで三亀ボクシングだなｗ
工作すればするほど、なぜかスポンサーが追い詰められるあれ
503:名無しさん＠編集中
08/11/05 01:59:21 UKx9xgRC
つまり、プロだな
プロには、人と金は集まるモノ
504:名無しさん＠編集中
08/11/05 02:10:58 56oSUSHU
いい加減に現実をみろよ、ビデオ編集ワークステーションはNVIDIA
URLﾘﾝｸ(www.thomson-canopus.jp)
プロはNVIDIA
URLﾘﾝｸ(www.thomson-canopus.jp)
カノープスの技術者は才能あるからね。
505:名無しさん＠編集中
08/11/05 22:00:21 hw1NKaBq
そんな1企業の採用事例だけ示されてもな。
俺はどちらかに傾倒しているつもりはないが>>502>>504のほうがよっぽどnVIDIA信者に見える
506:名無しさん＠編集中
08/11/05 22:16:50 mGEWq2RQ
Macは全部Geforceだし。
507:名無しさん＠編集中
08/11/05 23:08:26 UKx9xgRC
>>505
オレにもそう見える。
nVIDIAなら全ておk!! みたいな過度の依存スタンスが、己の目を曇らせ、自らの審美眼を閉ざす
508:名無しさん＠編集中
08/11/05 23:21:22 9MGwgADk
>>506
さらっと嘘つくなよ。
509:名無しさん＠編集中
08/11/06 14:20:45 BAjQOfNE
最近あちこちで必死な書き込みよく見るし、NVIDIAも大変なんだな。
510:名無しさん＠編集中
08/11/06 15:11:56 SYWy3NAB
PCゲーがコピー多すぎて下火になってコンシューマに以降してるからな。
これからは動画再生に強くないと一般のPCに積む意味が無くなるし。
511:名無しさん＠編集中
08/11/09 12:27:33 oYmH7ZjY
だが動画再生についてはPS3が断トツな状況。
512:名無しさん＠編集中
08/11/10 01:16:01 YR4fsrbM
消費電力ありえないから
513:名無しさん＠編集中
08/11/10 01:16:52 ezZcxULD
Vistaから搭載されてるEVRを使ってセカンダリモニタで
再生させているけど、色変換がされないのは仕様？
514:名無しさん＠編集中
08/11/10 16:28:13 DYj8Q7Um
>>513
色変換されなかったらテンでめちゃめちゃに見えると思うけど。
俺はGeForceだけどセカンダリモニタでメディアプレイヤー(EVRを使う)で再生しても問題なし。
515:513
08/11/10 21:49:48 ezZcxULD
>>514
色変換がされていないというより、無駄に明るくなってる感じ
MPC homecinemaだとEVR Custom Presで正しい色で表示できた
ただWMPでは相変わらずです
考えたらスレ違いじゃんorz
516:名無しさん＠編集中
09/01/25 17:53:39 9kWbJuXa
テスト
517:名無しさん＠編集中
09/01/26 00:20:06 xXymHlkA
質問なんですが
DVD→DGindex→AVS（DGDecode）で24fps化→AviutlでCanopusDVコーデックに変換。
この手順だと余計なスケール変換を起こさずにストレート変換になっているのでしょうか。
518:名無しさん＠編集中
09/01/26 00:46:48 HjGrvUZC
AVSにConvertToYUY2を入れてあれば色空間の変換による劣化はないが
519:名無しさん＠編集中
09/01/26 01:32:52 xXymHlkA
DGDecode_mpeg2source("DVD.d2v")
ConvertToYUY2(interlaced=true)
IT(fps = 24, ref = "TOP", diMode = 0)
こんな順番で並べてますが大丈夫でしょうか？
520:名無しさん＠編集中
09/01/26 05:52:49 jgtFxFAw
ffdshowでYC伸張
URLﾘﾝｸ(replaymugen.seesaa.net)
521:名無しさん＠編集中
09/01/26 14:09:55 QrGS90t4
>>517
AviUtlの入力プラグインがAviSynth Script File Readerとかならいいんじゃないか
DGMpgDec とかもAVS読み込みできるがVFAPI経由でRGBに変換されてるから注意な
522:名無しさん＠編集中
09/01/26 14:18:40 l1IkvcKA
最近エンコやりはじめたが、色空間難しいぜ。ちくしょう。
523:名無しさん＠編集中
09/01/26 18:48:36 xXymHlkA
>>521
AviSynth Script File Readerを入れてなかったです。
これでようやくすっきりしました。
みなさまどうもありがとう。
524:名無しさん＠編集中
09/01/26 23:35:48 xXymHlkA
実際にエンコしてみたら今までに比べてかなり満足のいくものができた。
重ね重ねありがとう。
525:名無しさん＠編集中
09/01/31 22:01:33 jB6dv5bG
YUY2で処理したBT.709のﾌｧｲﾙをavisyunthでConvertToYV12する場合
ConvertToYV12()じゃ駄目？
526:名無しさん＠編集中
09/01/31 22:23:32 nLahnMo0
ConvertToYV12するんだからConvertToYV12()するんだろ？
527:名無しさん＠編集中
09/01/31 23:12:46 jB6dv5bG
判りづらくてすんまそん、ConvertToYV12(matrix="")で色空間指定しないと
bt601に変換されちゃうのかな？って事です。
528:名無しさん＠編集中
09/01/31 23:25:12 Kgq3NFlB
YUY2→YV12なら関係ない。
529:名無しさん＠編集中
09/02/01 00:05:19 SE2S103i
BT.601やらBT.709ってのはYUV>RGB変換式の違いなだけでデータの並びとかの
差異はない。だから少なくともYUV色空間内でそのような変換は起こりえない。
530:名無しさん＠編集中
09/02/01 01:19:35 sBtIc6en
なる程RGB変換を挟まない場合は気にしなくていいんですね、
ありがとうございます。
531:名無しさん＠編集中
09/02/05 00:16:23 HBNND2LJ
SD放送のTSもHDと同じくBT.709らしいけど、レコで出力したのをPV4でキャプった場合はどうなってるんだろうか。
レコがBT.601に変換したりしてるんだろうか。
532:名無しさん＠編集中
09/02/05 01:39:38 Ably69zJ
レコによるんだろうが、
D1、D2出力するときはBT.601で
D3、D4出力するときはBT.709で
出力されるのが一般的だと思うが・・
533:名無しさん＠編集中
09/02/05 02:02:34 HBNND2LJ
そーなのかー㌧
あと170M と601の違いがよくわからん。
ググったら同じものって書いてあるのが多いけど色域変換プラグインで170Mと601は全然色が違う。
SD放送のTSはどっちを指定すればいいの？
534:名無しさん＠編集中
09/02/05 03:12:02 ewMuHAv/
3原色のパラメータの違いだって色域変換のテキストに書いてあるじゃん
535:名無しさん＠編集中
09/02/05 04:41:11 HBNND2LJ
調べれば調べるほどわけわかめになってきた…
m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
されないならこの指定は何のためにあるのか？
元の YUV データを維持にして読み込んで色域変換で3原色を601にするのが正解？
AvisynthならColorMatrixでmode="Rec.709->Rec.601"？
536:名無しさん＠編集中
09/02/05 08:52:45 eQ13tqG2
日本のデジタル放送はどれもBT.709と言うことになっているから、HDならそのままで、
SDでエンコードする場合は、ColorMatrix(mode="Rec.709->Rec.601", interlaced=true) としておけば良い。
放送のMPEG-2 MPはYV12(YCbCr 4:2:0)だから、interlacedの指定は必要。
x264に --colormatrix bt709(smpte170m)を付けておけば、デコードで間違える事もなくなる。
私はAviUtlを使わないので、それについてはコメントできない。
537:名無しさん＠編集中
09/02/05 13:18:51 ewMuHAv/
>>535
＞m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか？
そのくらい自分で試したらわかるだろ常考
普通のレコーダーならSDのTSだろうがアナログだろうがD1・D2ならBT.601に、D3・D4ならBT.709で出力される。
深夜にチャンネル片端から調べたらテストパターンいくらでも見つかるんだからHD、SD、地アナそれぞれ
録画して調べたらわかる。
538:名無しさん＠編集中
09/02/14 11:20:20 dw7BNvr7
じゃあ強引にBT709で作った規格外DVDはどうなるの？
(出来るのか？意味あるのか？というのは置いといて。)
539:名無しさん＠編集中
09/02/16 00:39:33 DOFIC1hR
>>538
おまえは何言ってるんだ？YUVデータにbt.709もbt.601もないだろがww
540:名無しさん＠編集中
09/02/20 01:36:31 iuyWOEIb
mp4の動画をffdshowで再生した時にオンスクリーンディスプレイで色空間を見たら
YV12,adjとなっていた。YV12は分かるとしてadjって何？
541:名無しさん＠編集中
09/02/20 03:08:27 etoDEjkN
あじゃすとじゃね
542:名無しさん＠編集中
09/02/22 02:41:43 geHe90rg
>>520
ちょっと微妙だな。せめて、ディスプレイの色温度ぐらい考慮しろよ・・・
白を基準に判別するなら。
543:名無しさん＠編集中
09/02/23 00:43:28 KBSCBtYv
>>538
ないのじゃなくてどちらの色空間で記録されてるかはあるだろ。
むしろBT.601の色空間で強引に記録したHD放送が欲しい位。
HDがBT.709で記録されたら最後、撮影時の彩度の高い赤も
エメラルドグリーンもxvYCCを使わない限り切り捨てられる点を何故誰も
騒がない？
現時点でDVDの方がBDより色域は広い。特に赤と緑は。
BT.709をBT601にmatrix変換？したら似非色表示で意味がなくなる。
YC伸張や色温度の話も良いが、色空間というなら限りなく狭いHDTVの
色空間を元に広げるハリウッドリマスター機能をフィルターにつけるべき。
そうでないとPC再生は今後絶望的では？
544:名無しさん＠編集中
09/02/23 08:41:40 30x+h4KM
んなキモい変換を前提にしたら互換性もなにもないし
素直に未使用領域使うxvYCCで収録しろ。未対応ならクリップされるから大丈夫だろ。
狭い空間の色を勝手に広帯域の範囲にまで拡張するのはカラーマネージメントを無視してるし
どの環境でもそれなりの色再現性があってこそだろ。
エメラルドグリーンを再現したければそれなりの色空間で近似色に変換させろ
RGBで再現不可能な領域は不可能のままで良い。
545:名無しさん＠編集中
09/02/23 15:02:54 1Fo5Bp0s
>>544
同意。
546:名無しさん＠編集中
09/02/24 00:48:41 h6SdtFVk
否定してもいいが、それなりの色空間なんてないから既に手遅れだよ。
xvYCC非対応のほとんど全てのBDやHD放送の存在は放置しろって言ってる
ことになる。クリップしてるからHD放送の色が酷いことに気づいていないの？
HD規格でエメラルドグリーンの海と真っ赤な花は表示不可能なんだよ。
既に表示できているように見える全TVメーカーは未公表で類推アルゴリズムを
入れて疑似色拡張して表示している訳。BT.609（sRGB)色域忠実再生じゃ一目
で他社に見劣りして誰も買ってくれないからね？SONYはちょっとやり過ぎだけど。
忠実にこだわってPCモニタでのHD再生だけ既に取り残されてる訳。
必ずxvYCC対応色拡張変換アルゴリズム込みのフィルターはでてくるだろうけど・・・。
547:名無しさん＠編集中
09/02/24 01:02:56 L3cRA9fu
色域ばっかり気にしているけど、まずは4:2:0から4:4:4の規格拡張が重要だろうな。
あとxvYCC対応色拡張変換アルゴリズムはないけど、色補正は今だってあるよ。
ワイドモードとかね。
548:名無しさん＠編集中
09/02/24 02:34:20 G9nJ43CE
SDTV/DVDもNTSC比70%程度しかない罠。
色域が広いNTSC(ITU-R BT.470-6 System Mになってる)は、今のSDTV/DVDの色じゃないよ。
SDTV(SMPTE-170M)もHDTV(SMPTE-240M)も色自体はSMPTE-Cで共通。
(1970年代には今の色)
ITU-T H.264 の仕様書が、各パラメーター(色,伝送,マトリクス)の違いが一覧になってて分かりやすい。
全体は英文で300ページ以上あるけど、色空間関係なら数ページで足りるので目を通すといいよ。
549:名無しさん＠編集中
09/02/24 08:29:27 L3cRA9fu
とりあえず、パナのハリウッドカラーリマスターとハリウッドクリアカラー
の相乗効果はすごいと思ったよ。
店頭で見た限りだけど。
550:名無しさん＠編集中
09/02/25 00:42:06 fGb7RQ5r
>>548
まずはありがとう。ITU、有料だよね～ 日本語版JT-H264でもいいでしょ？
URLﾘﾝｸ(4megaupload.com)って安そうだけど安全かしらん？
trial 5$ 3日間で他のITUも落としまくるのがいいかしらん？
551:名無しさん＠編集中
09/02/25 03:11:23 3repSfpT
ITU-T H.264 最新の仕様書(2007-11月版)は全564ページだった。
pdf内を709で検索して出てくるのが殆ど該当箇所なのは一緒。
>>550
ITU-Rは有料(年3冊まで無料)で、ITU-TのPDFは無料だよ。
この手の文書は翻訳で駄目になる事も多いから、英文が殆ど読めない人が使う場合でも
英文資料の方がマシ。
今回は参考用に付いてくる一覧表が目当てだから、大丈夫だろうけど。
552:名無しさん＠編集中
09/02/26 01:52:12 rdQIsAwr
>>551
重ねゞゝ ありがとう。 英文資料は問題ないです。手にしました。
なるほど翻訳で駄目になる・・・（笑）
PCモニタ表示域はNTSC(1953)比で書かれるし、NTSC（1953)とばかり思っていた。
これ見るとSMPTE-240Mは（1999）だし170Mは（2004）、どんどんアップデートされるとはいえ、
1970年代にこの色域に変更とは恐れ入るね。TVってめちゃくちゃ表示だったってことか？
と記憶をたぐり寄せて不思議な気がしてしまうのでした。
553:名無しさん＠編集中
09/02/26 01:59:21 rdQIsAwr
おっと、もう１点いや２点不思議
・標準CからD65光源って、1970年代にそれはないでしょ？変わった？
・xvYCCって自然界の網羅率は良い筈だけど、xy色度値が中途半端だね？
現SMPTE-C？とやらと上位互換性とった筈じゃなかったっけ？
554:名無しさん＠編集中
09/03/29 02:34:12 LgOxc4FB
sRGB、AdobeRGB、x.v.colorのそれぞれの表現可能な色数をご存知の方
がいたら教えてくださいな。
555:名無しさん＠編集中
09/03/29 03:20:18 Mg6SirGV
色数じゃなくて表色域だろ。CIExyとかでググれば見つかるんじゃねーの
556:名無しさん＠編集中
09/03/29 03:31:01 LgOxc4FB
色域は分かるよ。
写真とか放送のキャプ取った時に色数も調べるけど
10万色とか5万とか色々ある。
で規格自体はどの程度まで表現可能とか思ったわけ。
557:名無しさん＠編集中
09/03/29 06:30:50 irGSnl3X
色域であって分解能の規定はないのいづれも無限色を表現できるよ。
558:名無しさん＠編集中
09/03/29 06:33:44 LgOxc4FB
>>557
その理屈だと、規格を分ける必要なくね？
無限色を表現できるなら。
559:名無しさん＠編集中
09/03/29 07:02:40 irGSnl3X
1から10までの間に数字はいくつありますか。
3から15までの間に数字はいくつありますか。
いづれも無限にあるだろう。
560:名無しさん＠編集中
09/03/29 07:04:22 LgOxc4FB
いやそれ有限・・・
561:名無しさん＠編集中
09/03/29 08:11:20 mPOA3JVd
では1から10までの間の数がいくつか答えてください
分解能の規定はありません
562:名無しさん＠編集中
09/03/29 12:30:38 lA7p07ar
>560
整数は有限だけど、小数まで含めたらって話。
563:名無しさん＠編集中
09/03/29 14:46:20 WH8zR3jM
>>554
sRGB、AdobeRGBの理論上の色数はどちらも8bit^3
x.v.colorにおいては8bit以上が認められているのではっきりした数字は出ない
同じ色数だから必要ないというような馬鹿な返しはしないでね ＾＾；
564:名無しさん＠編集中
09/03/29 16:01:06 Mg6SirGV
PNGとかTIFFは16bit/chも使えるな
565:名無しさん＠編集中
09/03/29 18:52:35 mgett4HQ
ID:irGSnl3X
ID:mPOA3JVd
何言っているんだこの馬鹿は。
566:名無しさん＠編集中
09/03/29 18:53:42 mgett4HQ
>>563
説明できないなら勉強してこい。無知は。
567:名無しさん＠編集中
09/03/29 19:12:00 O/rx7RRI
>>554
sRGB、AdobeRGB、x.v.colorもそれぞれ8bitパネルでも対応できることから
1677万色の中で既定されている規格だと推測できる。
1677万色の範囲で色の範囲の幅が広いか狭いかだけ。
1677万色と言うのは赤・緑・青の３色を組み合わせて作り出せる色の数のこと。
568:名無しさん＠編集中
09/03/29 21:47:50 uW/WlEec
勝手に変な解釈しないでください
569:名無しさん＠編集中
09/03/29 21:55:13 EooxQNTN
スレが進んでると思ったら荒らしか・・・
分解能の説明でも納得せず
色域の話も納得せず
規格上の分解能含めても納得せず
放置しろ予w
570:名無しさん＠編集中
09/03/29 22:07:38 mwRUF3BT
お馬鹿なのに変に難しい話に首突っ込むなって感じだね
571:名無しさん＠編集中
09/03/29 22:14:57 O/rx7RRI
まあ、予備知識のない人には勘違いしやすいからね。
連投してファビョちゃったのはちょっとみっともないけどｗ
572:名無しさん＠編集中
09/03/29 22:56:37 RzyZqHsx
色数は、RGB16～235だから219階調を３乗すればいい。
あとは、EBU 100%（NTSC 72％）≒sRGB、ITU-R BT.709＝sRGBだから
その法則にしたがって、割合を求めればいいだけ。
573:名無しさん＠編集中
09/03/29 23:29:16 lA7p07ar
揚げ足とりだが、16と235も含むから220階調な。
574:名無しさん＠編集中
09/03/30 04:16:42 yj7nNcLJ
sRGBは0-255だろ
575:名無しさん＠編集中
09/03/30 04:38:54 tvUz5+v1
また、バカが沸いてきた。調べもせずにに毎回よく恥じかけるよ。
576:↑
09/03/30 04:58:53 zw8YBBel
自分が理解できないからひがんでいるとしか思えないぞw
つか、荒らし系の話題にはやっぱこんな馬鹿がよってくるんだから無視するに限るね
577:名無しさん＠編集中
09/03/30 05:20:23 YluRllTz
釣りか真性かよく分からんバカがいるな。扱いに困る＾＾
578:名無しさん＠編集中
09/03/30 05:25:03 vWECeExE
色空間wikiの一般的な色空間の所にRGBの項目があるってなんか変に感じる
コンピュータにおける表色系、と言った方があってる気がするんだが・・・
sRGBとかは色空間でいいんだろうけど・・・
579:名無しさん＠編集中
09/03/30 09:51:25 KeRAFiM1
>>574
お勉強してこい。面倒みきれん。
580:名無しさん＠編集中
09/03/30 23:33:18 8id16EcK
>>579
馬鹿は自分の面倒見ていろよ、別に頼んでないからw
581:名無しさん＠編集中
09/03/30 23:56:14 OyiakWMp
何億色表現可能というTVの誇大宣伝について色彩学会に問い合わせた。答えは、
いたずらに色数がいくつあるかという議論は混乱を招くだけであり、
もはや研究対象にすらなっていない。と。
色相/彩度より輝度差に敏感な眼は同時256階調未満の識別しかできないが、暗視野での256階調とは
輝度値が異なるため、あらゆる環境照度での識別可能な輝度値となると確かに無限に増える。
しかし実際は見ている人に同じ印象の色に見えるものは一緒と考えれば
結局最初のRGBで256階調分、YUVで220階調分でも十分と言うのが定説。
その上でB～BR～Rは元々高彩度の最高輝度が低い色群
BG～G～Yは元々高彩度の最低輝度が高い色群で
最大256階調が必要なのは実は白～黒無彩色グラデーションだったりする。
その結果、一般に十分明るい照度下で眼の良い人が見分けられる色数の限界は
1000万色（～1500万色）と言われ、この500万色もある幅が最早、色数を数え上げることに
実用上意味がないことを示している。
実用上の色分布なら最近ならSOCS（約5万色）データベースを参照する方が建設的。
582:名無しさん＠編集中
09/03/31 00:08:39 DM0neHXk
sRGBの色域なら8bitで十分だろうけどそれより広げると
8bitではトーンジャンプおこすからって10bitやら16bit採用している例が増えてきているよね
scRGBも16bitじゃなかったっけ？
583:名無しさん＠編集中
09/03/31 00:21:18 ss1HR4fU
ID変えている奴バレバレだな。これ以上まだ恥かくのか？ｗ
ネットで一生懸命探して間違いを2chで公表しなくていいから専門書を一つでも読みなさい（笑）
584:名無しさん＠編集中
09/03/31 00:27:46 ss1HR4fU
ちょっとググレば出て来るのにな。
なに的外れな勘違いしているのか。
馬鹿に生まれなくて本当によかった（笑）
585:名無しさん＠編集中
09/03/31 00:38:40 6Om0hbMi
トーンジャンプは色空間の変換や色調補正とかで最も起こりやすいから
その処理を10bitや12bitで処理するものは多いね。そういう部分を丁寧に行って
ディザリングを施して8bitに丸めればまず違和感は起こらんと思う。
人間の目は明るさにもっとも敏感で暗いと色の判別が困難になるし
もともと青の色覚が弱いからYUVってかなり合理的な色空間なんだよな。
赤は比較的敏感だからYUV420とかで劣化が目立つのが玉に瑕だけど
586:名無しさん＠編集中
09/03/31 01:55:33 ee8xsR2u
>>ID:ss1HR4fU
まぁ連投するやつにろくなのがいないのだが
ついでに俺にも説明してくれまいか
いつからsRGBの量子化の実行範囲が16-235になったんだ？
まさかsYCCと混同しているのか？
587:名無しさん＠編集中
09/03/31 13:46:25 EizfDYSg
スレ違いとは思いますが、瞬間湯沸し器的に沸騰してしまい、つい書き込みしてしまいました。お許しください。
普段は決して沸点が低い物質ではないのです。わたしという人間は。
今更エンコードに興味を持ち、あちらこちらの先輩方のサイトを拝見させていただいておりました。
なぜ、赤が観辛いか。
mpg系圧縮は赤が強めにでて、既に赤っぽい場合が多い。それが赤いと、しつこく感じる。
目が青い外人は、少し赤いほうが綺麗に観れるらしい(謎
外人の家の明かりが、総じて暖色系なのは、そのためかも知れませんね。
そんなワケで、しつこいから少しだけ赤を抑えてみる。(0)
ちなみに、緑減らすと赤くなるのも覚えておこう。
逆に、日本人のは青い色が綺麗に見える。蛍光灯とか少し青い方が、明るく見えるのは、そのため。
∴すこしだけ青が強い方が、日本人には締まって見える。(1)
地デジの赤色がやけにどぎつく、滲んで見えるのはmpg2の仕様か！
千と千尋のＤＶＤが赤色っぽいのは海外販売に合わせたためか！
所詮白人の作った規格、利益の大きい海外市場戦略に合わせる必要性。
日本人にとって理不尽であろうとも、我慢や無駄な努力をしなければいけないのですな。
ふぅ、駄文失礼しました。
588:名無しさん＠編集中
09/03/31 15:03:11 P0BXIJ+t
地デジでは当てはまりませんが従来のNTSCはもともとその伝送構造的に周波数の低い赤が苦手です
また、mpeg系の量子化形式も元々NTSCに従っているのでやはり赤の再現性は苦手なのが原因です
人間の色彩に対しての感度は人種により大きく異なることも事実ですが
（もともと人類の目は緑に対して感度が高いですが、アフリカ系の人は緑に対して異様に感度が高いとかetc）
同じ人種でも個人差もでかいですし、同じ個人でも年齢によって大きく異なってきます
一般的に年をとるにつれて周波数の高い色（濃いブルーなど）は非常に見えにくくなってきます
ただ、人間は脳内で色彩情報を補正して認識しているので目の機械的感度での論議は無意味とも言えます
また、目の色の差違で感度が違うとか、日本人が色温度が高いのを好むというのはオカルトです
589:名無しさん＠編集中
09/03/31 16:08:31 JlZoO2Ku
糞スレになったな
590:名無しさん＠編集中
09/03/31 17:21:11 6Om0hbMi
>>589
お前がいるからな
591:名無しさん＠編集中
09/03/31 20:43:16 kBh3bxQ0
>>578
こんなところで愚痴らないで、ノートページに書くか、
自分で直接書き換えろ。
592:名無しさん＠編集中
09/04/01 13:36:53 zym/N56e
まだ調べきれてなかったのか・・・せっかく宿題にしたのに。
やっぱり、ダメな子だな。
URLﾘﾝｸ(www.sony.co.jp)
>輝度、色度信号値の量子化において8ビットのとき、1から15と241から254も映像信号として使用して、
>定義式を定め広色域化を図る。また8ビット以上も定義して高階調化にも対応している。
ヒントというかもうこれは正解を教えてやったのと同じだな。俺もバカに優しすぎる。
593:名無しさん＠編集中
09/04/01 13:38:07 zym/N56e
おい>>586 >>574分かったか？頭悪い子には時間を置いて考えるくせをつけてやらないとな。
594:名無しさん＠編集中
09/04/01 16:55:30 6wqwXSX3
で、どこにsRGBが16-235だと書いてあるんだ？sRGBとBT.709がどっちも16-235だと思っちゃってるの？
595:名無しさん＠編集中
09/04/01 22:43:03 GzKFN+2F
>>594
例によってDQNはいつまでたってもDQNって事だろw
たしかにこういった技術系の板で>>594のようなやつがわいてくると困るよね
無視するに限るが無視すれば嘘八百書き込んだのが訂正されずにログに残るからねぇ
596:名無しさん＠編集中
09/04/02 03:18:04 Hbe8OVGI
>>592 >>593 >>595
エイプリルフールは終わったぞ、さっさと訂正しろよな
sRGBの量子化は1ピクセルあたり24bitは常識中の常識だろ
どうやったら16-235みたいな中途半端な数字が出てくるんだよ宿題にしてやるから後で提出しろ
597:名無しさん＠編集中
09/04/02 10:37:52 LFuqvVjG
>>594 >>596みたいな素人がここにもいるとはね。春休みか。
とりあえず、ここは初心者スレじゃないので質問は他でやれ。
598:名無しさん＠編集中
09/04/02 14:05:50 Hbe8OVGI
>>597
アホか？素人過ぎるのはおまえだろww
RGB各色の先頭2bitがヘッダとして使われているから実行6bitだとかの理由なら形式によってはあり得るかもしれんが
10進表記した上で16-235がどうとかって・・・あまりにも無知すぎる
これ以降反論があるならちゃんとそれなりの反論をしてくれよな・・・お馬鹿さん
599:名無しさん＠編集中
09/04/02 14:10:30 Hbe8OVGI
連投ですまん
>>957
で、どこに>>952のHPにsRGBの量子化についての説明があるんだ？
おまえが示した箇所はYUVのスーパーホワイトとスーパーブラックの領域についての言及だけなんだが
ちょっと病院に行った方が良いかと思うぞwww
600:名無しさん＠編集中
09/04/02 14:44:23 Ihw/AXO8
なぁ素人の俺様にもどっちが正しいかわかるように
まともな事書いてる奴は丁寧に煽らず
DQNはwとか連発していかにも低脳そうに書いてクレよ。
いまはどっちもアホにしか見えなくて困る。
601:名無しさん＠編集中
09/04/02 17:45:25 GDkFtAxK
BT.709
・Quantization levels
Black level 16
Nominal peak 235
・Quantization level assignment
Video data 1 through 254
Timing references 0 and 255
黒レベル16 白 235
データ範囲 1-254 0と255は同期信号
これだけしか規定されていない
1-15と235-254の扱いはご自由にどうぞ
表現できるならやってもいいんじゃないってレベルだな
602:601
09/04/02 17:54:37 GDkFtAxK
×235-254
○236-254
603:名無しさん＠編集中
09/04/03 07:03:30 nHFB0SN+
>>600
sRGBが16-235と煽っている方がNG
そもそもYUV表記でもないのに16-235と言う数字が出るのもおかしいし
さらに>>601で示されたとおりYUVでも1-254も認められている
604:名無しさん＠編集中
09/04/04 13:38:41 Fl+N8r/4
縦解像度540だとbt.709にすべき？bt.601？
605:名無しさん＠編集中
09/04/04 13:48:57 lxktbjwP
SDでも縦は最高576(PAL)あるから、私だったらBT.601にするかな。
606:名無しさん＠編集中
09/04/04 14:14:08 Fl+N8r/4
㌧
607:名無しさん＠編集中
09/04/05 01:41:56 Lz+1kL2/
>>604
再生システムによって変わると思うので
自分でCBでもエンコしてやってみるしかないんじゃないかな
608:名無しさん＠編集中
09/04/18 02:49:20 SQvglqeo
ColorBars (720, 480)
Trim(0,29)
ConvertToYV12()
と
ColorBars (960, 540)
Trim(0,29)
ConvertToYV12()
と
ColorBars (1280, 720)
Trim(0,29)
ConvertToYV12()
でx264でエンコしてffdshowで再生したのを比べたら480=540だった。
609:名無しさん＠編集中
09/04/18 03:11:06 o6lZ9Rdc
ConvertToYV12()だとmatrix=Rec601だから、x264に--colormatrix smpte170mを付けておかないと、
一番下はおかしな色でRGBにデコードされる。
610:名無しさん＠編集中
09/04/18 03:13:16 EPh0h7JE
それは分かってて盾540の時はどうなるのか比較実験でやっただけだろ…
611:名無しさん＠編集中
09/04/18 23:01:02 94eLiRXd
たぶんそれはハードとかデコーダーによると思う。
RADEONは縦720以上でHDと判定されてffdshowだと横1024以上がHDだったかな？
612:名無しさん＠編集中
09/04/19 06:07:45 AaMeDDYt
ffdshowは720pをSDと判定するってこと？
ffdsowの仕様はよく知らないけど、それはないんじゃないかなぁ
613:名無しさん＠編集中
09/04/19 06:10:43 H/OGhjB9
良く嫁
614:名無しさん＠編集中
09/04/19 08:48:41 qO0R7U85
--corlormatrixをエンコ済のmp4/264ファイルに設定する方法ってあるの？
615:名無しさん＠編集中
09/04/20 23:53:12 zX8SIsCy
>>611
気になったんで調べたら、ffdshowは
width > 1024 or height >= 600: BT.709
width <=1024 and height < 600: BT.601
だって
616:名無しさん＠編集中
09/04/21 09:01:58 qOM3eyLU
シネスコだと600切ったりするから自分でいじれる方がいいなぁ～
617:名無しさん＠編集中
09/04/21 10:00:06 WGQHHGAU
>>615は自動の場合の話
強制指定ももちろん可能
618:名無しさん＠編集中
09/04/21 14:37:23 v+OxEIgE
>>615
DXVAだと縦が576ラインを境にしてSDとHDを切り分けるみたいです。
NTSCだと縦480だけど、PALが縦576だからでしょうね。
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
For standard-definition content, treat as DXVA2_VideoTransferMatrix_BT601.
For high-definition content, treat as DXVA2_VideoTransferMatrix_BT709.
(High-definition content is defined for this purpose as anything with a source height greater than 576 lines.)
619:名無しさん＠編集中
09/04/21 18:04:26 Ix1+B7Fu
ffdshowはエンコーダ(たとえばx264)側で指定しても615のようになるな
強制指定(RGB32出力のみ)だと毎回変えないとならないし
H.264の場合だとCoreAVCでRGB32で出力してあげると指示に従ってくれる
620:名無しさん＠編集中
09/05/08 15:18:36 UiuZb1mF
最近このスレ知って、avsをaviutlで開いてみたんだけど、
d2vを開いてYUVマトリクス変換2でYCbCr48(BT.601)→YPbPr48(BT.709)をオンにした時には見られなかった変な線が入るんだけど原因分かる人いる？
URLﾘﾝｸ(paint.s13.dxbeat.com)
621:名無しさん＠編集中
09/05/08 19:22:59 yMrDmpsk
YV12＞RGBにプログレッシブで変換しているせい
avsの最後にConvertToYUY2(interlaced=true)をいれる
622:名無しさん＠編集中
09/05/08 19:26:08 yMrDmpsk
あるいはいっそAviutlで出力するなら
MPEG2SouceでupConv=1にすればYUY2にアップサンプルされる。
ただしavs内のフィルタ処理が全部YUY2になるので若干重くなったり
ほかの弊害が出る可能性はある。
623:名無しさん＠編集中
09/05/08 20:22:54 UiuZb1mF
>>621-622
ConvertToYUY2(interlaced=true)入れたら出なくなった。ありがとう。
upconvはいろいろ問題ありそうなのでやめときます。
624:名無しさん＠編集中
09/05/08 21:48:30 IEIA5OSm
avsでプログレッシブにしておいてから、最後にConvertToYUY2(interlaced=false)とするのがベスト。
625:名無しさん＠編集中
09/05/09 11:10:03 aNNDvFLE
>624
プログレッシブにするのはYV12→YUY2変換する際に、インターレスだと縞が消えたりするから
それを防ぐ意味で書いてるなら、ベストだと思うけど……
626:名無しさん＠編集中
09/05/09 16:30:45 Upx3EWnL
インターレースのまま変換したいなら
AutoYUY2を使うかこれ
ｽﾚﾘﾝｸ(avi板:16番)
627:名無しさん＠編集中
09/05/11 23:08:38 07FXz0Q4
もうわけわかめだから、一から勉強使用と思うんだけど
おすすめの本とかありますか？
カラーマネジメント技術って本ググって見つけたんだけど
これでも良さげでしょうか？
628:名無しさん＠編集中
09/05/11 23:20:29 ceeLrtJd
ググりながらこのスレを10回見直すといい
629:名無しさん＠編集中
09/05/11 23:30:37 +vaSfW7B
真面目にその辺の売ってる本よりこのスレ読んだほうがよっぽど詳しい
630:名無しさん＠編集中
09/05/12 22:44:28 QlqHmfaC
URLﾘﾝｸ(f61.aaa.livedoor.jp)
TV->PCｽｹｰﾙ補正をしたのですが
AviUtl（拡張色調補正TV->PC）とAviSynth（ColorYUY2 - V0.17-3）では違ったモノになります
AviSynthの方は緑がかったような感じ
これはやり方が間違ってるのでしょうか(´･ω･｀)
LoadAviUtlInputPlugin("D:\DTV Tools\AviUtl\m2v.vfp", "MPEG2VIDEO")
MPEG2VIDEO("R:\TEMP\Clipping 01.m2v")
ColorYUY2(levels="TV->PC",matrix="",interpolation = "411->422",interlaced = true)
return last
631:名無しさん＠編集中
09/05/12 22:47:29 bFqUczGR
AviUtlで実際に出力した映像をキャプるとどうなる？
632:名無しさん＠編集中
09/05/12 23:06:11 QlqHmfaC
>>631
上の画像と同じです 出来上がったモノを比べるとやはり緑掛かって汚いような感じになります。
圧縮オプションも同じなのですがファイルサイズがAviSynth（ColorYUY2 - V0.17-3）の方が
小さくなります。