記稿.2019/11/10
＞ テレビＵＳＢ挿しにおいて、実写の方では処理が重くなる
＞ 黄岐黄嶺（二度揚げ）だとギリギリで再生こそすれ一時停止しつつ動く感じだ
＞ （しかも音声再生される余裕も無い‥つまりテレビ放送より容量が大きいのだ‥）
（無論、パソコン上では問題ない）
（無論、パソコン上では問題ない）
（無論、パソコン上では問題ない）
‥これより判断できる要素は
業界は当然実写に合わせて規格を立てている（まぁ当然）
だから、そちらに沿わせるだけでは、アニメの質は怪しいままとした予想が立つ
アニメと実写は根本的に何かが違っているのに、実写に沿わせざるを得ないのが現状だ
‥考え方としては
アニメの情報量の方が圧倒的に単調化されているので
少なめのビットレートでは、特定量以下では極端に質が落ちるということだろう
実写はその点、嫌になるほど光に詰め込まれてあるので
そこは、どこまで言っても光学的な計算通りに適うと言うことだろう
‥それの見た目がまずかろうとも、データ的正確さこそ正義の世界がそれだ
だが、アニメはそうではなく、特定域だけに色の器が偏っていることが予想される
だから数値的な均一性で間引くだけでは上手く行かない事になる
アニメの特定域の色の器を確実に捉えるには、特定量のビットレートを必要とする
不思議と、低いレベル（3.2以下）での色落ち色剥がれを見せるのはアニメの方だ
実写においてのそれは、ピントがボケるとした形を想定内にやらかしているが
アニメの方ではそれだけではうまく行かずに、色剥がれする形を垣間見せるのだ
（つまり、キーフレームのレベルでビットレート不足ということだ）
‥時に、実写でもデジタルの初期の頃には、目玉の瞳が欠けてるような映像も見られたが
比率で言っても、その手の色剥がれは、アニメの方が多かったはずだ
（ピントがぼやけているのでそのままではわからずとも、黄岐黄嶺で補正すると白日に晒される）
（一方、実写では恐ろしいほどに情報を保管していたかのように引き延ばしても違和感は想定内）
＞ ‥このアニメと実写のビットレート域の要求の差において
＞ ゼロ寄りにCRFをあてがえるアニメの方が、JPGノイズに悩まされずに済むのは因果だろう
アニメにおけるデジタルとアナログの差は、実写同様に光を移し込んでいるか否かの差だ
デジタルアニメでは、単純に、格子の中の色の凸凹に奥行きを想定する必要が無い
背景をアナログ描きでのそれをスキャンでもしない限り、実写と同じ光でも平坦な情報しかない
その単調なはずの情報が、なぜか低いビットレートでは上手く行かないのだ
＞ この問題は、光を基準に動きサーチを作っていることに起因するように思われる
アナログアニメの場合、それは、絵の具の溜りだったりするわけだから
光の一定調子の推移とは似ても似つかない動きを見せている
且つ同時に光の一定調子の推移を併せ持つのだ（フィルム撮影）
‥だから、サーチに溜り斑を見せることにもなる（結果、徹底的にサーチせざるを得ない）‥
そこを、光と同様の扱いでスムージングしては
必要なはずのブロックが不要と判断されて、残念な結果になるのだろう
それこそが
徹底的なサーチ×特定域のビットレート量を必要とする内訳に思われる
‥その点デジタルアニメは、アナログのそれと比べて
基本的な情報量が単調だから、必要とされる色の器たる領域外での圧縮率が高くなる
（ただし、解像度が変わることで、色の器の在り方も随分と変わるクサさに変わりがない）
＞ アニメにおいてそこは、デジタルアナログ共に
＞ 必要以上にビットレートを多く宛がってもダメになる
＞ 基本的に、動きとしての色の凸凹が単調ゆえに潰れてしまうのだ
‥ところが実写はそれほどでもない傾向だ
（その代わり）
‥徹底的に動きサーチをやらかして、ビットレートを盛れば盛るほど
スキャナーの超拡大高精細な光のつぶつぶに分解されたような雰囲気を醸し始めるのだ
デジタル実写における黄岐黄嶺（二度揚げ）では、まさにそこの見やすさとの境目にあたるらしい
‥ＣＧ合成されるとまた違ってくるだろうにせよ
ビットレートを減らして行けば、嫌でもＪＰＧノイズとの葛藤だっ
そこで解像度を増やして対応せざるを得ないのが実写での流れだったように思われる
