書き出したモーション動画の文字のぼけを直す方法
1920×1080で書き出した動画にも、実質的にはその4分の1の寸法で収録した文字が入ることがあります。出力寸法が表すのはフレームであり、その中で利用できる細部ではありません。
文字がぼけている場合、書き出し解像度を上げても期待外れになりがちなのは、そのためです。製品のスクリーンショットを小さなビットマップに縮め、接写用に拡大していたら、失った字形はレンダラーでは取り戻せません。同じぼやけた輪郭の周囲に、ピクセルを増やすだけです。
書き出し動画の文字のぼけを診断するには、文字が初めて明確さを失う段階を探すと有効です。元の素材から構図、レンダリングしたフレーム、エンコード済み動画、実際のプレーヤーへ、連鎖をたどります。最初に失敗する段階を直します。場所を見つける前に最終ファイルをシャープにすると、根本問題を残したまま、輪郭の周りに明暗の縁を加えがちです。
同じ文字を同じ大きさで比べる
問題を含む代表的なフレームから始めます。比較ごとに、タイムスタンプ、切り取り、表示サイズをそろえます。大きなエディタープレビューと小さなプレーヤーを比べると、成果物と視聴条件の両方を変えてしまいます。
納品したファイルからフレームを抽出し、元のピクセルサイズで確認します。ツールが出せるなら、ロスレスのレンダリングフレームと比べます。その後、関連する部分を、元のスクリーンショットや編集可能なテキストレイヤーと比べます。エンコード前に細部を失ったのか、エンコード中なのかが分かります。
メッセージアプリのプレビュー画像に頼らないでください。低解像度のサムネイルを作っているかもしれません。許可される場合は実際のファイルをダウンロードし、どの素材を開くかを検証します。動画プレーヤーのスクリーンショットは、別の拡縮を加える場合があるので、デコードした動画フレームと区別します。
意図して難しい文字を選びます。小さなUIラベル、細い線、色付き文字、細かい背景の上で動く文字です。淡い面の大きな黒い見出しが美しくても、小さなナビゲーションラベルは使えない場合があります。試すべき領域は、最もきれいな場所ではなく、視聴者が必要とする情報です。
最後に、ぼけと思った問題が、実は小さすぎることなのかを確認します。鮮明にエンコードされたラベルでも、公開時の幅では読めないほど小さいかもしれません。構図の問題です。ビットレートを上げても、8ピクセルの文字を読める段落のようにはできません。
アニメーションの前にスクリーンショットを確認する
元のスクリーンショットを、本来の寸法以上に拡大せず開きます。同じラベルを読めますか。読めなければ、製品へ戻り、よりよい元の状態を収録します。収録しなかった細部を、書き出し設定で補うことはできません。
スクリーンショットのピクセル寸法は、配置との関係で重要です。幅1200ピクセルの画像を、幅1200ピクセルの構図に置けば、ラベルに十分な細部があるかもしれません。後でカメラが、画像の4分の1を同じ幅いっぱいに見せると、その領域は約4倍に拡大されます。実効的な素材解像度は、構図の解像度よりずっと低くなります。
予定する最も狭い切り取りに足りる細部を収録します。高密度のキャプチャ、製品の通常のズーム操作で撮った別の接写、異なるショット設計が必要かもしれません。チュートリアルでその違いが重要なら、別に収録した接写を、連続した実画面のズームのように示唆しないでください。
スクリーンショットを鮮明に見せるためだけにUIの文字を描き直し、無加工のキャプチャと呼び続けてはいけません。外側に説明ラベルを加える、単純化した図だと明示することはできますが、異なる視覚素材です。製品の証拠と、編集上の説明の違いを保ちます。
元の形式も調べます。UIのスクリーンショットを強く圧縮したJPEGとして何度も保存すると、アニメーションに入る前から輪郭を傷める場合があります。可能なら適切なロスレス素材を使います。最終動画は圧縮されるので、素材の段階で避けられる損傷を加える理由はほとんどありません。
編集可能な文字とラスター化された文字を分ける
構図のレイヤーとして描く文字は、構図の出力解像度でレンダリングできます。スクリーンショット内の文字は、すでにラスター化されています。同じズームでも、大きく違って見えることがあります。
見出しが鮮明で、UIラベルがぼけるなら、全体のレンダリング設定を変える前に、画像の倍率を確認します。両方がぼけるなら、構図の解像度、出力の拡縮、再生サイズを調べます。この単純な区別で、無関係な実験をいくつも避けられます。
不可欠な情報では、元のUIラベルを読む必要があるのか、役割を理解すればよいのかを考えます。実際のスクリーンショットで製品状態を示し、控えめな外側の注釈で結果を説明できます。注釈は、証拠を覆ったり、スクリーンショットが支えない主張を加えたりするべきではありません。
UI全体を、大きなラベルに変えないでください。一つの問題を別の問題に交換します。動画が製品に似なくなり、密な注釈ポスターになってしまいます。今のステップに必要な一つか二つの細部を特定し、そこを中心にショットを設計します。
製品自体の文字が小さいなら、見えるUIを減らして接写するのが、誠実な答えかもしれません。狭いソーシャルフィードへ縮めたダッシュボード全体を、読めるままにすることはできません。物理的な制約であり、コーデックの欠陥ではありません。
動いているときだけぼけるかを確認する
停止フレームは鮮明で、動くとぼけて見えるなら、常にぼけた素材とは違う問題です。速度、フレームレート、シャッターやモーションブラーの設定、文字がピクセルの格子を横切る仕方を調べます。
各デコードフレームの輪郭が鮮明でも、速く動く文字は読みにくくなります。動く言葉を追う必要があるからです。書き出し解像度を上げるより、安定したホールドを長くする方が役立つかもしれません。重要な指示や数値を担うなら、読むよう求める前に落ち着かせます。
サブピクセルの位置も、フレームごとに輪郭の見え方を変えます。細い縦線が1ピクセル未満ずつ動くと、連続フレームで違うサンプリングを受ける場合があります。ちらつきや、太さの不一致に見えるかもしれません。ピクセルへ合わせることが役立つ場合もありますが、すべてを整数へスナップすると、段階的な動きが目立つ場合もあります。一律のルールを使わず、実際の動きを評価します。
モーションブラーは意図した効果であり、自動的に品質不良ではありません。移動を連続的に感じさせる一方、小さな文字を移動中に読みにくくする場合があります。文字の役割に合わせて使います。装飾的な文字と請求条件では、優先順位が異なります。
役立つ診断は、同じ文字を静止させ、その後で同じ経路を動かす、短い比較を作ることです。素材、大きさ、エンコードは固定します。ほかの原因から動きを切り分けられます。まったく違うデザイン二つを比べ、すべての差をモーションブラーのせいにしないでください。
エンコードによる損傷を特定する
元の素材とロスレスのレンダリングが明確で、エンコードした動画だけが不明確なら、エンコード設定を試します。輪郭近くのブロック状の乱れ、高コントラストな文字周囲のリンギング、移動中に崩れる細部などが、よくある兆候です。
動画圧縮は、空間と時間でトレードオフを行います。大きな平面は効率よく保てても、小さな動く文字や細かな背景には苦戦する場合があります。MDNの動画コーデックガイドは、コーデックの選択、圧縮、互換性を区別しています。実務への意味は、形式の名前だけで画質は決まらないということです。MDNの動画コーデックガイド
条件をそろえた比較で品質を上げます。寸法、フレームレート、素材、シーンは保ち、一つのエンコード項目を変えて、難しい領域を見ます。大幅に高品質にしても同じ問題が残るなら、損傷はおそらく、もっと前に起きています。
色のサブサンプリングも、特に小さな色文字では一因になり得ます。よく使う配信形式は、色の細部を明るさより低い空間解像度で保存します。大きな無彩色の文字は保てても、細く彩度の高い線は不正確に見える場合があります。すべての動画を、互換性の低いピクセル形式にするべきという意味ではありません。文字色、太さ、大きさも、配信の判断の一部だという意味です。
すべての製品動画に、一つのビットレートを指定しないでください。静的なスライドと、速く動く細かなUIでは、圧縮の要求が異なります。代表的な区間で試し、実際の出力を見て、掲載先の必要を満たす品質を選びます。
実際の縮小処理の比較
この記事に付属する実験では、Remotionのレンダリングのドキュメントの実際のスクリーンショットを、元画像に使いました。1280×720の領域を320×180へ縮め、1280×720へ戻した版も作りました。文字と切り取りは同じまま、途中で意図的に空間の細部を失わせています。
両画像とも1280×720です。二つ目に残るのは、途中の320×180で生き残った細部だけです。
自分の動画を診断するときも、このような条件をそろえた対を使います。元の領域がすでに縮められているなら、交換か再収録をします。元は明確でロスレスのレンダリングがぼけるなら、構図の拡縮やラスター化を調べます。ロスレスは明確で動画が傷んでいるなら、エンコードを調べます。
最も狭い切り取りと実際の表示サイズに合わせて、元の細部を選びます。同じフレーム幅に表示する大きな見出しより、小さなラベルには多くの元ピクセルが必要です。
近くへ切り取ると、損失の場所が分かりやすくなります。縮小版では、文字の小さな内側の空間と、隣り合う線の間隔が、一緒にぼけています。最終キャンバスを大きくしても、再び分離できません。その観察から修正を選びます。明確な元キャプチャか、抑えたズームは、素材の細部の問題へ対処します。高いビットレートが対処するのは、後のエンコードで入る損傷だけです。大きい画像が、単に読みやすいという理由で勝たないよう、表示倍率をそろえます。
公開された配信版を別に確認する
プラットフォームは、明確なアップロードから、複数の配信版を作ることがあります。ブラウザーが最初は低品質のストリームを選ぶかもしれません。ページが小さい素材を拡大したり、重要な領域を読みにくくする切り取りをしたりする場合もあります。
配信先での処理後に、動画を確認します。期待する配信版を見ていて、処理が終わっているかを確かめます。同じ時点を、元のアップロードと比べます。配信先だけがぼけるなら、同じ素材をより高品質で繰り返し書き出しても、掲載の問題は解決しないかもしれません。
サイトでは、プレーヤーのCSS寸法と、収め方を確認します。エンコード寸法より大きく表示した動画は、ぼけることがあります。高密度ディスプレーでも、元の細部は変わりません。逆に、大きなファイルを小さな表示に押し込むと、エンコードがよくても、小さなラベルは読めなくなります。
狭いモバイル枠では、必要ならショットを作り直します。近い切り取り、見せるタスクの短縮、明確な外側のラベルで、意味を保てます。メッセージの中心の情報を読むためだけに、拡大やスクラブをしてもらえると期待しないでください。
正確な公開幅を確認します。390ピクセルのページ内プレーヤーには、全画面のデスクトップチュートリアルより、近いショットが必要かもしれません。
診断を隠す修正を避ける
強いシャープ化は、文字の輪郭を強く見せながら、明暗の縁を加えることがあります。一枚には効果があっても、失った細部が戻ったという、誤った感覚を生む場合があります。境界の見かけのコントラストだけでなく、小さな文字の内側の形を比べます。
同様に、細いフォントをすべて太くすれば丈夫になる場合がありますが、視覚的な優先順位も変わります。小さな掲載枠には正しい選択かもしれませんが、構図の修正であって、書き出し工程を直した証拠ではありません。違いを保ち、次の動画で同じ工程の問題が戻らないようにします。
アップスケーリングのツールは、もっともらしい輪郭を生成できます。しかし、元で読めないラベルの正確な文言は、確立できません。製品の証拠として文字が重要なら、本物の、細部を多く含むキャプチャへ戻ります。説得的な再構築は、検証した画面と同等ではありません。
説明の注釈を加えるなら、役割を明らかにします。本当の結果を見つけたり解釈したりする助けにし、傷んだラベルを、元がもう支えない主張へ黙って交換してはいけません。基礎の状態を識別できるなら、元のUIが小さいままでも、注釈で伝達を改善できます。
修正中は、診断用の中間素材を保ちます。原因の段階が分かるまで、元キャプチャ、ロスレスフレーム、エンコード比較を残します。早く消すと、本当の改善と、表示サイズやプレーヤー挙動の変化を区別しにくくなります。
最も単純な成功する修正は、フィルターほど華やかでないことがよくあります。よい収録、近いショット、静かな背景、長い安定区間です。傷んだピクセルを強く見せるだけでなく、届く情報を改善します。
最初に失敗する段階で、書き出し画質を改善する
素材がぼけていれば、再収録します。構図が拡大しすぎるなら、ショットを変えるか、よりよい素材を用意します。文字は鮮明でも小さすぎるなら、優先順位と構図を変えます。停止中だけ読めるなら、動きか読む時間を変えます。明確なレンダリングをエンコードが傷めるなら、コーデック設定を調整して再比較します。プラットフォームだけの問題なら、配信先の処理と表示条件を調べます。
これらの対処は、交換できません。シャープ化は、欠けた言葉を戻せません。大きなビットレートは、過密な画面を読めるものにできません。高いフレームレートは、解像度の足りない収録を直せません。
最良の結果は、どんな犠牲を払っても技術的に最も鮮明にしたファイルではありません。実際に出会う大きさと速さで、必要な文字を無理なく読める納品動画です。連鎖の中の最初の損失を見つければ、推測による書き出しを減らして、そこへ至れます。