5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名無しさん@編集中:2005/05/17(火) 02:08:47 ID:rCi9I/eS
ループ上等。
フォーマットそのものや、YC伸張(スケール変換)、
オーバーレイやTV出力等々、総合的に議論するスレです。

過去ログ

YC伸張する?しない?総合スレッド
http://pc8.2ch.net/test/read.cgi/avi/1050299614/

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

2 :名無しさん@編集中:2005/05/17(火) 02:12:46 ID:zdeFJ2Fu
(゚听)イラネ

3 :名無しさん@編集中:2005/05/17(火) 03:34:50 ID:jMUq6Xcq
sRGBって色を赤くして濃くしてるだけなのですか?
もっともテレビに忠実だとか言われてるけど正気の沙汰とは思えない色合いです。

4 :名無しさん@編集中:2005/05/17(火) 07:36:06 ID:Ujki+ecm
>>3
カラーマッチングの基礎概念が分ってないと思われ。

5 :名無しさん@編集中:2005/05/17(火) 09:30:13 ID:xUWkp07B
そもそも、ITU-R.BT601に合わせてキャリブレーションしてるのかと小一時間・・・

6 :名無しさん@編集中:2005/05/17(火) 11:54:01 ID:rCi9I/eS
sRGBって緑とかの表現が・・・
AdobeRGBを擁護する訳じゃないけど、
sRGBが世界標準・標準環境になってしまうのにはギモンを感じる。

7 :名無しさん@編集中:2005/05/17(火) 12:14:06 ID:t9oeNBRf
ここで注意しておきたいのが綺麗に見える色が自然界では必ずしも自然ではないということだ。

8 :名無しさん@編集中:2005/05/17(火) 12:34:48 ID:Sssh8YtA
色スレ復活おめ!

9 :名無しさん@編集中:2005/05/17(火) 14:29:12 ID:xUWkp07B
D65光源+sRGB=ITU-R.BT-709=HDTV


10 :名無しさん@編集中:2005/05/17(火) 14:59:56 ID:xUWkp07B
ここが参考になる
ttp://jumper-x.hp.infoseek.co.jp/begin/status/2/

11 :名無しさん@編集中:2005/05/17(火) 20:08:04 ID:lm52QAqp
>>6
AdobeRGBはDTVには必要ありません

12 :名無しさん@編集中:2005/05/18(水) 06:23:45 ID:Z0kgbogH
色が間引かれてる映像は、なぜ赤色系だけが大きく劣化するんですか?

13 :691 ◆AFS777vyz. :2005/05/18(水) 07:03:17 ID:ydQaMEh1
>>12
劣化した信号をテレビで見るからです。

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

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

14 :名無しさん@編集中:2005/05/18(水) 13:57:10 ID:xb/s2qEk
赤色系って、DSフィルタやオーバーレイで劣化を補正しても
チープな感じが否めない(;´Д`)

15 :名無しさん@編集中:2005/05/19(木) 04:22:05 ID:g3lVhGcB
チープな感じって意味がわからないけど
色情報の補間なしじゃもっとチープ(?)じゃない?

16 :名無しさん@編集中:2005/05/19(木) 04:48:21 ID:xz3FiY/i
動画データはYUV(NTSC)で編集・保存して、PCで見る時にsRGB変換ですよね。
でないと、ユニバーサルじゃなくなるから。

17 :691 ◆AFS777vyz. :2005/05/19(木) 12:56:26 ID:8Gysnl8p
>>16
現在のWindowsでは動画に関するカラーマネジメントが存在していません。
ですので、何をどうするのも自己責任ということになります。

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

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

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

18 :名無しさん@編集中:2005/05/19(木) 13:01:03 ID:Kgw5XwWQ
sRGBに変換って何?具体的にどうすること?

19 :名無しさん@編集中:2005/05/19(木) 13:23:18 ID:QDuXOfKr
>>18
決まってるじゃないか!色を赤くして濃くする変換技術。

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

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

20 :名無しさん@編集中:2005/05/19(木) 13:36:55 ID:P1xg4AU9
>>19
青いサングラスをかけて見る

ワロタ

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

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

22 :名無しさん@編集中:2005/05/19(木) 14:15:28 ID:GgwrAn93
紫色の不思議
http://science3.2ch.net/test/read.cgi/sci/1101166711/
【眼の科学】視覚についてもっと知ろう【目のスレ】
http://science3.2ch.net/test/read.cgi/life/1113846988/

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

23 :名無しさん@編集中:2005/05/19(木) 14:47:25 ID:R5M4rZ4l
千と千尋か、懐かしいな。
初めて地上放送でやったとき、実況板がとんでもないことになってたけど。

24 :名無しさん@編集中:2005/05/19(木) 14:49:02 ID:xqKlNUUr
>>18
色温度とは何か?ということについて知らなくてはならない。

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

25 :名無しさん@編集中:2005/05/19(木) 16:24:19 ID:Kgw5XwWQ
質問に答えてもらってないような気が・・・
sRGBについて聞いてるわけではないんだけど・・・

26 :名無しさん@編集中:2005/05/19(木) 17:04:57 ID:R5M4rZ4l
いや、言葉の意味そのまんま、「変換」するわけだけど。。

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

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

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


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

27 :名無しさん@編集中:2005/05/19(木) 17:14:40 ID:Kgw5XwWQ
AviUtlにそんなプラグインがあったのか
それは知らなかった

28 :名無しさん@編集中:2005/05/20(金) 00:22:20 ID:KN70UjDW
>>21
最近周りがブルーに見えるのはそのせいだったのか…
飯も喉を通らないほどの欝状態。
病院でカウンセリング受けるかな……

29 :名無しさん@編集中:2005/05/20(金) 02:45:01 ID:CCBZ4xuv
>>26
ハァ?
キャプチャ時にちゃんとキャリブレートされているという前提なら
色空間の変換はしないのが鉄則だろ。
再生時に、再生デバイスに対して「この映像の色は○○ですよ」という指定をしてやればよい。
または、手動でパラメータを適宜調整する。


30 :名無しさん@編集中:2005/05/20(金) 05:07:18 ID:Uy/lgTI3
世の中キャプチャソースだけではない

31 :名無しさん@編集中:2005/05/20(金) 06:51:25 ID:SiBhdRoK
|∀・)つブルドッグ・ソース

32 :名無しさん@編集中:2005/05/21(土) 01:16:40 ID:PD4v2/3Y
ttp://www10.plala.or.jp/p205tb16/scale.txt

33 :名無しさん@編集中:2005/05/21(土) 01:35:01 ID:bxkQE+X0
>>32
その情報はずいぶん古いな

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

34 :691 ◆AFS777vyz. :2005/05/21(土) 15:20:35 ID:R2b+QCEe
ちょっと難しい話ですけど、こちらに興味がある方が多そうなので転載します。

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


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


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


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


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


39 :691 ◆AFS777vyz. :2005/05/21(土) 15:24:50 ID:R2b+QCEe
読み返すと若干不正確な表現がありますが...
概略と言うことでご容赦を

40 :名無しさん@編集中:2005/05/21(土) 15:48:51 ID:dnBz8m9D
このスレってこういう感じなのか?
どういう人にとって必要な知識なのかが分からん
テレビキャプチャする人がsRGBなんて意識する必要ないんでしょ?

41 :名無しさん@編集中:2005/05/21(土) 16:25:43 ID:i9aLeUmn
DTVってちゃんとノート取って勉強しないと地雷ファイルだらけになりそう
俺みたいに(^^

42 :名無しさん@編集中:2005/05/21(土) 16:58:34 ID:uhX9ZnjB
地雷処理はプラグイン作者の仕事。
一般エンコーダーは普通にエンコすればいい。
普通にエンコして地雷になるようならプラグイン作者の責任。

43 :名無しさん@編集中:2005/05/21(土) 18:48:01 ID:lJqrZ116
>>42
プラグイン作者といっても、プロからアマまでいるしな。
フリーのプラグインなら、それを選んだユーザの責任だろ。

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

44 :名無しさん@編集中:2005/05/21(土) 22:36:25 ID:gCiPf9m8
だな

45 :名無しさん@編集中:2005/05/23(月) 11:14:44 ID:aZxNbooi
結局家電レコ使ったほうが早いよな
キャプボ、キャプソフト、エンコソフトでのRGB、YUVの色空間の違い
圧縮、伸長の方法やら素人には複雑すぎて手に負えない

46 :名無し募集中。。。:2005/05/23(月) 11:28:16 ID:63W+AFi6
もともと素人が適当にやってもうまくいくようになってたのに
YC伸長だなんだと素人を惑わせる人が出てきたからだよ

47 :名無しさん@編集中:2005/05/23(月) 12:23:45 ID:rmBMYpac
ヒストグラムを見れば、素人でもYC伸張の意味がわかるけどなw

48 :名無しさん@編集中:2005/05/23(月) 12:28:14 ID:Gowu1WAP
>>45
というか、民生機器やPC周辺機器業者が色空間について理解した上で開発してるのか
不安になって来た…
ボードによっても色合いがまちまちだしなぁ。

49 :名無しさん@編集中:2005/05/23(月) 12:32:30 ID:rmBMYpac
>>48
色合いなんて個々のPC環境に依存するからな(グラボ、モニタ等)
ヒストグラム表示できるフロントエンドで逐一チェックしないとどうにもならん。

50 :名無しさん@編集中:2005/05/23(月) 14:14:01 ID:lEzx/RML
PCモニタに合わせて鮮やかな色にするって機能、
ありがた迷惑になってきたな。

51 :691 ◆AFS777vyz. :2005/05/23(月) 20:04:17 ID:J3aMVn7a
>>48
AV機器のLSIには普通にカラーコンバータ入ってますよ。
通常は N2S と同じように ICC ワークフローのコンバートのはずです。
チューナー付きテレビだと色々工夫してるでしょうけど。

52 :名無しさん@編集中:2005/05/23(月) 21:07:02 ID:pWgyMq9z
家電って、デフォでもかなり綺麗な色が出るような

53 :名無しさん@編集中:2005/05/24(火) 03:04:42 ID:W1nxhqZX
もちろん機種や設定によって全然違うんだろうけど、家電は鮮やか杉の色と
NRを効かせすぎでノッペリした画質というイメージが全体的にある。

54 :名無しさん@編集中:2005/05/24(火) 03:07:42 ID:bkQcT+3I
ビクターなんかは特にそうだね。

55 :名無しさん@編集中:2005/05/24(火) 05:20:24 ID:e0YQU8Qt
デジタイザの差もあるんだろうけど彩度とコントラストを上げて
意図的にメリハリのある画質にしてる

56 :名無しさん@編集中:2005/05/24(火) 13:31:25 ID:EOyvljSq
peg2ファイルを作るときに YC伸長フィルタで開始高輝度を16終了輝度を235に
設定すると 例えば人間の髪の毛なんかpcモニター上では真黒になるけど
これでいいの?


57 :名無しさん@編集中:2005/05/24(火) 13:47:07 ID:Y732FBcD
>>56
よくないw

58 :名無しさん@編集中:2005/05/31(火) 01:07:52 ID:wmKwE28D
VMR9使いたくて、やっとDirextX 9対応のグラフィックボード
買ったのに、VMR9はYC伸張されない仕様なんですね。
ずっとオーバーレイでYC伸張された動画見てたから違和感がある。
このままオーバーレイ使ったほうがいいのかな。
念のためRADEON選んどいてよかった。

59 :名無しさん@編集中:2005/05/31(火) 02:43:35 ID:cE2VQZpO
だから自前でYC伸張済みを渡してやるんだよ

60 :名無しさん@編集中:2005/05/31(火) 10:35:38 ID:wmKwE28D
>>59
それってタイミング的にはCodecのデコードが
終わったあとになりますよね。
なんかそこまでCPUでやってしまうと
VMR9使ってCPU負荷を下げたいという
当初の目的が満たせなくなってしまうような。

61 :名無しさん@編集中:2005/05/31(火) 12:37:52 ID:Pe29Le77
VMR9はゴミ。
さっさと死滅しろ。

62 :名無しさん@編集中:2005/05/31(火) 13:43:00 ID:S214bBiT
ProcAmpで調節すればいいだけじゃん
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dxvaguide_c0890752-2fdc-4f74-a537-b5a56f9cdf16.xml.asp

63 :名無しさん@編集中:2005/05/31(火) 17:30:17 ID:cE2VQZpO
>>60
ソフトウェア処理のVMR9の時点で負荷はVMR7よりも高い
CPU負荷下げたいなら素直にOverlayでも使っておけ

64 :名無しさん@編集中:2005/05/31(火) 23:11:14 ID:wmKwE28D
前使ってたのDirectX6世代のグラッフィクボードだから
一気に3世代通り越して浦島太郎状態なんだよね。
前のボード、オーバーレイくらいしか使えなかったから
ハードウェアデインターレースは普通に感動した。
とりあえず、やりたいことと現状の問題点を整理しとくと

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

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

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

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

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

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

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

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

65 :名無しさん@編集中:2005/06/01(水) 00:20:16 ID:YqHQr0hP
何かVMR7でオーバーレイ使えばすべて解決するような気がしてきた。

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

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


66 :名無しさん@編集中:2005/06/01(水) 00:35:40 ID:YqHQr0hP
WMP10のパッチはレンダラの設定に関係なく
強制的にVMR9になってそうだ。どうも伸張されてなさげ。

67 :名無しさん@編集中:2005/06/01(水) 02:40:51 ID:6EKlFLxM
>>66
WMP10はレジストリ直接弄らないとVMR7にはできないよ

68 :名無しさん@編集中:2005/06/01(水) 03:02:21 ID:YqHQr0hP
>>67
ヘルプには

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

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

69 :名無しさん@編集中:2005/06/01(水) 07:08:38 ID:KKmuiGYm
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄」
―――――――――――――‐┬┘
                        |
       ____.____    |
     |        |        |   |
     |        | ∧_∧ |   |
     |        |( ´∀`)つ ミ |
     |        |/ ⊃  ノ |   |  VMR9
        ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄    |

70 :名無しさん@編集中:2005/06/01(水) 12:58:03 ID:5bJHTvmx
VMR9はマジでイラネ

71 :名無しさん@編集中:2005/06/04(土) 22:59:24 ID:6gfEZDub
>>48
色空間じゃないけど、ソフトも怪しいのありますよ。
どことは言わんけど、DVからは絶対にトップファーストのMPEG2を作ってくれないソフト。
CCEだと作ってくれるんだけど。

72 :名無しさん@編集中:2005/06/06(月) 01:51:00 ID:KJUwEFMM
>>48
当然理解はしてると思いますが、
メーカーごとに味付けされてるんじゃないかな?
所詮素人向けの機器だし…


73 :名無しさん@編集中:2005/06/12(日) 16:23:20 ID:u9MPTwvw
RADEONにおいて非オーバーレイのVMR(VMR9など)でYC伸張する方法発見
試したドライバはCatalyst5.6

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

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

74 :名無しさん@編集中:2005/06/12(日) 19:38:08 ID:GuuXFQDI
常時強制ハードウェアYC伸張みたいなものか?

75 :名無しさん@編集中:2005/06/15(水) 07:04:37 ID:U4Q7WQy1
スカパをアナログキャプなんですけど、
元はペグ2だから4:2:0だと思うけどアナログ
でとると4:4:4になってるの?
YUY2で撮ってるから4:2:2になるけどこれって
損失あるのかな?

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

76 :名無しさん@編集中:2005/06/15(水) 14:49:15 ID:LAIXrAm7
補完されたアナログ出力を「4:4:4」とは言わないよ。
普通のアナログを4:2:2でサンプルするなら実用上の「損失」は無いから大丈夫。

77 :名無しさん@編集中:2005/06/15(水) 15:25:16 ID:9zIsKKj4
アナログ(NTSC)信号では、色はフィールドごとに市松模様になってるから
4:4:4でも4:2:2でもない。情報量的には4:2:2に近い。

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

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

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

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

78 :名無しさん@編集中:2005/06/15(水) 15:59:09 ID:ysaCKcj7
NTSCの4:2:2の帯域の比率がまず先にあって、BT601やYUY2ってのは後付けの規格だよ。
市松模様だから4:2:2ではない、って訳じゃない。

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

79 :名無しさん@編集中:2005/06/15(水) 17:24:21 ID:9zIsKKj4
帯域はY:I:Q=4:1.5:0.5

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

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

80 :名無しさん@編集中:2005/06/15(水) 21:06:34 ID:h3HL/SGR
「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
受信機のNTSCデコーダではY:U:V=4:0.5:0.5で処理している。」
という記述をよく見るんだけど、やっぱり民生品では
Y:I:Qで色をデコードしてるのって存在しないんでしょうか?
コンポジット出力も同様なんですか?

81 :名無しさん@編集中:2005/06/15(水) 22:27:59 ID:9zIsKKj4
>>80
放送はチャネルあたりの帯域自体が狭い
>「放送局自体は確かにY:I:Q=4:1.5:0.5を送出してるけど、
してない
でもスカパーには関係ない
放送信号とコンポジットとS端子とD端子では全部帯域が違う

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

82 :名無しさん@編集中:2005/06/15(水) 22:57:30 ID:9zIsKKj4
ちなみにNTSCの色差は離散アナログ値なんで、
サンプル位置と帯域も別の話な

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

83 :75:2005/06/17(金) 02:32:14 ID:UnRyHKBJ
あの…
つまり今のままで大丈夫なんでしょうか…?(ビクビクッ

84 :名無しさん@編集中:2005/06/17(金) 19:40:02 ID:pufw26Nu
>>83
大きな損失は無いから実用上問題ない

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

85 :名無しさん@編集中:2005/06/29(水) 01:31:35 ID:qTP2Zkhm
Yは普通に範囲内に飽和させてますが
CbCrも飽和させるもんなのでしょうか?
濃過ぎません?

86 :名無しさん@編集中:2005/06/29(水) 12:29:16 ID:ubYKEIvC
>>85
CbCrも範囲内に飽和させればいい

元々範囲内に収まっているなら何もしなくていい

87 :名無しさん@編集中:2005/07/02(土) 00:21:09 ID:tcso3n9Z
>>86
ありがとう!

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

88 :名無しさん@編集中:2005/07/02(土) 09:27:02 ID:wdfsasf3
つ飽和演算

89 :名無しさん@編集中:2005/07/02(土) 13:28:09 ID:UkmcXytg
ほわほわ

90 :名無しさん@編集中:2005/07/02(土) 13:48:04 ID:kyHLlvhB
ほっちゃん、ほわほわ

91 :名無しさん@編集中:2005/07/08(金) 22:29:00 ID:nuaw2rUr
ttp://sakots.pekori.jp/cgi/sn/src/up23955.jpg

92 :名無しさん@編集中:2005/07/19(火) 05:49:46 ID:TcNYDJuR
ffdshow050711で確認したんだが、
YUY2,YV12で出力するとオーバーレイ、VMR9に限らずRGB32で出力したときより灰色っぽくなる。
結局どの色空間で動画見れば一番いいのかわかんなくなってきた

93 :名無しさん@編集中:2005/07/19(火) 13:00:58 ID:0Qb7yKV5
RGB32

94 :名無しさん@編集中:2005/07/19(火) 13:46:06 ID:wZrVIFTo
>>92
とりあえず落ち着いて近所のカラスでも眺めてみなよ
そのカラスも灰色に見えてきたらそれは、眼科に( ry

95 :名無しさん@編集中:2005/07/26(火) 01:28:37 ID:/V6HwuuE
あまりよく分かってないで質問するんだが・・・

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

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


96 :名無しさん@編集中:2005/07/26(火) 01:43:12 ID:+USFhy7M
違和感なく見えるようにオーバーレイで調整しろ


97 :名無しさん@編集中:2005/07/26(火) 02:52:54 ID:/V6HwuuE
>>96
なるほど。

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

98 :名無しさん@編集中:2005/08/25(木) 23:11:54 ID:5AytfZ+B
msyuv.dllの減色問題ってXP SP1以降なら気にしなくて
いいんだよね?

99 :名無しさん@編集中:2005/08/26(金) 20:14:29 ID:CDD28cNr
>>98
msyuv.dllをhuffyuvdllなどに置き換えるのは、
DirectX8のmsyuv.dllのYUV->RGB変換が16bitという"仕様"のため。
DirectX9を入れてたら問題なし。

100 :名無しさん@編集中:2005/08/26(金) 22:53:28 ID:wZfOxUWq
>>99
そうでしたか!
今DirectX9cなので大丈夫かな。(これはこれでどっか悪いらしいですが…色が大丈夫なら(・ε・)キニシナイ!! )
どうもありがとうございました。

101 :名無しさん@編集中:2005/09/14(水) 20:51:48 ID:Km3X/gE8
あげ

102 :名無しさん@編集中:2005/10/11(火) 12:18:41 ID:QGBzZFc8
age(゚д゚)age

103 :名無しさん@編集中:2005/10/20(木) 11:04:38 ID:qtau/VEU
テストチャート
http://www.belle-nuit.com/testchart.html

104 :名無しさん@編集中:2005/10/29(土) 07:30:16 ID:86eAfRNt
ダウンスキャンコンバータのような機器でWindows上のオーバーレイのみを
アスペクト比固定のままでS端子やD端子でTV出力出来る機器は有りますか?
もし有ればTV用の映像製作等でTV出力画面を見ながらPC側でメイクや調整が出来るのですが・・・。

105 :名無しさん@編集中:2005/11/12(土) 16:20:16 ID:x/xlkAiF
hosyu

106 :名無しさん@編集中:2005/11/17(木) 18:42:38 ID:xNQvQB2J
http://www.geocities.jp/aji_0/
↑にあるNTSC to sRGB Directshow Filterをつかって、
ふぬああで視聴時にリアルタイムに色域変換できないのでしょうか?
録画済のAVIファイルなら変換されるのですが、
ふぬああでリアルタイム視聴にも使いたいです。

107 :名無しさん@編集中:2005/11/17(木) 20:42:33 ID:FvVHW1cb
>>106
ビデオフィルタの設定で「NTSC to sRGB」を接続した
プロファイルを作って、デバイスの設定→グラフの
ビデオフィルタにそのプロファイルを適用すればいいんじゃない。

108 :名無しさん@編集中:2005/11/18(金) 14:32:08 ID:07dYi81R
返答ありがとうございます。
NTSC to sRGBという名前のフィルタが見当たらなく、
代わりにColorSpaceConverterというものとColorConverterというものがそれっぽいんですけど、
ColorConverterのほうは接続不可となって利用できないのでColorSpaceConverterだけ利用できるみたいで、
こちらを利用してフィルタで使ってもいまいち変化が見られないんですがこれくらいしかやれることはないものなのでしょうか?

109 :名無しさん@編集中:2005/11/20(日) 13:07:21 ID:lH1Dgt7C
つ regsvr32 ntsc2srgb.ax

110 :名無しさん@編集中:2005/11/20(日) 17:48:14 ID:00xj7OTn
よくわからないです・・

111 :名無しさん@編集中:2005/11/20(日) 19:00:28 ID:lH1Dgt7C
>>110
一覧に無いのはフィルターが登録されてないから。
ふぬああのインスコ時にやった事をもう一回やればよい。

112 :名無しさん@編集中:2005/11/20(日) 20:57:57 ID:00xj7OTn
そうだったんですか。
やってみます。
アンインストールしたくなったときはどうしたら元に戻せますか?


113 :名無しさん@編集中:2005/11/20(日) 21:02:09 ID:P82v53lv
   ??   ??                      ??  ??
  ??::  ?                         ?  ::??
 ??::              ?      ?             :::??
  ??:: ::     ●     ?::    ?  ??     ●    :: :::??
 ????::            ?:::  ?? ::??         ::::???
  ?????:::: ::        ??:::? ?:::??        :: ::::???
   ??????:::: ::       ??  ??        :::????

            知らんがな

114 :名無しさん@編集中:2005/11/20(日) 23:17:14 ID:00xj7OTn
レジストリに登録(?)するので元にはそう簡単には戻せないのかな?

115 :名無しさん@編集中:2005/11/21(月) 00:01:59 ID:UWmbZlnf
>regsvr32 -h

を実行してみよ。

116 :名無しさん@編集中:2005/11/21(月) 00:16:32 ID:H6Yoxxh5
ntsc2srgbのアーカイブにインストール用と
アンインストール用ののバッチと入ってるがな

117 :名無しさん@編集中:2005/11/21(月) 01:31:35 ID:qpqf8fwT
そのパッチ実行するとntsc2srgb.axもアンインストールされるんですか?

118 :名無しさん@編集中:2005/11/21(月) 11:16:26 ID:M4lzHsIf
ちったあやってみてから聞け

119 :名無しさん@編集中:2005/11/21(月) 12:27:56 ID:aizuJhG9
やってみればすぐ分かる事を何で聞くかなぁ。
しかもよく分からないものに手を出すなんて。

120 :名無しさん@編集中:2005/11/21(月) 17:56:24 ID:qpqf8fwT
よく分からないからきいたんです・・

121 :名無しさん@編集中:2005/11/21(月) 20:00:14 ID:aizuJhG9
>>120
>やってみればすぐ分かる事を何で聞くかなぁ。

122 :名無しさん@編集中:2005/11/21(月) 21:15:24 ID:qpqf8fwT
やると何がおきるか分からないからきいたんです・・

123 :名無しさん@編集中:2005/11/21(月) 21:18:54 ID:wbTcogo/
この先生きてて何があるかわからないので早く死んだ方がいいですよ。

124 :名無しさん@編集中:2005/11/21(月) 21:28:54 ID:v/HgjyuE
地アナキャプったのってエンコる前にsRGBとかに変換した方がいいの?

125 :名無しさん@編集中:2005/11/21(月) 21:55:15 ID:qpqf8fwT
なにごとも注意は必要ですから・・

126 :名無しさん@編集中:2005/11/23(水) 13:02:20 ID:lWHjWUua
No

127 :名無しさん@編集中:2005/11/28(月) 21:56:58 ID:O6zWJGFD
インスコ
regsvr32 ntsc2srgb.ax

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

流れワロス
やり方示したからさっさと死ねよ☆

128 :名無しさん@編集中:2005/11/28(月) 23:06:32 ID:7dRXQWCx
一週間前の流れになに言ってんだか( ´,_ゝ`)プッ

129 :名無しさん@編集中:2005/12/11(日) 13:07:47 ID:Xp/PjcdW
今さら過去ログを読みなおしてみたが、AviUtlの波形表示プラグインの見方を勘違いしている
奴がいて混乱させられたのを思い出した。


130 :名無しさん@編集中:2005/12/11(日) 13:36:44 ID:Vvt59utv
どういう勘違い?
俺もしてるかも。いまいちよくわからん。

131 :名無しさん@編集中:2005/12/11(日) 19:14:52 ID:Xp/PjcdW
上下の線は16,235(240)なのに0,255だと思っていたり、YUY2読み込みしつつCCIR601用の
補助線は意味がないと筋違いのことを言ったり、まあ理解が浅い者を惑わすようなことを
していた。

132 :名無しさん@編集中:2005/12/12(月) 01:36:40 ID:qYdivUMw
あー0.255だと思ってたわ・・
だってCCIR601補助線?をだすと16と235に線がでるよね?
255メーターをスライドすると一番上にあった線が一番下に来るよね?
だから0.255だと思ってたわ。


133 :名無しさん@編集中:2005/12/12(月) 01:53:32 ID:0Cj/DrUZ
>>131も間違ってる希ガス
間違っているというか、常に正しいとは限らないというか

134 :名無しさん@編集中:2005/12/12(月) 03:30:00 ID:Dg6Kx4oJ
はっきり間違ってるって言っちゃえよw

135 :名無しさん@編集中:2005/12/12(月) 05:41:09 ID:yMjndqPb
そりゃあ上で書いたことは前提があるわけで。そういう些末なことでなく、
使い方を誤った上で波形表示プラグインは信用できない代物扱いしている
者がいたという話。

136 :名無しさん@編集中:2005/12/12(月) 07:10:58 ID:qYdivUMw
CCIR601補助線?をだすと16と235に線がでるのはなぜ?
255メーターをスライドすると一番上にあった線が一番下に来るのはなぜ?

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

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


138 :名無しさん@編集中:2005/12/12(月) 22:40:43 ID:qYdivUMw
拡張色調補正などでyoffを-256とかにすると
丁度一番上にあった輝度が一番下にこなかったっけ?
だから波形表示は0-255でやってるのかと思った

139 :名無しさん@編集中:2005/12/13(火) 10:08:44 ID: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 :名無しさん@編集中:2005/12/15(木) 13:08:08 ID: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 :名無しさん@編集中:2005/12/15(木) 13:13:36 ID:XY/E7Tjs
0.99の色情報バグは承知の上での発言だろうな?

142 :名無しさん@編集中:2005/12/15(木) 13:29:12 ID:4v+i7ZSe
>>140
その通りでVFAPI経由は全部RGBになるでやんす。
m2v.aui⇒Huffyuv⇒TMPGEnc3しかYUY2には出来ないでやんす。
ザッツオーライでやんす。

143 :名無しさん@編集中:2005/12/15(木) 15:25:30 ID:nXZgaJPk
>>142
あってますか安心しました。

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

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

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

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

144 :名無しさん@編集中:2005/12/17(土) 13:09:37 ID:1PudFZMd
readme読めYUY2アップサンプリングフィルタの優先度は最大だ

145 :名無しさん@編集中:2005/12/18(日) 14:43:31 ID:SZVU2JPM
何でプレステとかのゲーム機って16777216色も使えるんだろう?
赤・緑・青それぞれの輝度が256段階だから、
256の3乗で16777216色なんでしょ?
パソコンは0-255だけど、テレビは16-235だから、
もっと少なくてもよくない?
ダメ?
俺、アホなこと言ってる?

146 :名無しさん@編集中:2005/12/18(日) 17:15:49 ID:lxFMBKlv
>>145
技術的にリアルタイムA/Dコンバートが8ビットで限界だった時代に作られた規格だから
8ビット中の1ビットで表せられる以下の値は切り捨てているんだよ。
本当はもっと欲しかったんだろうよ。
DVDは10ビットだし、今の放送用機器はそれ以上だし。

147 :名無しさん@編集中:2005/12/18(日) 22:51:09 ID:SZVU2JPM
>>146
せっかく解説してもらったのに、
ついてけない。orz
スマヌ。

148 :名無しさん@編集中:2005/12/18(日) 23:50:48 ID:nrTJ9nY3
>>146は間違ったことはいってないが>>145の答えになってない

149 : ◆.WcbPIljrw :2005/12/19(月) 00:16:27 ID:t3U52JI9
>>145
作業はPC上でやるんだから256^3のほうが扱いやすい。
16-235のレンジにはゲーム機が出力時に変換することだし。

150 :名無しさん@編集中:2005/12/19(月) 00:59:47 ID:Kz7CRruJ
ヒント:アナログとデジタルの違い

151 :名無しさん@編集中:2005/12/23(金) 15:16:38 ID:J4aN7rjc
デジタルのチューナーからS端子やD端子(D1)でPCでキャプチャして保存してるんですが、
色はCCIR601用の6角形にあわせるべきなんでしょうか?
それともチェックをなくした値にあわすべきですか?
MTVX2004HFというのを使っているんですが、これのデフォルトでカラーバーを録画すると、
CCIR601より色がすこし濃いのですが、デフォルトではダメですよね・・?

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

152 :名無しさん@編集中:2005/12/23(金) 22:24:53 ID:BY+QkJWf
迷うくらいなら結果で判断すればいいと思う
キャプチャしたものをDVDして再度キャプチャ
明るさや色が変わらなければOK

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

154 :名無しさん@編集中:2005/12/23(金) 22:38:14 ID:M6j5OgDC
ちなみにハイビジョン放送の企画書だと
BT.709色空間を使うがチューナー側はBT.601でもいいことになってるので
相互変換せずとも一応それほどおかしなことにはならにようになっている
おかしなことになってるように見えるが

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

155 :名無しさん@編集中:2005/12/23(金) 23:28:02 ID:J4aN7rjc
709と601では色の濃さがどう違うとかで判別できないもんでしょうか?
6角形の色の形は綺麗なので601なのかな?

156 :名無しさん@編集中:2005/12/23(金) 23:33:47 ID:i2xPfkki
>ただそれ以前の問題があって現状の地上波はデタラメになってる

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

157 :名無しさん@編集中:2005/12/24(土) 00:05:27 ID:M6j5OgDC
>>156
そのあとのを読んでくれ
局側がまともな変換して放送していないんだよ

158 :名無しさん@編集中:2005/12/24(土) 11:03:23 ID:UI+j1ItE
あんたらどこでそんなの調べて来るんだよ。
もうキャプ暦5年になるが、ついていけない。orz
>>151なんて、当たり前のようにデジチューからD端子キャプなんて言ってるけど、
普通コピワンだろう。

159 :名無しさん@編集中:2005/12/24(土) 11:17:29 ID:PAvYBQZ1
151だけど、MTVX2004HFとか2005HFはふぬああでも使えて、ふぬああならキャプできるんだすよ。
まあD1でしかキャプできないけど。
色がわかんない・・

160 :名無しさん@編集中:2005/12/24(土) 16:53:45 ID:QhiXkkkE
>>156
ゴーストが乗った状態の明るさが異常なんだろうよ

161 :名無しさん@編集中:2005/12/30(金) 16:54:57 ID:3zZ2o1h2
昨日の紅白、荻野目洋子のドレスが白飛びしてたぞ。
数年前流した奴は普通だったのに。
色空間が変なのか?

162 :名無しさん@編集中:2005/12/30(金) 17:05:40 ID:iGqHZWeB
それは色空間以前の問題じゃね?
アナログテープが劣化するのは当たり前でしょ

163 :名無しさん@編集中:2005/12/31(土) 01:53:33 ID:6jCcsghu
前回流してから3年くらいしか経ってないのに?
劣化するなら、初回の86年→前回の方が劣化するんじゃないか?

164 :名無しさん@編集中:2005/12/31(土) 02:48:58 ID:6jCcsghu
ちょっと不安になって、
前回のと今回のをパソコンに取り込んで見比べてみたら、
色空間どころじゃなかった。
明るさが全然違う。

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

165 :名無しさん@編集中:2006/01/05(木) 23:25:29 ID:XaogePmj
白側だけPCスケールなDVD多いな・・
色も濃い気がするけど変換式わからんし俺調整でいいや・・

166 :名無しさん@編集中:2006/01/05(木) 23:29:03 ID:os1DNs3D
白側だけPCスケールなDVDなんてないよ
RGB収録じゃないんだから

167 :名無しさん@編集中:2006/01/05(木) 23:43:04 ID:XaogePmj
スケール、な

168 :名無しさん@編集中:2006/01/05(木) 23:47:22 ID:os1DNs3D
だからYUV>RGBにしたときにどっちのスケールを取るかってのが
TVスケール PCスケール
逆はないんだよ
BT.601でも範囲外のデータが存在することが認められてるんだから
YUVのY235をオーバーしてるDVDがあってもいいの
目で見ておかしいなら
それが製作者の趣味としかいいようがないんだよ
そんなDVDモーヲタは腐るほど持ってるよ

169 :名無しさん@編集中:2006/01/06(金) 01:40:06 ID:seorVa/v
ソースのYUVに手を入れずに、
再生時の変換で各自環境にあわせて独自にスケール設定する、でFA


170 :名無しさん@編集中:2006/01/09(月) 05:25:41 ID:pAG59LDu
アニメのフレームレートを報告するスレ
ていうのもあることだし

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

171 :名無しさん@編集中:2006/01/09(月) 05:45:36 ID:2jZtSUi7
よくねーよw
色空間の意味分かってるのか?

172 :名無しさん@編集中:2006/01/09(月) 05:47:34 ID:m/9P09dN
ts抜いても判別するのシンドイよそれ

173 :名無しさん@編集中:2006/01/09(月) 06:24:36 ID:jT8TEXiC
色温度はけっこうめちゃくちゃじゃない?
ガンマは普通にとっただけで黒→白が直線だった。

174 :名無しさん◎編集中:2006/03/15(水) 00:33:42 ID:BZUboBef
YUV読み込みバグ改善したaviutl1.00まだー

175 :名無しさん@編集中:2006/03/16(木) 07:39:47 ID:0Fi1jfXS
>>174
YUY2アップサンプリングでとりあえず対処汁。

176 :名無しさん@編集中:2006/06/24(土) 05:26:16 ID:oLoqeDzv


177 :名無しさん@編集中:2006/08/29(火) 11:36:43 ID:7zhaEaEv
捕守

178 :名無しさん@編集中:2006/09/13(水) 03:18:43 ID:uNV8LL0J
キャプ後単純にAviUtlではYC伸張フィルタをON、AviSynthではColorYUY2(,levels="TV->PC")を加えるだけで、
とりあえずOKとしておいていいのでしょうか?

179 :名無しさん@編集中:2006/09/13(水) 23:41:20 ID:UaqMYGD2
キャプぼによるからそれでいい世別に

180 :名無しさん@編集中:2006/10/02(月) 22:51:05 ID:9y4GEzpU
な、なんのために?

181 :名無しさん@編集中:2006/10/31(火) 14:49:56 ID:8tH8dcPo
xvYCCがこの先生きのこるには

182 :名無しさん@編集中:2006/11/01(水) 00:03:00 ID:y9zE+ZjK
      _,,,......,,__
  /_~ ,,...:::_::;; ~"'ヽ
 (,, '"ヾヽ  i|i //^''ヽ,,)
   ^ :'⌒i    i⌒"
      | ( ゚Д゚)  < xvYCCもきのこれ
      |(ノ  |)
      |    |
      ヽ _ノ
       U"U

183 :名無しさん@編集中:2006/12/28(木) 09:55:28 ID:7t5vCKgd
RGB24は1ピクセルあたり24bit。
yuv411は1ピクセルあたり12bit。
yv12は1ピクセルあたり9bit。


184 :名無しさん@編集中:2006/12/28(木) 16:09:34 ID:Ay0x59Nq
>183
YV12はYUV=4:2:0だから平均するとピクセルあたり12bit。
ピクセル当たり9bitなのはYUV9。

185 :名無しさん@編集中:2007/01/27(土) 23:44:41 ID:Axr80zLU
ほす

186 :名無しさん@編集中:2007/02/06(火) 03:43:53 ID:R+eFn8hQ
YUY2のplanarとinterleaveって何が違うんでしょうか

187 :名無しさん@編集中:2007/02/06(火) 04:06:14 ID:M8EDPCKc
データのならべ方が違う

188 :名無しさん@編集中:2007/02/06(火) 20:44:08 ID:p0LMrJTX
どもです

189 :名無しさん@編集中:2007/02/19(月) 23:13:43 ID:aEdql+0K
DVD2AVI

190 :名無しさん@編集中:2007/02/19(月) 23:21:54 ID:aEdql+0K
他スレからここを紹介されました

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



191 :名無しさん@編集中:2007/02/19(月) 23:39:22 ID:wz6b04WH
綺麗に見えたほうが正解

192 :名無しさん@編集中:2007/02/20(火) 01:38:05 ID:q1Y9nnwJ
>>190
d2vをどうやって読み込むかによって違う

193 :名無しさん@編集中:2007/02/20(火) 15:26:56 ID:7oMn6iAj
YC伸長フィルタを使っておのれの感性を信じ
調整するのが正解。

194 :190:2007/02/21(水) 01:03:40 ID:EYB5pI5b
サンクスですとりあえず前者でいくことにしました
DVD2AVIもDGIndexにバトンタッチして心機一転です
個人的には変換前に帯域を十分に使ってるからだと信じてます

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

でわでわ

195 :名無しさん@編集中:2007/02/26(月) 02:37:32 ID:DjxyUoq5
>>191
ある意味正しい。


196 :名無しさん@編集中:2007/03/10(土) 10:42:59 ID:vpNP6lA7
TMPGenc2.5でYC圧縮済みファイル作成可能?

197 :名無しさん@編集中:2007/03/11(日) 00:07:25 ID:D/PyMUuG
意味分からん

198 :名無しさん@編集中:2007/04/25(水) 20:27:25 ID:gx2mBUZi
RGB24しか入力できないリアルタイム映像処理ソフトが有るのですが、
それにYUY2出力のUSBカメラを繋いでリアルタイムでRGB24にフォーマット変換して
RGB24出力のデバイスとして認識させる方法って無いでしょうか?


199 :名無しさん@編集中:2007/04/25(水) 23:51:02 ID:L8S2tmlH
そもそもそのソフトにどうやって映像を受け渡ししてるわけ?

200 :名無しさん@編集中:2007/04/26(木) 10:45:24 ID:3m61xA3h
普通のUSBカメラです。
YUY2でも写ることは写るのですが、RGB24でないとできない処理があります。
検索するとリアルタイムで色空間を変換してくれるソフトが有るみたいですね。

201 :200:2007/04/26(木) 14:06:31 ID:3m61xA3h
こう言うDirectShow Filterと言うのがあるのですが、対応ソフトでないとだめなのかな?
http://www.medialooks.com/products/directshow_filters/resizer.html
使い方が分かりませんorz

202 :名無しさん@編集中:2007/04/26(木) 14:48:57 ID:HrUsUqgy
おい手前等!!

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

203 :名無しさん@編集中:2007/04/26(木) 15:49:23 ID:QYZvbHiU
グラサンかけてるたかじんに色空間は無理

204 :名無しさん@編集中:2007/04/26(木) 15:58:25 ID:fdYtFTZ1
前々スレは激しかったよ

205 :名無しさん@編集中:2007/04/27(金) 09:15:52 ID:ely+IcWK
グラボに金かけてるヒマじんに色空間は有利


206 :名無しさん@編集中:2007/05/01(火) 18:08:54 ID:IeEDGuKg
Vista Ultimate買ってきた。MPEG2デコーダー入ってた。
で、色々弄ってみたけどEVRってやつがVMRとかオーバーレイの代わりに使われてるんだな。
でもEVRもTVスケールでYC伸張してくれないみたいで白っぽいのだが、これってバグ?
PCで再生するならYC伸張するべきだと思っていたのだが、ちがうの?
ゲフォとラデ両方試してもどちらもYC伸張してくれないみたい。。。


207 :名無しさん@編集中:2007/05/05(土) 10:55:45 ID:QK7qRbPj
>>206
ラデなら最新の7.4ドライバー入れるとVistaでも伸張してくれるようになるぞ。


208 :名無しさん@編集中:2007/05/13(日) 04:53:53 ID:/l8P16+Y
DGMPGDecってBT.601だけだけど、同じようなソフトでBT.709対応しているの知らない?


209 :名無しさん@編集中:2007/05/13(日) 05:34:21 ID:uZxa7KW4
まるも
http://www.marumo.ne.jp/mpeg2/

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

210 :名無しさん@編集中:2007/05/13(日) 06:27:32 ID:/l8P16+Y
>>209
あんがと。丁度みたらDGMPGDecが1.49になっていてBT.709出力の問題が直っていた。


211 :名無しさん@編集中:2007/05/20(日) 04:54:31 ID:21QP2V1W
Vista+GeForceだけどどうやら最近の風潮ではYC伸張はしないってのがデフォなのかね?
オーバーレイがあった頃はYC伸張されているっぽい感じが主流だったと思ってたけど、
VistaになってすっかりYC伸張しなくなってきているね。
やっぱHDVとかHDTVとかが範囲を超えて使い始めたからかな?


212 :名無しさん@編集中:2007/05/20(日) 04:56:05 ID:/kqyXlc3
        |
        |
        し
           ハ_ハ
         ('(゚∀゚∩.
          ヽ  〈.
           ヽヽ_)

213 :名無しさん@編集中:2007/05/20(日) 18:26:17 ID:ELpAuxLi
マジなのか笑わせにかかってんのかよくわからんな


214 :211:2007/05/20(日) 19:34:37 ID:21QP2V1W
>>213
私は至ってマジです。

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


215 :名無しさん@編集中:2007/05/20(日) 20:25:51 ID:R795EJOs
>>214
>168あたりを読んで納得できる?

216 :名無しさん@編集中:2007/05/20(日) 20:28:23 ID:R795EJOs
ごめん。

217 :名無しさん@編集中:2007/05/20(日) 22:26:18 ID:ELpAuxLi
>>214
やはり話がよく見えないな。YC伸張する云々はどの時点での話なんだ。


218 :名無しさん@編集中:2007/05/20(日) 23:03:34 ID:d66fujsT
>>214
テレビのモニタなら自動でゲインを調整するからね。
多少明るくても問題ない。
グラでAGCを使うべきなのかもな。
SDだろうとHDだろうと100IRE以上の素材なんて腐るほどあるよ。

219 :名無しさん@編集中:2007/05/21(月) 09:45:25 ID:MGT2U7ZD
>>218
どうもあなただけは話の内容を理解しているようですね。

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


220 :名無しさん@編集中:2007/05/21(月) 10:14:52 ID:MGT2U7ZD
>>214
ちなみに最初の質問はVistaがYC伸張しなくなったという話についてだが、
恐らくだが特に最近のHDコンテンツが16-235の範囲外を使い始めたという事実が
PCモニターでsRGBに最適化されているWindowsでどうしようもなくなってきたのではないかな?
結局、YC伸張しないようにすることで見た目は悪くなることがあっても、情報の欠落よりはマシだと思ってるんじゃないかな?


221 :名無しさん@編集中:2007/05/21(月) 23:33:53 ID:PIe4n1OH
基本は伸張だと思うよ
範囲外を使っているソースがあったとして
>明らかに明るい部分のディテールがギタギタになっちゃうんだよね
の問題があったとしても
これをストレート変換で見るとなると
他の部分は色がくすんで見える(sRGBの一般的なモニターならば)。

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

HDVとかHDTVとかでそういうデーターが出始めているって事は
オマエラ、いつまでも古臭いショボモニター使ってないで
買い換えろって事じゃないか?(ゲイツもそれに賛同しているとか)

222 :名無しさん@編集中:2007/05/22(火) 00:23:50 ID:uizLjBzr
>>221
確かに基本は伸張だと思うが、特に235-255はHDになってからはまるで当たり前のように使ってるね。
それに最近のHDTVはこのあたりの値もちゃんと画面上に表示しているように見える。
xvYCCなんか特にそうだけど、もうRGB変換後に範囲外になるようなYUVデータは平気で使われつつあると感じる今日この頃。

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


223 :名無しさん@編集中:2007/05/22(火) 00:41:59 ID:qVsgX0nD
http://www.avsforum.com/avs-vb/showthread.php?t=523614&page=1&pp=30

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


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

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

224 :名無しさん@編集中:2007/05/22(火) 04:07:12 ID:uizLjBzr
>>223
思うに伸張変換もストレート変換も両方正しいと思う。問題は好きな方をどうやって使うか。
Vistaなんかだとメディアプレイヤーもメディアセンターもそれ選べるようには作られてない。
どうやらVistaだとVMR9の後継のEVRってのが使われていてそれがVMR9と同じようにストレート変換を使うようです。

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

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

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


225 :名無しさん@編集中:2007/05/22(火) 18:45:38 ID:Q1n9cdXS
そりゃ間違ってるなら規格にならないだろう。
どちらも正しいからこそ両方の規格があるわけで、
どちらを選ぶかは時と場合(と使用者の趣味)によるのは自明。

つーことで結論に同意。

226 :名無しさん@編集中:2007/05/22(火) 22:23:05 ID:rrTNAVnB
実にフザケタ規格だ
なんかムカムカするよ
筋が通ってねえ

227 :名無しさん@編集中:2007/05/23(水) 00:01:19 ID:+4PXH4t1
nVIDIAのドライバ開発が、糞なだけに一票。
規格とか実際の使いかってとか。どうせ、何も考えてないって。('A`)

228 :名無しさん@編集中:2007/05/23(水) 01:05:18 ID:m/7ZVbLP
>>227
君は今までの内容をまるで読んでいないだろ・・・
おじさんビックリだよ

229 :名無しさん@編集中:2007/05/23(水) 02:53:46 ID:+4PXH4t1
ええ。
224氏が最後に記述した結論でいいでしょ。問題無い。
御免ね。「 nVIDIAのドライバ開発が糞 」って云いたかっただけなんだ。
「 nVIDIAが何も考えてないで、ドライバ開発してる 」とか云いたかっただけです。

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

230 :名無しさん@編集中:2007/05/23(水) 08:09:12 ID:FQyq0JCt
ドライバに不満あるようだけど
何に不満なんだ?
オーバーレイの色が標準でntscブラウン管向けになっていない点?
evrがストレートだから?
pcモニタで見るならRadeonだって正解ではないし
ソース時点でバラバラだから正解なんて無い
てのが結論でしよ


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


232 :名無しさん@編集中:2007/05/25(金) 19:08:52 ID:DMXx3JvV
YC伸張を勉強中のものです。色々調べた挙句、どうすれば良いのか行き詰ってしまった。

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

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

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

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


233 :名無しさん@編集中:2007/05/25(金) 21:49:13 ID:Qmri8tz6
先駆者なんていないよ
制作側がPCで見る事を無視して
いるのだからどうしようもない 

234 :名無しさん@編集中:2007/05/26(土) 01:36:12 ID: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 :名無しさん@編集中:2007/05/26(土) 06:32:10 ID:Nf9jHvew
アナログ時代に16-235なんて概念すらない。なぜならアナログだから。
数字に対応させたのはあくまでデジタル化のため。
PCは規格に従って16-235を有効範囲にしてるだけ。
盲目的とかいうわけではないし、デバイスの制限とかでもない。
BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
その値をどう表示するかは受け手次第。

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

236 :234:2007/05/26(土) 14:58:45 ID:IKNN1LT+
>>235
大筋は私が言っている通りだとは思うけど。

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

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


237 :名無しさん@編集中:2007/05/27(日) 10:22:42 ID:SuU4v6cz
>236
結局、
> BT.601と709の規格上では16-235の外まで使っていいことになってるんだから、235-255があっても問題ない。
> その値をどう表示するかは受け手次第。
ってことだろ。
そこから先はもう宗教論争でしかないよ。

238 :名無しさん@編集中:2007/05/27(日) 15:01:32 ID:IVs/+CUP
>>237
うーん、>232って宗教論争と関係ないような。フリーソフトの作者か何かじゃまいか?
その受け手次第の部分を>232がどうにかしようとして困っているんじゃまいか?
>ガンマを適用しながら16-255を0-255に伸張する
アイデアは良いと思うし多分今時のテレビもやってそうと思う。
漏れは頭良くないんで誰か頭いい人いたら>232を助けてやってくれ。
そしたらいいソフトが出てくるかもしれん。


239 :名無しさん@編集中:2007/05/27(日) 19:51:49 ID:phyEHhl3
ffdshowで入力を16-255にすればいいじゃん
ガンマは変更する必要ないと感じる

240 :名無しさん@編集中:2007/05/28(月) 00:34:09 ID:bf/dY99X
16-235を守ってるメーカーだってあるのに、規格を軽視してる一部メーカーのためだけに
自分も規格を無視するなんて普通はやらないとおもうが。

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

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

241 :名無しさん@編集中:2007/05/28(月) 03:54:26 ID:X+udwO24
>>239
それ駄目だと思う。
入力を16-255で出力を0-255にすると、結果としては暗い方向にシフトするから画面が暗くなる。
だからガンマ掛けないと駄目だという話になるんだと思うよ。


242 :名無しさん@編集中:2007/05/28(月) 03:58:28 ID:X+udwO24
>>240
俺もメーカーだけど、16-235はかなり微妙になってきている気がする。
試しに235-255のデータ作って最近のHDTVで表示してみな。
どれも結構けろっと表示すると思うよ。

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


243 :名無しさん@編集中:2007/05/28(月) 04:02:32 ID:X+udwO24
>>232
俺はメーカーでも直接携わっているわけじゃないんで大丈夫だと思う。
細かくは計算してないけど、どんぶり勘定だとガンマ0.9位で良いかも。


244 :名無しさん@編集中:2007/05/28(月) 15:37:26 ID:yP1g2Co7
何に悩んでるか理解できん
規則にあわせて作ってくれない物に対して
それを作者の意図する色を再現させようなんて無理
その素材を作った人が基礎となる色を示さない限り
見る側が調整するしか無いし、決め撃ちできない

245 :名無しさん@編集中:2007/05/28(月) 16:01:16 ID:X+udwO24
>>244
残念ながらその信じている規格は特に絶対を定義しているわけじゃないんですよ。それが現実なんですよ。
無理と言われても製品作んないといけないし、大体はうまく行くような落としどころも探さないといけないし。
規格とか無理とか言ってると物は出てきませんよ。


246 :名無しさん@編集中:2007/05/28(月) 16:39:51 ID:Wh0vqJJt
>>245
私は244と違うけど
貴方が妥協点を見つけたいと考えるのは理解できるが
何を基準に決定するのですか?
そんなの無理じゃないの?

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

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

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

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

247 :名無しさん@編集中:2007/05/28(月) 16:42:55 ID:Wh0vqJJt
無理という言葉はよくないね。

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

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

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


248 :名無しさん@編集中:2007/05/28(月) 17:42:06 ID: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 :名無しさん@編集中:2007/05/28(月) 18:08:54 ID:Wh0vqJJt
>>248
表示デバイスの色域が
昔と変化したから
その帳尻合わせをデーター側で行おうという事ね。

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

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

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

250 :名無しさん@編集中:2007/05/28(月) 22:21:20 ID:ytNPdy9C
>>232のケースで理論的に正しいのは、ガンマ変換を行わない事だよね。
Y 16-235から0-255への変換とY 16-255から0-255への変換では、
単に明るさが2割違うだけだから。(ガンマ 2.2の場合)

A.Y=16を黒(0),Y=235を白(1)にとる ガンマ 2.2のグラフ
B.Y=16を黒(0),Y=255を白(1)にとる ガンマ 2.2のグラフ
C.Y=16を黒(0),Y=235を白''(0.82509)にとる ガンマ 2.2のグラフ
D.Y=16を黒(0),Y=255を白'(1.21988)にとる ガンマ 2.2のグラフ
を描くと一目瞭然。
BとC(AとD)は同じグラフになる。

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

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

251 :名無しさん@編集中:2007/05/29(火) 00:39:04 ID:JTzPshyt
>>242
そのHDTVって16未満はそれ相応に表示されるの?
表示されるなら単にストレート変換になるけど。

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

252 :名無しさん@編集中:2007/05/29(火) 02:08:48 ID:FHHidpBJ
>>249
TVだと表示デバイス側で出来るけど、PCモニタだと無理だよね。250氏が的を得てる感じだな。

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


253 :名無しさん@編集中:2007/05/29(火) 02:24:57 ID: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:2007/05/29(火) 22:51:44 ID: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 :名無しさん@編集中:2007/05/30(水) 02:24:25 ID:ftvRBIkp
>>254
>>好みではないけど、>>243に書かれているガンマ0.9は悪くない誤魔化し方だと思う。
>>暗部が16-235 YC伸張に近くて、明部がストレート変換に近い入出力曲線になるから。
俺もガンマ0.9は結構悪くないかも。正確に計算する方法が分かればいいのだが。

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


256 :250:2007/05/31(木) 00:56:15 ID: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 :名無しさん@編集中:2007/05/31(木) 15:51:56 ID:TgR+YRvz
>>256
なんかややこしくなっているだけの気が。

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

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


258 :250:2007/06/01(金) 23:35:42 ID:0L7wCrzw
>>257
2割という数字の出所か。それは気がつかなかった。
それじゃ、16-235範囲のみが話の筋からずれていると思うのも当然だね。

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

259 :名無しさん@編集中:2007/06/02(土) 04:05:02 ID:kvVZTR3G
>>258
ストレート変換の状態16-235[0-15と236-255はクリップしない]と、
その内の16-255を0-255にリニア変換した場合の明るさの違いの話じゃないの?


260 :250:2007/06/03(日) 12:22:53 ID:sQJkgEcx
>>259
なぜ、ストレート変換を16-235と表現するの?

261 :名無しさん@編集中:2007/06/03(日) 12:43:23 ID:gJ8zyvVr
きっと色空間って概念を全く理解してないからだよ。

262 :名無しさん@編集中:2007/06/04(月) 15:15:44 ID:hSQLv5Js
>>260
慣例でしょ?ググってもストレート変換を16-235と表現している方が多いし。
それに259氏は実際に"[0-15と236-255はクリップしない]"と注釈まで付けているじゃん。
てか250氏、揚げ足取るよりも>259が指摘した16-255を0-255とした場合の明るさの違いという指摘の方が大事かと。


263 :名無しさん@編集中:2007/06/25(月) 14:12:49 ID:Nq6UpP7a
PS3とかXbox360の最新ファームで設定できるようになってるやつって16-235と0-255の切り替えだよね?
でもXbox360には3種類の設定があってその中間みたいなのが選べるみたいだけど、あれってなに?8-245とかには見えないけど。。。


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

265 :名無しさん@編集中:2007/07/04(水) 20:57:11 ID:wTmbV+oG
> PC内部では全て伸張無しの0-255ストレート
なんだこりゃ

266 :名無しさん@編集中:2007/07/04(水) 21:26:18 ID:AHrIg2p1
γが1.0って事じゃねえの?

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

268 :名無しさん@編集中:2007/07/05(木) 05:02:09 ID: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 :名無しさん@編集中:2007/07/06(金) 01:35:49 ID:mFQXzn6S
>>268
これがこのスレのFA?もうこれ以上はこのスレで議論する話もないかな。。。


270 :名無しさん@編集中:2007/07/08(日) 07:01:08 ID:wBtlNGR6
このスレでアニメの話して良いのかわかんないけど、
ウミショーって
>>221
に書いてある見たな、
235より上の輝度入ってる?



271 :名無しさん@編集中:2007/07/09(月) 17:35:39 ID:ZUP50VT4
>>270
DVD?TV?何の話だ?
235より上が入っていても構わない、ただし、それを受け手が表示するかどうかは受け手次第。
逆に、16より下は入っていても構わないが、受けては表示しちゃだめ(もしくは見えないように調節する)。


272 :名無しさん@編集中:2007/07/14(土) 21:49:39 ID:cJSPtMDN
>>250 くらい的確な説明が出来る人が理解してる人。



273 :名無しさん@編集中:2007/07/14(土) 21:50:51 ID:cJSPtMDN
>>240
頭がかたい

274 :名無しさん@編集中:2007/07/15(日) 00:47:00 ID:pI+Mwr6R
16より下を表示しちゃいけない理由がわからないんだけど、
なにか規定があるのかな。

275 :名無しさん@編集中:2007/07/15(日) 00:55:40 ID:0Y65Ku51
0と255は同期信号だから使っちゃ駄目ってのはどっかで読んだ

276 :名無しさん@編集中:2007/07/15(日) 02:49:12 ID: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 :名無しさん@編集中:2007/07/15(日) 11:53:31 ID:p9uHdJj3
>>275
0-255を直接アナログに変換した場合の0と255にあたるアナログレベルの場合な。
デジタルでは0と255は存在しても構わないし、実際にPCでは表示する。


278 :名無しさん@編集中:2007/07/15(日) 14:18:31 ID:pI+Mwr6R
>>276 そんな古い慣習を今まで引きずってるのねえ。

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


279 :名無しさん@編集中:2007/07/16(月) 14:57:15 ID:4aVb+cno
0-15はデータに入っててもいいけど、表示側は見えないように調節しておいて欲しい。
236-255はデータに入っててもいいし、表示側は出来れば見えるようにがんばって欲しい。
ってのが建前。
あとは結果は受け手次第のベストエフォート型。



280 :名無しさん@編集中:2007/07/19(木) 21:24:24 ID: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 :名無しさん@編集中:2007/07/19(木) 22:41:47 ID:0DeyL2E3
それはもう、好きなほうをとしか言えない気がする。
HDデータはBT.709でしか再生できないってなら別だけども。
再生できないというか709として再生されてしまうということね。
なので601でエンコしてそれを709プロファイルで再生した場合にどうなるか
逆に709のものを601で再生した場合にどうなるか
ってのも考えに入れておいたほうがいいかもしれない。

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

282 :名無しさん@編集中:2007/07/19(木) 23:04:36 ID:dRxMo2eW
もともとRGBのデータをBT.709のYUVで保存したものがあるのですが、これをできるかぎり
元のRGBに近い状態にするにはどのような変換式を使えば良いのでしょうか?

283 :名無しさん@編集中:2007/07/19(木) 23:20:19 ID: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:2007/07/19(木) 23:28:07 ID:bEE+yokE
あと、ソースがBT.709なのは明らかだと思います。
m2v.auiでソースを維持、BT.709、BT.601をそれぞれ選び、
それぞれAviUtlで読み込み、フレームをBMPで保存して見比べたところ
ソースを維持とBT.709はまったく同じ色でした。
他に方法があるのかもしれないですが、もっと楽なやり方があるなら笑ってやってください。

285 :名無しさん@編集中:2007/07/20(金) 00:06:15 ID:0DeyL2E3
これでいけない?
ttp://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm
ファイルはこれね
ttp://avisynth.org/warpenterprises/files/colormatrix_25_dll_20050223.zip

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

286 :名無しさん@編集中:2007/07/20(金) 00:07:35 ID:0DeyL2E3
間違えた。
Haali Matroska SplitterじゃなくてHaali Media Splitterだった。

287 :名無しさん@編集中:2007/07/20(金) 00:14:37 ID:ddO/yq+C
>>280
質問の中によく解らない部分がありましたので、よろしければ教えて下さい。

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

の部分です。もしも、

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

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

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

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

288 :283:2007/07/20(金) 01:34:28 ID:hMZV6A4v
>>285
colormatrix、いけそうですね。試してみます。
今初めて、HomeCinemaの存在を知りました
えーと切り替えとは709で再生するか、601で再生するかを選択できるということですか?
できたら説明お願いします。

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

基本的に再生時の色で見たのではなくて、
m2v.auiを通して変換させてAviUtlのプレビューを使っています。
ようするに、
まずDVDのVOBをm2vconf.exeを使いBT.601、BT.709、元データ維持を3回設定しなおして
AviUtlでYUY2で読み込み、それぞれの設定で3回読み込ませ、毎回同じフレームをBMPで保存して
すべてを比較します。
次にBDのm2tsをmpgとして同じように3回設定しなおして
AviUtlで3回読み込ませ、すべて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 :名無しさん@編集中:2007/07/20(金) 20:07:19 ID:X60N8DXO
>>288
切り替えはそれであってる。
参考用に画像撮ってみた。
ttp://www.uploda.net/cgi/uploader4/index.php?file_id=0000016720.png
ソースはここの動画。
ttp://www.gran-turismo.com/jp/gt5p/

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

290 :名無しさん@編集中:2007/07/20(金) 20:09:49 ID:X60N8DXO
ああ、ここ直リンできないのか。
こっちで落として。
ttp://ud.gs/4072r

291 :287:2007/07/20(金) 21:52:33 ID: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 :名無しさん@編集中:2007/07/21(土) 01:11:04 ID:X9tNrxTT
>>291
709は709で変換しないとおかしくなる。
SD時代の古めのソフトは601専用な事が多いからなHD時代だと基本は709だから量対応が必修。


293 :288:2007/07/21(土) 02:48:01 ID:/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:2007/07/21(土) 02:52:13 ID:/2A9wEhM
MPCはHomecinema 1.0.8.0です。

295 :名無しさん@編集中:2007/07/21(土) 17:00:44 ID:X9tNrxTT
>>293
確かXPのVMRとかVMR9ってBT.601専用だったと思う。
VistaのEVRはBT.601とBT.709の両方対応していたと思うよ。


296 :名無しさん@編集中:2007/07/22(日) 12:44:58 ID:o66TfgWH
>>295
確かにVistaだとBT.601とBT.709に対応しているみたいだけど、まだドライバーが安定してないっぽい。


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

298 :名無しさん@編集中:2007/07/25(水) 16:48:59 ID: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 :名無しさん@編集中:2007/07/26(木) 22:10:33 ID: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 :名無しさん@編集中:2007/07/27(金) 02:46:34 ID: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 :名無しさん@編集中:2007/07/27(金) 05:29:16 ID:VbhM82UL
最近変なのが住み着いたんだね、このスレ

302 :名無しさん@編集中:2007/07/28(土) 02:06:51 ID:kpavWSQ5
>>301
ん?>280のことか?


303 :名無しさん@編集中:2007/08/03(金) 16:05:35 ID:Nzw2XfB2
PCをHDMIでフルHDのTVにつなぐ場合、PCではYC伸張するべき?しないべき?
VistaにCatalyst 7.7入れたらYC伸張しなくなった、これはバグ?それとも仕様?


304 :名無しさん@編集中:2007/08/06(月) 13:00:24 ID:CbFoNtus
>>303
たぶんね、もうDisplayPortが出ないとどうにもならないかも。
HDMIって家電用のガチガチ企画っていうし。


305 :名無しさん@編集中:2007/08/08(水) 02:28:08 ID: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)

かwスマソwww


306 :名無しさん@編集中:2007/08/08(水) 03:25:49 ID:D2kdxwUa
見慣れたYV12での24ビット騒動か

307 :299:2007/08/09(木) 18:41:00 ID:z8uLSEhi
>>300
返信が遅れてしまって申し訳ありません。

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

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

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

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

308 :名無しさん@編集中:2007/08/10(金) 01:53:43 ID:BNucx8Ny
>>307
ラデスレによるとラデの最新ドライバはかなりおかしいみたいだよ。
7.6まではオーバーレイ、VMR9とEVRは伸張ON。
7.7ではオーバーレイが伸張ON、VMR9とEVRは伸張OFF。


309 :名無しさん@編集中:2007/08/16(木) 16:17:10 ID:+STcBzPQ
>>308
ラデスレより
http://pc11.2ch.net/test/read.cgi/jisaku/1186755639/337


310 :名無しさん@編集中:2007/08/22(水) 00:47:30 ID:Tr6RwzoJ
>>309
ゲフォ用の設定もよろしこ


311 :名無しさん@編集中:2007/08/29(水) 17:48:43 ID:or3/ZWgR
で、YC伸張するのしないのどっちよ、このスレ的には。

312 :名無しさん@編集中:2007/08/29(水) 18:05:40 ID:87P8S1R8
バカ来た

313 :名無しさん@編集中:2007/08/30(木) 00:02:16 ID:ZMFJt0vs
伸張するしないとは無縁の世界を構築せよという結論ですよ。

314 :名無しさん@編集中:2007/08/30(木) 17:12:54 ID:G2FzpI0C
>>312
じゃああんたはどっち派よw

YC伸張する ノ


315 :名無しさん@編集中:2007/09/09(日) 07:15:43 ID: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 :名無しさん@編集中:2007/09/09(日) 17:17:44 ID:+XcDO3KJ
>>315
GJ!

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


317 :名無しさん@編集中:2007/09/09(日) 18:43:27 ID: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 :名無しさん@編集中:2007/09/12(水) 06:20:20 ID: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 :名無しさん@編集中:2007/09/12(水) 18:26:35 ID:7UEThZyN
>>318
キャプチャー時に0-255に伸張されていて基準白が255になっているってこと?
それはキャプチャーデバイスがおかしいね。
基本はキャプチャー時は16-235で再生時に伸張して0-255。
0-235ってのもありだけど、ITUとかで定義されてないからあんまり誰もやりたがらないよね。
↑の方に色々とヒントになりそうなこと書いているけど。


320 :名無しさん@編集中:2007/09/12(水) 19:23:47 ID:h+jsmPMQ
>>319
レスありがとうございます。
モンスターXの画像がなぜかコントラストが強かったので波形プラグインで色々調べてたらそうなってました。
D3キャプという特殊性からくるためかな?しかもカラーバー入れてオートゲイン働かせるとYゲインが基準よりデカめに調整されるので
ここでもコントラストがでかくなる要因があった。PV3はどうなってるんだろう。

321 :名無しさん@編集中:2007/09/13(木) 01:24:23 ID:GUwd5cmM
>>320
コンポジットだろうとコンポーネントだろうとHDMIであろうと、DVI以外のときは入力は16-235でキャプチャーされるべきだね。
一部のカードはあらかじめYC伸張するという糞仕様をデフォルトにしてるな。


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

323 :名無しさん@編集中:2007/09/13(木) 14:45:34 ID:GUwd5cmM
>>322
そもそもなんで途中か最後にRGBに変換してるんだろ?
ずっとYUVのままならYC伸張もなにもいらないのに。


324 :名無しさん@編集中:2007/09/13(木) 18:54:41 ID:8ugE1STt
>>323
それって出力までTVで見なさいよってこと?

325 :名無しさん@編集中:2007/09/13(木) 21:24:44 ID:/NoMQh50
グラボに直接YUVデータ流し込めば?

326 :名無しさん@編集中:2007/09/13(木) 21:50:24 ID:uoV1Y7YI
>>323
勉強不足でおっしゃる意味がわからんのですが ^^;
とうぜん、エンコ自体はYUV(YUY2)で通してます。
RGBへ変換しているのはチェックのためにAVIUTL+波形表示プラグインで開くときだけです。
>>323さんがおっしゃるのは、BT709のまますれば?って言ってるんですの?

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

327 :名無しさん@編集中:2007/09/14(金) 00:42:13 ID:0L3PidzA
波形表示はYC2のまま表示できるじゃん。

328 :名無しさん@編集中:2007/09/14(金) 00:51:18 ID:Gooqaxlg
>>326
>とうぜん、エンコ自体はYUV(YUY2)で通してます。
ってことはどこで伸張されてるの?
だってYPbPr→YUY2なら伸張関係ないはず。
どこかにYUV→RGBがなければ輝度そのものはYPbPrのソースのままのはず。


329 :名無しさん@編集中:2007/09/14(金) 01:15:25 ID:4FkTMcTk
書き方が悪いのかなぁ・・
キャプボのデフォが0-255でキャプされていて
それを変則Y0-235に調整した場合Pb、Prはどうしたら良いのかって事が元々の質問の趣旨だったんですが・・

330 :名無しさん@編集中:2007/09/14(金) 01:19:25 ID:/oxrRaau
色差も0-255でキャプされんの?

331 :名無しさん@編集中:2007/09/14(金) 01:20:51 ID:4FkTMcTk
そうです

332 :名無しさん@編集中:2007/09/14(金) 01:30:30 ID:/oxrRaau
もうデフォで妥協したら?0-235と言ってもそのままじゃ使えないし、とは言え調整は容易ではないし。

333 :名無しさん@編集中:2007/09/14(金) 01:50:44 ID:4FkTMcTk
調整自体は意外と簡単にできるので苦にはならないんですが ^^;
一応参考までに
http://www.borujoa.org/upload/source/upload14534.zip

334 :名無しさん@編集中:2007/09/14(金) 16:26:43 ID:Gooqaxlg
>>329
>キャプボのデフォが0-255でキャプされていて
だからこれが糞だって。
IREレベルのYPbPrをデジタルのYCbCrにするときに白黒のリファレンスが16、235になるようにデジタル化するのが普通。
デジタル化されたときに既に0-255になってたら駄目駄目。


335 :名無しさん@編集中:2007/09/15(土) 02:08:22 ID:nHDpgRGI
>>334
そうなんだけど、PV3のソース見たらこっちもデフォで0-255になってましたねぇ
モンスターXは一応プレビュー用と言うことで売ってますのでこれも仕様かとは思いますけどねw
ただ、モンスターXスレ見てても誰もこのことに言及してないのが不思議だな。

336 :名無しさん@編集中:2007/09/15(土) 03:15:50 ID:qjkrcvQt
白黒リファレンスが16、235で調整されてて
それを超える範囲も一応記録してるんじゃまいか?

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

337 :336:2007/09/15(土) 03:21:00 ID:qjkrcvQt
あ、何か勘違いしてるかも
聞き流して下さいな

338 :名無しさん@編集中:2007/09/15(土) 17:36:02 ID:ZK57mHoD
>>335
揚げ足取るつもりはないけど。
プレビュー時にYUV→RGB変換を行うのはモンスターX?それともビデオカード?
ビデオカードならYC伸張されているデータをさらにYC伸張されてしまって黒と白が飛んじゃうよ。
だから、記録時はYC伸張しない、再生時にYC伸張する。データはYC伸張しないで保持。


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

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

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


341 :名無しさん@編集中:2007/09/16(日) 07:57:46 ID:Xe+cQNMU
0-255だと当然、16-235より綺麗なグラデーションになるからね
再縁故前提な設定な気がしないでもない

342 :名無しさん@編集中:2007/09/16(日) 12:41:51 ID:YFlcdrm9
>>341
は?取り込むときにソースが16-235に正規化されているんだから
それを変換するときに0-255に伸張したらグラデェーションは変わらないか、
変換誤差のために16-235に変換するより劣るぜ。
0-255にする利点は標準黒と白をRGBの黒と白にマッピングできるということだけなんだが。


343 :名無しさん@編集中:2007/09/16(日) 15:50:57 ID:QzOecP32
MonXのフルスケールが気に入らないならキャプった後に編集段階で修正するんではダメなのか?
キャプ段階でやるのとどういう違いが出るかは分からないが。

344 :名無しさん@編集中:2007/09/16(日) 18:13:15 ID:uvDRGnda
楽しそうなので上げときますね

345 :名無しさん@編集中:2007/09/17(月) 03:03:05 ID:RM/ZqUvR
>>343
キャップした段階で伸張されてしまっていたら0-15と236-255のデータがなくなってしまっているのだが。
0-15はまあ良いとしてもハイデフソースとかだと236-255は普通に使っている。


346 :343:2007/09/17(月) 03:10:15 ID:09CdCSIN
それは分かってる。そういうことじゃなくてボードがデフォで伸張してしまうのだったら
いくらMonster-X Setting Utilityで16-235になるように設定調整しても意味ないんじゃね?ってこと。

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

347 :名無しさん@編集中:2007/09/17(月) 09:16:33 ID:vU02pj/E
>>346
意味はあるよ。ちゃんとモンXではY100%輝度以上も出力している。
モンX標準のPIC MJPEGの設定は100%以上と0以下は問答無用にカットされちゃうので
余計に意味が出てくる。

348 :名無しさん@編集中:2007/09/17(月) 14:56:35 ID:09CdCSIN
なるほど参考になった。内部的にはどうなってるんだろう。
一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか・・・

349 :名無しさん@編集中:2007/09/17(月) 15:51:26 ID:RM/ZqUvR
>>348
もともとのデータは16-235と取り込んでるはずだから、16-235にすればそのままになるんじゃね?
いずれにせよ0-255は取り込みようじゃなくてプレビュー用と思うけど。


350 :名無しさん@編集中:2007/09/17(月) 20:53:46 ID:kX/QPJjZ
>>348,349
内部的にも何もそもそものデータがアナログ信号なんだから
A/Dがどの範囲でデジタル化するかって事だけでしょう。

351 :名無しさん@編集中:2007/09/18(火) 01:42:36 ID:ZHyG5t9G
>>350
ずっとその話をしているんだがw


352 :名無しさん@編集中:2007/09/18(火) 02:22:13 ID:X+S8a+zv
わかってないのがいるようだから
>>349
>一回伸張したものを16-235にしているのか、余計な工程を挟まず普通にストレートで16-235として取り込んでいるのか・・・
余計な工程なんてない。A/Dはただ単に決められた値と解像度で量子化しているだけ。
100%輝度が255と設定されたらそうしているだけ。235でも同じ。

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

353 :名無しさん@編集中:2007/09/18(火) 16:02:19 ID:ZHyG5t9G
>>352
A/Dで16-235と0-255に選択出来るやつもあるが何か?
ようはどうでもいい話で、取り込み時は16-235にするでFAなんだって。
で、再生時に必要に応じて16-235と0-255を切り替える。
普通はPCモニターだから0-255に伸張するで正解。


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

355 :名無しさん@編集中:2007/09/19(水) 06:09:31 ID: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. YPbPrゲイン調整フィルタで、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 :名無しさん@編集中:2007/09/19(水) 17:55:27 ID:Wtwyot7W
>>354
>0-255で最初から記録することもありだろう
ってことは基準黒のアナログレベルをデジタルの0、基準白のアナログレベルをデジタルの255にするって事?
つまり、16-235のデジタルを伸張して0-255にするんじゃなくて、アナログから一発で0-255のデジタルにするって事?
そんなのあんまり聞いたことないけど。。。


357 :名無しさん@編集中:2007/09/20(木) 03:15:46 ID:fRgafxj8
>>356
>16-235のデジタルを伸張して0-255にするんじゃなくて
エンコ時に0-255に伸張する人なら最初から0-255へ伸張するのも有りではと言うこと。
別にそれを人に推奨するつもりはないが、自分のシステムがどういう挙動をするのかわかっている人なら、
おかしな考え方でもないと思うがね。

358 :名無しさん@編集中:2007/09/20(木) 03:39:49 ID:ptE2UkfB
うちではMonsterXの初期設定&オートゲイン、オートオフセットONにすると
0%が0、100%が235でキャプチャされる(PIC M-JPEGで)。100%を超えるのは
235-255の範囲に入ってる。100%が255にはなってないみたいだけど。

359 :名無しさん@編集中:2007/09/20(木) 04:10:13 ID:Xs8FzPgb
うちのもhuffyuvで、ほぼそんな感じ。1個前のドライバにて。

360 :名無しさん@編集中:2007/09/20(木) 06:08:48 ID:2d42orMe
入力機器によって違うのかもね。
AG、AO入れてるとうちでは(RD-E300)Y-0%は0 Y-100%は255以上になるなぁ・・
少なくともゲインだけは弄らないとコントラストがつきすぎる。

361 :名無しさん@編集中:2007/09/20(木) 14:12:29 ID:c/y0B0Ek
>>358
AGとAOって結構賢いんだな。0-235なら完璧じゃね?


362 :名無しさん@編集中:2007/09/20(木) 19:23:18 ID:A9uhv/26
>>361
カラーバー入れている限りはAG,AFは結構かしこいよ。
ただ、普段の映像を入れてどうかは別問題。
つか、0-235で完璧って・・・・^^;

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

363 :358:2007/09/20(木) 19:38:38 ID:lWsziCi4
>>362 カラーバーでなら、PbPrの色差100%と-100%の値は読めるかもですが
通常の映像ではどうやって読んだら良いですか?

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

364 :名無しさん@編集中:2007/09/20(木) 21:34:33 ID:1UPYTeI8
ならカラーバー入れてみてくださいな。
オートだから当然入力画像によってゲインやオフセットが上下するんだからw
普通0%輝度がY0になってるんなら、100%輝度は255が標準ですよ。
上の方で意図的に0-235にするとどうなるかって事を言ってた人もいたけどね。


365 :358:2007/09/20(木) 22:10:08 ID:ptE2UkfB
ttp://www11.axfc.net/uploader/20/so/He_34743.zip.html
monx

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

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

366 :名無しさん@編集中:2007/09/21(金) 02:16:17 ID:K8jsJkUS
>>365
HD素材なら基準黒を0、基準白を235でαの部分のいわゆるスーパーホワイトを236-255にするのが良いかと。


367 :名無しさん@編集中:2007/09/21(金) 06:53:58 ID:oDo/VOx9
>>366
なんで0-235なの??
その際のPbPrはどっちに合わすの?

368 :名無しさん@編集中:2007/09/21(金) 07:11:16 ID:oDo/VOx9
>>365
Y0-235になってるねぇ・・・うちではデフォのAG、AO入れてると
Yは0-255ちょいオーバーになるけどねぇ
個体差なのか、うちがおかしいだけなのか、入力機器によって違うのか・・・
PbPrは中間の±242あたりになってるね。

369 :名無しさん@編集中:2007/09/25(火) 00:05:04 ID:qT59KP4m
>0-235

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

370 :名無しさん@編集中:2007/09/25(火) 00:47:10 ID:uWE59oxC
>>369
16-235と0-255は標準化されているけど、両方とも問題あり。
ようは0-16→0にしたいけど235-255は保持したいということで0-235。


371 :名無しさん@編集中:2007/09/25(火) 02:50:03 ID:Czk3k+G9
xvYCC規格とかが関係してるのかのう…

372 :名無しさん@編集中:2007/09/25(火) 11:47:42 ID:3du+U6wn
>>370
その考え方はおかしいよ。
100%以上0%以下をカットしないコーデックだっていっぱいあるんだから、気になるならそれ使えば良いだけだし
だいたいそれしちゃうと、思いっきり全体が暗くなるじゃん。
それでなくてもストレート変換された時点でTVよりずいぶん暗くなっているんだから。

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


374 :名無しさん@編集中:2007/09/25(火) 17:34:28 ID:peFtJ/TZ
まぁ自分が0-235で良いって言うんだからそれはそれで良いとは思うけど
ここで断言的に書くのはよくないと思うな。
やっぱり基本は16-235なんだからね。
しかも、PCのVGAドライバもコーデックもすべて16-235を基準として設計されているわけで
独自設計された家電を持ち出されても説得力はないと思うよ。

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


376 :名無しさん@編集中:2007/09/25(火) 18:49:34 ID:peFtJ/TZ
だから、何をやりたいのかは理解できていますよ。w
そんなに挑戦的に書かれなくてもね ^^;
でもそれはあなたの考え方なんだから、あまり押しつけるのはよくないんでないの?って言っているだけ。
だいたい、YC伸張するドライバではそれしちゃうとダブル伸張になるでしょ?白側は良いとしても黒側が潰れちゃうよね?
YC伸張しない場合で、0-255で記録されていても、コーデックによっては255オーバーも記録できているわけだから
再生時の設定でもスパーホワイトの表示は可能だしね。
それぞれを理解できている人がやるのは別にかまわないけど、それが絶対とは言えないでしょ?環境にもよるでしょってこと。
わかってもらえたかな?

377 :名無しさん@編集中:2007/09/26(水) 02:38:59 ID:Vc7YBhsu
>>375
>>376
話がかみ合ってないだけだろ。
>375は変換そのものに関して話しているみたいだからドライバ伸張の話だろ?
>376はどうもコーデックとドライバーを混ぜくちゃにしているみたいだな。大体、今時はコーデックでは伸張なんかしないよ。コーデックはYUVカラースペースのままだから伸張は関係ない。コーデックがRGB変換するってかなり古い知識だと思うぞ。


378 :名無しさん@編集中:2007/09/28(金) 15:26:08 ID: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    l     ノ


379 :名無しさん@編集中:2007/10/08(月) 08:37:53 ID:7U//T957
何このマリオ

380 :名無しさん@編集中:2007/11/06(火) 19:03:56 ID:7MSa3azk
吉井さんだよ

381 :名無しさん@編集中:2007/12/17(月) 09:10:54 ID:r6k/Mv7w
VistaSP1+NvidiaドライバーでYC伸張してくれるようになったお。


382 :名無しさん@編集中:2008/01/03(木) 09:33:36 ID:kUstuUcA
age

383 :名無しさん@編集中:2008/01/07(月) 15:26:39 ID:jatr8V+y
>>381
本当だ!試しにSP1の評価版と最新の169.25デトネイタを入れたらYC伸張する!

384 :名無しさん@編集中:2008/01/18(金) 19:13:18 ID:dIqZ1VjC
>>383
ラデオンだとSP1入れても未だYC伸張してくれない。ジーフォースに買い換えないと駄目?ラデオンは負け組みって事?

385 :名無しさん@編集中:2008/01/20(日) 06:30:50 ID:qKn4NFML
>>384
現状だとAMDが死に体だからATIは負け組みかもね。。。
今後はIntel vs NVidiaでATIはS3とかMatrox化していく気がする。。。


386 :名無しさん@編集中:2008/01/20(日) 16:55:32 ID:UGOZQUm7
ここDTV板だろ・・・この期に及んでnVidiaがいいとか、ラデがYC伸張しないとかドンだけでたらめなんだよwwww

387 :名無しさん@編集中:2008/01/21(月) 14:43:08 ID:7nQnxAf7
>>386
実際、YC伸張にすぐさま対応したのはnVidia、AMDはすでに会社そのものがヤバイだろw


388 :名無しさん@編集中:2008/01/21(月) 16:38:11 ID:3bbyPTda
>>387
おいおいwwww何言っても良いが嘘はいかんよ、嘘はwwww

389 :名無しさん@編集中:2008/01/22(火) 03:41:52 ID:/zpg/jzB
>>388
誰も嘘言ってないけどな。。。
会社の時価総額でもAMD(ATIを含め)はnVidiaの数分の一になってるって知ってるか?
NASDAQで過去一年間くらいの株価見てみろ。


390 :名無しさん@編集中:2008/01/22(火) 04:06:29 ID:Fxbgf48Q
>>389
>>388がつついてるのはそこじゃないだろ
>実際、YC伸張にすぐさま対応したのはnVidia
こっちだろ。どんな認識でこんな大嘘言えるのか俺も思うよ。

391 :名無しさん@編集中:2008/01/22(火) 16:56:09 ID:/zpg/jzB
>>390
nvのVistaドライバースレで一ヶ月以上前に報告上がってたよ。
確か169.1xとVistaSP1 BetaでYC伸張がされるようになったとか。


392 :名無しさん@編集中:2008/01/22(火) 17:24:39 ID:kxE/tNIn
俺の知っている限りでは
Radeonは7000番台の時代からYC伸張に対応している。
Gefoeceはドライバの84.21からYC伸張できるようになっている。
しかも動画に関してはつい最近までRadeonが2歩先を行っていた。
(ドライバの100番台に入ってやっとだいぶん追いついてきたようだけどまだまだだね。)
3Dに関しては逆の評価みたいだね。使い物にならんのがラデみたいだ。

393 :名無しさん@編集中:2008/01/22(火) 17:26:09 ID:CkEl96Ph
( ゚д゚ )

394 :名無しさん@編集中:2008/01/23(水) 03:01:22 ID:9vQAApKT
>>392
君のは大昔のオーバーレイが全盛だったときの話じゃ。。。
Vistaの話題なんだから非オーバーレイについてに決まっていると思うが?


395 :名無しさん@編集中:2008/01/27(日) 18:35:51 ID:zFIAvNr0
いまだにオーバーレイしてますが

396 :名無しさん@編集中:2008/02/03(日) 19:10:02 ID:Z+V8klSw
Gefoeceで動画ってどんだけマゾいんだよw

397 :名無しさん@編集中:2008/02/05(火) 15:18:27 ID:hZhMjXov
>>396
オーバーレイの時代はかなり微妙だったけど、非オーバーレイのVistaになってからは下手するとATIよりも良いという評価も聞かれるけどな。


398 :名無しさん@編集中:2008/02/05(火) 22:56:31 ID:7FvsqN7X
すまん便乗で。
XPのオーバーレイ環境下だと今でもnVidiaはいまいちくんなの?

399 :名無しさん@編集中:2008/02/06(水) 03:41:07 ID:MlrDLIgF
>>394
大昔ってXPのVMR7もオーバーレイミキサ使っているし、だいたいEVRを使っているユーザーが今いくらくらいいるとお思ってるんだ?

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

400 :名無しさん@編集中:2008/02/06(水) 17:55:38 ID:VbrsKj9X
>>399
お前Vista使ってないのばればれ。
VistaのメディアプレイヤーとかメディアセンターはEVRだし、PowerDVD7もEVRだぞ。
いつまでも食わず嫌いだから遅れるんだよw


401 :名無しさん@編集中:2008/02/09(土) 10:17:23 ID:I/YvmMW0
>>397
それはそうだね。
あとは色空間変換やCRT使いの人向けにDACの性能が良くなれば、
nVIDIAは駄目という声も減ると思うけど。

402 :名無しさん@編集中:2008/02/09(土) 13:23:00 ID:HbQT2ot8
RADEONはとりあえず"UseBT601CSC"="1"つっこんどきゃY/C伸張するんじゃねーの
Vistaは知らんけど

403 :名無しさん@編集中:2008/02/10(日) 06:19:16 ID:6OTEFHQO
XPでnvdiaグラうボ使ってる人向けの画質設定晒しとく
94.24で確認したから100以降のドライバは知らん

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

これでまともな色になる

404 :名無しさん@編集中:2008/02/10(日) 14:30:56 ID:Y3N12W/F
>>402
他スレで散々既出だがVistaにはそのレジストリは存在してないし、同様のNVidiaのやつもXPのみ。

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


405 :名無しさん@編集中:2008/02/14(木) 17:19:11 ID:7GXiyzhX
Vista SP1+ゲフォ最新βドライバーだとPowerDVDなんかもYC伸張するようになるな。
いったいどれが今までバグってたのか、全くプンスカ。


406 :名無しさん@編集中:2008/03/04(火) 10:33:49 ID:abB8HAgX
nVIDIAチップ特有の白っぽくてパサパサした色合いがちょっと苦手
ゲームやるぶんにはnVIDIAが良いんだろうけど、ATIの色味に慣れちゃうとなかなか抜け出せないわ
そろそろ買い替え予定なんで、Vista環境も考えてみるか

407 :名無しさん@編集中:2008/03/04(火) 11:05:55 ID:xYUVKfTT
nvidiaは9000番台の次から動画関連に大幅に手を入れるって言ってる
今うんこなのは当たり前w

408 :名無しさん@編集中:2008/03/26(水) 15:39:58 ID: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 :名無しさん@編集中:2008/03/26(水) 16:37:00 ID:Z2J+WSKO
SDに変換する時はColormatrix等でBT.601にする必要があるな。

410 :名無しさん@編集中:2008/03/26(水) 16:51:59 ID:0JfwX7St
DVDもBT.601ですので、HDキャプチャしてDVD出力する場合も変換しないとおかしくなりますね。
DVDレコもちゃんと変換しているみたいです。
あとチューナーのコンポーネント出力はBT.709で出していますが、S端子はちゃんとBT.601に変換されていました。

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

411 :名無しさん@編集中:2008/03/28(金) 03:49:08 ID:DL/Lx8g8
>>408
>上の方に出ていた、解像度によってBT.601かBT.709を判断しているようですね。
Vista+EVRを使えばDXVA2経由でBT.601とBT.709をドライバーに指示できるみたいよ。


412 :名無しさん@編集中:2008/03/28(金) 04:14:15 ID:qRjTrz58
BT.709のカラーバーというものは存在しないんだけど・・・
色域がBT.709になるかBT.601になるかはRGBへマッピングするときに決めるだけ
よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど

413 :名無しさん@編集中:2008/03/28(金) 18:10:59 ID:DL/Lx8g8
>>412
>よって解像度によってドライバが画像サイズによって変えるのは至極当たり前の仕様なんだけど
これはちょっと誤解を生むよ。HD放送の合間のSDは解像度がHDじゃなくてもBT.709になっているのは常識。
アプリがコンテンツの状況に応じてドライバーに変換関数を知らせた方が正確。


414 :名無しさん@編集中:2008/03/28(金) 18:13:58 ID:TXNosBRg
私はFriioを持っていないから確認できませんが、日本のSDのデジタル放送のcolorimetryを
DGIndexはきちんとBT.709だと判定できるのだろうか。

415 :名無しさん@編集中:2008/03/28(金) 19:10:24 ID:wG38zexJ
SDってBS1,2か?教育も一部時間はSDか。

416 :名無しさん@編集中:2008/03/31(月) 07:45:51 ID:ZNpWyTs8
どっかで見たけど、NHKとかのデジタルSDはmatrix_coefficientが省略されてるみたい。
でもテレビだとBT.709として処理してるようだ。

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

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

417 :名無しさん@編集中:2008/03/31(月) 07:57:55 ID:byVcSBaz
BT.601 = BT.470-2(DGIndexの自動判定) = SMPTE 170Mだから、それだったらやはり
ColorMatrix(mode="Rec.709->Rec.601",interlaced=true)とでも書いてBT.601に変換する必要があるな。

418 :名無しさん@編集中:2008/04/04(金) 21:51:39 ID:59KSVULO
よくわからんけど、
CCEやTMPGで709→601にするときはどうすればいいの?
0-255か16-235しかないよ。

419 :名無しさん@編集中:2008/04/05(土) 02:52:17 ID:fbi2C0NX
>>418
いいよおまいは話に参加しなくても

420 :名無しさん@編集中:2008/04/21(月) 15:26:15 ID:gMV7SetX
BT変換とTVスケールへの伸張はどっちを先にやったほうがいいのでしょうか

421 :名無しさん@編集中:2008/05/24(土) 20:32:12 ID: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 :名無しさん@編集中:2008/05/24(土) 20:49:02 ID:si+3EZcc
>>421
DGMPGDec 1.5.0では変更された。
http://forum.doom9.org/showthread.php?p=1084980#post1084980

423 :名無しさん@編集中:2008/05/24(土) 21:06:55 ID:EW5fNDtN
へー、そーなんだ知らんかった。ゴメン

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

424 :名無しさん@編集中:2008/05/24(土) 21:24:16 ID: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
http://forum.doom9.org/showthread.php?t=131169

425 :名無しさん@編集中:2008/05/24(土) 22:31:12 ID:EW5fNDtN
> MPEG-2 Video(H.262)の標準がBT.709でもDVD VideoのそれはBT.601だったりややこしい様だ。
そんなにややこしいなら尚更Unspecifiedを返すべきなんじゃ?
DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい

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


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

426 :名無しさん@編集中:2008/05/24(土) 22:41:27 ID:si+3EZcc
>DGIndexが勝手に指定してるだけなのかソースが指定してるのかいちいち調べるのが糞だるい

Colorimetry: BT.470-2 B,G*

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

427 :名無しさん@編集中:2008/05/24(土) 23:40:16 ID:KJ5Y8Mo3
TSソースで試したら、HDはBT.709になったがSDはBT.470-2 B,G*になった。
色見るとどちらもBT.709なのに、SDでは指定されてないのかな、謎だ。

428 :名無しさん@編集中:2008/08/09(土) 22:53:47 ID:rSmXo3C9
PALなら5:1.5:1.5ですね。

429 :名無しさん@編集中:2008/08/28(木) 17:54:22 ID:DplL5tuS
 

430 :名無しさん@編集中:2008/08/31(日) 04:04:32 ID: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 :名無しさん@編集中:2008/08/31(日) 09:50:22 ID:VJQGf6bX
>>430
うちもそうなるよ

432 :名無しさん@編集中:2008/08/31(日) 11:56:42 ID:apcIcXt4
PC(0-255)ってことはストレート変換、つまり伸張しない。
TVなら黒を16、白を235としてPCスケールに伸張するっていう意味なんだが。
理解の仕方が反対だよ。

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

433 :名無しさん@編集中:2008/09/04(木) 18:49:30 ID:qGh5AYHA
RGB24のソースをAVISynthを使ってカット編集して
YV12変換してx264でエンコードするのと
AVIUtlを編集に使ってRGB24→YUY2→YV12と変換するのでは
やはりAVIUtl経由は劣化してしまいますか?

434 :名無しさん@編集中:2008/09/04(木) 19:20:34 ID:Ot5eU7BW
AviUtl本体にはYV12へ変換する機能は無い。

435 :名無しさん@編集中:2008/09/04(木) 19:43:56 ID:qGh5AYHA
言葉足らずでした
AVIUtlの拡張x264出力プラグインに、
x264に渡す前にYV12に変換する機能がついてるんです

436 :名無しさん@編集中:2008/09/04(木) 23:59:11 ID:R68KTdq0
AviUtlでの編集は正確には
RGB24>YC48(これで編集)>YUY2>YV12
色変換だけ考えたらRGB24>YV12と違いはないので
同じだと思うけどAviUtlはフィルタ精度が12bitだから
劣化の具合で言ったら理論的にはUtlのほうが少ない。
つーても肉眼ではわからんだろ。

437 :名無しさん@編集中:2008/09/05(金) 02:49:56 ID:Gk5w7tAl
カット編集としか書いてないから、違いはないんじゃないか?

438 :435:2008/09/05(金) 04:13:38 ID:TbXX27C5
どうもありがとう
フィルタはかけないけど、かけた場合はフィルタの精度も重要ですね
回答してくれた人愛します<3

439 :名無しさん@編集中:2008/09/13(土) 14:13:01 ID:21caLQWg
>>432
dgindex150を使用して、PC scaleで出力してエンコーダに渡せばストレート変換?
YV12ソース>dgindex(PCscale)>エンコーダ(YV12)出力
これで良いのでしょうか?

440 :名無しさん@編集中:2008/09/19(金) 05:24:40 ID:KHzW8kGD
>>439
avisynth経由の話ならdgindexの設定は関係ない
その設定は使われないので意識する必要なし

441 :名無しさん@編集中:2008/09/19(金) 10:21:34 ID:E9nS3Lq4
dgindex のPC/TVscaleの設定はVFW経由の場合にのみ有効って認識でいい
たぶん。

442 :名無しさん@編集中:2008/09/20(土) 21:14:25 ID:fAg2w24o
今まで9600GT使っててHD 4850に交換したんだけど、RADEONってYC伸張しないんだな
WMV9でYC伸張でエンコした動画ずっと見てたからなんか変な感じ
OSはVistaSP1

443 :名無しさん@編集中:2008/09/20(土) 21:59:27 ID:CNZMlSyU
>>442が今時まれに見る情報弱者だということは理解した

444 :sage:2008/09/20(土) 21:59:58 ID:SyoX7pM0
>>442
ATI HD Registry Tweaks

445 :名無しさん@編集中:2008/09/21(日) 14:02:39 ID:LTBBnYvd
ビデオカードにYC伸張やらせるなんてアホらしい
動画側にやらせるべき

446 :名無しさん@編集中:2008/09/21(日) 14:05:56 ID:Ro0+EH/h
それだとTVに写すとき困るし〜!

447 :名無しさん@編集中:2008/09/21(日) 17:57:54 ID:g12aJ8Ao
>>445
データはストレート保存で再生時に伸張。これ常識。

448 :名無しさん@編集中:2008/09/21(日) 20:51:09 ID:WS3/bMbQ
>>445
DVDは伸張されてないんですが、それもアホらしんですね
もう何もPCでは見られませんね
伸張して保存するなんていつの時代の話だよ
変な流れを最初に作った諸悪の根源はnVIDIAなんだけどな

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

449 :名無しさん@編集中:2008/09/22(月) 02:37:13 ID:vL6DAe5x
Haali's Video Rendererはとても優秀

450 :名無しさん@編集中:2008/09/22(月) 21:48:39 ID:/OoVLfz9
NPC内臓のHaali使うと引き伸ばしの画像がおかしくなる。
おかしいというよりはリサイズが糞っぽい。
リサイズはffdshowに任せたほうがよさげ

451 :名無しさん@編集中:2008/09/22(月) 21:57:34 ID:/VyuUluT
NPCってなんれすか?

452 :名無しさん@編集中:2008/09/22(月) 23:17:29 ID:1A0Ol3pO
少し質問です。
まるも氏のm2vプラグインでストレート変換読み込みした場合と
DGIndexでPCスケールで読み込みをした場合に色合いがほぼ同じになります。

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

453 :名無しさん@編集中:2008/09/22(月) 23:27:35 ID:vL6DAe5x
VFAPIがややこしいのなら、DGDecode_mpeg2sourceでd2vを開けば、YV12のまま伸張も何もしない。

454 :名無しさん@編集中:2008/09/22(月) 23:43:43 ID:DIJGvtux
>>452
そもそもまるも氏のストレートとそうでないのとで色ちゃんと変わってる?
話を聞く限りまるも氏のプラグインでRGB展開してない気がするが

455 :名無しさん@編集中:2008/09/22(月) 23:57:35 ID:ARySuTFW
>>452
aviutlの仕様です

456 :名無しさん@編集中:2008/09/23(火) 08:33:42 ID:t2QFmLhW
m2v.auiはYUY2読み込み
readme読め

457 :名無しさん@編集中:2008/09/23(火) 17:12:30 ID:D66+eWYE
超初心者なのですが、伸張するっていうのは0-255なのか16-235のどっちなんでしょうか?
0-255の方が範囲が広いのでこっちにしたいのですが、伸張されるっていうのがどっちなのかわからなくて・・・
ちなみにここの話題とは全然違ってPS3をつないだモニタの設定でどっちにしたらいいのか迷っているからなんで・・・・

458 :名無しさん@編集中:2008/09/24(水) 02:27:37 ID:toi/BNHh
16-235としてPCスケールに伸張(0-255)
上に何度も書いてあるけど「伸張保存はするな」
って言っても色空間から理解する必要があるからなあ・・・
伸張云々よりも先にそこから勉強したほうがいいよ

459 :名無しさん@編集中:2008/09/26(金) 09:47:47 ID:d9xJhVIR
その前に8bit=255から理解する必要があるのでは?
そして次はYUVを勉強してBT.601を勉強してそれに今時はスーパーホワイト領域の事も考慮して・・・etc
最後は論文かけるようになるかもねw

460 :名無しさん@編集中:2008/09/26(金) 14:03:09 ID:EPyHUXU0
エンコ時に伸張するほうが精度が高いって知ってた?

461 :名無しさん@編集中:2008/09/26(金) 14:23:46 ID:mjIORAaH
>>460
マジで?
エンコ時なら8bit演算でしか伸張できないけど。
ちゃんとディザリングとかかけたりしてくれるソフト有るの?

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

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

462 :名無しさん@編集中:2008/09/26(金) 15:46:04 ID:Ux/K698u
>>460
どっちにしても大多数のコンテンツがストレート保存だから再生時に伸張するのがデファクトスタンダードである事に変わりない。
もはや精度がうんぬんという話は全く意味もないことだな。


463 :名無しさん@編集中:2008/09/26(金) 15:53:29 ID:gIV7Ydpv
昨今(と言っても相当昔から)の動画コーデックは、YUVも含めた上での圧縮。
エンコード時に伸張してやること自体がナンセンス。

464 :名無しさん@編集中:2008/09/26(金) 22:49:49 ID:pYp5CLLQ
伸張も圧縮もせず元のYUVをYUVのまま置いとくのが一番でしょ。

465 :名無しさん@編集中:2008/09/28(日) 19:29:53 ID:yzQFyw3r
初心者でもしスレ違いだったらすみませんが、詳しい方教えて下さい。

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

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

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

468 :名無しさん@編集中:2008/09/28(日) 22:15:57 ID:oGMa9b6c
>>467
液晶って家電のほうだよな?
家電でそういうミスはあんまり考えられない気もするんだけど・・・
うーむ、どうなんだろう。

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

470 :名無しさん@編集中:2008/10/14(火) 14:05:57 ID:v+GfvfiY
元に居たにいたスレで話していましたがスレ違なのでこちらに来ました。
DGIndexをTVスケールでVFAPI経由読み込みした際にYUVデータを維持したまま
読み込んだ画像に比べて色がかなり薄くなり疑問に思いました。
以下の画像を参照して下さい。

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

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

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

471 :名無しさん@編集中:2008/10/14(火) 14:09:39 ID:1ThNXYmm
YCbCrはTVスケール、RGBはPCスケールにするのが普通のやり方。

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

472 :名無しさん@編集中:2008/10/14(火) 14:30:31 ID:v+GfvfiY
d2vファイルをAviUtlで編集する場合、avsから読み込めば問題無しで
VFAPIを用いる場合はPCスケールにすればOKということ??

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

473 :名無しさん@編集中:2008/10/14(火) 14:36:09 ID:1ThNXYmm
1. DGIndexでd2vを作って、それを入力にavsを作る。
2. "x264.exe" --crf 20.0 --output "output.mp4" "input.avs"

474 :名無しさん@編集中:2008/10/14(火) 14:42:41 ID:v+GfvfiY
x264がYV12入力だからavsから直接やれば無問題ってことは解っていて
とても有りがたい返答ではあるのですが現在知りたいのは
DGIndexとAviUtlを用いた際の色の扱い方なので…。

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

475 :名無しさん@編集中:2008/10/14(火) 14:52:26 ID:1ThNXYmm
DGVfapi.vfpの色空間はRGB24で、RGBは一般的にPCスケールである事を前提として扱われる。

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

476 :名無しさん@編集中:2008/10/14(火) 17:50:08 ID:v+GfvfiY
あーなるほど。
漸く理解できました、本当ありがとう!

477 :名無しさん@編集中:2008/10/14(火) 18:04:11 ID: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 :名無しさん@編集中:2008/10/14(火) 18:04:43 ID:ULjBfQ5G
おそかったorz

479 :名無しさん@編集中:2008/10/14(火) 18:09:12 ID:v+GfvfiY
ご…ごめんなさい…。


480 :名無しさん@編集中:2008/10/14(火) 18:25:18 ID:1ThNXYmm
YV12とRGBの変換は、TV/PCスケールに加えて、BT.601/BT.709、
インターレース/プログレッシブをきちんと把握しないと、変な色になるからとても面倒くさい。

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

481 :名無しさん@編集中:2008/10/14(火) 19:52:24 ID:wMQpUmr7
俺みたないなお馬鹿はVFAPI経由させるなってことか

482 :名無しさん@編集中:2008/10/14(火) 22:56:39 ID:VCoPi0+g
動画を扱うこと自体をやめるべきでは

483 :名無しさん@編集中:2008/10/14(火) 23:10:23 ID:M0RbEkyM
自分で楽しむだけならいいんじゃね。

484 :名無しさん@編集中:2008/10/17(金) 08:25:45 ID:EbrZG3U2
>>477
>ソースがYUV: プレビューでY: 16-235, UV: 16-240をY: 0-255, UV: 0-255にしてからRGB: 0-255に変換、出力は変換なし
出力は変換なしってどういうことですか?
プレビュー(編集時)は伸張しているが、実際の出力は伸張していないという認識でいいのでしょうか?

485 :名無しさん@編集中:2008/10/17(金) 10:35:58 ID: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 :名無しさん@編集中:2008/10/17(金) 10:38:38 ID:2z8ZQ3vU
AviutlのプレビューはBT.601だから、
デジタル放送だと色がおかしくなるので注意ね

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

487 :名無しさん@編集中:2008/10/17(金) 10:56:02 ID:xMb2oRTj
HD->SDのエンコードにはBT.709->BT.601の変換が必須だけど、
UtlにはSynthのColorMatrixに相当するプラグインはあるの?

488 :名無しさん@編集中:2008/10/17(金) 11:00:34 ID:XaaXSGaQ
ttp://www.geocities.jp/aji_0/
あじさんとこの色域変換プラグインがそうじゃないかな

489 :名無しさん@編集中:2008/10/17(金) 11:07:25 ID:xMb2oRTj
どうもありがとう。

490 :名無しさん@編集中:2008/10/17(金) 13:16:20 ID: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 :名無しさん@編集中:2008/10/17(金) 18:34:24 ID:MRiUv4La
ROMってた初心者なんですが、検索して調べても混乱が増すばかり・・・

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

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

492 :名無しさん@編集中:2008/10/17(金) 20:09:27 ID: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 :名無しさん@編集中:2008/10/17(金) 20:23:21 ID:PpIpzRbE
おや、Makki氏降臨?

494 :491:2008/10/18(土) 02:13:30 ID:jPlvR2xo
>>492
レスありがとう。用事があってチェックが遅れてしまった。
非オーバーレイってことはMPCだとVMR9とかかな・・・

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

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

495 :名無しさん@編集中:2008/10/18(土) 02:20:58 ID:fL9tI0O9
>展開でTVスケールがPCスケールへ変化することがあるかどうか
スケール自体はかわらんだろ

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

496 :491:2008/10/18(土) 02:29:11 ID:jPlvR2xo
レスサンクス。
色空間は展開で要注意って認識でいいのかな。
いろいろごちゃごちゃしてしまって整理できず混乱してた。
ほんとありがとう。

497 :名無しさん@編集中:2008/10/18(土) 02:46:40 ID:HhiL0M+6
自分はこれを使って確かめている。
http://www.avisynth.info/?Histogram

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

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

498 :491:2008/10/18(土) 02:59:03 ID:jPlvR2xo
今までヒストグラムはRGB表示してた・・・
というかRGなんてこった。

>>

499 :491:2008/10/18(土) 03:01:32 ID:jPlvR2xo
ミスってしもたorz
今までヒストグラムはRGB表示してた・・・
というかYCbCr表示できたんだね、なんてこった。

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


500 :名無しさん@編集中:2008/10/31(金) 17:11:30 ID:yOSQ1IfA
今VMR9で伸張出来るのと出来ないのどっちの環境が多いんだろ

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


502 :名無しさん@編集中:2008/11/04(火) 23:40:56 ID:gfCUEmdh
もう色がおかしかったことがばれちゃってるのに
まだRADEONの色が正しい色と盲信してんのか。
しかもUVD2のダイナミックコントラストは
マッハバンドが出る低画質フィルタw

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


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

503 :名無しさん@編集中:2008/11/05(水) 01:59:21 ID:UKx9xgRC
つまり、プロだな
プロには、人と金は集まるモノ

504 :名無しさん@編集中:2008/11/05(水) 02:10:58 ID:56oSUSHU
いい加減に現実をみろよ、ビデオ編集ワークステーションはNVIDIA
http://www.thomson-canopus.jp/catalog/rexceed/rexceed_m500v_index.php

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

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


505 :名無しさん@編集中:2008/11/05(水) 22:00:21 ID:hw1NKaBq
そんな1企業の採用事例だけ示されてもな。
俺はどちらかに傾倒しているつもりはないが>>502>>504のほうがよっぽどnVIDIA信者に見える

506 :名無しさん@編集中:2008/11/05(水) 22:16:50 ID:mGEWq2RQ
Macは全部Geforceだし。

507 :名無しさん@編集中:2008/11/05(水) 23:08:26 ID:UKx9xgRC
>>505
オレにもそう見える。
nVIDIAなら全ておk!! みたいな過度の依存スタンスが、己の目を曇らせ、自らの審美眼を閉ざす

508 :名無しさん@編集中:2008/11/05(水) 23:21:22 ID:9MGwgADk
>>506
さらっと嘘つくなよ。

509 :名無しさん@編集中:2008/11/06(木) 14:20:45 ID:BAjQOfNE
最近あちこちで必死な書き込みよく見るし、NVIDIAも大変なんだな。

510 :名無しさん@編集中:2008/11/06(木) 15:11:56 ID:SYWy3NAB
PCゲーがコピー多すぎて下火になってコンシューマに以降してるからな。
これからは動画再生に強くないと一般のPCに積む意味が無くなるし。

511 :名無しさん@編集中:2008/11/09(日) 12:27:33 ID:oYmH7ZjY
だが動画再生についてはPS3が断トツな状況。

512 :名無しさん@編集中:2008/11/10(月) 01:16:01 ID:YR4fsrbM
消費電力ありえないから

513 :名無しさん@編集中:2008/11/10(月) 01:16:52 ID:ezZcxULD
Vistaから搭載されてるEVRを使ってセカンダリモニタで
再生させているけど、色変換がされないのは仕様?

514 :名無しさん@編集中:2008/11/10(月) 16:28:13 ID:DYj8Q7Um
>>513
色変換されなかったらテンでめちゃめちゃに見えると思うけど。
俺はGeForceだけどセカンダリモニタでメディアプレイヤー(EVRを使う)で再生しても問題なし。


515 :513:2008/11/10(月) 21:49:48 ID:ezZcxULD
>>514
色変換がされていないというより、無駄に明るくなってる感じ

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

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

516 :名無しさん@編集中:2009/01/25(日) 17:53:39 ID:9kWbJuXa
テスト

517 :名無しさん@編集中:2009/01/26(月) 00:20:06 ID:xXymHlkA
質問なんですが
DVD→DGindex→AVS(DGDecode)で24fps化→AviutlでCanopusDVコーデックに変換。
この手順だと余計なスケール変換を起こさずにストレート変換になっているのでしょうか。

518 :名無しさん@編集中:2009/01/26(月) 00:46:48 ID:HjGrvUZC
AVSにConvertToYUY2を入れてあれば色空間の変換による劣化はないが

519 :名無しさん@編集中:2009/01/26(月) 01:32:52 ID:xXymHlkA
DGDecode_mpeg2source("DVD.d2v")
ConvertToYUY2(interlaced=true)
IT(fps = 24, ref = "TOP", diMode = 0)

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

520 :名無しさん@編集中:2009/01/26(月) 05:52:49 ID:jgtFxFAw
ffdshowでYC伸張
http://replaymugen.seesaa.net/article/108512661.html

521 :名無しさん@編集中:2009/01/26(月) 14:09:55 ID:QrGS90t4
>>517
AviUtlの入力プラグインがAviSynth Script File Readerとかならいいんじゃないか
DGMpgDec とかもAVS読み込みできるがVFAPI経由でRGBに変換されてるから注意な

522 :名無しさん@編集中:2009/01/26(月) 14:18:40 ID:l1IkvcKA
最近エンコやりはじめたが、色空間難しいぜ。ちくしょう。

523 :名無しさん@編集中:2009/01/26(月) 18:48:36 ID:xXymHlkA
>>521
AviSynth Script File Readerを入れてなかったです。
これでようやくすっきりしました。

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

524 :名無しさん@編集中:2009/01/26(月) 23:35:48 ID:xXymHlkA
実際にエンコしてみたら今までに比べてかなり満足のいくものができた。

重ね重ねありがとう。

525 :名無しさん@編集中:2009/01/31(土) 22:01:33 ID:jB6dv5bG
YUY2で処理したBT.709のファイルをavisyunthでConvertToYV12する場合
ConvertToYV12()じゃ駄目?

526 :名無しさん@編集中:2009/01/31(土) 22:23:32 ID:nLahnMo0
ConvertToYV12するんだからConvertToYV12()するんだろ?

527 :名無しさん@編集中:2009/01/31(土) 23:12:46 ID:jB6dv5bG
判りづらくてすんまそん、ConvertToYV12(matrix="")で色空間指定しないと
bt601に変換されちゃうのかな?って事です。

528 :名無しさん@編集中:2009/01/31(土) 23:25:12 ID:Kgq3NFlB
YUY2→YV12なら関係ない。

529 :名無しさん@編集中:2009/02/01(日) 00:05:19 ID:SE2S103i
BT.601やらBT.709ってのはYUV>RGB変換式の違いなだけでデータの並びとかの
差異はない。だから少なくともYUV色空間内でそのような変換は起こりえない。

530 :名無しさん@編集中:2009/02/01(日) 01:19:35 ID:sBtIc6en
なる程RGB変換を挟まない場合は気にしなくていいんですね、
ありがとうございます。

531 :名無しさん@編集中:2009/02/05(木) 00:16:23 ID:HBNND2LJ
SD放送のTSもHDと同じくBT.709らしいけど、レコで出力したのをPV4でキャプった場合はどうなってるんだろうか。
レコがBT.601に変換したりしてるんだろうか。

532 :名無しさん@編集中:2009/02/05(木) 01:39:38 ID:Ably69zJ
レコによるんだろうが、
D1、D2出力するときはBT.601で
D3、D4出力するときはBT.709で
出力されるのが一般的だと思うが・・

533 :名無しさん@編集中:2009/02/05(木) 02:02:34 ID:HBNND2LJ
そーなのかーd

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

534 :名無しさん@編集中:2009/02/05(木) 03:12:02 ID:ewMuHAv/
3原色のパラメータの違いだって色域変換のテキストに書いてあるじゃん

535 :名無しさん@編集中:2009/02/05(木) 04:41:11 ID:HBNND2LJ
調べれば調べるほどわけわかめになってきた…
m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか?
されないならこの指定は何のためにあるのか?
元の YUV データを維持にして読み込んで色域変換で3原色を601にするのが正解?
AvisynthならColorMatrixでmode="Rec.709->Rec.601"?

536 :名無しさん@編集中:2009/02/05(木) 08:52:45 ID: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 :名無しさん@編集中:2009/02/05(木) 13:18:51 ID:ewMuHAv/
>>535
>m2v.auiでYUY2 色空間行列 (m2v.aui 用)をBT.709にして読み込めばちゃんと変換されるのか?
そのくらい自分で試したらわかるだろ常考

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

538 :名無しさん@編集中:2009/02/14(土) 11:20:20 ID:dw7BNvr7
じゃあ強引にBT709で作った規格外DVDはどうなるの?
(出来るのか?意味あるのか?というのは置いといて。)

539 :名無しさん@編集中:2009/02/16(月) 00:39:33 ID:DOFIC1hR
>>538
おまえは何言ってるんだ?YUVデータにbt.709もbt.601もないだろがww

540 :名無しさん@編集中:2009/02/20(金) 01:36:31 ID:iuyWOEIb
mp4の動画をffdshowで再生した時にオンスクリーンディスプレイで色空間を見たら
YV12,adjとなっていた。YV12は分かるとしてadjって何?

541 :名無しさん@編集中:2009/02/20(金) 03:08:27 ID:etoDEjkN
あじゃすとじゃね

542 :名無しさん@編集中:2009/02/22(日) 02:41:43 ID:geHe90rg
>>520
ちょっと微妙だな。せめて、ディスプレイの色温度ぐらい考慮しろよ・・・
白を基準に判別するなら。


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

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

545 :名無しさん@編集中:2009/02/23(月) 15:02:54 ID:1Fo5Bp0s
>>544
同意。

546 :名無しさん@編集中:2009/02/24(火) 00:48:41 ID:h6SdtFVk
否定してもいいが、それなりの色空間なんてないから既に手遅れだよ。
xvYCC非対応のほとんど全てのBDやHD放送の存在は放置しろって言ってる
ことになる。クリップしてるからHD放送の色が酷いことに気づいていないの?

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

547 :名無しさん@編集中:2009/02/24(火) 01:02:56 ID:L3cRA9fu
色域ばっかり気にしているけど、まずは4:2:0から4:4:4の規格拡張が重要だろうな。

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



548 :名無しさん@編集中:2009/02/24(火) 02:34:20 ID: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 :名無しさん@編集中:2009/02/24(火) 08:29:27 ID:L3cRA9fu
とりあえず、パナのハリウッドカラーリマスターとハリウッドクリアカラー
の相乗効果はすごいと思ったよ。

店頭で見た限りだけど。

550 :名無しさん@編集中:2009/02/25(水) 00:42:06 ID:fGb7RQ5r
>>548
まずはありがとう。ITU、有料だよね〜 日本語版JT-H264でもいいでしょ?
http://4megaupload.comって安そうだけど安全かしらん?
trial 5$ 3日間で他のITUも落としまくるのがいいかしらん?

551 :名無しさん@編集中:2009/02/25(水) 03:11:23 ID:3repSfpT
ITU-T H.264 最新の仕様書(2007-11月版)は全564ページだった。
pdf内を709で検索して出てくるのが殆ど該当箇所なのは一緒。

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

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


553 :名無しさん@編集中:2009/02/26(木) 01:59:21 ID:rdQIsAwr
おっと、もう1点いや2点不思議
・標準CからD65光源って、1970年代にそれはないでしょ?変わった?
・xvYCCって自然界の網羅率は良い筈だけど、xy色度値が中途半端だね?
 現SMPTE-C?とやらと上位互換性とった筈じゃなかったっけ?

554 :名無しさん@編集中:2009/03/29(日) 02:34:12 ID:LgOxc4FB
sRGB、AdobeRGB、x.v.colorのそれぞれの表現可能な色数をご存知の方
がいたら教えてくださいな。

555 :名無しさん@編集中:2009/03/29(日) 03:20:18 ID:Mg6SirGV
色数じゃなくて表色域だろ。CIExyとかでググれば見つかるんじゃねーの

556 :名無しさん@編集中:2009/03/29(日) 03:31:01 ID:LgOxc4FB
色域は分かるよ。

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

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

557 :名無しさん@編集中:2009/03/29(日) 06:30:50 ID:irGSnl3X
色域であって分解能の規定はないのいづれも無限色を表現できるよ。

558 :名無しさん@編集中:2009/03/29(日) 06:33:44 ID:LgOxc4FB
>>557
その理屈だと、規格を分ける必要なくね?
無限色を表現できるなら。

559 :名無しさん@編集中:2009/03/29(日) 07:02:40 ID:irGSnl3X
1から10までの間に数字はいくつありますか。
3から15までの間に数字はいくつありますか。
いづれも無限にあるだろう。

560 :名無しさん@編集中:2009/03/29(日) 07:04:22 ID:LgOxc4FB
いやそれ有限・・・

561 :名無しさん@編集中:2009/03/29(日) 08:11:20 ID:mPOA3JVd
では1から10までの間の数がいくつか答えてください
分解能の規定はありません

562 :名無しさん@編集中:2009/03/29(日) 12:30:38 ID:lA7p07ar
>560
整数は有限だけど、小数まで含めたらって話。

563 :名無しさん@編集中:2009/03/29(日) 14:46:20 ID:WH8zR3jM
>>554
sRGB、AdobeRGBの理論上の色数はどちらも8bit^3
x.v.colorにおいては8bit以上が認められているのではっきりした数字は出ない

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

564 :名無しさん@編集中:2009/03/29(日) 16:01:06 ID:Mg6SirGV
PNGとかTIFFは16bit/chも使えるな

565 :名無しさん@編集中:2009/03/29(日) 18:52:35 ID:mgett4HQ
ID:irGSnl3X
ID:mPOA3JVd

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

566 :名無しさん@編集中:2009/03/29(日) 18:53:42 ID:mgett4HQ
>>563
説明できないなら勉強してこい。無知は。

567 :名無しさん@編集中:2009/03/29(日) 19:12:00 ID:O/rx7RRI
>>554
sRGB、AdobeRGB、x.v.colorもそれぞれ8bitパネルでも対応できることから
1677万色の中で既定されている規格だと推測できる。

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

568 :名無しさん@編集中:2009/03/29(日) 21:47:50 ID:uW/WlEec
勝手に変な解釈しないでください

569 :名無しさん@編集中:2009/03/29(日) 21:55:13 ID:EooxQNTN
スレが進んでると思ったら荒らしか・・・

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


放置しろ予w

570 :名無しさん@編集中:2009/03/29(日) 22:07:38 ID:mwRUF3BT
お馬鹿なのに変に難しい話に首突っ込むなって感じだね

571 :名無しさん@編集中:2009/03/29(日) 22:14:57 ID:O/rx7RRI
まあ、予備知識のない人には勘違いしやすいからね。
連投してファビョちゃったのはちょっとみっともないけどw

572 :名無しさん@編集中:2009/03/29(日) 22:56:37 ID:RzyZqHsx
色数は、RGB16〜235だから219階調を3乗すればいい。

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

573 :名無しさん@編集中:2009/03/29(日) 23:29:16 ID:lA7p07ar
揚げ足とりだが、16と235も含むから220階調な。

574 :名無しさん@編集中:2009/03/30(月) 04:16:42 ID:yj7nNcLJ
sRGBは0-255だろ

575 :名無しさん@編集中:2009/03/30(月) 04:38:54 ID:tvUz5+v1
また、バカが沸いてきた。調べもせずにに毎回よく恥じかけるよ。

576 ::2009/03/30(月) 04:58:53 ID:zw8YBBel
自分が理解できないからひがんでいるとしか思えないぞw
つか、荒らし系の話題にはやっぱこんな馬鹿がよってくるんだから無視するに限るね

577 :名無しさん@編集中:2009/03/30(月) 05:20:23 ID:YluRllTz
釣りか真性かよく分からんバカがいるな。扱いに困る^^

578 :名無しさん@編集中:2009/03/30(月) 05:25:03 ID:vWECeExE
色空間wikiの一般的な色空間の所にRGBの項目があるってなんか変に感じる
コンピュータにおける表色系、と言った方があってる気がするんだが・・・
sRGBとかは色空間でいいんだろうけど・・・

579 :名無しさん@編集中:2009/03/30(月) 09:51:25 ID:KeRAFiM1
>>574
お勉強してこい。面倒みきれん。

580 :名無しさん@編集中:2009/03/30(月) 23:33:18 ID:8id16EcK
>>579
馬鹿は自分の面倒見ていろよ、別に頼んでないからw

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

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

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

582 :名無しさん@編集中:2009/03/31(火) 00:08:39 ID:DM0neHXk
sRGBの色域なら8bitで十分だろうけどそれより広げると
8bitではトーンジャンプおこすからって10bitやら16bit採用している例が増えてきているよね
scRGBも16bitじゃなかったっけ?

583 :名無しさん@編集中:2009/03/31(火) 00:21:18 ID:ss1HR4fU
ID変えている奴バレバレだな。これ以上まだ恥かくのか?w
ネットで一生懸命探して間違いを2chで公表しなくていいから専門書を一つでも読みなさい(笑)

584 :名無しさん@編集中:2009/03/31(火) 00:27:46 ID:ss1HR4fU
ちょっとググレば出て来るのにな。
なに的外れな勘違いしているのか。

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

585 :名無しさん@編集中:2009/03/31(火) 00:38:40 ID:6Om0hbMi
トーンジャンプは色空間の変換や色調補正とかで最も起こりやすいから
その処理を10bitや12bitで処理するものは多いね。そういう部分を丁寧に行って
ディザリングを施して8bitに丸めればまず違和感は起こらんと思う。

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

586 :名無しさん@編集中:2009/03/31(火) 01:55:33 ID:ee8xsR2u
>>ID:ss1HR4fU
まぁ連投するやつにろくなのがいないのだが
ついでに俺にも説明してくれまいか
いつからsRGBの量子化の実行範囲が16-235になったんだ?
まさかsYCCと混同しているのか?

587 :名無しさん@編集中:2009/03/31(火) 13:46:25 ID:EizfDYSg
スレ違いとは思いますが、瞬間湯沸し器的に沸騰してしまい、つい書き込みしてしまいました。お許しください。
普段は決して沸点が低い物質ではないのです。わたしという人間は。
今更エンコードに興味を持ち、あちらこちらの先輩方のサイトを拝見させていただいておりました。

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

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

588 :名無しさん@編集中:2009/03/31(火) 15:03:11 ID:P0BXIJ+t
地デジでは当てはまりませんが従来のNTSCはもともとその伝送構造的に周波数の低い赤が苦手です
また、mpeg系の量子化形式も元々NTSCに従っているのでやはり赤の再現性は苦手なのが原因です

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

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

589 :名無しさん@編集中:2009/03/31(火) 16:08:31 ID:JlZoO2Ku
糞スレになったな

590 :名無しさん@編集中:2009/03/31(火) 17:21:11 ID:6Om0hbMi
>>589
お前がいるからな

591 :名無しさん@編集中:2009/03/31(火) 20:43:16 ID:kBh3bxQ0
>>578
こんなところで愚痴らないで、ノートページに書くか、
自分で直接書き換えろ。

592 :名無しさん@編集中:2009/04/01(水) 13:36:53 ID:zym/N56e
まだ調べきれてなかったのか・・・せっかく宿題にしたのに。
やっぱり、ダメな子だな。

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

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

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

593 :名無しさん@編集中:2009/04/01(水) 13:38:07 ID:zym/N56e
おい>>586 >>574分かったか?頭悪い子には時間を置いて考えるくせをつけてやらないとな。

594 :名無しさん@編集中:2009/04/01(水) 16:55:30 ID:6wqwXSX3
で、どこにsRGBが16-235だと書いてあるんだ?sRGBとBT.709がどっちも16-235だと思っちゃってるの?

595 :名無しさん@編集中:2009/04/01(水) 22:43:03 ID:GzKFN+2F
>>594
例によってDQNはいつまでたってもDQNって事だろw
たしかにこういった技術系の板で>>594のようなやつがわいてくると困るよね
無視するに限るが無視すれば嘘八百書き込んだのが訂正されずにログに残るからねぇ

596 :名無しさん@編集中:2009/04/02(木) 03:18:04 ID:Hbe8OVGI
>>592 >>593 >>595
エイプリルフールは終わったぞ、さっさと訂正しろよな
sRGBの量子化は1ピクセルあたり24bitは常識中の常識だろ
どうやったら16-235みたいな中途半端な数字が出てくるんだよ宿題にしてやるから後で提出しろ

597 :名無しさん@編集中:2009/04/02(木) 10:37:52 ID:LFuqvVjG
>>594 >>596みたいな素人がここにもいるとはね。春休みか。
とりあえず、ここは初心者スレじゃないので質問は他でやれ。

598 :名無しさん@編集中:2009/04/02(木) 14:05:50 ID:Hbe8OVGI
>>597
アホか?素人過ぎるのはおまえだろww
RGB各色の先頭2bitがヘッダとして使われているから実行6bitだとかの理由なら形式によってはあり得るかもしれんが
10進表記した上で16-235がどうとかって・・・あまりにも無知すぎる
これ以降反論があるならちゃんとそれなりの反論をしてくれよな・・・お馬鹿さん

599 :名無しさん@編集中:2009/04/02(木) 14:10:30 ID:Hbe8OVGI
連投ですまん

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

600 :名無しさん@編集中:2009/04/02(木) 14:44:23 ID:Ihw/AXO8
なぁ素人の俺様にもどっちが正しいかわかるように
まともな事書いてる奴は丁寧に煽らず
DQNはwとか連発していかにも低脳そうに書いてクレよ。
いまはどっちもアホにしか見えなくて困る。

601 :名無しさん@編集中:2009/04/02(木) 17:45:25 ID: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:2009/04/02(木) 17:54:37 ID:GDkFtAxK
×235-254
○236-254



603 :名無しさん@編集中:2009/04/03(金) 07:03:30 ID:nHFB0SN+
>>600
sRGBが16-235と煽っている方がNG
そもそもYUV表記でもないのに16-235と言う数字が出るのもおかしいし
さらに>>601で示されたとおりYUVでも1-254も認められている

604 :名無しさん@編集中:2009/04/04(土) 13:38:41 ID:Fl+N8r/4
縦解像度540だとbt.709にすべき?bt.601?

605 :名無しさん@編集中:2009/04/04(土) 13:48:57 ID:lxktbjwP
SDでも縦は最高576(PAL)あるから、私だったらBT.601にするかな。

606 :名無しさん@編集中:2009/04/04(土) 14:14:08 ID:Fl+N8r/4
d

607 :名無しさん@編集中:2009/04/05(日) 01:41:56 ID:Lz+1kL2/
>>604
再生システムによって変わると思うので
自分でCBでもエンコしてやってみるしかないんじゃないかな

608 :名無しさん@編集中:2009/04/18(土) 02:49:20 ID: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 :名無しさん@編集中:2009/04/18(土) 03:11:06 ID:o6lZ9Rdc
ConvertToYV12()だとmatrix=Rec601だから、x264に--colormatrix smpte170mを付けておかないと、
一番下はおかしな色でRGBにデコードされる。

610 :名無しさん@編集中:2009/04/18(土) 03:13:16 ID:EPh0h7JE
それは分かってて盾540の時はどうなるのか比較実験でやっただけだろ…

611 :名無しさん@編集中:2009/04/18(土) 23:01:02 ID:94eLiRXd
たぶんそれはハードとかデコーダーによると思う。
RADEONは縦720以上でHDと判定されてffdshowだと横1024以上がHDだったかな?

612 :名無しさん@編集中:2009/04/19(日) 06:07:45 ID:AaMeDDYt
ffdshowは720pをSDと判定するってこと?
ffdsowの仕様はよく知らないけど、それはないんじゃないかなぁ

613 :名無しさん@編集中:2009/04/19(日) 06:10:43 ID:H/OGhjB9
良く嫁

614 :名無しさん@編集中:2009/04/19(日) 08:48:41 ID:qO0R7U85
--corlormatrixをエンコ済のmp4/264ファイルに設定する方法ってあるの?

615 :名無しさん@編集中:2009/04/20(月) 23:53:12 ID:zX8SIsCy
>>611
気になったんで調べたら、ffdshowは
width > 1024 or height >= 600: BT.709
width <=1024 and height < 600: BT.601
だって

616 :名無しさん@編集中:2009/04/21(火) 09:01:58 ID:qOM3eyLU
シネスコだと600切ったりするから自分でいじれる方がいいなぁ〜

617 :名無しさん@編集中:2009/04/21(火) 10:00:06 ID:WGQHHGAU
>>615は自動の場合の話
強制指定ももちろん可能

618 :名無しさん@編集中:2009/04/21(火) 14:37:23 ID:v+OxEIgE
>>615
DXVAだと縦が576ラインを境にしてSDとHDを切り分けるみたいです。
NTSCだと縦480だけど、PALが縦576だからでしょうね。

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

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


619 :名無しさん@編集中:2009/04/21(火) 18:04:26 ID:Ix1+B7Fu
ffdshowはエンコーダ(たとえばx264)側で指定しても615のようになるな
強制指定(RGB32出力のみ)だと毎回変えないとならないし

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

620 :名無しさん@編集中:2009/05/08(金) 15:18:36 ID:UiuZb1mF
最近このスレ知って、avsをaviutlで開いてみたんだけど、
d2vを開いてYUVマトリクス変換2でYCbCr48(BT.601)→YPbPr48(BT.709)をオンにした時には見られなかった変な線が入るんだけど原因分かる人いる?
ttp://paint.s13.dxbeat.com/up/src/paint_16349.jpg

621 :名無しさん@編集中:2009/05/08(金) 19:22:59 ID:yMrDmpsk
YV12>RGBにプログレッシブで変換しているせい
avsの最後にConvertToYUY2(interlaced=true)をいれる

622 :名無しさん@編集中:2009/05/08(金) 19:26:08 ID:yMrDmpsk
あるいはいっそAviutlで出力するなら
MPEG2SouceでupConv=1にすればYUY2にアップサンプルされる。
ただしavs内のフィルタ処理が全部YUY2になるので若干重くなったり
ほかの弊害が出る可能性はある。

623 :名無しさん@編集中:2009/05/08(金) 20:22:54 ID:UiuZb1mF
>>621-622
ConvertToYUY2(interlaced=true)入れたら出なくなった。ありがとう。
upconvはいろいろ問題ありそうなのでやめときます。

624 :名無しさん@編集中:2009/05/08(金) 21:48:30 ID:IEIA5OSm
avsでプログレッシブにしておいてから、最後にConvertToYUY2(interlaced=false)とするのがベスト。

625 :名無しさん@編集中:2009/05/09(土) 11:10:03 ID:aNNDvFLE
>624
プログレッシブにするのはYV12→YUY2変換する際に、インターレスだと縞が消えたりするから
それを防ぐ意味で書いてるなら、ベストだと思うけど……

626 :名無しさん@編集中:2009/05/09(土) 16:30:45 ID:Upx3EWnL
インターレースのまま変換したいなら
AutoYUY2を使うかこれ
http://pc11.2ch.net/test/read.cgi/avi/1238505263/16

627 :名無しさん@編集中:2009/05/11(月) 23:08:38 ID:07FXz0Q4
もうわけわかめだから、一から勉強使用と思うんだけど
おすすめの本とかありますか?
カラーマネジメント技術って本ググって見つけたんだけど
これでも良さげでしょうか?

628 :名無しさん@編集中:2009/05/11(月) 23:20:29 ID:ceeLrtJd
ググりながらこのスレを10回見直すといい

629 :名無しさん@編集中:2009/05/11(月) 23:30:37 ID:+vaSfW7B
真面目にその辺の売ってる本よりこのスレ読んだほうがよっぽど詳しい

630 :名無しさん@編集中:2009/05/12(火) 22:44:28 ID:QlqHmfaC
http://f61.aaa.livedoor.jp/~kasuga/images/hikaku.jpg

TV->PCスケール補正をしたのですが
AviUtl(拡張色調補正TV->PC)とAviSynth(ColorYUY2 - V0.17-3)では違ったモノになります
AviSynthの方は緑がかったような感じ

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

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

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

return last


631 :名無しさん@編集中:2009/05/12(火) 22:47:29 ID:bFqUczGR
AviUtlで実際に出力した映像をキャプるとどうなる?

632 :名無しさん@編集中:2009/05/12(火) 23:06:11 ID:QlqHmfaC
>>631
上の画像と同じです 出来上がったモノを比べるとやはり緑掛かって汚いような感じになります。
圧縮オプションも同じなのですがファイルサイズがAviSynth(ColorYUY2 - V0.17-3)の方が
小さくなります。

633 :名無しさん@編集中:2009/05/12(火) 23:07:39 ID:7x49t78M
>>630
元ソースTSか?
AviUtlのプレビューは常にBT.601だ、プレビューを信用してはダメ、エンコしてみるべし
YUY2読み込みして一時的にプレビューを出力イメージに近づけたいなら
YUVマトリクス交換2のYCbCr48→YPbPr48にチェック、ただしエンコするときははずせ

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

634 :名無しさん@編集中:2009/05/12(火) 23:24:51 ID:QlqHmfaC
>>633
ソースはTSです(1920x1080)

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

635 :名無しさん@編集中:2009/05/13(水) 00:30:42 ID:EnIaFlVF
>>634
ミスった
AviUtlでプレビューをエンコ後のイメージに近づけるにはYPbPr48→YCbCr48にチェックだった
とりあえず、試してみたけど同じになった。

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

636 :名無しさん@編集中:2009/05/13(水) 00:51:23 ID:jo2Mm3P7
て言うかよっぽど古いVGAとかSDにダウコンしない限りスケール補正やマトリックス変換なんて要らないんだけどな

637 :名無しさん@編集中:2009/05/13(水) 00:56:10 ID:jo2Mm3P7
あー、当然プレビューはそうとは限らないけど。
ちなみに、Aviutlならオーバーレイ表示に対応してるからそれ選択すれば
(おそらく)再生時と同じ色になる。おそらくってのは再生時のレンダラが
オーバーレイじゃなかったら違うかもしれないからな。

638 :名無しさん@編集中:2009/05/13(水) 05:39:34 ID:2MjdqDfH
http://latoninf.free.fr/d9/SL/SmoothLevels.v1.02.avsi

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

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

639 :630:2009/05/13(水) 17:36:29 ID:gkDV60U7
レスtyです。

何か話がAviUtlのプレビューの方向へそれていますが
AviUtlの拡張色調補正TV->PC)を使いたい訳ではありません

AviSynth(ColorYUY2 - V0.17-3)と比較した場合出力イメージが、かなり異なるので
これは何事かと悩んでいた訳です

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


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


640 :名無しさん@編集中:2009/05/13(水) 17:38:13 ID:gkDV60U7
間違えました


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

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

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


641 :名無しさん@編集中:2009/05/13(水) 18:39:41 ID:EnIaFlVF
いや、だからAviSynthもエンコして試してる?
AvsPのプレビューで00.jpg読み込んでみると
ImageReader("00.jpg")
ConvertToYUY2(matrix="Rec709", interlaced=false)
ColorYUY2(levels="TV->PC",matrix="",interpolation = "411->422",interlaced = true)
ConvertToRGB(matrix="Rec709", interlaced=false)
これで01.jpgの色になるし

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

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

642 :名無しさん@編集中:2009/05/14(木) 00:39:54 ID:VTXhiy+Q
http://pc11.2ch.net/test/read.cgi/avi/1221494912/671-674

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

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


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

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


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


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

643 :名無しさん@編集中:2009/06/02(火) 04:21:20 ID:BhVjMRFl
ID:なんかどうでもいいよ
暇な人がいるな

644 :名無しさん@編集中:2009/06/02(火) 04:32:05 ID:Z4TGrYsH
ID:BhVjMRFl = ID:VTXhiy+Q

馬鹿晒しage

645 :名無しさん@編集中:2009/06/02(火) 06:24:17 ID:BhVjMRFl
しっかりしろ大丈夫か

646 :名無しさん@編集中:2009/06/07(日) 04:02:36 ID:TzVAm/V2
ヘルプミー

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

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

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

647 :名無しさん@編集中:2009/06/07(日) 04:09:01 ID:iWqd3NuG
最近のradeonはレジストリ弄っても伸張してくれないよ。

648 :名無しさん@編集中:2009/06/07(日) 04:19:29 ID:TzVAm/V2
え?伸張されるのは確認済みなんだけど。

649 :名無しさん@編集中:2009/06/07(日) 06:50:56 ID:BM8DP167
AviUtlは何経由で読み込んでんの?
読み込み時一回RGBになってる落ちは無いよな

650 :名無しさん@編集中:2009/06/07(日) 10:00:42 ID:TzVAm/V2
m2v.auiっす。

651 :名無しさん@編集中:2009/06/07(日) 17:28:39 ID:wiN4VakQ
UseBT601CSCはレジストリに有っても無くても結果は同じ
だいぶ前のドライバからそうなってる
ちゃんと有無の度に再起動して自分で比較して見れば判る

652 :名無しさん@編集中:2009/06/07(日) 17:35:48 ID:TzVAm/V2
じゃあ最近のは何もしなくても伸張してくれるのか。知らなかった。

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

653 :名無しさん@編集中:2009/06/07(日) 17:47:20 ID:34WaVguB
ffdshowが709で伸張しててPDVDは601で伸張してるとかじゃないの

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

654 :名無しさん@編集中:2009/06/07(日) 17:52:50 ID:TzVAm/V2
どっちもPDVDとは違った。うーん…

655 :名無しさん@編集中:2009/06/07(日) 17:57:50 ID:34WaVguB
レンダラは同じなの?
別のレンダラ使っててレンダラ側で色調整してるとか

656 :名無しさん@編集中:2009/06/07(日) 18:03:42 ID:TzVAm/V2
レンダラは全部VMR9 (Renderless)

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

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

657 :名無しさん@編集中:2009/06/07(日) 18:06:17 ID:34WaVguB
あほすぎてつきあってられん

658 :名無しさん@編集中:2009/06/07(日) 18:19:50 ID:iWqd3NuG
放置しれ。

659 :名無しさん@編集中:2009/06/08(月) 02:27:39 ID:hPIXsi+z
>>651
家X1950proだけどUseBT601CSCを1にしないとVMR9で伸張されない
オーバーレイは関係なく伸張されるけど。

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

660 :名無しさん@編集中:2009/06/09(火) 00:44:32 ID:TmPJSAf5
aviutl0.99h2の「色変換の設定」でBT.709>BT.709にチェックしたら
TSをDGINDEXでd2v出力したd2vもきちんとBT.709でエンコ出来るの?
これでもうavs通さなくてもいい?

661 :名無しさん@編集中:2009/06/09(火) 01:05:08 ID:n53TPHl7
d2vで読むならどっちにしろavisynth通したほうがいいんじゃないの

662 :名無しさん@編集中:2009/06/09(火) 04:43:21 ID:7a2hBTLc
>>660
マニュアル読め
txtにYUY2入出力時にって書いてるんだからd2vじゃダメだろ
あとスレ違いだな

663 :名無しさん@編集中:2009/06/11(木) 00:24:17 ID:WVmK/xJW
色域変換プラグインの使い方
DVD
IN YCbCr 601 170M 65000
OUT(PC YCbCr sRGB 709 65000

PT1(HD+SD
IN YPbPr 601 709 65000
OUT(PC YCbCr sRGB 709 65000

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

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

664 :名無しさん@編集中:2009/06/12(金) 03:24:26 ID:E1KwXEy6
なにが言いたいのかサッパリ分からん

665 :名無しさん@編集中:2009/06/16(火) 05:00:18 ID:BvteGRnj
http://ruru2.net/jlab-ruru/s/ruru1245095978036.jpg

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

667 :名無しさん@編集中:2009/07/15(水) 20:27:34 ID:HHsZOcAC
1月ぶりの書き込みだお^^
ここの過疎っぷりははんぱないおっおっ^^

668 :名無しさん@編集中:2009/07/15(水) 21:16:31 ID:GGmzEZ/k
>>666
自分はそこまで詳しくないんでほとんど答えられないんですけど、
その前に、
>自分でやってみたのですが、特にカラー変化してないように見えるのですが、
というのは何のソフトで再生しての話? flashplayer?
再生環境もわからないと答えにくいかと…。

669 :名無しさん@編集中:2009/07/15(水) 21:24:13 ID:aohi0DBu
>>666
デコーダーでRGB変換させないとそのオプションは反映されないよ。
あとその解像度なら大半のレンダラはBT.709>BT.601変換を行うので
どっちにせよ色は変わらんと思う

670 :名無しさん@編集中:2009/07/15(水) 21:38:31 ID:N6xS0INa
>>668
MPC-HC +CoreAVC VMR7(windowed)
Radeon4670 Catalyst8.10
LCDはsRGBモードあと、ビデオオーバーレイでREGZA 37Z2000で見ています。
AviUtl内の色変換モードは入力出力とも自動です
こんなところです。
あとコンテナはmp4です


671 :名無しさん@編集中:2009/07/15(水) 21:45:25 ID:N6xS0INa
連投すいません。
>>669
と言う事はオプション気にしなくていいと言う事ですか?
う〜ん!皆さんのレスが宇宙語に見えます
自分の勉強不足を痛感しております


672 :名無しさん@編集中:2009/07/15(水) 21:55:17 ID:aohi0DBu
ffdshowとかCoreAVCとか出力色空間指定できるやつを使え

673 :名無しさん@編集中:2009/07/27(月) 09:39:40 ID:m89ClQOK
PV4キャプをHDエンコードするときは、
「入力 BT.601、出力 BT.709」で合っていますか?
最近この設定項目に気づいて、それまで601-601のままやってた\(^o^)/
確かに、601-709と601-601はエンコ後は異なっているようでした(x264 r1181)

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

674 :名無しさん@編集中:2009/07/27(月) 10:19:42 ID:wC4sVfCC
>>673
間違ってる

675 :名無しさん@編集中:2009/07/27(月) 10:22:55 ID:mhNHK0aD
>>673
OK

676 :名無しさん@編集中:2009/07/27(月) 10:32:30 ID:m89ClQOK
>>674-675
レスありがとうございます。
あれ・・・どっちなんでしょうw

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

677 :名無しさん@編集中:2009/07/27(月) 11:51:45 ID:UYZ3aPK9
AVIUTLでの話なら、
PT1のtsを709-709と
PV4のdvを601-709が同じ色になった

678 :名無しさん@編集中:2009/07/27(月) 12:13:32 ID:/VDaXh5/
質問する前に少しは用語をググってみましょう

679 :名無しさん@編集中:2009/07/27(月) 12:14:32 ID:m89ClQOK
>>677
ありがとうございます。
使用しているのはAviUtlのh4です(書き忘れすみません)

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

680 :名無しさん@編集中:2009/07/27(月) 13:09:39 ID:jL6Rbfgn
ありがとう。とんでもないことに気付いてくれましたね・・・・orz

681 :名無しさん@編集中:2009/07/27(月) 13:33:17 ID:qRfFnMhN
. ... ....:: ::: ::::;;;*。+ _、_゚ + ・
   Λ_Λ_・.(<_,` )_゚ ・  やあ数ヶ月前の私
  /,'≡ヽ::)m)V _ n   l  *
 ゙̄-' ̄`--´ ̄ ̄E_ ).ノ ̄ ̄

682 :名無しさん@編集中:2009/07/27(月) 15:01:24 ID:zVxvJ5lk
自分は使ってないけど上で質問してるこのx264のオプション
--videoformat ntsc --nal-hrd --colorprim bt709 --transfer bt709 --colormatrix bt709

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

683 :名無しさん@編集中:2009/07/27(月) 15:18:08 ID:MZmqwpL9
>>682
>それとも BT.709のフラグを付けるだけで実際は BT.601のままなのですか?

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

684 :名無しさん@編集中:2009/07/27(月) 15:35:54 ID:zVxvJ5lk
>>683
すきりしました
ありがとう。

685 :名無しさん@編集中:2009/07/27(月) 17:06:36 ID:m89ClQOK
遅くなりました。皆さんありがとうございます。
以上をまとめると、「AviUtl Version h4」における「色変換の設定」の項目は

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

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

686 :名無しさん@編集中:2009/07/27(月) 17:43:48 ID:zVxvJ5lk
>>685
自分はaviutl使わないけどココは参考にはなる
http://resic.laburec.net/
ここの下のほうね

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

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

687 :名無しさん@編集中:2009/07/27(月) 17:55:43 ID:m89ClQOK
>>686
難しいですね…
わからないから、もうこのままデフォルト(601-601)放置してしまっていいかな、と
思っている自分がいます。。。

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

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

688 :名無しさん@編集中:2009/07/27(月) 18:09:10 ID:/VDaXh5/
>>685
そういう覚え方するとあとでまた質問する羽目になるよ

689 :名無しさん@編集中:2009/08/04(火) 10:13:47 ID:FlWohczg
上の例で、入力 BT.601 出力 BT601でも--colormatrixで601で出力した事を付け加えれば
HDサイズでもプレイヤーが対応してれば正確な色で再生されるという事?
709で出力するのは安全策?

690 :名無しさん@編集中:2009/08/04(火) 11:38:31 ID:bjw/qu92
入力も出力もBT.601にしてたら色は変化しないよ。HDソース(PVのぞく)ならBT.709のままだ。
だからその場合は--colormatrix bt709じゃないとおかしな色になる

691 :名無しさん@編集中:2009/08/04(火) 11:54:28 ID:2xx8WQJj
誘導されて来ました。
PV4で録画したものって、PVで再生するときと、Aviutl等で読み込んだときとでなんで色が違うんですかね?
かなめもとか特に酷いんだけど・・・。読み込むときに伸張されてんのかな。

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

692 :名無しさん@編集中:2009/08/04(火) 11:59:56 ID:WlTIeTLY
PV3/PV4の1080iは601で記録される
再生の時に709に伸張する(グラボで709でRGBに戻されるため)

とかだったような・・・

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

693 :名無しさん@編集中:2009/08/04(火) 12:11:48 ID:UKpFlaYx
月曜未明に放送される(かもしればい)カラーバーを録って比べると判りやすいかも。

694 :名無しさん@編集中:2009/08/04(火) 12:48:33 ID:1FteMqnp
>>691-692
aviutlの0.99hから、読込601、出力709って指定できるようになったよ。
あと基本的な事だが、PV.txtでオーバーレイ設定だと、ビデオカード側でオーバーレイ専用のカラーテーブルになる。
ATiもnVidiaもドライバのバージョンによってはデフォルトでTV>PC伸張分ガンマカーブが調整されてるから、そのせいもあるかもな。

695 :名無しさん@編集中:2009/08/04(火) 18:24:07 ID:2xx8WQJj
>>692-694
レスありがとう!
>あと基本的な事だが、PV.txtでオーバーレイ設定だと、ビデオカード側でオーバーレイ専用のカラーテーブルになる。
これでオーバーレイ切ったら、色がPVでプレビュー時と、Aviutlで編集してるときとで色が近くなりました。
601,709の違いじゃなくて、TVスケールかPCスケールかのような気がするんだよね・・・。

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

696 :名無しさん@編集中:2009/08/04(火) 21:18:06 ID:bjw/qu92
色伸張について調べてください

697 :名無しさん@編集中:2009/08/04(火) 22:01:38 ID:Cnl7BC2Q
これでTVスケール伸張したらハイライト飛びまくりでしょ

698 :名無しさん@編集中:2009/08/04(火) 22:44:28 ID:x+gHlEeK
↑間違えますた。忘れて下さい(汗

699 :名無しさん@編集中:2009/08/05(水) 00:03:53 ID:lTF6/tMB
>>690
上の例ってのはそのPVで撮った時の事ね

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

701 :名無しさん@編集中:2009/08/06(木) 17:42:37 ID:QD/0UwF2
>>700
詳しくアドバイス有難う。ビデオカードは7600GSです。
ガンマカーブは補正0、ってかデフォにしましたが、改善無しでしたorz
PC>TVして、YC伸張使って誤魔化してますが・・・('A`)

702 :名無しさん@編集中:2009/08/06(木) 18:41:02 ID:e/nMVXM7
ちゅーか、最新ドライバじゃgeforceもradeonも伸張しないよ。
再生側で何とかする。

703 :名無しさん@編集中:2009/08/06(木) 18:43:06 ID:e/nMVXM7
>>702はSDの時ね。
HDなら何もしなくても伸張してくれるはず。

704 :名無しさん@編集中:2009/08/07(金) 17:27:24 ID:O3AQgJR4
いやいや、最近のは「ソフトウェアの設定を使用する」とかになってるだろ。
つまりプレイヤーが補正してるかどうかだな。

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

705 :名無しさん@編集中:2009/08/07(金) 17:45:51 ID:DC0CBGei
早朝のカラーバー録画して検証してみなよ。

706 :名無しさん@編集中:2009/08/07(金) 18:43:00 ID:KKLTm3fy
ttp://toku.xdisc.net/cgi/up2/oiu/xs10972.png
たぶんこれで正しいはず。TSからソフトウェアでBT.709>BT.601変換して
PCスケールに伸張

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

707 :名無しさん@編集中:2009/08/07(金) 18:46:15 ID:DRk9HbWS
>>695のはさらにもう1段くらい飛んでるような白さだね

708 :名無しさん@編集中:2009/08/07(金) 18:47:09 ID:KKLTm3fy
>>695は単にガンマ補正がかかってるだけみたいだな。BT.609にもなってるみたいだし

709 :名無しさん@編集中:2009/08/07(金) 18:51:29 ID:KKLTm3fy
ごめんヒストグラム見たらやっぱ飛んでる

710 :名無しさん@編集中:2009/08/09(日) 00:56:44 ID:rwF55XfM
モニタとかのキャリブレーションしてないから、いくら調整しても変なんじゃね?
正しく色が表示されてないのに、見た目だけで調整すると、こういう事になりやすいし

711 :名無しさん@編集中:2009/08/12(水) 15:51:48 ID:YrmWOkui
まずは705の書いたとおりPV4の色調整からだな。
カラーバーはNHK EかBS JAPANが毎日早朝にやってる。

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

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

712 :名無しさん@編集中:2009/08/12(水) 17:04:48 ID:tq5SG/YY
送り出しがレコならタイマー録画しとくといいかも
俺は調整で時々使う事あるから消さずに残してる

713 :名無しさん@編集中:2009/08/12(水) 20:30:04 ID:Q+lBPwRK
アースソフトにあるカラーバーをレコに読み込ませるのはだめなの?

714 :名無しさん@編集中:2009/08/12(水) 20:46:36 ID:vX9FlTCG
AviSynthでカラーバー作ってmpeg2エンコではだめ?

715 :名無しさん@編集中:2009/08/12(水) 21:25:34 ID:akN0sO8m
間違いなく正しいサンプリングになってる自信があるなら問題ない

716 :名無しさん@編集中:2009/08/12(水) 23:42:52 ID:kaa6YkjE
本物の放送映像使った方が間違えが少ないよ。番組も放送に乗っかってくるわけだからな。
自作はどこに罠があるかわからんよ。

717 :名無しさん@編集中:2009/08/16(日) 17:48:59 ID:cNWRlOqa
>>711
水曜から昨日まで早朝にNHK E録画したけど全然無かったよ。
ウソツキorz

718 :名無しさん@編集中:2009/08/16(日) 19:14:49 ID:AMWKSUUA
毎日だっけ?月曜朝だと思ったが
PT1使ってるから放送ないときに録画すると不安定になりそうで怖いんだよな…
チーズスイートホームを失敗したら…!

719 :名無しさん@編集中:2009/08/17(月) 03:04:38 ID:7+aDe2xR
>>717
NHK-Eにとらわれずに狙うべし。休止が多い日曜深夜〜月曜朝が狙い目。
俺が以前月曜朝に狙った時はNHK-E/TBS/テレビ東京/テレビ埼玉がいっぺんに録れてた。
NHK-G/フジ/NTVはこの日休止しなかったので予約しなかった。

720 :名無しさん@編集中:2009/08/22(土) 10:53:47 ID:qXCbtqqY
>>717
俺がやったときは去年の8/21(木曜)の早朝5時前で当時は毎日やっていたが
今はもうやってないのか。すまんな。
地域にもよるのかな?

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

721 :名無しさん@編集中:2009/08/27(木) 01:26:53 ID:PrC/GCk8
>>666
よく解らないので勉強ついでにOPTIONの意味調べてみた。
でも解らない部分多すぎorz

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

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

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

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

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

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

722 :名無しさん@編集中:2009/08/27(木) 02:01:45 ID:YybzNksQ
MPEGのヘッダについて調べるべきだな。

723 :名無しさん@編集中:2009/08/27(木) 11:29:07 ID:jNYYn/ih
まあ、--colormatrix指定してもそれを読みとる環境じゃないと色変わんないすけどね

724 :名無しさん@編集中:2009/08/28(金) 21:18:36 ID:CKingRL2
逆に読み取られて反映されたら困ることもあるしね

725 :名無しさん@編集中:2009/08/30(日) 22:19:10 ID:ZtvQARIR
TV放送をPT1でTS録画したのを、dgindexでd2vにしたら一度RGBになってしまうから、d2vにしないほうがいいということだよね?
いつもはm2vファイルをm2v.aui経由でaviutlに入れてます。
どうしてもd2v使う時は、avsにconvertToYUY2()記述すればOK?

726 :名無しさん@編集中:2009/08/30(日) 22:29:29 ID:Py4FfTLy
YV12

727 :名無しさん@編集中:2009/08/30(日) 22:33:02 ID:UYZIeIo2
>>725
単にConvertToYUY2()としただけでは、縞が崩れてしまうから、デインターレースまでをavsでやっておけばよい。

例:
MPEG2Source("input.d2v")

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

ConvertToYUY2

728 :名無しさん@編集中:2009/08/30(日) 23:09:35 ID:pO99p7mr
MPEG2SourceでupConv=trueとするかAutoYUY2を使うのがよい。
ConvertToYUY2(interlaced=true)でもいいけどあまり品質は良くない。
ベターなのは>>727だけど場合によっては先にYUY2化したほうがいい事もある

729 :名無しさん@編集中:2009/08/30(日) 23:11:29 ID:pO99p7mr
>>725
ていうかなんか勘違いしてるみたいだけどd2vがRGBになるのはVFAPI経由のときであって
MPEG2Source使えばYV12でロードできるぞ

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

731 :名無しさん@編集中:2009/08/30(日) 23:53:37 ID:q1MZGJqA
若干スレチな内容かもしれんが
DGVfapi には
VFAPI経由でAVSを読み込む機能がある

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

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

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


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

732 :名無しさん@編集中:2009/08/31(月) 00:45:06 ID:TyVN9vNa
>>730です
どうやら、Dgdecode.dllがうまく働いてなかったみたいです
手動で指定してあげたらうまく開けました
>>729の言うとおり、何もしないでもYUY2で読み込めました。
とりあえずテストは出来たのでよかったです。
助言くださった方々、ありがとうございました。
プラグインは全部avsに記述するのが、無難なのでそうすることにします

733 :728:2009/08/31(月) 01:07:30 ID:hBrFOPVF
今更だけどupConvはbool型じゃなくてint型で0-2を指定するんだった。


734 :名無しさん@編集中:2009/08/31(月) 22:04:20 ID:kSm5TrzT
ちょと聞きたいんだけど

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

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

735 :名無しさん@編集中:2009/09/01(火) 00:04:30 ID:FdBzBTxk
>>734
1.従来色域≒sRGB=BT.709
2.広色域≒AdobeRGB≠xvYCC

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

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

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

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

736 :名無しさん@編集中:2009/09/01(火) 01:56:16 ID:k8M7DHMD
いわゆる後方互換ってヤツか

737 :名無しさん@編集中:2009/09/01(火) 01:57:09 ID:k8M7DHMD
なに言ってんだ前方互換だorz

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

739 :名無しさん@編集中:2009/09/02(水) 01:22:56 ID:BswH7nyK
xvYCCてYが大きいまたは小さいときにCbCrの値が大きいと
結果が0-255を超える範囲になるのを利用してるから
RGB(-255,255,-255)とかは完全に範囲外だと思われる。

740 :名無しさん@編集中:2009/09/03(木) 01:46:11 ID:bUVHut+i
放送波は視聴者の反応が怖くてまだ採用できないだろうけど、
BT.709の色域は狭すぎ。
標準規格なのだから、ライブカラーでもハリウッドカラーリマスターでも
HDMIでxvYCCフラグ立てて出力するレコーダー、プレーヤー、ブルーレイが出てきたとき、
表示できない高彩度領域は色潰れするだけでエラーとなる訳ではない。

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

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

741 :名無しさん@編集中:2009/09/11(金) 23:32:27 ID:lVk4UI6U
>>727
ちょっとまて。
ConvertToYUY2(interlaced=true)
こうしておけばインタレ問題ないんだが。

742 :名無しさん@編集中:2009/09/12(土) 00:33:47 ID:EK0C2vmF
>>741
>>727の人はあちこちでそれでは少々問題ありと言ってまわってる人だよ
まあ、たしかにそれで問題なければドナルドもAutoYUY2なんてわざわざ作らんと思う

743 :名無しさん@編集中:2009/09/12(土) 01:41:27 ID:9jYyGNGF
問題あるかないかで言えばないけどよりよい方法が他にあるのは確か。
要するにベストではない

744 :名無しさん@編集中:2009/09/12(土) 02:35:05 ID:9MhpyxJN
720x480(Bt.601)の動画を960x720にリサイズしてColorMatrix(mode="Rec.601->Rec.709")した動画と
元動画って同じ色で表示されるはずだよね?

745 :名無しさん@編集中:2009/09/12(土) 03:15:38 ID:OGxTzALn
再生環境によって変わってくんじゃねえの?

746 :名無しさん@編集中:2009/09/12(土) 15:56:54 ID:IrIYPsP5
>>744
縦720以上はBT.709としてRGBにデコードする環境が多いだろうから、それで問題は無いと思う。
x264だったら、--colormatrix bt709 と指定しておけば間違いない。

747 :名無しさん@編集中:2009/09/12(土) 19:54:34 ID:OeLlCttP
>>745-746
サンクス
うちの環境がおかしいだけなのか縦横比が4:3だと縦720以上でもBt.601の変換係数を使って伸張しているようなんだ
1440x1080や1280x720だと正常(元ソースと同じ色になる)だけど960x720や1024x768や1280x960だと駄目
x264のcolormatrixで指定しても駄目だった
GeForce7800みたいな化石ビデオで伸張させてるのが間違いなんだろうか

748 :名無しさん@編集中:2009/09/12(土) 20:05:04 ID:Omvgwras
Radeon買うかffdshowでRGBに変換すればいい

749 :名無しさん@編集中:2009/09/12(土) 20:09:08 ID:IrIYPsP5
ffdshowやCoreAVCを使ってRGBで出力すれば、ビデオカードに関係なく、
H.264のmatrix_coefficientsに従った正しい色でデコードされる。

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

750 :名無しさん@編集中:2009/09/12(土) 22:23:42 ID:9jYyGNGF
RGBで出力させることが前提だけどね

751 :名無しさん@編集中:2009/09/12(土) 23:01:16 ID:PtWm0w4K
>>747
よくわからないけど、特定の解像度じゃないとbt.709にならないとか
試しに1440x1080や1280x720の縦や横を少し伸ばした変態解像度だとどうなる?

752 :名無しさん@編集中:2009/09/12(土) 23:33:42 ID:l1cb8ry4
あ、AR4:3の時なんですね。すまん、よく読んでなかった(汗
GF7800はbt.709の変換条件にARも見てるんですかね。
(16:9になるよう--sarを調整するとbt.709になったりするのかな?)

753 :名無しさん@編集中:2009/09/13(日) 00:40:24 ID:bn2wL18J
>>748-750
レスどうもです
ffdshowで出力するようにして解決しました
昔はCoreAVCで伸張してたんですが誤変換することがあったのでビデオで伸張するようにしてたのですが
>>752
960x720 sar11520:8640でdar16:9にしてやっても誤変換するようです

754 :名無しさん@編集中:2009/09/13(日) 00:57:14 ID:9yRMEvVk
>>753
どうでも良いけど960*720でDAR16:9ならsar4:3だよ

755 :名無しさん@編集中:2009/09/13(日) 14:39:35 ID:U1dF4sFC
xvYCC色空間なんだけど理論的にはこれでおkなのかな?

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

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

756 : ◆xOoJISANx6 :2009/09/15(火) 02:25:07 ID:u67UcJFi
>>755
LabじゃないそれはCIExy色度図。だから空間とは呼ばない。
その推定図も輝度値が考慮できていないため間違っている。

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

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

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

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

757 :名無しさん@編集中:2009/09/15(火) 21:11:01 ID:PMQXTlWv
>>756
おお詳しくありがとう。
確かにこの図だとRGB(0,0,0)とかどこにもないから変なのよねw
それを描いたのが挙げてくれたグラフになるのか。
(1)についてはなるほどすぎる。自分の参考にしてたもの自体が間違った使い方してたんだなあ。
(2)についてはその通りだと思うけど数値としてってことで。
紫外線や赤外線は視認できないし太陽も直視できないのと同じようなことだと思っとくw

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

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

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

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

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

759 :名無しさん@編集中:2009/09/18(金) 07:14:19 ID:DB9tzchW
4. Full Range

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


これ本当?

760 :名無しさん@編集中:2009/09/18(金) 14:15:45 ID:aXW0hvdp
うそ

761 :名無しさん@編集中:2009/09/18(金) 20:41:29 ID:lV9mGGSN
大抵16-235より多少はみ出しているけどな。
それをもってフルレンジ使っていると表現するのはどうかと。

762 :名無しさん@編集中:2009/09/19(土) 00:07:47 ID:yJo8lFPe
>>749
CoreAVCのRGB出力って
Input ColorspaceのAuto設定にしたらcolormatrix(matrix_coefficients)でしか判断してないんだな

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

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

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

763 :名無しさん@編集中:2009/09/19(土) 00:59:38 ID:8HeSvLD5
456 名前:名無しさん@編集中[sage] 投稿日:2009/09/05(土) 06:48:47 ID:UNt/b8gi
BT.709の放送をSDするったって、わざわざBT.601にする必要はないんじゃない。
そっちの方が色が好みならしてもいいだろうけどさ。

こういう勘違いしてる人は再生環境が劣悪なのもあるんだろうな
色が変わって見えないようにするための処置なのに

764 :名無しさん@編集中:2009/09/19(土) 05:54:35 ID:i7NplYlH
なんでわざわざデコーダでRGB変換してるの?
その後の経路が重くてしょうがないだろうに。。。

765 :名無しさん@編集中:2009/09/19(土) 05:59:28 ID:KMuU3TQ8
>>747からの流れを見る限り古いゲホは正しく伸張してくれないからだろ

766 :名無しさん@編集中:2009/09/20(日) 12:45:52 ID:UJ1Kcj9Y
Avisynthを絶讃ιょぅょ Part27
ttp://pc11.2ch.net/test/read.cgi/avi/1246414384/564-570
から誘導されて来ました。
このスレをぱっと見ただけでもまだまだ学ぶことは多いと実感しました・・・。

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

767 :名無しさん@編集中:2009/09/20(日) 13:51:56 ID:BjisnSiQ
>>766
同じ要領でソースのtsもキャプチャしないとどっちがどっちとも言えない

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

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

768 :名無しさん@編集中:2009/09/20(日) 15:03:29 ID:qgF4Uefa
>>766
Avisynthスレから追っかけて来たよ。
向こう>>565-566で伸張の違いと言われてたけど、それは関係ない。
BT.601かBT.709かの違いだよ。 その動画の実際の色空間と、デコーダーの判断が違うと色が変わってしまう。
解決策は767氏の言うとおり。 それと>>746かな。

769 :名無しさん@編集中:2009/09/20(日) 15:20:15 ID:UJ1Kcj9Y
>>767
お手数をおかけしてすみません。
ソースです
ttp://nagamochi.info/src/up35899.jpg
仰るとおり、Avisynthでエンコしたものとほとんど変わっていないのが確認できました。

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

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

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

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

770 :名無しさん@編集中:2009/09/20(日) 17:42:46 ID:N6bV6+4m
日本の放送はTVスケールのBT.709だから、SDにリサイズしないのなら、色は一切いじらずに、
x264で、--colormatrix bt709とだけ付けておけば良い。

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

771 :名無しさん@編集中:2009/09/20(日) 18:07:14 ID:qgF4Uefa
>>769
>それとDGIndexの設定は[Video]→[YUV->RGB]をTV Scaleにしてからプロジェクトを保存すること
あっちで教わったことはほとんど間違ってるから忘れた方がいい。
AvisynthでもTV Scaleに設定しなければいけない。

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

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

772 :771:2009/09/20(日) 18:14:41 ID:qgF4Uefa
自己レス
AvisynthではDGIndexの設定は関係無かった。 申し訳ない。吊ってくるorz

773 :名無しさん@編集中:2009/09/20(日) 18:30:48 ID:T9+lqtCy
>>771
まるもをVFAPI経由でAviUtlで使うやつなんているのか?

774 :名無しさん@編集中:2009/09/20(日) 18:41:31 ID:vC8SSVAo
ID:qgF4Uefaみたいなのが勢い余って変なこと書くから初心者が混乱するんだよな

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

775 :名無しさん@編集中:2009/09/20(日) 20:08:09 ID:xhqvbVb0
>>771
DGIndexもVFAPI経由な訳だが(DGVfapi.vfpは)


776 :名無しさん@編集中:2009/09/20(日) 20:39:33 ID:UJ1Kcj9Y
アドバイスをくださった皆さん、どうもありがとうございました。
皆さんのおかげで問題が無事解決できただけでなく、
今まで気にしていなかった色空間のことを調べるきっかけを得ることが出来ました。
今後のエンコライフに役立てたいと思います。本当にありがとうございました。

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

778 :名無しさん@編集中:2009/09/21(月) 08:41:11 ID:RtpQzziY
>>777
最新のaviutlにはデフォルトで色変換の設定がある
旧バージョンから上書きインストールした場合、入力BT.601、出力BT.601になってる

779 :名無しさん@編集中:2009/09/21(月) 21:06:18 ID:EqvmlXbP
>>778
入力と出力が同じ設定なら色空間のリサンプルは行われないよ。
だから設定がその状態でBT.709の動画を読み込んでもBT.709のままで吐き出される。

780 :名無しさん@編集中:2009/09/21(月) 23:04:56 ID:YZvp7o4+


781 :名無しさん@編集中:2009/09/21(月) 23:36:47 ID:ZGCwVnQK
プレビュー画面の色がおかしくなるだけで出力には影響ないね

782 :名無しさん@編集中:2009/09/23(水) 04:16:31 ID:8Pb+3EJ6
だなw 最初それで戸惑った

783 :名無しさん@編集中:2009/10/08(木) 12:30:18 ID:zZpNYCRK
RGB値を入力したら、何色か文字で表示されるサイトとかないでしょうか?

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

当方色弱者です。

マルチすいません

784 :名無しさん@編集中:2009/10/08(木) 12:42:40 ID:4Y7RwTms
敢えて文字で表現しようとする意味が解らない。
例えばRとGだけの変化で、どこからどこまでが黄色で、どこから山吹色で、どこからオレンジかなんて決まりは無いだろ?

785 :名無しさん@編集中:2009/10/08(木) 14:27:03 ID:B2GkG9Er
>>783
富士通アクセシビリティ・アシスタンス
ttp://jp.fujitsu.com/about/design/ud/assistance/
> ColorSelectorなど

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

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

786 :名無しさん@編集中:2009/10/08(木) 14:48:15 ID:q/3Zj4oj
>>783
色名からRGB値をだすのなら
http://ja.wikipedia.org/wiki/%E8%89%B2%E5%90%8D%E4%B8%80%E8%A6%A7
とかがあるけど・・・

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

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

787 :名無しさん@編集中:2009/10/15(木) 05:15:23 ID:az4581jV
次の手順でDVDをH264にエンコードした場合、DVD2AVIの設定でYC伸張が行われた事になるのでしょうか。
それともaviutl側でフィルタを通さなければ駄目なのでしょうか。

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



788 :名無しさん@編集中:2009/10/15(木) 06:40:29 ID:NmUK96LM
うる覚えだがパソコン色調だと伸張されるんじゃなかったかな

789 :名無しさん@編集中:2009/10/15(木) 06:50:25 ID:w0Sh52FO
DGIndexでd2vを作成(4:2:0) -> それをソースにavsを作成 -> そのavsをx264でエンコード

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

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

791 :名無しさん@編集中:2009/10/15(木) 07:22:47 ID:T6PBhqq0
>>787
aviutlならMPEG-2 VIDEO VFAPI Plug-In(m2v.aui)で読み込んでYC伸張フィルターでも
使った方が良いんじゃないか。
その質問だとYC伸張のままエンコしたいって読めるけど、その理由も書いた方が良い。

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

792 :名無しさん@編集中:2009/10/15(木) 07:53:07 ID:rD938YI7
下らない話なんだけど、Avisynth使ってエンコしたのに色がおかしい!
と思ったら、MPCを複数起動すると1枚目だけちょっと赤っぽくなるだけだった
これってなんで?

793 :名無しさん@編集中:2009/10/15(木) 07:54:18 ID:az4581jV
>>789
DGindexはブルーレイにも対応していてヨサゲですね。
さっそく試してみます。

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

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

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





794 :名無しさん@編集中:2009/10/15(木) 08:06:43 ID:agdUnab0
YUV420の地デジTSをaviutlでm2v.aui入力→拡張x264出力を使って出力しています。
どうしてか色が薄いのですが正しい色空間で出力するするにはどうしたらいいでしょうか?
色変換は入出BT.709にしています。
エンコのオプションでは訳もわからず--colormatrix bt709つけてるんですがこれは余計なのでしょか?

795 :名無しさん@編集中:2009/10/15(木) 08:14:24 ID:4uBXmTax
>>792
使ってるレンダラによって違う
オーバーレイ表示になってるんだろ
>>793
よほど古いビデオを使っていない限りはドライバ入れたら伸張されるので
エンコード時に伸張するとおかしくなると思うんだが・・・
まあ好きにすればいいよ

796 :名無しさん@編集中:2009/10/15(木) 08:21:32 ID:w0Sh52FO
元のTSから色を一切いじらず、x264で --fullrange off --colormatrix bt709 と付けておけば、
これらのVUIを読むデコーダ(ffdshow, CoreAVC等)なら、正しい色のRGBを出力できる。

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

797 :名無しさん@編集中:2009/10/15(木) 08:27:32 ID:az4581jV
色々と教えてくださって有難うございます。
YC伸張は再生側に任せるようにして、余計な色変換は行わないようにします。


798 :名無しさん@編集中:2009/10/15(木) 08:37:37 ID:agdUnab0
>>796
ありがとうございます

799 :名無しさん@編集中:2009/10/15(木) 11:31:46 ID:8m519n3d
>>795
最近のゲフォは伸張されないよ

800 :名無しさん@編集中:2009/10/15(木) 15:17:12 ID:dq8UtIge
GeForceは最近のドライバなら
「プレーヤーに任せる・限定レンジ・フルレンジ」を
コンパネから指定できるけど。

801 :名無しさん@編集中:2009/10/15(木) 16:27:20 ID:8m519n3d
>>800
レンダラがVMR7などでオーバーレイミキサを使用している場合はコンパネで指定しても適用されない
XPでMPCなどレンダラが指定できるプレーヤーならレンダラをVMR9などに変えれば回避できるが
PowerDVDなどの市販DVDプレーヤーなどではYC伸張されない
以前は上記の場合はちゃんとYC伸張してたんだけどね
まぁもうXPなんてかまってられないというところなんだろうがあまりにもお粗末だとは思う

802 :名無しさん@編集中:2009/10/15(木) 20:34:05 ID:HAmgurWE
>>794
m2v.aui 0.6.57はYUV出力時の色空間指定が入れ違ってない?
色空間指定の無いソースではBT.709がBT.601になるようだ。


803 :名無しさん@編集中:2009/10/15(木) 21:45:42 ID:tsGqAdC9
ちゃんとm2vconf実行しているのか?

804 :名無しさん@編集中:2009/10/16(金) 02:18:55 ID:zYKoQIGp
>>800
Windows 7使ってるけど、プレイヤーに任せるってやると、
メディアプレイヤー : フルレンジ(伸張あり)
メディアセンター : 限定レンジ(伸張なし)
ってなってるみたい。
コンパネで設定すると確かにプレイヤーに関わらず指定できるようになるね。
これは良い!

805 :名無しさん@編集中:2009/10/16(金) 05:10:29 ID:loWC9LXh
>>802-803
m2vconf.exeで元のYUVデータを維持に設定するとだめなんですか?BT.709を選択すべきでしょうか?
アチャーあれからテスト用に何本かエンコ、比較してそれなりに好い感触は得ていたのですがやっちまいましたね。
また何本かテスト用動画作って比較してみます。

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

807 :名無しさん@編集中:2009/10/16(金) 06:38:16 ID:YJbYqzsa
>>806
matrix_coefficientはその動画のカラーマトリックスが何なのかわかるようにするための御呪いみたいなものだよ
デコーダが対応してなきゃ意味ない
殆どの場合、設定してようがしてまいがデフォルトの動作をする(通常は720p以上はbt.709、それ以下はbt.601と判断)

808 :806:2009/10/16(金) 06:57:27 ID:loWC9LXh
>>807
ありがとうございます。
m2v.vfp入力の自動認識と同じ様に判断されるということですね。
BT.709と判断されているようで出力結果も合わせて納得しました。

809 : ◆47o/marumo :2009/10/16(金) 07:30:03 ID:jLe7fFFe
>>806
matrix_coefficient が設定されていない場合、その上の
「色空間行列(省略時)」に従って入力カラーマトリックスを
決定します。

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

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

810 :名無しさん@編集中:2009/10/16(金) 08:05:36 ID:loWC9LXh
>>まるもさん
たまたま正しい選択をしていただけで色々と勘違いしていたようです。
私のような初心者の頓珍漢な質問にお答えいただき恐縮です。

811 :802:2009/10/16(金) 21:17:29 ID:RzuxG7VV
あれから調べてみた所、AviUtilでYUY2モードと通常のモード間を移行すると
必ず色空間がBT.601に設定されてしまうのが原因だと気づきました。

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

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

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



812 :名無しさん@編集中:2009/10/16(金) 21:49:35 ID:r7Nrr25f
ところでPCでエンコモノ再生させるにしてもRADEONやGeForceなら縦720px以上の
動画はBT.709と判断してRGB展開させるから無理にエンコ時に変換する必要もないんだけどな

813 :名無しさん@編集中:2009/10/16(金) 22:00:27 ID:OZVvhOwm
>>811
バカだよポップさん Log 2009/06
http://resic.laburec.net/log/2009_06.html#20090604

814 :名無しさん@編集中:2009/10/17(土) 12:32:54 ID:FbcoTVZr
>>812
縦解像度でBT.601/BT.709を判断するのはDXVA1(VMR)を使うときだけで
DXVA2(EVR)やDXVA-HDの場合はAPI経由で指定するようになってるよ。

815 :名無しさん@編集中:2009/10/18(日) 01:41:42 ID:KLBuvV46
>>767 >>774 >>787-788 >>790
亀レスだけど再生時に伸張する場合はTV scaleではなくPC scaleだよね?
ttp://neuron2.net/dgmpgdec/DGIndexManual.html#YUVtoRGB

816 :名無しさん@編集中:2009/10/18(日) 01:56:19 ID:R6+Yavty
>>815
質問の意味がいまいちわからんが
再生時にYUV [16, 235(Y)/240(UV)] → RGB [0, 255](PC Scale) の変換(伸張)を行う
エンコ時は弄らずTV Scaleのままね
その辺がややこしいからエンコ時にはRGB変換をかまさないように意識するといい

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

817 :名無しさん@編集中:2009/10/18(日) 02:10:41 ID:0ZZQoRsf
横からすまんけど
x264で色空間指定しておかないといけない再生環境ってどんな場合があるの?

818 :名無しさん@編集中:2009/10/18(日) 02:21:34 ID:R6+Yavty
>>817
>>814のような環境やCoreAVCのRGB変換
--colormatrixは指定しておいて損はない
将来的なことも考えて指定しておくべき
逆に指定しておかないと後から見てカラーマトリクスに何を使ってるのかがわからなくなる

819 :名無しさん@編集中:2009/10/18(日) 02:48:38 ID:ZVnnwvZA
話題ぶったぎり?で悪いが、ひさびさにMediainfo更新したらmatrix_coefficientsなる項目が追加されていた

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

820 :名無しさん@編集中:2009/10/18(日) 02:52:30 ID:KLBuvV46
>>816
分かりにくくてスミマセン。
エンコ時に色を弄らずにRGBに変換するというのは、
DGIndexのYUV->RGBをPC scaleに設定するはずなのに、
何故か少し上のレスではTV scaleに設定しろと書いてあるのが気になったので。

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

821 :名無しさん@編集中:2009/10/18(日) 03:40:15 ID:ANiuz35q
VFAPI経由ってコトはaviutl?

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

822 :名無しさん@編集中:2009/10/18(日) 03:41:09 ID:0ZZQoRsf
>>818
うちは今Win7x64 ラデHD4830の環境なんだけど
別にcolormatrix指定していなくてもSDでもHVでもEVRでそれぞれ正しく色空間変換されるよ
これって>>814の環境じゃないのかなぁ
つまりそこまでcolormatrixをうるさく言う必要性をあまり感じないんだけど・・・

823 :名無しさん@編集中:2009/10/18(日) 03:42:55 ID:KLBuvV46
>>821
そうです。

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

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

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

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

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

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

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

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

824 :名無しさん@編集中:2009/10/18(日) 04:08:49 ID:Fg3u/RoJ
http://latoninf.free.fr/d9/SL/SmoothLevels.v1.02.avsi

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

825 :名無しさん@編集中:2009/10/22(木) 19:55:41 ID:sLs0nbOh
すみません確認なのですが、地デジやBS,CSの場合はSD放送であっても
「ITU-R BT.701」ですよね?

826 :825:2009/10/22(木) 19:58:57 ID:sLs0nbOh
地デジでSD放送はあまりありませんね。
たとえばBS2などです。

827 :名無しさん@編集中:2009/10/22(木) 20:01:54 ID:1NuSCDBl
ISDBは、SD/HDの両方とも、ITU-R BT.701になっている。

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

828 :名無しさん@編集中:2009/10/22(木) 20:06:28 ID:sLs0nbOh
>827

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

829 :名無しさん@編集中:2009/10/22(木) 20:08:21 ID:Uc86/9KJ
BT.709

830 :名無しさん@編集中:2009/10/22(木) 20:10:12 ID:G80e5xng
質問するほうも答えるほうも709を701と間違っていると、さすがに釣られたくなるな

831 :名無しさん@編集中:2009/10/22(木) 20:15:45 ID:1NuSCDBl
つられて間違えた。やはり、コピペなんてするものじゃないな。

832 :名無しさん@編集中:2009/10/22(木) 22:51:19 ID:VdZJGvqf
放送大学のカラーバーもSDでBT.709だったよ

833 :名無しさん@編集中:2009/10/22(木) 22:57:58 ID:m9Atz555
ISDBでは解像度に関係なくBT.709が指定されてたはず

834 :825:2009/10/25(日) 01:09:17 ID:yWHgJgI4
うろ覚えでググってひっぱてきたら・・・。
609&709
ですよね。

835 :名無しさん@編集中:2009/10/25(日) 01:30:30 ID:hdmQGoUg
601&709

836 :825:2009/10/25(日) 23:17:34 ID:tb97zs4j
もうボロボロっすね・・・


837 :名無しさん@編集中:2009/10/26(月) 00:15:17 ID:Dlqlwez3
fack you

838 :名無しさん@編集中:2009/10/26(月) 00:54:34 ID:SJUh5aQ8
色々調べていると混乱してしまいました。
どなたか自分の認識の確認お願いします。

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

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

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

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

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

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

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

839 :名無しさん@編集中:2009/10/26(月) 01:06:43 ID:Av5dKFN4
> HDからSDの場合、ColorMatrix(mode="Rec.709->Rec.601",interlaced=false)
>を使い、x264のオプションに --fullrange off --colormatrix bt709 をつける。

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

840 :名無しさん@編集中:2009/10/26(月) 01:16:17 ID:SJUh5aQ8
>>839
> HD->SDなら、avsはそれでいいがx264のほうは--colormatrix smpte170mになる
やはり間違えてましたか。ご指摘ありがとうございます。
avsはそれでいいというのは、1)と2)は正しいと解釈してもよかったですか?

841 :名無しさん@編集中:2009/10/26(月) 01:41:13 ID:tc4eLmXg
> SDからHDの場合、ColorMatrix(mode="Rec.601->Rec.709",interlaced=false)

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

842 :名無しさん@編集中:2009/10/26(月) 06:12:25 ID:7n+CTY4M
BT.701吹いたw
601なんだか709なんだかマジ分からんw

843 :名無しさん@編集中:2009/10/26(月) 11:37:37 ID:SeddTvhX
BS1、2もBT.709?

844 :名無しさん@編集中:2009/10/26(月) 11:57:19 ID:6LFezO/5
>>838
TSがソースなら2)はConvertToYUY2(matrix="rec709")、ConvertToYV12(matrix="rec709")
だと思うのだが、正しいかどうかは自信ないから保証しない。
あと4)はCoreAVCスレで聞いた方がいい。

845 :名無しさん@編集中:2009/10/26(月) 12:25:56 ID:Av5dKFN4
ConvertToYUY2やConvertToYV12のマトリクス指定はRGB->YUVのときだけ
YUY2<->YV12でマトリクス指定するとエラーになる
自信がないなら書くなよ

846 :名無しさん@編集中:2009/10/27(火) 01:41:13 ID:8CHub/kk
レス遅くなってすみません。
>>840,>>841


847 :名無しさん@編集中:2009/10/27(火) 01:42:34 ID:8CHub/kk
間違って送信してしましました。

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


848 :名無しさん@編集中:2009/10/27(火) 01:47:09 ID:8CHub/kk
また、間違えてしまいました。
これを最後のレスとします。

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

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

849 :名無しさん@編集中:2009/11/25(水) 23:37:20 ID:7YFwX31b
デジタル放送はYUV420だから、YV12読み込みで劣化なしと考えていいのかしら?

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

850 :名無しさん@編集中:2009/11/26(木) 01:10:47 ID:gaUAZYgq
キャプチャ時の422のメリットはインターレースを考慮しなくてもいいという点

851 :名無しさん@編集中:2009/11/26(木) 06:19:36 ID:lJUl7Siv
放送やDVDと言ったMPEG-2 Video Main Profileをソースにする場合は、DGIndexでd2vを作って、
MPEG2Source("input.d2v, upConv=0)として読み込めば、リサンプリングによる劣化はしない。

852 :名無しさん@編集中:2009/11/26(木) 06:21:46 ID:lJUl7Siv
MPEG2Source("input.d2v, upConv=0) -> MPEG2Source("input.d2v", upConv=0)

853 :849:2009/11/26(木) 20:53:42 ID:o3wQozq8
>>850
なるほど上のほうで出てる話だね

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

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

854 :名無しさん@編集中:2009/11/27(金) 06:56:20 ID:wBO66cpo
Helix YV12 / I420 VFW Codecs
http://forum.doom9.org/showthread.php?t=56972

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

855 :名無しさん@編集中:2009/11/27(金) 17:01:39 ID:FkULgom4
やっと分かりかけてきたのですが、AVIUTLでYUY2入力したかったら
まるもm2vか、DGDecodeとAVSを使用するかがある
でいいのですよね?

856 :名無しさん@編集中:2009/11/27(金) 17:16:01 ID:/4tK74np
>>855
何の話?
mpeg2なら別にDirectShowFileReaderでも入力はYUY2になるが

857 :名無しさん@編集中:2009/11/27(金) 22:04:41 ID:uwRdJ/tZ
>>813
このテスト内容AとBってさ実はソースコピーしてるだけじゃないの?

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

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


858 :名無しさん@編集中:2009/11/27(金) 22:38:14 ID:+JQFX6F3
>>779

859 :名無しさん@編集中:2009/11/27(金) 22:43:02 ID:uwRdJ/tZ
>>858
てことは、フィルタ使うと色域のリサンプリングが行われて
同じフィルタを同じ設定で使っても違うファイルが出来るの?

860 :名無しさん@編集中:2009/11/27(金) 23:14:22 ID:Q1MiGKuS
プレビュー比較
.ts->m2v.aui
709->709
ttp://uproda.2ch-library.com/1918742ib/lib191874.png
601->601
ttp://uproda.2ch-library.com/191875sdZ/lib191875.png
.dv->EARTH SOFT DV.aui
601->709
ttp://uproda.2ch-library.com/191879zdz/lib191879.png

861 :名無しさん@編集中:2009/11/27(金) 23:18:42 ID:Q1MiGKuS
あくまでプレビューなんで、エンコーダ等に渡すデータはまた違うかも知れません

862 :名無しさん@編集中:2009/11/27(金) 23:28:48 ID:WPLZ3s5w
>>860
.ts->m2v.aui
m2vconf.exeでYUY2色空間行列を BT601にして
709->709と601->601 の画像お願い



863 :名無しさん@編集中:2009/11/27(金) 23:37:19 ID:+JQFX6F3
Qonohaでキャプ
色変換を間違えてRGB表示すると
http://toku.xdisc.net/cgi/up/qqq/nm19106.jpg

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

864 :名無しさん@編集中:2009/11/27(金) 23:39:55 ID:WPLZ3s5w
>>813のCの実験もYUY2だけで処理してるんだから本来同じファイルじゃないとおかしくないの?

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


865 :名無しさん@編集中:2009/11/27(金) 23:40:15 ID:Q1MiGKuS
>>862
SMPTE 170M
601
ttp://uproda.2ch-library.com/191892Xxk/lib191892.png
709
ttp://uproda.2ch-library.com/191894StN/lib191894.png

866 :名無しさん@編集中:2009/11/27(金) 23:43:29 ID:WPLZ3s5w
>>865
お手数かけて悪いけど
m2vconf.exeの一番右下にある設定のほうです
YUY2色空間行列 (m2v.aui用)って項目
そこにBT601があるんで

867 :名無しさん@編集中:2009/11/27(金) 23:46:48 ID:Q1MiGKuS
スマソ
709
ttp://uproda.2ch-library.com/191899zkG/lib191899.png
601
http://uproda.2ch-library.com/1919001Lj/lib191900.png

868 :名無しさん@編集中:2009/11/27(金) 23:50:23 ID:Q1MiGKuS
601->601と元のYUV維持(恐らく709)->709は同じっていうことでいいのかな

869 :名無しさん@編集中:2009/11/27(金) 23:57:21 ID:WPLZ3s5w
.ts->m2v.aui bt709
709->709
ttp://uproda.2ch-library.com/1918742ib/lib191874.png

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

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

870 :名無しさん@編集中:2009/11/28(土) 00:07:14 ID:Nbxw41Lu
ts->m2v.aui bt601
601->709
ts->m2v.aui bt709
601->709

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

俺はバカだ

871 :名無しさん@編集中:2009/11/28(土) 00:39:05 ID:JfcnbEAF
プレビュー変わるのは入力だけ

872 :名無しさん@編集中:2009/11/28(土) 00:43:03 ID:Nbxw41Lu
>>871
だよね

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

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

873 :名無しさん@編集中:2009/11/28(土) 01:45:22 ID:JfcnbEAF
>>872
PV4は仕様上BT.601で取り込んでいるので、AviUtlの入力をBT.601とするとプレビューまでは正しくなる
m2vconfの色空間行列ををBT.601、AviUtlの入力をBT.601にしたときと一緒
出力はHDならBT.709にしておけばよい
って感じでいいのかな

874 :名無しさん@編集中:2009/11/28(土) 02:14:22 ID:AwLR0jDB
>>873
出力ってどっちにしても同じファイルが出来上がらない?


875 :名無しさん@編集中:2009/11/28(土) 03:17:25 ID:JfcnbEAF
>>874
変わることは変わるけど、なんか俺が思ってたのと違うことになってる
もうよくわからんので、カラーバー置いときます
ttp://www1.axfc.net/uploader/Li/so/52015.zip

876 :名無しさん@編集中:2009/11/28(土) 05:53:19 ID:R1sEnmdc
>>875
↓みたいに、パートで分けて考えると判りやすいかも
 ts(bt.709)→再生機器─→PV4→.dv(bt.601)┐
┌──────────────────┘
└→EARTH SOFT DV.aui→入力色変換(bt.601→RGB)aviutlコア(RGB)→出力色変換(RGB→bt.709)→出力 ┐
┌────────────────────────────────────────────┘
└→デコーダ+レンダラ+グラボ(HD動画はbt.709→RGB)→モニタ再生(RGB) *注)RADEON DXVAの場合
間違ってたらごめんw


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

878 :名無しさん@編集中:2009/11/28(土) 08:03:27 ID:v0ATo8eP
aviutlの出力がおかしいんじゃないの

879 :名無しさん@編集中:2009/11/28(土) 11:30:44 ID:IQC2WXDo
AviUtlプラグインの波形表示の最新版が709のベクトル表示付いてるから
それ使って調べればいいんじゃね

880 :名無しさん@編集中:2009/11/28(土) 16:46:12 ID:TDnh5qP5
>>876
Aviutl内部はRGBではなくYC48(YCbCr各12bit)

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

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

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

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

881 :名無しさん@編集中:2009/11/28(土) 17:19:57 ID:TDnh5qP5
あちょっと訂正

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

まあまとめると

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

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

882 :名無しさん@編集中:2009/11/28(土) 21:59:43 ID:6GpiMBnx
ちょっと気になったんだけど
入力時と出力時の色空間が違っても
(出力時に)勝手にyc圧縮/伸張はされたりはしないよね?

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

883 :名無しさん@編集中:2009/11/28(土) 22:02:31 ID:6GpiMBnx
>>882
ちなみにソースはTVスケールのmpeg2で
出力もTVスケールでやってます

884 :名無しさん@編集中:2009/11/28(土) 22:08:33 ID:TDnh5qP5
d2v作成時の設定と読み込み設定による。
d2vで読み込むとMPEG2でフラグが正しくないとインターレース壊れるぞ。RGBだし

885 :名無しさん@編集中:2009/11/28(土) 22:15:05 ID:as0+mCwA
せっかくd2vを作るのなら、avsを読めるxvid_encrawやx264(CLI)を使えばいい。
自分でColorMatrix等を使わない限りは元のままなので、色空間で悩む必要もなくなる。

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

887 :名無しさん@編集中:2009/11/28(土) 22:47:20 ID:6GpiMBnx
>>884
DVD2AVIで
「色空間指定」を“YUV4:2:2”
「YUV->RGB変換」を“テレビ色調”
にしてプロジェクト経由です。

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

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

889 :877:2009/11/28(土) 23:52:02 ID:JfcnbEAF
AVCなら問題ありませんでした
ttp://kissho.xii.jp/1/src/1jyou97837.jpg

890 :名無しさん@編集中:2009/11/29(日) 00:03:26 ID:/mt7KybQ
バカだよポップさん Log 2009/05
http://resic.laburec.net/log/2009_05.html


891 :名無しさん@編集中:2009/11/29(日) 01:16:31 ID:dH2CEN+U
>>888
「AVI File Reader(Video for Windows)」は、YUY2形式のコーデックだろうがなんだろうが
RGB展開になるから、「AVI/AVI2 File Reader」の優先度を上げとくといいと思うんだ。

892 :877:2009/11/29(日) 01:51:16 ID:ohAZqONo
>>891
ご指摘どおりでした
結局、最初の>>873の考えでOKです
ttp://uproda.2ch-library.com/192261P54/lib192261.jpg

893 :名無しさん@編集中:2009/11/29(日) 12:19:39 ID:IzVu18F+
>>881
YC48(BT.601).なんて概念は無いでしょと言うのは置いといて

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

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

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

894 :877:2009/11/29(日) 13:53:27 ID:ohAZqONo
>>893
見た目が変わるからBT.709>BT.601って書いてんじゃないかな

895 :名無しさん@編集中:2009/11/29(日) 14:14:13 ID:755dDIBY
YC48はBT.601変換式(+スケール変換)でRGBと相互変換できる形式みたいだから
便宜的にそう書かれたのでは、とエスパーしてみた

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

897 :名無しさん@編集中:2009/11/29(日) 19:02:58 ID:mT76S+UL

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

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

898 :名無しさん@編集中:2009/11/29(日) 23:04:14 ID:dKjId32G
色々議論中に話の腰を折るようで悪いのだが・・・>>838ってあってる?
DestripeやBCSInterlacedResize使って縦を縮めたときって
直後でColorMatrixを使ってやらないとサイズ戻すときにおかしなことにならない?

899 :名無しさん@編集中:2009/11/29(日) 23:10:20 ID:3i11wI3D
最終的にSDにするのなら、IVTCの後にColorMatrixを付けたらいい。
縦720以上なら、ソースのまま(BT.709)にしておく。

900 :名無しさん@編集中:2009/11/29(日) 23:19:26 ID:dKjId32G
>>899
レスどうもです。
エンコ初めたばかりでわからないことが多く助かりました。

901 :名無しさん@編集中:2009/12/15(火) 19:41:35 ID:8eMubjYZ
PT2で録画した地デジTSをVLCでPS変換し、aviutlでm2v.aui経由で読み込み、
WMVやxvidなどでD4〜D5エンコする場合
m2vconf.exeでの設定はどうするのが正しいんでしょうか
・YUV→RGB変換はどちらにチェックを?
・色空間行列(省略時)とYUY2色空間行列(m2v.aui用)は何を指定すれば良いのでしょう

何を今更、と思われるかもしれませんが、ぐぐって調べても
ここを具体的に指摘してくれてるページに出会えなかったもので…
どなたかご教示願えませんでしょうか

902 :名無しさん@編集中:2009/12/15(火) 21:53:11 ID:fnelTTWR
Utl使って再エンコするのになぜPS変換?

903 :名無しさん@編集中:2009/12/15(火) 22:09:15 ID:DP6SyV39
TSは激しく分散して記録されており、その後の作業にも影響があるので
デフラグをかねて変換するらしい

904 :名無しさん@編集中:2009/12/15(火) 22:22:32 ID:9QL3hsBD
http://www.up-cat.net/CBR%25A4%25CE%25B8%25B8%25C1%25DB.html
>このため、放送用のコンテナ(例えば.ts:MPEG-2 Transport Stream)のデータをそのまま記録し、
>後ほど再生する場合には、'シークの基準は時間ではなく、データ量になる。
>つまり1時間の動画の50%部分にシークをしても、30分の部分に当たるとは限らない。
>これが30分に当たることがあるとすれば、それは擬製的なCBR(ヌルパケットやパディングなどの
>無駄なデータが含まれる)であるか、偶然前半も後半も平均すれば同じビットレートであったというだけである。…

こういうのも関係あるかもね

905 :名無しさん@編集中:2009/12/16(水) 00:34:45 ID:0gvHv4Lw
いや、その部分はTSでもPSでも同じじゃね?

906 :名無しさん@編集中:2009/12/16(水) 01:46:08 ID:TptFbxh/
>>809あたり?

907 :名無しさん@編集中:2009/12/22(火) 08:57:17 ID:RlhwNndl
地デジのtsストリームをTSmemoryで伸張された色はITU-R BT.601 という規格に沿っています。
映像信号の規格にはいろいろあり、コレを調べれば調べるほど本当の色ってなんだろう?って思います。
地デジはHDTVのITU-R BT.601 であるのでコレをPCの静止画の標準(?)であるsRGBに変換します。
元の色差信号がYPbPrであるので、YCbCrに変換する事も必要でしょう。

http://areya777.blog123.fc2.com/blog-entry-44.html

908 :名無しさん@編集中:2009/12/22(火) 15:02:24 ID:fTTKW5fE
日本の放送はBT.709

909 :名無しさん@編集中:2009/12/22(火) 17:09:22 ID:z0oHIQP5
単にBT.601って言っても、
色空間の方の「BT.601(YCbCr)」・「BT.709(YPbPr)」で使ったり、
YC量子化レベルの方の「BT.601(16-235/16-240)」・「フルスケール(0-255)」
で使ったりしてるが、どっちか分かりづらい。
BT.709でもYC量子化の部分はBT.601なんだし。

910 :名無しさん@編集中:2009/12/22(火) 20:10:17 ID:1aUN2LwW
なんか屁理屈っぽいぞw
色空間スレなんだし、BT.601のサンプリング周波数が13.5MHzとかいう話なんて誰もしてないだろ。
それともMPEG2だったらITU-R BT.470-2 System B, Gと言う方が正しいとつっこんだ方がいいのか

911 :名無しさん@編集中:2009/12/23(水) 03:49:23 ID:kUw0CbSS
>>907
ブログのコメントの指摘を完全スルーしててわろたwww

912 :名無しさん@編集中:2009/12/23(水) 09:59:38 ID:IHzcdViX
大前提として色なんかだいたい合ってりゃいい

って人だからね。スルーしてもしょうがないww

913 :名無しさん@編集中:2009/12/23(水) 14:10:15 ID:eG1JsR+c
最初から正しい色で読み込むか、変な色で読み込んで正しく補正するかの違いだからね
どっちでもいいんじゃない

914 :名無しさん@編集中:2009/12/24(木) 00:00:38 ID:PLWcjbMx
>>907
ありやがでたらめなだけだよ
TSmemoryはまるものm2vconf.exeの設定が反映されるから
その設定次第でAviutlは601でも709でも表示できる




915 :名無しさん@編集中:2009/12/24(木) 00:46:43 ID:33Sc8OhV
>>907
この人、アースソフトのPVでのキャプがメインらしいから
それ用にAviUtl本体の「色変換の設定」の「入力」をBT.601にしたままで検証やってるんじゃないかな

916 :名無しさん@編集中:2009/12/24(木) 00:53:02 ID:35+6xALV
でも最終的に間違ってないんだろ?

917 :名無しさん@編集中:2009/12/24(木) 10:06:49 ID:ev0t3SKV
>>916
そもそも正解が無いからな
sRGBの問題点はこのスレの最初のほうで語られている

ただでたらめな点がちらほらあるなーって思われるだけで
>地デジのtsストリームをTSmemoryで伸張された色はITU-R BT.601 という規格に沿っています。
>地デジはHDTVのITU-R BT.601



918 :名無しさん@編集中:2009/12/24(木) 10:59:41 ID:boWbk/sF
揚げ足取りとまでは言わないけど
目くじら立てるほどでもないな
コメント無視しているんじゃなくて気がついてないんじゃないの?

919 :名無しさん@編集中:2009/12/24(木) 14:15:35 ID:hLIrLH/Y
>>915
半年前くらいからTSmemoryが主みたいよ

まあ基本的に色空間とかどうでもいい人なんだろw
ttp://long.2chan.tv/jlab-long/10/s/long73846.jpg
ttp://long.2chan.tv/jlab-long/10/s/long73847.jpg

920 :名無しさん@編集中:2009/12/24(木) 17:44:26 ID:/S060CVg
その画像はなに?

921 :名無しさん@編集中:2009/12/24(木) 19:28:13 ID:b+Cz6Nri
サービスです。

922 :名無しさん@編集中:2009/12/25(金) 00:08:28 ID:sN2EppV7
Liveムービーメーカーでデジカメ動画編集すると色空間が勝手に変換されて
白っぽくなってしまいますが、無変換にはできないものでしょうか?


923 :名無しさん@編集中:2009/12/25(金) 00:21:56 ID:9nMCiYYt
YC伸長しないクズVGAなんだろ

924 :名無しさん@編集中:2010/01/12(火) 21:45:36 ID:+UBrKa3e
>>907
わろたw

925 :名無しさん@編集中:2010/01/15(金) 14:58:57 ID:vsEmLgtp
AとBは同じ色
http://img.f.hatena.ne.jp/images/fotolife/a/apollo440/20070624/20070624230539.jpg

これ判らない奴は色空間なんて気にするな

926 :名無しさん@編集中:2010/01/15(金) 21:56:19 ID:ibuPjlnI
http://img4.imageshack.us/img4/7774/bt601.png
http://img706.imageshack.us/img706/239/bt709.png

普通の映像で、違いが分からない人は居ないだろう。

927 :名無しさん@編集中:2010/01/16(土) 18:18:17 ID:qmsjAsSZ
何でその映像なんだw

928 :名無しさん@編集中:2010/01/16(土) 21:01:33 ID:ik0pgh7P
じゃあ何ならいいんだよw

929 :名無しさん@編集中:2010/01/16(土) 21:10:12 ID:XC5twVHu
そりゃ女の裸だろ
二次元か三次元かで別の文句が出そうだが

930 :名無しさん@編集中:2010/01/16(土) 21:50:02 ID:FyrbS7fV
正座で待機

931 :名無しさん@編集中:2010/01/17(日) 10:40:23 ID:axocvWi5
三次元TSでBT601にしたとき、肌が桃色っぽくなるのも捨てがたい。
長年アナログで植え付けられた呪縛かもしれんが・・・

932 :名無しさん@編集中:2010/01/17(日) 10:57:46 ID:ArQr6t7O
BS2アナログキャプチャをデジタルに移行しようと比べてみたが
デジタルはやはり緑が弱い
avisynthのフィルタで変換しても肌色がピンクなんだな
停波までアナログでがんばることにした

アナログキャプチャがフィリップスチップだったから
最初は「ナメック病」かと思った

933 :名無しさん@編集中:2010/01/17(日) 19:05:21 ID:DtwHdEsD
AviUtlの色調補正で

明るさ 20
コントラスト 46
輝度 -47
色の濃さ -36

にしてぱっと見で元との違いがすぐわからないなら色盲だから考えるだけ無駄

934 :名無しさん@編集中:2010/01/18(月) 02:03:50 ID:uNsUEXNL
>>925>>933かね。
こないだから何がしたいんだこのバカは。

935 :名無しさん@編集中:2010/01/18(月) 16:53:40 ID:g2Pk5Nsc
>>934
お前は一体誰と戦ってんの?w

936 :名無しさん@編集中:2010/01/18(月) 20:29:37 ID:FgBwSFya
色空間と戦ってるんだろ

937 :名無しさん@編集中:2010/01/18(月) 20:40:12 ID:5BXK9QrW
マクー空間に引きずり込め!

938 :名無しさん@編集中:2010/02/07(日) 22:53:58 ID:Mo2XRQC+
BT.709のRGB⇔YUV変換の式を調べていたのですが、
まるもさんの2002年5月15日の記事によると、以下のようになっています。
  Y = 0.2125 × R + 0.7154 × G + 0.0721 × B
  U = − 0.115 × R − 0.386 × G + 0.500 × B
  V = 0.500 × R − 0.454 × G − 0.046 × B
一方、色空間のWikiなどを見ると、
  Y = 0.2126 × R + 0.7152 × G + 0.0722 × B
  U = -0.1146 × R - 0.3854 × G + 0.5000 × B
  V = 0.50000 × R - 0.4542 × G - 0.0458 × B
となっており、微妙にパラメータが異なっているようです。
更にググったところ、
  ttp://koujinz.cocolog-nifty.com/blog/2009/03/rgbycbcr-5d00.html
の記事に、
  「BT.709 に関する係数値が MPEG2,MPEG4 と H.264 では異なります。(中略)
   どうやら BT.709 の古い規格では係数値が異なるようです。(←未確認)」
とあったのですが、この記事にあるようにBT.709の変換係数には新旧の2種類があり、
MPEG2とMPEG4では古いほう(まるもさんの記事の数値)、
H.264では新しいほう(Wikiとかの数値)を採用していると考えればよいのでしょうか?
また、Avisynthなどではどちらの変換式を採用しているか、ご存知の方はいらっしゃいますでしょうか?
(微妙な違いなので実質的にはほぼ変わらないとは思いますが)

939 :名無しさん@編集中:2010/02/07(日) 23:28:28 ID:P80EvOi/
>>938
avisynthの場合
http://avisynth.org/mediawiki/Color_conversions

940 :名無しさん@編集中:2010/02/08(月) 21:26:38 ID:ExxjyaCE
>>939
ありがとうございます。英語Wikiにそんなページがあったのですね・・・失礼しました。orz

その後また調べていたのですが、
  ttp://developer.apple.com/quicktime/icefloe/dispatch019.html
を見ると、Avisynthやまるもさんの式はBT.709-1で規定された式で、
色空間Wikiなどの式はBT.709-2から変更された式のようですね。
なんだかややこしいのですね・・・。

941 :名無しさん@編集中:2010/02/08(月) 21:45:22 ID:v466wu6G
まあ8ビットはもちろん12ビットでもめったに違いはでないと思うけどな

942 : ◆xOoJISANx6 :2010/02/11(木) 11:49:44 ID:3nuXUIma
>>940
CIE1988で青色側の視感度曲線の修正案が承認された。
但し、xy色度図を変更することは避け、あくまでも参考値とされた。
しかし、多くの実用上での眼の特性はこの方が忠実であることは判っていた。

従って1990年以降の規定は有効数字が3桁しかないXYZ系に従わず、
その後の精度面での成果を組み込んで4桁以上の規定がされていったということ。
尚、Y値だけはもともと7桁精度がある。それまでのuvの4桁は単なる補間値。

Y値のBの係数が相対的に大きくなる方向に修正されている。

943 : ◆xOoJISANx6 :2010/02/11(木) 11:51:58 ID:3nuXUIma
あれっまた間違えた
誤:有効数字が3桁しかないXYZ系
正:有効数字が3桁しかないxy色度図(厳密には1桁とも言えるが)

944 :名無しさん@編集中:2010/03/09(火) 12:54:59 ID:DsCoCJCQ
現在、勉強中の素人ですけど教えてください。
先日某実況スレでキャプ職人さんがUPした画像を見て
「色空間が変だぞ」、違うスレでは「二重伸張だ」と言ってる人が居たんですが
素人の自分には全く分かりませんでした。玄人になると見ただけで分かる物なのでしょうか?
または、調べる方法やソフトなどが有るのでしょうか?
宜しくお願いします。

945 :名無しさん@編集中:2010/03/09(火) 14:38:02 ID:l10YziPP
素人なら気にするな

946 :名無しさん@編集中:2010/03/09(火) 14:39:31 ID:99D/dE/m
>「色空間が変だぞ」、違うスレでは「二重伸張だ」と言ってる人が居たんですが
ダウソ板でやれ

947 :名無しさん@編集中:2010/03/09(火) 15:11:08 ID:ih86X4FG
色空間が変といえばGM1ziAg9V9

948 :名無しさん@編集中:2010/03/09(火) 15:33:19 ID:jIMesENq
>>944
玄人になると雰囲気でわかるよ、マジでw
色空間、おそらくカラーマトリクスの事だと思うが、雰囲気で間違ってるってわかるようになる。
二重伸張、おそらくYC伸張を二回かけてる事だと思うが、こっちはすぐわかるようになるよ。

949 :名無しさん@編集中:2010/03/09(火) 17:52:39 ID:DsCoCJCQ
>>945
確かにその通りなんですが好奇心て奴が…
>>946
ダウソ板で質問するべきでしたか、板違い失礼しました。
>>947
鳥は付いてなかったので、その人かは分かりませんが…
>>948
やっぱり分かる人には分かる物なんですね
知識と経験って奴ですかね 奥が深い…

皆さん、レスどうも有難う御座いました。

950 :名無しさん@編集中:2010/04/16(金) 00:35:59 ID:giMEO56r
ああああああああ
ずっとtsのHDソースエンコしてたから
tsのSDソースでBT.709>BT.601に変換すんの忘れてソース消してしまったw
一応--colormatrix "bt709"指定してるけど704x396だから複雑な気分だw

951 :名無しさん@編集中:2010/04/16(金) 21:40:45 ID:/e3HK94x
そんなに外れるわけじゃないから気にするなw

952 :名無しさん@編集中:2010/04/24(土) 09:47:29 ID:7lpibqix
MonsterTV HDUSで抜いたTSなんですが、
これってYUY色空間は飽和レンジになってるはずですよね?
FFdshowのヒストグラムで確認したところ、
アニメ番組だとそのようになっているようですが、
NHK「MUSIC JAPAN」のライブ映像だと、
シャドーだけ圧縮されてハイライトはフルレンジめいっぱい使ってるようなのです。
これはどのような意図で作られているのでしょうか?
テレビでも問題なく視聴できて、
PCとかフルレンジ対応の機器ではハイライトの諧調を残せるとか?


953 :名無しさん@編集中:2010/04/24(土) 13:28:48 ID:z492pMvW
235-255はよくスーパーホワイトって言われてる。実写では割とよくある。
家電テレビならダイナミックコントラストで調整してくれるだろうしPCでは
デコーダーかビデオカード次第だろう

954 :名無しさん@編集中:2010/04/24(土) 13:41:17 ID:BU0qr/Ow
Radeonならダイナミックコントラストを有効にするとスーパーホワイトも飛ばないようになる
家電より反応が遅くて、シーンチェンジでちょっと輝度が不安定になったりするが

955 :952:2010/04/24(土) 20:07:37 ID:7lpibqix
>>953
>>954
ありがとうございました。スーパーホワイトでググって理解しました。
放送でも100IRE以上を含む可能性があるということですね。


956 :名無しさん@編集中:2010/04/27(火) 23:37:01 ID:8ji6wPjp
輝度が236-255のスーパーホワイトまで使われてる映像というのは
CbCrについてはどういう扱いになってるんだろう?
色も16-255 or 0-255のように広く取られてるのか、それとも16-240に収まってるのか…

957 :名無しさん@編集中:2010/04/28(水) 09:09:20 ID:NjDGfjBF
難しすぎ(;´∀`)

958 :名無しさん@編集中:2010/04/28(水) 09:18:36 ID:skBqMitO
>>953
空を飛ばしてでも顔を明るくしたかったりするからな。

959 :名無しさん@編集中:2010/04/28(水) 10:14:32 ID:yI3xaMK5
>>956
スーパーホワイト部分はあくまでもオプション扱いなので
Yが16-235(+20)でCbCrもしくはPbPrは16-240

960 :名無しさん@編集中:2010/05/08(土) 02:34:56 ID:6SvXUBYW
m2v.auiで読み込んで地デジTSをAviUtlでエンコする場合、m2vconf.exeの設定を
・YUV→RGB変換 をストレート変換
・色空間行列(省略時) を自動認識(解像度から)
・YUY2 色空間行列(m2v.aui 用) 元のYUVデータを維持
に設定した場合、YC伸張フィルタを使うと2重伸張になる、であってますか?

TSはBonTsDemuxでm2vにしてあります

961 :名無しさん@編集中:2010/05/08(土) 12:44:29 ID:Cfi1fZGo
>>960
m2v.auiならVFAPIじゃないんで、YUY2読みになるから、
・YUV→RGB変換 をストレート変換
・色空間行列(省略時) を自動認識(解像度から)
これ関係ないんじゃね?

で、そこでYC伸張フィルタ入れるだけなら、
単にフルレンジのデータになる。

ただし、今の一般的な再生環境だと、再生時に伸張するのが多いから、
そういう時は、再生結果は2重伸張になる。

962 :名無しさん@編集中:2010/05/08(土) 16:11:14 ID:6SvXUBYW
>>961
レスありがとうございます
なるほど、再生時に伸張してくれるんですか
て事は、一般的にはYC伸張フィルタは掛けなくても良いって事ですね

963 :名無しさん@編集中:2010/05/09(日) 21:42:55 ID:pNiEQvM0
僕 インタレ解除時と中間ファイル完成時に
両方YC伸張かけてzoomeに投稿した動画の色が好きなんだけど
これってwebプレイヤーでもYC伸張かかってるだろうから3重伸張になるの?

964 :名無しさん@編集中:2010/05/10(月) 08:13:11 ID:YUDU9cqW
わろたw

965 :962:2010/05/10(月) 09:09:36 ID:6B/PUGY4
>>963
うん?俺間違った解釈しちゃった?
詳しそうだから是非>>961をもう少し分かりやすく答えてほしい・・・

966 :963:2010/05/10(月) 14:36:44 ID:McKr5TDk
僕完全に横槍レスだから気にしないで
自分が好きな色で良いんじゃねってことでw

967 :名無しさん@編集中:2010/05/10(月) 15:13:01 ID:jIszEUrh
それ、このスレにいる必要なくね?w いや、まあどうでもいいんだけどw

968 :名無しさん@編集中:2010/05/10(月) 16:03:52 ID:/8xiH3TY
PCとTVの規格が違うから面倒だよねw

969 :962:2010/05/10(月) 16:59:14 ID:6B/PUGY4
ん〜、質問の仕方が悪いのかそれとも
質問スレじゃないから質問スレ行けってこと?

970 :名無しさん@編集中:2010/05/10(月) 18:20:02 ID:1JBTlKF4
>>969
いや、だから>>963は関係ないって言ってるじゃん。
再生時に[16-235/240]から[0-255]に伸張してるなら要らない。
そっちの再生環境が伸張するのかどうかは知らんけどさ。

971 :名無しさん@編集中:2010/05/10(月) 23:01:21 ID:6B/PUGY4
>>970
そうですかありがとうございます
>>963読んだらやたらと気になったので。



972 :名無しさん@編集中:2010/05/11(火) 04:50:36 ID:y/K+Hy+u
>>971
もう2度とくんなよw
うざいからw

973 :名無しさん@編集中:2010/05/11(火) 05:21:29 ID:y/K+Hy+u
つーかここ質問スレじゃないぞ

974 :名無しさん@編集中:2010/05/12(水) 00:55:26 ID:FDPCVT2y
 よ ほ う 診  医 精 一 忠 は あ ま
 さ  う け 察 .者 神 度 告 て き さ
 そ が .た を  の 科    す た れ し
 う           の    る な     く
 だ                が  :
、___          ___       :
   (_____,/::::::::::::`ヽ、
          /::rー‐-ー-、:::l__,   , -─
          _|:lr_‐、 ̄-=、l:::|   //
        /)Y ´゚`ri 、'゚゙' |/,〉 /´
        |` |l /ヽ _,ノl |ノ|
        ヽ_| '-=ニ=-l !/
         /|ハ  -‐  /\
   _,. -ー'`´ l l \    /'/! l`ー-、_


975 :名無しさん@編集中:2010/05/12(水) 07:57:12 ID:xXupYwBo
>>974
自覚してるなら早く行ってこいw

976 :名無しさん@編集中:2010/05/12(水) 15:13:08 ID:OxdnVQu0
ここまで俺の自演

977 : ◆IBu8UMAAJI :2010/05/12(水) 20:33:51 ID:VUFKqBrM
 

978 :名無しさん@編集中:2010/07/25(日) 04:43:54 ID:Cf4CxqVU
DVDの色ってBT.601って規格ですよね?
DVDをアプコンしようと思ってるのですがあってるかどうか不安なのでちょっと質問です。
Avisynth→Aviutl→x264でエンコしようと思ってます。リサイズは780x420→1280x720。


まずリッピングしたVOBをDGindexでd2v+wavにする。

d2vをAvisynthにDGDecode経由で読み込み。

インタレ解除やノイズ除去等の処理後にConvertToYUY2で"YV12"を"YUY2"へ変換。

AvitulにAvisynth Script File Reader経由で"YUY2"読み込み。(サイズは720x480のまま)

AviutlでYUY2を読み込ませる場合、入出力でBT.601とBT.709の二種類あるんですけど
この場合はどっちにチェック入れればいいのでしょうか?

BT.601とBT.709はYUV2→RGB変換でしか関係ない?



979 :名無しさん@編集中:2010/07/25(日) 07:58:31 ID:e+NBohuz
マルチ乙
しかも他のスレで質問した方で答え出てるのに
何しに来たんだ?

980 :名無しさん@編集中:2010/07/25(日) 17:02:11 ID:aETd1KCF
僕 色変換の設定は自動でやるのが好きなんだけどこれってまずいの?
YUV2→RGB変換じゃないから関係ないんですかー?

981 :名無しさん@編集中:2010/07/25(日) 22:40:18 ID:1rqeBGtG
愛があれば大丈夫さ。ちょっと色が変わったって愛がカバーしてくれる。だから大丈夫さ。

304 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)