2017年10月17日

【エンコード】ダウンサイズ×銀色での妥協

↓2)改稿2017/10/26...20171017...

> 銀色や金色は中間色の螺旋でできている
> だから、「高解像」×「秒間高フレーム」ほど美麗だ


 ‥ということで、ダウンサイズするなら
 まず、銀色のピンボケ感を諦めなければならない

 これは、どんなに頑張ったって物理的に無理というもの

 そもそも金属&鉱物光沢の輝きの再現にこだわるなら
 始めからFHDで挑めば良い、無理にダウンサイズエンコードで挑戦することでは無い

 とはいえ、4k映像の登場は、そこに執着した要望も有ったように思われる
 (光の表現の再現性の追求に対して、こだわった技術陣も居ったと)


> 裏返せば
> 金属光沢の色合いがどれほどに再現されているかが、エンコード品質の一つの基準とも言えそうだ


 金属フレームバリバリの映像を眺めたいなら、そりゃSD画質よりHD画質だよ
 (ハリウッド映画やレーシング好きならそういうことにもなるだろう)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 22:45 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

【AVC】CABAC×視覚心理補正の怪

記稿.2017/10/17

> CABACとは


 つまり、ビットレート量子化の単純な印象は
 波のパターンの大小の組み立てにあるのだから、そのままだと
 細かい細部の再現性が、どうしても、イメージとしてもモヤッとするだろうと想像が付く

 実際、このCABACの選択をオフにすると
 画質が、一気にぼやけた感じに陥り、抜け出せない
 (これは、ビットレートを増やしても同じだろう、非効率だ)

 ‥そこで検討されたのが

 輪郭周辺の補正としてのCABACということのようだ
 (なんでも、輪郭周辺にノイズを加えて、見かけ上の見映えを演出するという)

 ノイズを加えると言っても、元画を参考にはしているように思われる
 しかし、それにしてもノイズでしかないのだからやり過ぎは禁物である


> さて、具体的には、どのような劣化が起こるかというと


 昭和の時代のフィルム感度は、暗いところになるとかなりあまい
 ウォッシュリンクしてみると、その動きのへんてこさに驚く
 ‥ただでさえモヤモヤしているのだ


 この手のフィルム特性からくるモヤモヤは、黒い部分での感度全体に及んでいるようで
 巨大な重機のタイヤのアップめシーンでも同じだ

 ‥こんな場面での、CABACの強度調整で気をつけたいのが
 Psy-Rd(視覚心理最適化)項目、trellisの数値変更である‥0.00(デフォルト)


> RODの方は、解像度に合わせて、見合った分だけ上げてやると見映えがよくなるが
> trellisは、デフォルトのままが無難だ


 ‥trellisの値を 0.05も上げると
 モヤモヤしている映像をさらに強調して、モコモコとして気になり出す
 0.1よりさらに上げていくと、モヤモヤはボコボコに変形してしまう(あきらかに失敗エンコだ)


> RODでも気をつけたいのが


 ‥輪郭の印象の基準をどこに目を付けるかである
 人物の見映えに水準を見出そうとしても、背景の印象の方が、先に度ギツくなってしまう
 ので、適当な背景のパンを見つけて、そこから調整の度合いを見極めてみる方が無難だ


> ついでに


 細部の再現性を上げる項目に
 フレーム一枚あたりでのビットレートの割合の度合いを決める項目がある

 AQ(適応的QP)の項目、「AQ強さ」である

 ビットレートの配分に影響しているので
 割り当てるビットレートの絶対量が少ないのに、輪郭への割り当てを多くしても
 輪郭周辺に対して、ブロッキングの要因にしか成らない

 (あと、解像度の違いでも、適切な値は変わるだろう)
 (2パスと品質基準でのエンコードでも多少違うらしい)
posted by 木田舎滝ゆる里 at 00:33 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

2017年10月16日

【AVC】シーンカット閾値(いきち)の怪

↓1)改稿.2017/10/16...20171016...

> シーンカット閾値(いきち)とは、Iフレームをどこで入れるかの識別度合いの値です
> AVCの場合、デフォルトは(40)です


 ‥さて、このシーンカット閾値(40)の振る舞いが
 「参照距離」×「最大連続Bフレーム数」の値次第で変わるのをご存じでしょうか?

 参照距離が変わると、Iフレームの総数も変動します

 参照距離が伸びる程に
 Iフレームは数を減らし、代わりにPフレームが増加します
 (オープンGOPでは関係無いように思われます‥未確認)

 Pフレームが増加すると
 Bフレーム参照の遅延が減るのかなと‥不思議に思うところですが
 不思議と、動きの質が向上します


 ‥素人解釈の思い込みだと
 「参照距離が伸びるとBフレームの方が多くなるはずだ」

 実際、多くなるブロックもありますが、Pフレームもしっかり抽出するので
 アニメに思いがちな2コマ撮り3コマ撮りの図式でキッチリ算出されるわけでは無いようです


> 4フレームなら色味重視(Iフレーム数が多い)
> 5フレームなら色味と動きのバランス重視
> 6フレームを越えると画質が赤っぽく劣化を始める(アニメ3コマ撮り作品はさほど気にならない)


 ‥で
 どのぐらいの差が起こるのかというと
 風速8〜12mの風が、時折吹いた後の枝の揺れの残像が正しく再現されるかされないか
 という‥葉と葉の揺れの頂点をきちんと検出するかどうかです(実写)

 Bフレームに割り当てるビットレートが足りないと、正しく再現されません
 その点Pフレームに検知があって、ビットレートが十分だと正しくなります

 ‥この傾向は
 一枚ごとの画像比較では、どうにも識別できないので、動画にて確認するしかありません


> さらに、言うと‥動き探査範囲の値が低いと、シーンの細部検知と画質に劣化影響するようです
> レート制御先行探査フレーム数の考慮も欠かせません


 ‥まぁざっくり、秒間24フレームの映像なら

 シーンカット閾値(40)に対して
 レート制御先行探査フレーム数(65)‥あまり長いと音声の再現性で処理遅延が出る感じかなと
 動き探査範囲(32)‥Uneven Multi-Hexagon、11(Full RD)

 参照距離(5)
 最大連続Bフレーム数(4)
 適応的Bフレーム挿入:完全‥が限度一杯といったところでしょうか
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 23:11 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

2017年10月15日

【参考】ビットレートを数学的に妥協する‥補足

記稿.2017/10/15

> AVCエンコードのメインをXMedia Recodeから、AviUtlの拡張 x264 出力(GUI)に変えた


 ‥理由は、AviUtlの拡張 x264 出力(GUI)の方が
 エンコード結果をログ出力でき解析しやすいからだ
 あと、より細かい数値でのエンコードをサポートしている

 なにより、ウォッシュリンクした設定からの直接エンコードに対応する点が大きい

 ‥ということで

 エンコード結果のIフレームの総数と平均バイト、同じくPフレームとBフレームのそれぞれが
 その都度示されるのを見比べていると
 Pフレームの大きさの比率は、概ね

 {I:P:B}={4:2:1}‥ということのようだ

 この割合は

 IーPフレーム関係数(%)40(デフォルト)
 P−Bフレーム関係数(%)30(デフォルト)
 ‥で示される設定に基づいている。(通常、この数値をいじる必要は無い)


> ということで


 P=27分の1にこだわるなら
 I=27分の2、B=54分の1ということになる

 (実質的には、Iフレームは画質に大きく関係するので2倍よりちょい大きめの比率だ)
 (又、オープンGOPを用いない限り、概ねIフレームの比率に神経質になる必要は無い)
 (尚‥オープンGOPでエンコードした場合、TVでのUSB再生時に早送りと巻き戻しが効かない)


 フレーム構成で考えられる最大と思われる構成のベースタイプ@
 (P)+(P)=54分の4

 フレーム構成で考えられる平均と思われる構成のベースタイプ@
 (P)+(B)=54分の3

 フレーム構成で考えられる最小と思われる構成のベースタイプ@
 (B)+(B)=54分の2

 最大:平均:最小=4:3:2


> 720x540(カラー)解像度の場合
> 1166400バイトをキロバイトに直すと、1139.0625KB


 ‥ベースタイプ@で秒間24フレームの場合
 {(P)+(B)=54分の3}×12
 1139.0625÷54×36×8‥(キロビットレートに換算)

 最大:平均:最小=8100:6075:4050(キロビットレート)


> 算出された6075キロビットレートでエンコードしてみると
> Pフレーム平均27分の1を下回ってしまうケースが多発する


 ‥そこで
 前回の‥最大:平均:最小=8775:6480:5670(キロビットレート)
 の平均を取り出して
 最大:平均:最小=4:3:2に直してみた


 最大:平均:最小=8640:6480:4320(キロビットレート)


 ‥こちらだと上手く行く(その誤差平均値270分の1)
 Iフレーム考慮の補正分ということだろうか??

 ‥「え?」、最大と最小の違いがどれほどに関係するのかって?
 ‥以前との違いはあるのかって?
 ‥そこは、個人の趣向です(どうせなら、すっきりした数値を使いたいと言うことです)


 ※ これで抽出された1話25分もの動画に音声AAC(576Kbbs)を追加すると
   概ね1.25GBになる(2PASS)

 (DVDよりは小さく収まる、それでいて画質比は単純2倍)
 (BDからのダウンサイズだといささか複雑だが、DVDとの比較ならまぁさほど気にならない)
 (‥目的がウォッシュリンク映像での抽出だから)
posted by 木田舎滝ゆる里 at 22:55 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

2017年10月10日

【参考】エンコードの量子化とは?

記稿.2017/10/10

> 量子が波を意味するのはわかるが、エンコードにおいてそれは何なのだ?


 エンコードの量子化と、JPG圧縮に見られる格子状の区切りが
 何をしているのかがわかるイメージを見つけました


 dct_morino.png

 参考:http://www.nnet.ne.jp/~hi6/lab/quantize/index.html


 ‥デジタル信号に置き換えられた映像は光の成分です
 光の成分を分解するにおいて、四角のマスに区切ると
 上のイメージのような単調なパーターンに分類できるようです
 これを量子化と表現するらしい

 (CGに着色するときの筆のパターンなんかもこれです)
 (Σとlogが出てくる方程式で導けるようです)
 (パーターンを算出する上での計算に、格子のサイズ枠が欠かせないと言う事です)
 (その格子の中で波打つパーターンを導いて、重ねて再現します)


 ‥で、仁王像のような木像を思い浮かべてみましょう
 土台と成る大きなパーツの上に、小さなパーツを順に重ねていきます
 フィギアでもそうですが、大きなパーツの上に小さいパーツを足していくのが一つの形です


 ‥映像の量子化も同じことで
 大きな区切りをまず算出して、順繰りに小さいパーツを置いていきます

 ‥この時、ど素人でも気がつく事が一つ
 光を重ねると白に近づくということです
 つまり、暗めの画像の方がエンコードに有利
 明暗の差の激しい画面ほど、計算が大変で、ビットレートを多く必要とする

 ‥まぁ実際、どのように分解して重ね直すのか
 なんとなくでしかイメージできませんが
 量子化する上での細かさがピンボケしていると上手く行きそうも無いことだけは想像できます


 ‥で、ヒトの感覚的に
 大きなブロックには、大きな量子
 小さなブロックには、小さな量子
 なら、圧縮率が上がるだろうと思う訳ですが
 光の性質(重ね合わせ)は至って均一なので、そういう解釈には無理があるらしく
 粗い波の上に表現を乗せるにも、土台の粗さに合った、細かさの許容(バランス)が絡むようです
posted by 木田舎滝ゆる里 at 09:58 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

2017年10月08日

【参考】ビットレートを数学的に妥協する

改稿.2017/10/08...20171007...

> 動画をエンコードする際、ビットレートを割り振らなければならない
> どうやって妥協するか‥そこが問題だ‥


 まず、一枚あたりどれほどに圧縮されるのか?
 ‥ここが実に気になる‥

 どれぐらいの圧縮比なら満足の許容なのか?
 ‥ここが実に気になる‥

 で、得られた解釈が
 Iフレーム9分の1
 Pフレーム27分の1
 Bフレーム45分の1
 ‥という具合にして計算してみた(比率感はさほど悪くない)


 秒間24フレーム構成で考えられる最大と思われる構成
 {(I)+(P×23)}=27分の26(135分の130)

 秒間24フレーム構成で考えられる最小と思われる構成(4フレーム間隔想定)
 {(P)+(B×3)}×6=45分の28(135分の84)

 秒間24フレーム構成で考えられる平均と思われる構成
 {(P)+(B)}×12=45分の32(135分の96)

 最大:平均:最小=130:96:84=65:48:42


 * これは、AVCシーン変更感度(40)&GOPどちらかというと無し想定での話です


> 720x540(カラー)解像度の場合


 1166400バイトをキロバイトに直すと、1139.0625KB
 1139.0625÷135×{130,96,84}×8‥(キロビットレートに換算)


 最大:平均:最小=8775:6480:5670(キロビットレート)


 ‥ちなみに
 6480キロビットレートだと、特撮&アニメの52話シリーズが64GBのUSBに収まらない

 ‥どうしてSDサイズなのかというと
 HDサイズだと、計算上、解像度比分の色見があせるので、泣く泣くSD選択っす‥
 (色味の許容というか再現品質の理想的解釈が、Pフレーム27分の1というところかと)

 ‥ちなみに
 HD画質ならこれの1.77777777777‥倍(端数切り上げ)
 FHD画質ならこれの4倍で
 16:9なら‥それぞれさらに1.33333333333‥倍(端数切り上げ)
 計算のし直しが必要だが単純に‥30フレームならさらに1.25‥倍(端数切り上げ)


> しょうがないので、ここから0.xx倍とかに下げて妥協します(痛ぁああ)
> でも、実際には444から420に減衰されるので
> 0.625倍してから、1.x倍した方が、すっきりした数値を得やすいです



 4フレーム間隔より多く取ると、どこかの項目設定次第では、動きの欠損率が上がります
 (これでは、ほとんど出荷品質だよ‥HEVCでは自動化されてるみたい)

 (アニメの1話25分が2GBとか、どんなに大好きでもうれしくないので1GBちょいに収めたい)
 (許容できても1.5GB以内かな‥DVDとさして変わらねぇ想定だな)
 (‥早いとこ、1TBのUSBメモリーが手軽に買える時代になって欲しいっす)
 (‥というか、HEVC再生できるテレビの方が選択支としては大きいかなと)
posted by 木田舎滝ゆる里 at 00:12 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

2017年09月21日

【Wash Link】R(offs)R(gamm)G(gain)値を再び0に変更

記稿.2017/09/21

> 再エンコードテストを色々と確認している内にふと気がつきました


 β版の実写の色合い−(色の濃さG倍)は、再エンコードには赤すぎて
 β版のアニメの色合い0は視聴するには、物足りなさを感じてしまい
 こんがらがっていましたが、実写に合わせてみたところ
 それぞれで異なっていることを確認しました

 β版のアニメの色合い0は、そのままで再エンコードすると、不思議と違和感が相殺されます

 ‥で
 実写の色合いの算出をどう補正するかと言うことになりまして‥


> −(色の濃さG倍−基本値)
> ‥に置き換えて再エンコードすると違和感少なくなります‥(一覧記事修正済み)


 ‥ついでに

 Cb(gain)とB(gain)
 Cr(gain)とR(gain)は、呼応しているんじゃないかと思いまして
 ならば
 G(gain)=1の状況は、アンバランスではと思いまして

 改めて確認してみたところ

 R(offs)=R(gamm)=G(gain)=0の方が、再エンコード時の誤差が減るようです


 ‥これは
 AviUtlの内部のカラー処理の問題と
 実際のRGBの数値のそれぞれの値の幅が異なっているので
 0にしておかないと正しい割合に整わないようです

 (256段階の表記の上に0が表示されているわけですから、0で良かったと言うことになります)

 アニメセルとCGの合成過渡期の色合いのウォッシュリンク置き換えの正確さにおいても
 僅かながらの差が確認できました

 (‥やれやれ、訂正ばっかやん、すまん‥m(_ _)m)
posted by 木田舎滝ゆる里 at 20:30 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

【AviUtl】ウォッシュリンク数値のコントラスト見直し(写真版)

改稿.2017/09/21...20170918..20170917...

> 色の濃さを増やしたことで、明るさへの許容が広がっていたらしく
> アニメ&実写ともどもさらにコントラストを上げた方が、色のくすみが解消するようです
> ‥が、再エンコードすると赤味が強く出すぎて失敗しやすい傾向のようです


 ‥概ね、減衰しない写真向けということかな‥
 と言うことで


<色調補正> 写真版‥左列からレベル0、1、2‥
明るさ   : 42、 47、 51、 55、 59、 63、 68、 72、 76、 80
コントラスト: 42、 47、 51、 55、 59、 63、 68、 72、 76、 80
ガンマ   :−16、−18、−19、−21、−22、−24、−26、−28、−29、−31
輝度    : 26、 29、 31、 34、 37、 39、 42、 45、 47、 50
色の濃さ  :111、122、133、144、155、166、177、189、200、211
色合い   :−(色の濃さ)


<拡張色調補正> 写真版対応
Y(offs):26、29、31、34、37、39、42、45、47、50(左からレベル0に対応‥以下同)
Y(gain):−42、−47、−51、−55、−59、−63、−68、−72、−76、−80
Cb(offs):−2、0、、4、6、8、10、12、14、16
Cb(gain):概ね‥79(これ以外のパターンも有り得る‥ 最大値目安は|128|or|色の濃さ|)
Cr(offs):、0、−1、−2、−3、−4、−5、−6、−7、−8
Cr(gain):概ね‥−49(これ以外のパターンも有り得る‥最大値目安は|128|or|色の濃さ|)
R(offs):
R(gain):−49
R(gamm):
G(offs):−49
G(gain):
G(gamm):98
B(offs):−128
B(gain):79
B(gamm):256


 *ただし、それそれRGB24ビットでの編集状態であることが欠かせません


> コントラストを上げてさらに明るさが増したので
> 写真では、明るい風景ならレベル2、暗い風景ではレベル0で良い感じになるようです


 コントラストを上げると、見た感じは改善した感が増しますが
 再エンコード(動画)すると、減衰の影響をもろに受け(444→420)
 無駄に赤味が増しただけだったのがはっきりとし
 わざわざ、色合いを右に振らないとダメのパターンに嵌まるようです


 ‥実写、アニメとも、β版以上にコントラスト上げ再エンコードは鬼門のようです
 ‥ということで、サクッとレベルを上げるか、下げるかかが好いかも
posted by 木田舎滝ゆる里 at 19:46 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

【AviUtl】ウォッシュリンク数値見直し(アニメ)

改稿.2017/09/21...20170918..20170916...

 *ウォッシュリンク(Wash Link)‥ここでの名称。暗がりを消しつつ色味を艶やかにする意。

 ‥実写でのノウハウをアニメに応用してみたところ
 明るい場面は横ばいに、暗い場面は適度に明るめに、黄色のバランスが良くなりました
 (どうして双方のバランスが維持されるのかが不思議ですが、まったく分かりません)


<色調補正> β版‥左列からレベル0、1
基本値   : 10、 11

明るさ   : 42、 47
コントラスト:  0、  0
ガンマ   :−16、−18
輝度    : 26、 29

色の濃さ  :↓69、↓75
色の濃さG倍:111、122

色合い   :0(作品により必ずしも0に限らない)


> ‥色の濃さの幅が上がった影響がそれなりに出ますが
> 実写とは異なり、アニメの場合は、色合い:(色合い0−基本値)で視聴するのも有りです
> 再エンコードする場合は、(クセの無い場合に限り)0がそのまま適値のようです


 ‥明るめが気になる向きもありますが
 レベル0の暗めに納得できない場合は、サクッとレベル1に移行するのがよろしいかと



<拡張色調補正> β版対応
Y(offs):26、29
Y(gain):−42、−47
Cb(offs):(作品により必ずしもこれに限らない)−2、0
Cb(gain):(作品により必ずしもこれに限らない)0
Cr(offs):(作品により必ずしもこれに限らない)、0
Cr(gain):(作品により必ずしもこれに限らない)0
R(offs):
R(gain):−49
R(gamm):
G(offs):−49
G(gain):
G(gamm):98
B(offs):−128
B(gain):79
B(gamm):256


 *ただし、RGB24ビットでの編集状態であることが欠かせません
posted by 木田舎滝ゆる里 at 19:44 | Comment(0) | エンコードが始まらない | 更新情報をチェックする

【AviUtl】ウォッシュリンク数値見直し(実写)

改稿.2017/09/21...20170919..20170915...

> |ガンマ|:|輝度|:|コントラスト|:|明るさ|:|色の濃さ|=隣り合うそれぞれ黄金比


 ‥ということで
 ガンマ値を列に置き、黄金比数値(1.618033)を掛けて
 黄金比倍々して得た数値を単純に四捨五入して、整数値で並べたのが下の一覧です

 10、16、26、42、 69、111、179
 11、18、29、47、 75、122、197
 12、19、31、51、 82、133、215
 13、21、34、55、 89、144、233
 14、22、37、59、 96、155、251
 15、24、39、63、103、166、269
 16、26、42、68、110、177、287
 17、28、45、72、117、189、305
 18、29、47、76、123、200、323
 19、31、50、80、130、211、341


> 改めて見ると、六列目が、非常に興味深い数値の並びに気がつきます
> これを採用しないという手はなかったと言うことで、今回分は、数値の見直しということです


<色調補正> α版‥左列からレベル0、1、2‥
明るさ   : 42、 47、 51、 55、 59、 63、 68、 72、 76、 80
コントラスト: 26、 29、 31、 34、 37、 39、 42、 45、 47、 50
ガンマ   :−10、−11、−12、−13、−14、−15、−16、−17、−18、−19
輝度    : 16、 18、 19、 21、 22、 24、 26、 28、 29、 31
色の濃さ  : 69、 75、 82、 89、 96、103、110、117、123、130
色合い   :  0固定


 ↑こちらが、黄金比の想定に基づいての数値でしたが
 「艶」が出るまでには至らなかった段階です‥(8:5フィルター有り)
 (色の濃さを増した方が好い感じはしていたのですが、どうして良いのか分からなかった段階でした)


<色調補正> β版‥左列からレベル0、1、2‥
基本値   : 10、 11、 12、 13、 14、 15、 16、 17、 18

明るさ   : 42、 47、 51、 55、 59、 63、 68、 72、 76、 80
コントラスト: 26、 29、 31、 34、 37、 39、 42、 45、 47、 50
ガンマ   :−16、−18、−19、−21、−22、−24、−26、−28、−29、−31
輝度    : 26、 29、 31、 34、 37、 39、 42、 45、 47、 50

色の濃さ  : 69、 75、 82、 89、 96、103、110、117、123、130
色の濃さG倍:111、122、133、144、155、166、177、189、200、211
色の濃さ2倍:138、150、164、178、192、206、220、234,246、260(256)

色合い   :−(色の濃さG倍−基本値)‥再エンコード時
      *視聴だけなら−(色の濃さG倍)でも十分です


 ↑こちらが、艶効果を得るのに変則的に変えた形です
 見れば分かりますが、ガンマと輝度を一段階上げたわけです
 そうすると、色の濃さを上げても、釣り合いを保てるようになりました‥(8:5フィルター有り)

 (ぶっちゃけ、はじめは、色の濃さを単純に一つシフトして二倍したのを用いたわけですが)
 (再エンコードしてみると、所々で、想定外の色ムラが出てしまうようです)
 (明るすぎても、濃すぎても、再エンコードで均一な風合いには成らないようです)


 ‥色々と見比べて見た結果
 レベル4の明るさだと(実写の場合)‥衣裳に当たる光彩の度合いよっては
 よれよれの風合い、色落ちた風合いに見えてしまう場合もあるので
 レベル3が適当のようです

 (すっぽんぽんの映像なら、さほど気にならないんですけどね)


> さて、色合いですが


 −(色の濃さ)です
 普通に考えれば、真っ赤っかです
 真っ赤っかにならないのは、8:5フィルターの効果と、Cb(gain)、Cr(gain)をいじってあるからです
 (まさに魔法‥左ねじり込みとでも呼称したい)


<拡張色調補正> β版対応
Y(offs):26、29、31、34、37、39、42、45、47、50(左からレベル0に対応‥以下同)
Y(gain):−42、−47、−51、−55、−59、−63、−68、−72、−76、−80
Cb(offs):−2、0、、4、6、8、10、12、14、16
Cb(gain):概ね‥79(これ以外のパターンも有り得る‥ 最大値目安は|128|or|色の濃さ|)
Cr(offs):、0、−1、−2、−3、−4、−5、−6、−7、−8
Cr(gain):概ね‥−49(これ以外のパターンも有り得る‥最大値目安は|128|or|色の濃さ|)
R(offs):
R(gain):−49
R(gamm):
G(offs):−49
G(gain):
G(gamm):98
B(offs):−128
B(gain):79
B(gamm):256


 *ただし、RGB24ビットでの編集状態であることが欠かせません
posted by 木田舎滝ゆる里 at 19:34 | Comment(0) | エンコードが始まらない | 更新情報をチェックする