掲示板などにあったスケール変換関連のネタを拾ってある。 混乱の元は、TMPGEncがRGBで取ることと、ストレート変換するコーデックがあること、オーバレイが伸張されないビデオカードがあることですね。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/te30/box06/te30_post_2452.html 要望 - YUVデータをCCIR601ではなく、Basic YCbCrで出力する No.2452 らっか さん 2004/11/06 (土) 20:06 ( ID:yyjjti8kn4. ) [ 編集 / 削除 / 引用して返信 ] No.618, 1799 の質問、要望とかぶるのですが、 TMPGEnc Plus 2.5の「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」の 機能を要望します。 自分の使い方としては、 1. MTV1000でMPEGキャプチャ 2. aviutlで編集し、プロジェクト保存。 3. TMPGEncでMPEG再圧縮 のような使い方が多いのですが、基本的にキャプチャしたときのままの 色で出力したいと思っています。 2でPCスケールに変換すればよいとは思うのですが、なるべくなら無駄な変換は したくありません。 ---- この後aviutlでのRGBヒストグラムで、ソースMPGと2.5でストレート変換したMPGとは スケールが同じだが、3.0で変換したものはスケール圧縮されているのを示される。 →  2.5でRGB->YUV時にストレート変換にしないと合わないということは、どこかでYUV->RGB時に ストレート変換しているということ。おそらくはaviutlにMPGを読み込む時にVFAPI経由で ストレート変換しているものと考えられる。DVD2AVIでTV Scaleか、M2V.VFPでストレート にしているのだろう。解決策は次のいずれか。  RGB変換を嫌がるのならば、m2v.aui読みしてhuffyuv出力し、これを3.0に読ませればよい。 これならばRGB変換はされない。(画質的にはベスト)  プロジェクト渡し時(VFAPI)にYUV->RGBで情報が落ちるのが嫌なのでストレート変換する つもりならば、色調補正内の「YUVのCCIR伸張」で輝度・色差を両方とも255にすることで 対応することになる。(変則的)  RGB変換での情報落ちを気にしないのならば、aviutlに読むときにDVD2AVIでPC Scaleにするか M2V.VFPでCCIR601変換にして、3.0で普通に出力する方法でもよい。(PCのスケール変換的には 一番素直な方法) ------------------------------------------------------------------------------------------------ http://www.driver.novac.co.jp/driver/cceb/cceb_faq.htm Q.huffyuvで、RGBデータを YUY2 に変換したもので、YUY2形式のファイルを読みこませた場合、   「ビデオ設定」の「輝度レベル」をどちらに設定しているかに関わらず、必ず出力ファイルでは   輝度・色差信号のスケールが縮小されてしまうのですが... A.輝度レベルの設定は、入力がRGBの時のみ有効に機能します。   入力がYUY2の時は、変換せずにそのまま使用しています(スケール変換はしていません)。   もともとYUY2はCCE-Basicが受け付けることができる唯一のネイティブフォーマットです。入力としてRGBを受け取った場合、   それは内部的にYUY2に変換されます。そのときの変換方式が2種類あり、その方式は輝度レベルのところで選択可能です。もしネイティブの   YUY2がスケール変換されてしまうのであれば、0-255で変換したYUY2の信号もスケール変換されてしまうはずです(16-235で変換したものは   二重に変換されることになってしまいます)。   スケール変換をしているのは huffyuv 自身になります。スケール変換をしたくないのであれば、 HuffyuvS をご使用ください。 →これのミソは「RGBデータをYUY2に」にある。ここでスケール縮小されている。これをCCEに入れるときにYUY2のまま読む(スケール変換なし)が、元々スケール縮小してあるものを読んでいるので、当然出力も縮小されている。HuffYUVにCCEパッチを当てるとYUY2読み込みでなくRGB読み込みになる(多分)ので、読み込み時にHuffyuvがYUV->RGB変換時にスケール伸張し、スケール上は辻褄が合う。しかしYUV->RGB->YUVのスケール変換込みの計算が入るので精度として不利である。  HuffyuvSでは最初のRGB->YUY2時にスケール変換がない。それだけである。  この話からすると、YUY2キャプチャしてhuffyuvで保存し、CCEでエンコードすれば全く変換なしでMPEG2を作れそうである。 ------------------------------------------------------------------------------------------------ http://homepage2.nifty.com/GNB/tutorial/s_scope/s_scope.htm →CCIR601キャプチャ。YUVをそのままエンコードできる環境で、編集なくエンコードするときにのみ有利だと思われる。aviutlでhuffyuvで入出力してやるのならば、aviutlによる編集ならば許せるか。 しかし波形表示フィルタという発想はいいのだが、そのできは何か怪しい。 ...今読むと私は何を書きたかったのかわからない。PC画面を見ながら編集(色調整とか)をしないで、ストレート変換でエンコードできるならば使えるってことか? このスケール調整は、TMPGEnc2.5で「YUVデータをCCIR601ではなく、BasicYCbCrで出力する」をチェック(RGB->YUVストレート変換)して使う時には使える。2.5を使わないのならばやめたほうがいい。 ------------------------------------------------------------------------------------------------ http://cwaweb.bai.ne.jp/~icchan/Data/color/CCIR601.htm →最後のaviutlの部分。「...(236〜255)が255となり潰れます。」は昔話だ。PC/TVスケール補正はいづれの場合も不要のはず。TVスケールで取っちゃった人がモニタ上で色を確認するときにPCスケール変換のチェックを入れるという位か。 http://cwaweb.bai.ne.jp/~icchan/Data/hard/saa7130b.htm PCスケール補正で調整する意味がわからない。 やっぱり波形表示フィルタを使っている辺りが怪しい。 ------------------------------------------------------------------------------------------------ http://www.marumo.ne.jp/bt601/ 「YCbCr ストレート変換の場合」「YUV -> RGB -> YUV -> RGB と変換を繰り返した場合の画質の変化が最小限に抑えられる」 →うーん、スケール変換してると本当にストレート変換よりも精度が落ちるのだろうか?YUV-RGB変換するときにストレートだろうが伸張・圧縮があろうが同程度だと思うのだが...(スケール変換したときに整数に丸めちゃうというのは論外として) ------------------------------------------------------------------------------------------------ http://www.google.co.jp/search?q=cache:x0aC8ypFeUUJ:niiyan.s8.xrea.com/avisynth/color_test2.html+huffyuvs&hl=ja&ie=UTF-8 データはいっぱいある。 元は(10,238)。 003=huffyuvをCCIR601チェックなしで出力(12,233) 004=huffyuvをBASICYCbCrチェックで出力(0,252) huffyuvがRGBにするときに伸張し、TMPGEncがチェックなし時には縮小、チェックありではそのままに出している。チェックなし時には辻褄は合う。 009=huffyuvSをCCIR601チェックなしで出力(23,216) 010=huffyuvSをBASICYCbCrチェックで出力(8,236) huffyuvSではRGBにするときにそのまま、よってTMPGEncチェックなし時には縮小され、チェックあり時にはそのままになる。数値の差はRGB変換誤差? 011=huffyuvをCCEでYUV読み込み(10,237) 012=huffyuvをCCEでYUV読み込み(9,237) 015=huffyuvをCCEでYUV読み込み(9,237) 016=huffyuvをCCEでYUV読み込み(9,237) 017=huffyuvSをCCEでYUV読み込み(9,237) 018=huffyuvSをCCEでYUV読み込み(9,237) RGBに変換やスケール変換がないまま出ているのでベストだと思われる...がなぜか微妙に値が変わっている。 013=huffyuvをCCEでRGB輝度レベル16-235読み(12,231) 014=huffyuvをCCEでRGB輝度レベル0-255読み(0,253) 状況は003,004と同じ。 019=huffyuvSをCCEでRGB輝度レベル16-235読み(22,216) huffyuvSがストレートでRGBにしてきたものをCCEが縮小している。 020=huffyuvSをCCEでRGB輝度レベル0-255読み(8,236) 途中RGB変換が入るが、最終的な辻褄は合っている。 ------------------------------------------------------------------------------------------------ http://www.google.co.jp/search?q=cache:tguCdZnvdaEJ:niiyan.s8.xrea.com/avisynth/color_test3.html+huffyuvs&hl=ja&ie=UTF-8 飽和には触れない。元データは(7,238) 006=huffyuvをaviutlでYUV読みし、huffyuvにYUV出力(7,238) 014=huffyuvSをaviutlでYUV読みし、huffyuvSにYUV出力(7,238) RGB変換もスケール変換もされていないので変化なし。 008=huffyuvをRGB読みし、huffyuvにYUV出力(16,235) huffyuvがRGBに変換時に伸張(自動的に上下が飽和)したものをaviutlが読み込み時に縮小して内部YUVに変換している。 010=huffyuvをYUV読みし、huffyuvにRGB出力(16,235) aviutl内部ではデータは保持されているが、出力時にaviutlがRGBで伸張→huffyuvがRGB->YUV時に縮小されている。 012=huffyuvをRGB読みし、huffyuvにRGB出力(16,235) huffyuvがRGBに変換時に伸張したものをaviutlが縮小して読み込む。出力時にaviutlが伸張したものをhuffyuvが縮小している。辻褄は合うがかなり無駄。 016=huffyuvSをRGB読みしたものをhuffyuvSにYUV出力(22,220) このスケール縮小はaviutlが読み込み時に勝手に行っている。 018=huffyuvSをYUV読みしたものをhuffyuvSにRGB出力(0,255) このスケール伸張はaviutlが出力時に勝手に行っている。 020=huffyuvSをRGB読みしたものをhuffyuvSにRGB出力(7,238) aviutlが縮小して読み込み、出力時に伸張する。辻褄は合う。 まとめると、aviutl0.99ではRGB読み込み時(YUY2で展開オフ時)に、縮小して読み込んでいる。またRGB出力時(YUY2で圧縮オフ)にも伸張したデータをコーデックに渡している。これによってhuffyuv使用時に辻褄が合う動作をしている。PC(Windows)では一般的な動きである。 この辻褄あわせによってhuffyuvSは立場がなくなっている。逆にこのaviutlの仕様によってRGB入力時にストレート入力ができなくなっている。困ったもんだ。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box11/tmpgenc_post_6519.html これまでキャプチャー時のビデオ形式 としてRGB24を選択していましたが、YUY2を試したところ、容量が少なく済みましたが、TMPGEncでエン コードしたところ、色がにじんでしまいました。静止画でいえば、減色したような感じです。  Google等で検索したところ、RGB24に比べて劣る形式でもなさそうなので、試しに、間にAviUtl をかますと、にじみはなくなりました。見た目、RGB24と同等。  これは、TMPGEncの特徴なのか、それとも、YUY2がRGB24に比べて劣る形式なのか違いを含めて教えて ください。 → aviutlではyuy2で展開するので元データのままだが、TMPGEncでRGB読みだとMS-YUVによって減色される...ってわけですね。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box02/tmpgenc_post_1089.html AVIファイルでは黒。 別のエンコードソフトを使って、mpeg1/2ファイルを作成しても 黒は黒。 AVIファイルからTMPGEncでmpeg1/2ファイルを 作成すると黒ではなくなる。 灰色に近くなる。(明るくなる) ソフトの仕様かバグか判断が付きません。 → カノープスDVコーデックだった。このデータはYUV系だが、これをTMPGEncでRGB読みしたときにコーデックがストレート変換してくる。そのままMPEGにすると縮小されるので黒でなくなる。 別のエンコードソフトはアドビプレミア。YUY2読みするのでそのままMPEGにされる。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box02/tmpgenc_post_1089.html MWMPを4ブロック(縦横2ブロック)で確認したところ、 右ブロックが明るく表示され左ブロックは黒く表示。 MWMPの問題みたいでした。 WMPで確認したところ、両方黒く表示されました(多分)。 〜返信〜 MultiWindowMediaPlayerでは、基本的に最初に読み込まれた動画が オーバーレイになります。 2つ目以降に読み込まれた動画はオーバーレイを利用しません(できません) また、この特性を利用することで、 1.ダミーの動画をWindowsMediaPlayerで開き、オーバーレイを占有させる 2.比較したい動画を複数、MultiWindowMediaPlayerで開く とすることで、MultiWindowMediaPlayerによるオーバーレイ利用を 抑制することが可能です(汗) → なるほど。オーバーレイの方が縮小され、GDIはそのままってことはnVidia系だろうか。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box15/tmpgenc_post_9006.html 始めまして、初心者なので困っております。ご指南ください。 DVDレコーダーで録画したTV番組など(MPEG2)をMPEG1やAVI(DviX)に変換した際、 出来上がった映像がとても暗いんです。設定はデフォルトのままでイジっておりません。 ”簡易コントラスト調整”とかで調整したら明るくはなるのですが、なんかギトギトした映像 になってしまうんです。FlaskでMPEG1を変換したら画面の明るさの問題は全くありません。 一体何が原因なのでしょうか?操作方法が悪いのですか?宜しくお願いします m(_ _)m (返信1) DVD2AVIをお使いのときは、「テレビ色調」にあわせてありませんか? MPEG-2 VFAPI Plug-inのときは、「ストレート変換」を使っていませんか? (返信2) と、したら、おそらくCyberLink MPEG-2デコーダーが使われている可能性が高いですね。 PowerDVDの設定の中にある「グラフィック」→カラーコントロールを 確認してみてください。デフォルトであれば問題なさそうですが。 (返信3) PowerDVDの設定の中にある「グラフィック」→カラーコントロールですが、デフォルトだったんですがエンコードした映像が鑑賞に耐えないくらい暗かったのです。 → この辺りがTMPGEncのいやらしいところ。みんなVFAPI経由になるので、どのインタフェースで読み込んだかわからないのだ。結局はPowerDVDの設定でビビットにしていたからのようだ。 最後の「デフォルトだと暗かった」というのはnVidia風味。 ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box21/tmpgenc_post_12168.html MotionJPEG(PICVIDEO)でキャプチャしたAVIを読み込んでMPEG1に エンコードしたのですが、元の画像よりも画質が暗くなって しまいます。 同じ設定のまま AVI(無圧縮、MotionJPEG)を出力すると 暗くはならないようです。 また、(余談ですが?)同じ設定でDivX AVIを出力すると MPEGと同様 暗くなります。 各MPEG、AVIの出力は[ファイル]−[ファイルに出力]−[AVI]([MPEG]) で行っているので、各種設定に差はないと思っているのですが・・・ [量子化行列]の「YUVデータを CCIR601ではなく・・・」には チェックを入れています。 (返信)  フツーのウインドウズだと、無圧縮のAVIはオーバーレイ表示しない事が多い。  で、MPEG1とかDivX AVIはフツーはオーバーレイ表示するはず。 (最終的に) プレーヤを2つ並べてみたら、同じファイルでも色が違いました。 見た目が違っただけのようでした。 → PICVIDEO MotionJPEGコーデック。これもまたストレート変換。なのでBasic YCbCrにチェック。合っている。 結局はビデオオーバレイで縮小されていたようだ。nVidia系? ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box15/tmpgenc_post_8777.html お世話になります。MTV2000でCBR15Mでキャプチャ→DVD2AVI(TVスケール)→AVIUTIL(CMカッ ト+時間軸ノイズ除去のみ)→TMPGEncのプロジェクトウィザードDVD用(フィルタ全部デフォル ト)で再エンコすると元のmpgと比べて明るいmpgになってしまいます・・(黒い服とか見るとよ くわかってしまいます)。試しにMTVのDV-MPEGファイルコンバータというので再エンコ(VFAPI 経由)でやってみたら明るさは変わらなかったので自分のやり方に問題があると思うのですが・・ TMPGEncで再エンコした方が画質がよくなるのでTMPGEncで再エンコしたいのです。誰かご教授 下さい(;´д⊂)。 (返信) TVスケールで渡した場合は 量子化行列タブにある 「YUVデータをCCIR601ではなく、BasicYCbCrで出力する」にチェックを入れて 出力します。 → ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box15/tmpgenc_post_8777.html 1.MTV2000で録画したmpeg2ファイル(15M)を、MPEG-2 VIDEO VFAPI Plug-Inを通してAVIUTLで直読み、編集、プロジェクトファイル作成→TMPGでmpeg2(8M)に 前述のプラグインの設定は「ITU-R BT.601から伸張」、TMPGの該当項目はチェックを入れてません。 2.MTV2000で録画したAVI(huffyuv)ファイルを、AVIUTLで編集、プロジェクトファイル作成→TMPGでmpeg2(8M)に TMPGの該当項目はチェックを入れてます。 (返信) 1.は、プラグインでYC伸張して、TMPGEncでYC圧縮するようにチェックを入れてません。だから最終的にはYC伸張する前と同じ色になります。 2.は、AVIがYC伸張してないので、TMPGEncでYC圧縮しないようにチェックを入れてます。 できれば、1のときにプラグインでストレート変換にして、TMPGEncでチェックを入れるようにすれば、YC伸張→圧縮の行程がなくなるのでよりよいと思います。 → ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box15/tmpgenc_post_8777.html AVIのCODECについてはよく把握してないのでMPEG1/2での話になりますけど 再エンコード後のデータを再生するときに オーバーレイプレビューやプレーヤーでの再生時と同じ色合いにするには PCスケール(BT.601から伸張)で渡した場合 → チェックを外す TVスケール(ストレート変換)で渡した場合 → チェックを入れる #TVスケール、PCスケールをTVで見るかPCで見るかといった意味で捉えない方が良いと思います。 #もひとつ。YUVのhuffyuvは伸張するんでないかな。 → ------------------------------------------------------------------------------------------------ http://bbs.pegasys-inc.com/bbscgi/search/docs/ja/tmpgenc/box00/tmpgenc_post_182.html 量子化行列のタブにある「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」の オプションについて教えていただけませんか? 実は、あおさんのところの掲示板 http://www.mao.gr.jp/bbs3/bbs.cgi での「DVからDVDで」というスレッドで、 カノープスDVのようにCCIR601に準拠したデータをMPEG2に変換する場合、 私は、 ・チェックあり Y=16-235のデータがY=0-255に伸張される ・チェック無し そのまま と考えていたのですが、相手の方は ・チェックあり そのまま ・チェック無し Y=16-235のデータがY=32-215に変換される と言われるのですが、どちらが本当なのでしょうか? (返信) その場合、後者が正しいです。 「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」のオプションは RGB->YCbCr 変換するときの変換式を切り替えています。 ソースがCCIR601に準拠していない一般的なRGBデータの場合、   チェックしない:RGB(0-255) を YCbCr(16-235) に変換する式が使われます。   チェックする :RGB(0-255) を YCbCr(0-255) に変換する式が使われます。 ソースがCCIR601に準拠している場合、   チェックしない:RGB(16-235) を YCbCr(30-218) に変換する式が使われます。   チェックする :RGB(16-235) を YCbCr(16-235) に変換する式が使われます。 となります。 RGBデータをCCIR601準拠のYCbCrデータ(16-235)に変換する必要がありますので Canopus DV Codec のようなソースの時点で既にCCIR601に準拠している場合は チェックするのが正しいです。逆にCCIR601に準拠していないソースの場合、 チェックしないのが正しいです。 → ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=9&page=30 [5704] 色ズレ 投稿者:鈴木その子 投稿日:2003/11/26(Wed) 19:18 テロップ部分で目立つ、色ズレを修正しようとしたところ あることに気づきました。 (色タイミング補正[茂木さん]のパラメータで、縦・横各-2くらいのズレ) MPEG2、中間出力AVI(huffyuv)のフォーマットしか確認してないのですが 99で認められた色ズレが、98dだと現れないのです。 98d、99ともに各種フィルタ無し(m2v.aui、m2v.vfp除く)の プレーンな状態でも、この現象を確認しました。 (色ズレを認識しやすくするためオーバーレイはoffの状態です) 自分の解る範囲で検証したところ 以下のような結果となりました。 ■ huffyuv設定による違い(ズレ無し○、ズレ有り×)      YUV展開する  YUV展開しない 98d AVI    ○      ○ 99 AVI    ×      ○ ■ MPEG2に関しては、m2v.aui、m2v.vfp 99の場合、どちらから読み込んでも色ズレが確認できます 98dでは色ズレはおきません ■ ちなみに、99の「システムの設定」で 『YUY2フィルタモード(プラグインフィルタが使えなくなります)』 のチェックを入れるとでも、この現象を回避できます このチェックを入れずに回避する方法はないものでしょうか。。。 同じ現象の方おられますか? また、どうすればこれを回避できるでしょうか? お知恵をお貸し下さい。 → まさに私が色ゴーストで書いた内容。YUY2で読んだときの内部展開方法が不可解なので発生している。-2にすると隣の色と補間されるのでズレが直ったように(RGB画面上では)なる。実際には右ピクセルデータが補間されただけで左ピクセルデータはそのままなので、YUY2出力時には元に戻ってしまう。 4:2:2->4:4:4補間をすると両ピクセルが補間されるのでYUY2出力にも反映される。=aviutlのYUY2出力がLeft origin(左ピクセルの色データしか見ない)ことの証明でもある。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=9&page=45 [5594] なぞ…? 投稿者:古い人 投稿日:2003/11/18(Tue) 16:24 いままでver0.96gを使いつづけてまして、 そろそろ最新版に移行しようといろいろ設定いじってたのですが、 ver0.99で読みこんで出力した動画の色調がいままでと異なっているように見えます。 明るさ・輝度が高くなり色の濃さが低く見えます。(肌色の違いがわかりやすい) けっこうはっきりと違いが目に見え、それぞれのバージョンで ”フレームをクリップボードにコピー”したBMP同士を比較しました。 同じフレームをWMPで一次停止して比べましたがver0.96gの画像の方が WMPと同等でしたので、ver99の方が変じゃないのかと不安です。 ちなみにPICVideo MJPEG Codecでキャプしたaviです。 他の人たちはこういった現象は起こっていないのでしょうか? → どうも0.99とそれ以前とではこの辺りのスケール変換具合が変わったようである。(昔のことは私にはわかりませんが)この続きでPICVideo MJPEG CodecはYUV->RGBでストレート変換だということで解決されいてる。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=9&page=70 [5527] WMVのスケール 投稿者:M(=L) 投稿日:2003/11/10(Mon) 18:25 WMVエンコについての質問です。 2chスレ、「YC伸張する?しない?総合スレッド」、「映像の【色】総合スレ」によると、 PCスケールでWMEに渡した方がいいようなことが書いてあります。 PCスケールでWMEに渡してエンコしたファイルを、 nVIDIA(GeForce4 MX 420 )のPC、内臓VGA (i815E) のPCで再生して検証してみました。 両環境ともPCスケールで再生されてるようです。 内臓VGA (i815E) のPCで二重伸張されないようです。 正解なのでしょうか? 自分の目が腐ってるだけなのでしょうか? abcさんのレスを切望してしまいます。 よろしくお願いします。 [5527へのレス] Re: WMVのスケール 投稿者:abc 投稿日:2003/11/14(Fri) 20:56 >ネタにマジレス さん 動画に関連した話題ということでちょっとだけ堪忍してください あまり続くようだと場所を変えますから。     M(=L) さん 最初に断っておくと、私はWMVは使わないので具体的なことは言いません。 でも、まずは問題を整理してください。 PCスケール、TVスケールという言葉だけを使っていると混乱してしまいます。 色空間と関連づけて考えてください。 ●(厳密じゃありませんが)問題を単純に言うと RGBフルスケール(0-255、PCスケール)=YUV BT.601規定スケール(16-235、TVスケール) となるのが、圧縮・伸張です。 また、 RGBフルスケール(0-255、PCスケール)=YUVフルスケール(0-255、PCスケール) (つまり、0-255->0-255(16-235->16-235)へと、又はPC->PC(TV->TV)へと変換する) のがBASIC YCbCrとかストレート変換とか言われているBT.601で規定されている変換方式です。 ●さて、あなたが言っているPCスケールとはRGBですかYUVですか? またWMVに渡すのはRGBですかYUVですか? (ちなみにAviUtlでプロジェクト渡しやVFAPI RCで参照型AVIにした場合は  AviUtlでYUVでも、伸張変換されたRGB24で渡すことになります) ●また、再生についてですが、 オーバーレイには、YUVオーバーレイとRGBオーバーレイの2種類があります。 RGBオーバーレイの場合は、モニタ出力と同じ形式ですので変換とかは無関係です。 ●再生は本当にオーバーレイかどうかも確認要です。 WinXP SP1(WMP8.0)やDirectX9.0だとオーバーレイミキサーの変わりに VMR7/9も使えます。VMR9で再生されると従来のlegacy rendarerや Overlayとはまた見え方が違ってくることも考えられます。 (VMR9ではビデオカードのH/W adaptive deinterlaceやpixel shader(video shader)やセカンダリディスプレイでの使用等、  ただし3D pixel pipelineが8ビットのチップだとオーバーレイの10bitより画質は落ち、またビデオ帯域を多く使うことになる) → (元質問の)結果は問題ないようなのだが、問題だったのだろうか?ここでおきていることを想像するに、 PCスケールでWMEに渡してエンコ  RGBでちゃんとしているものをRGB渡しならば、RGB-YUV-RGBでWMEに渡り、RGB-YUVでエンコ、YUV-RGBで再生で元に戻っている。それぞれのRGB-YUV間でスケール伸張・圧縮が行われている。  YUV渡しならば、RGB(画面)で確認、それがRGB-YUVでWMEに渡り、YUVのままエンコ、以下同じ。 abcさんの話はちゃんとしているのでついでに引用。この言い方で理解されるかどうかはともかく。 他の問答でもそうだが、abcさんはaviutlについて相当知っている。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=9&page=75 [5502] 無題 投稿者:トラブルです 投稿日:2003/11/08(Sat) 11:57 AviUtl97fを使わせていただいてます。 このたび99を使わせてもらったのですが、 aviを読み込ませると縦に線が入ってしまいます(特に背景が赤の場合)。 同じファイルを97fに読ませると線は入りません。 aviはhunuaaのhuffyuvでキャプチャーしたものです。 OSはwindows2000pro、sp4です。 非常にAviUtl99は使いやすいので、できれば99を使いたいのですがこの現象を解決しないことには使用できません。 文章だけでは縦線がどんなものかわかりにくいと思いますので画像をアップしました。 http://www2.makani.to/akutoku/upload/dat/1068259399.bmp jpgであげようとしたのですが、jpgだと縦線が少しぼんやりしてしまうのでbmpであげてます。 bmpのサイズは241kbです。 この画像は上記の環境で320×240でキャプチャーした画像をわかりやすくするため2倍に拡大し、 縦線が入っている以外のところをサイズを小さくするためカットしました。 どなたかお助けください。 [5502へのレス] Re: 無題 投稿者:abc 投稿日:2003/11/08(Sat) 13:16 0.99のバグでしょう。 YUY2ソースを読み込ませると起きると思います。 これ以外にも左上に目立つドットも現れていることでしょう。 修正されるのを待つしかありません。 ただし出力もYUY2の場合は問題ないかも知れません。 (またはRGBで読み込ませると消えるんではないかな?) 原因は多分色差が2pixel分ずれて対応しているのではないのかと思います。 → 色ゴースト問題。なるほど、縦に2pixel分ずれたところに補間しているのかも知れません。とするとその対策フィルタも作れそうですね。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=8&page=35 [5051] 連番読み込みすると輝度が変化してしまう 投稿者:Roshe 投稿日:2003/10/12(Sun) 20:41 ふぬああで録った連番のAVIファイルを、連番AVI読み込みで開くと輝度が変化してしまいます。 バージョン0.97fでは輝度の変化はありません。 0.98d、0.99でも単ファイルで読み込むと輝度の変化はありません。 これは連番AVI読み込みのバグなのでしょうか。 それとも 0.97f→0.98 で仕様が変わったのでしょうか。 → こんな話が。しかしフォローがなかったので詳細はわからない。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=7&page=45 [4307] バグ? 投稿者:pamun 投稿日:2003/08/22(Fri) 23:02 ver0.99になってから、AVI/AVI2 FILE READERでファイルを読み込むと(入力に使用したAVIのコーディクは、MS MP42、DIVX4、DIVX5.05しか試してません) 必ず、左上にゴミが出ます。 同じver0.99でもVFW経由のREADERで読み込むと出ません 又、前verでも同様にゴミは出ません [4307へのレス] Re: バグ? 投稿者:   投稿日:2003/08/23(Sat) 18:26 プレビューだとでるけど、出力するとノイズはのってないですね。 [4307へのレス] Re: バグ? 投稿者:abc 投稿日:2003/08/23(Sat) 21:55 いえいえ、出力してもノイズは出てます。 ただし、YUY2入力してRGB出力時した場合ですが。 無圧縮(RGB24)とHuffyuvとで試しました。どちらもプレビュと同じくゴミが追加されます。 YUV->RGB変換がチョンボしてると思います。 なので、VFAPIも影響を受けます。(aupで受け渡す場合です) → これはYUY2展開の問題だ。右ピクセルは周りから補間しているわけだが、この際におかしくなっているようだ。VFW READERでは問題ないという。で、やっぱりYUY2出力では出ない(左のみ使われるので)が、RGBではそのままなので問題あり。 ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=7&page=30 [4339] YC伸張 投稿者:M1000 投稿日:2003/08/26(Tue) 16:53 AVIUTL0.98以降はコーデック入出力がYUY2対応しているようで 今までずっと MTV2000→DVD2AVI(PCスケール)→AVIUTL(098d YUY2圧縮展開にチェック)→DivX5.02 でエンコしていましたが WMPなどで再生すると編集時の色よりさらに伸張されていることに気づきました。 どうもコーデックに渡されるときにYUY2圧縮されずエンコされてしまい、ビデオオーバーレイで2重にYC伸張されているようです。 みなさんYC伸張どうなさってますか? [4339へのレス] Re: YC伸張 投稿者:流れ者 投稿日:2003/08/30(Sat) 23:08 ↑の手順が正解となるのはDVD2AVIが1.76系以外の場合です。ver.1.76は変換処理にミスがありPC変換時に白トビいたします。二重伸張まで行きませんが1.3重伸張くらいになりますね。 また再生環境がIntel845G系ですとデフォルト設定ではYUVオーバーレイ時に1.5重伸張くらいになります。 →そうだったのかー ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=16&page=124 色ずれ 投稿者:ハヤテ 投稿日:2004/12/08(Wed) 01:05 No.9800? 今までAvisynth2.5を使用していたのですが、ノイズ除去、ノイズ除去(時間軸)共にAviutlの方が高性能と気づき変更しようと思ったのですが、AviUtlで読み込むとAvisynthの時よりも下方向に僅かな色ずれ(色滲み?)が発生してしまい悩んでいます・・・。 MPEG2ファイル(MV5DX)をDVD2AVIでプロジェクト保存した物を読み込んでいます。 よろしければ解決策をお教え頂けないでしょうか? よろしくお願いします。 Re: 色ずれ aui - 2004/12/13(Mon) 15:29 No.9828? DVD2AVIプロジェクトをVFAPIで読むと、縦横両方向に補間が入ります。YV12->RGB24の時の補間です。これが影響していると思います。DVD2AVIのバージョン(派生もの)によっては補間のないものがあるかもしれません。 ちなみにm2v.auiを使っても縦方向の補間が入ります。 http://www10.plala.or.jp/p205tb16/aviutl_filter.html ここに補間がないと謳っているものがあります。 Re: 色ずれ あじ - 2004/12/14(Tue) 13:15 No.9835? http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html ここのFigure4を見てください。 インターレースのMPEG2では、色のサンプリング点と輝度のサンプリング点が縦方向にずれています。 m2v.auiではこれを線形補間して出力しています。 補間がないというのは変な表現なので、恐らく近傍補間していると思います。 その場合、奇数フィールドと偶数フィールドで色のずれ方が違う画像になってしまうので注意が必要です。 AviUtlの内部形式は4:4:4なので、インターレース4:2:0を読み込んだ場合に 縦方向の色滲みが発生するのは、基本的に避けられません。 対策としては以下のようなものが考えられます。 ・Avisynthで全部YV12のまま処理する ・キャプチャフォーマットをMPEG2などのYV12のものから、huffyuvなどのYUY2のものに変更する ・m2v.auiの線形補間を、より高度な補間アルゴリズム(ランチョス法、輝度のエッジ検出を使った処理など)に改造する ・そういうものだと思って我慢する →  なぜか勝手にリンクされていたもの。まあリンクは勝手にどうぞなのでイイのだが。この話、Avisynthを使ったときのYUV420からYUY2への補間の仕方と、DVD2AVIでAviutlで読み込んだときの補間の仕方(これはDVD2AVIがやっているわけだが)が異なっている、ってこと。この人がどうAvisynthを使ってどう確認したかが書かれてないので、前者の補間がどこで(Avisynthなのかフィルタなのかデコーダーなのかプレイヤーなのか)行われているのか分からないが。  で、AvisynthでOKだったんなら、それと同じ補間をかけてやればいい話。補間なしとかを見せると「なにコレ」って言われるのがおち。ノイズ除去とか言ってるのでアニメだ→ノンインタレース化って流れが予想できるし。補間なしで読み込み後、適当なYUV420->444フィルタで気に入ったものを使用すべし。補間後にノンインタレース化するのがいいのか、ノンインタレース化したものを補間するべきかは知らないが。  というか、本当に補間の問題なのか? ------------------------------------------------------------------------------------------------ http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=past&pastlog=15&page=147 [9043] 色彩について 投稿者:MBF-02 投稿日:2004/09/30(Thu) 00:00 MPEGファイルに変換の際には、毎回こちらの「AVIUTL」を使っているのですが、いろいろ工夫しても元データの色にならないのですが、何か方法があれば教えてください。 [9043へのレス] Re: 色彩について 投稿者:MBF-02 投稿日:2004/09/30(Thu) 17:42 すいません、説明が間違えていました。 MPEG→AVIへの変換でした。 手順なのですが、色調補正なしで変換をすると、全体的に色彩が暗い感じになってしまうので、補正をするのですが、うまい感じに元の色ができません。 [9043へのレス] Re: 色彩について 投稿者:ぢん 投稿日:2004/09/30(Thu) 18:09  暗くなる、っていうのが、元MPEGを再生した時・MPEGをAviUtlで読み込んで表示した時・AVI保存して再生したとき・AVI保存した後にそのAVIをAviUtlで読み込んで表示したとき、のどの時点で発生しているか確認して書いてくれれば、ある程度推測は出来ると思うけど。  MPEGはYUV系でTVスケールだから、拡張色調補正で「TV -> PC スケール補正」が要る、ってケースとか?  黒が明るく、白が暗く、成るんだったら、このケース。  黒がより黒くつぶれて、白が暗くなる、だったら、AVIで使ってるコーデックの仕様か、ビデオカードのオーバーレイ表示時の画質設定が影響してる場合も。 [9043へのレス] Re: 色彩について 投稿者:MBF-02 投稿日:2004/09/30(Thu) 19:24  いろいろ説明ありがとうございます。  当方は、「AVI保存した後」に「黒がより黒くつぶれて、白が暗くなる」ケースなので、codecを変えるなりしてまたやってみます。  まだ初心者なので、またお聞きするかと思いますが、その時は、なるべく詳しく説明させてもらうのでまたお願いします。 → ------------------------------------------------------------------------------------------------ 初めまして。 投稿者:あきぴょん 投稿日:2005/03/19(Sat) 03:52 No.10789 普段の使い方として、カノプのMTVX2004HFでIflame 25000kbps(要するに最高画質)で録画した.m2p(ほとんど映画とかドラマ)ファイルを、DVD2AVIでプロジェクトファイルを作成、SCMPXでWAVEヘッダMP3に変換して、御AVIUTLを使用して、DivXに720*480のAVIファイルに変換する使い方をしています。(DivX5.2.1を使用) そして作成したファイルについては、パソコンでそのまま見るか、S端子→TV出力で、閲覧しております。 ここで少し意見を伺いたいのですが、AVIUTLにてエンコード中、ノイズフィルタはWavelet3DNR2のみを使用しているのですが、ノイズ除去しか行わないために、映像自体がすごく暗く感じます。 そこでフィルタを色々いじっている間に、拡張色調補正を発見しまして、TV -> PCスケール にチェックを入れると、画面が明るくなり、テレビっぽく見えるようになると感じたのですが、皆さんはこの拡張色調補正というのはどのような目的で使われていますか? また、普段はこの補正は使うべきなのでしょうか? 自分の求める映像の目標としては、出来るだけ映像ソース(色など)に改変を加えず、標準で、実際動画の色がおかしいと思ったら、AGP(RADEON9600)やPCディスプレイ(TOTOKU CV821X)やテレビ自体(SONYのやつ)の色設定をして観たいと思っています。 どの動画もそのようにすれば、もし動画をよそで見たときにも、テレビの設定自体で良好さが保てるかな?と思ったからです。 もしよろしければ、いろんなご意見をお願い致します。 → 状況ははっきりとしていない。調整しないとおかしいかも知れないのも当然。としても結構情報は与えらているわけで、これで判断できることもある。そもそもTV->PCスケール伸張するくらいというのは調整とかいうレベルではないのではなかろうか。 ・2004HF おそらくそれなりに調整されているはず。 ・AVIUTL 他にいじってないなら問題なし。 ・DivX  問題ない ・DVD2AVI PCスケールか怪しい ってことで作ったファイルはDVD2AVIの設定を間違えていない(PCスケールにしている)ならばあまり問題はない。 ・RADEONオーバレイは合うはず ・CV821X(CRT)怪しい 問題はこっち。私もCV821を使っていたのだが、これをPCモニターとして使うためにコントラストを落としていくと黒がつぶれて色も薄くなってくる。この状況に似ている。ちなみに黒がつぶれないように輝度を上げると今度は黒浮きしてくる。 またRADEONのビデオオーバーレイとの相性も悪く、Radeonがきれいに見えない。ビデオをnVidiaにしていわゆるカノプー調整をする(デスクトップの輝度・コントラストを落とす)と見違えるような素晴らしいモニターだと思うのだが...今でも壊れずに使えているというのはうらやましい。 というわけでRadeonのビデオオーバレイのしょぼさがモニターの特性と合わさってより強調されていると予想。ビデオを見るときにはモニターの設定のコントラストをずっと上げてやってくれ。 ------------------------------------------------------------------------------------------------ 無題 投稿者:haro 投稿日:2005/05/27(Fri) 08:26 No.12107 aviファイル作成時に特に輪郭部分にノイズのようなものが出てしまうのですがこれはaviutlの仕様なんでしょうか? 編集中は気にならないのですが作成したファイルを再生してみるとかなりノイズ(ようなもの)が目立ちます。 → あっさりと「仕様ではない」「他の人のところでは何の問題もない」で斬られてしまっている。 これってもしかしてYUY2展開バグ?とか思ったが、ソースにはノイズは確認できないと言ってるから違うか...どうやってソースを確認したのか不明ではあるが、Aviutlに入れたところで見えていれば申告するだろうし。 ------------------------------------------------------------------------------------------------ 706 名前:名無しさん@編集中[sage] 投稿日:2008/02/23(土) 11:12:04 Utlってどういう風に色空間変換してるの? AVS(YV12)を読み込んでそれをHuffyuvで圧縮したのですが、 プレビューで表示されてる画像にはバンディングが出てないのに 圧縮後のやつはバンディングが出ていたので、 Huffyuvは可逆圧縮だから色空間変換が原因かと思ったのですが。 729 名前:名無しさん@編集中[sage] 投稿日:2008/02/23(土) 15:51:14 ... YUVを表示するときバンディングが出るのは、モニタはRGB表示なのに YUVの方がRGBより表現できる色数が少なく、いくつかの色が表現できないことが原因。 ... 809 名前: ◆MakKi3ZtD. [sage] 投稿日:2008/02/24(日) 04:49:08 ... 一応、発端のバンディングとの絡みについてまとめておきます。 1. Huffyuv等で出力した時のバンディングの発生原理は、>>729の後半にある通りで  表示時にYUV→RGBで伸張変換をしているため。(AviUtlとは無関係) 2. AviUtlの Y:16-235,UV:16-240に飽和する のオプションはYC伸張圧縮とは無関係。 → 話は合っていると思うが、最初の質問者はAVSを読み込んだ時点のプレビューでバンディングに気づかなかったのだろうか。オーバレイ表示だろうか。