
HDR ビデオ仕上げでは、明るいハイライトや飽和した色に余裕を与えることができますが、弱いショットを救うことはできません。 Runway は、2026 年 8 月 20 日に SDR から HDR へのカラー グレーディング モデルとして Ruby をリリースしました。 APOB クリエーターにとって、実際的な問題はもっと小さなものです。すでに承認されている 1 つのヒーロー クリップが、別の有料レンダリング、2 番目の配信ファイル、および追加のレビューを正当化するほど HDR 対応ディスプレイ上で十分な効果をもたらしますか?
このワークフローにより、生成と仕上げが分離されます。を使用して最強の SDR マスターを構築します。APOB AI ビデオ ジェネレーター、それを凍結してから、その正確なファイルを Ruby でテストします。 APOB AI は、2026 年 8 月 28 日に公式 Runway リリースと価格ページからこのガイドを作成しました。このガイドは、プライベート ベンチマークや、HDR によってすべてのクリップが改善されるという約束ではなく、管理された方法を報告します。
この SDR から HDR へのプロトコルは、発明された結果を公開しません。 2 回の試行上限を使用し、サポートされていない要求をすべて拒否し、正常な SDR フォールバックを維持します。
SDRを既定にする
SDR の前提から始めます。宛先、ソース ファイル、制御された比較のすべてが HDR コンパニオンを正当化するものでない限り、承認された SDR マスターを保持します。 Ruby は新しい仕上げオプションを作成します。生成中に何が起こったかは変わりませんし、すべてのプレーヤー、プラットフォーム、ディスプレイが HDR 対応になることもありません。
リリース事実. Runwayの8 月 20 日の変更履歴エントリRuby は、SDR ビデオを HDR に変換するネイティブ カラー グレーディング モデルであると説明しています。このエントリには、明るさと色の範囲を更新でき、ツール モード、ワークフロー、およびRunway開発を通じて利用できると記載されています。これらはベンダーが規定した機能として扱います。証拠の日付は 2026 年 8 月 28 日です。公開する前に変更ログを再確認してください。
サポートされている入力. 同じリリースでは、Ruby はRunwayモデル、サードパーティ モデル、既存のビデオ ファイルからの出力を受け入れると述べています。これにより、制御された APOB-first ハンドオフが可能になります。プロンプト、カット、デュレーションを変更せずに、所有するアセットを生成またはアニメーション化し、未処理のマスターを 1 つダウンロードして、そのファイルを Ruby に提供します。互換性は改善の証拠ではありません。テストルートが存在することを確認するだけです。
アクセスと料金. Runway には Ruby for Pro+ 計画とその現在のリストが掲載されていますモデルとクレジットのページは 1 秒あたり 20 クレジットを示します。したがって、10 秒の入力では、試行または反復が失敗するまでに 200 クレジットという生成推定値がリストに表示されます。日付の付いたページ、アカウント画面、実際のタスクコスト、領収書を保存します。 1 つのアカウント観察を永続的な価格要求に変えないでください。
記録する事実 | 8月28日時点の公式値 | ローカル証拠 |
|---|---|---|
リリース日 | 2026年8月20日 | 変更履歴のキャプチャ |
アクセス | Tool Mode、Workflows、Runway Dev、Pro+ の記載 | アカウント画面 |
記載料金 | 1秒あたり20クレジット | 見積もりと最終タスク費用 |
入力 | 固定済みのSDRマスター | ファイル名とチェックサム |
表示チェーンの検証
ラベルが高級に聞こえるため、HDR ビデオ コンバーターを介してキャンペーン全体を送信しないでください。配信コンテキストとビジュアル コンテンツが妥当な利点を生み出す場合にのみ、候補者を選択してください。決定はクレジットが消費される前に始まります。
HDR と 4K. HDR は、より広い明るさと色の範囲を表します。 4K はピクセルの寸法を表します。 4K HDR ビデオは両方を組み合わせていますが、一方が他方を保証するものではありません。アップスケーリングでは、クリップされたハイライトを復元せずにピクセルが追加される場合がありますが、HDR グレードでは解像度が向上せずに範囲が変更される場合があります。レビュー担当者が間違ったプロセスを評価しないように、解像度、コーデック、ビット深度、表示モードを個別に記録します。
. 意図的なハイライト、グラデーション、飽和したオブジェクト、肌のトーン、またはグレーディングの問題を明らかにする可能性のある製品表面を含む短いヒーロー クリップを 1 つ選択します。所有またはライセンスされたアセットから作成された承認済みのクリップを優先します。解剖学的構造が壊れている、製品テキストが読めない、過度の圧縮、または失敗したナラティブビートがある候補者を拒否します。これらの欠陥は、HDR ビデオ編集ではなく、上流にあるものです。
変換前にソースをスコアリングします: アイデンティティ、モーション、製品の忠実度、構成、露出、色、テキスト、エクスポートの整合性。それぞれの基準は合格か不合格です。 Ruby は、ソースがすべての保護された基準を満たし、宛先が HDR を表示できる場合にのみワークフローに入ります。
SDRで十分な場合. 宛先が HDR を確実にサポートしていない場合、クライアントが 1 つの単純なマスターを必要とする場合、ソースにハイライトやカラー範囲の圧力がほとんどない場合、または比較で意味のあるゲインが示されない場合は、SDR を維持します。 SDR は、顔が不自然になった場合、ハイライトが粗く見える場合、グラデーション バンドがある場合、またはプラットフォームの変換が不確実な場合の代替手段でもあります。 「変換なし」は有効な製造上の決定であり、失敗した実験ではありません。
マスターファイルを固定
APOB は真実の創造的な情報源であり続ける必要があります。そのRunwayと互換性のあるビデオワークフロー外部仕上げテストの前に、クリエイターが主題、モーション、長さ、承認された SDR クリップを開発するのに役立ちます。この分離には利点があります。チームは、生成エラーを解決するためにカラー パスを要求する代わりに、上流でアイデンティティやストーリーを修正できます。
ヒーロークリップを選択してください. 1 つのロックされたブリーフから小さなバッチを生成し、1 つのヒーロー クリップを承認します。通常の速度、ミュート、音声付きで、モーションや照明のトランジションをフレームごとに確認してください。なぜそれが勝ったのか、そしてどの欠陥が依然として許容できるのかを記録します。意思決定所有者は、Ruby が開かれる前に SDR マスターに署名します。そうしないと、2 つの移動ターゲットが存在するため、比較が無意味になってしまいます。
ソースの品質を維持する. 承認されたワークフローから利用可能な最高品質のサポートされているマスターをダウンロードします。画面を録画したり、メッセージング アプリを通じて送信したり、名前を変更するためだけに再エクスポートしたりしないでください。アスペクト比、フレーム レート、継続時間、オーディオ、および変更されていないファイルを保持します。配信プラットフォームでより小さいエンコードが必要な場合は、テスト ソースとして使用するのではなく、HDR の決定後にその派生ファイルを作成します。
ファイルの名前とバージョン. 系統を明らかにする名前を使用します。campaign_shot03_sdr-master_v1.ext、campaign_shot03_ruby-hdr_test01.ext、 そしてcampaign_shot03_sdr-delivery_v1.ext。ソースのチェックサム、Ruby 設定、タスク ID、日付、オペレーター、リストされた見積もり、最終的なクレジット請求、使用されたディスプレイ、および決定を保存します。 SDR マスターを決して上書きしないでください。新しいソース ファイルには新しいテスト ID が必要です。
1回のレンダリングで検証
このテストでは、Ruby の処理という点が 1 つ変わります。ソース、期間、アカウント パス、評価表示、部屋の照明、レビューの順序を安定させます。ツールが調整可能な勾配コントロールを公開していない場合は、設定を作成するのではなく、その事実を記録します。
テストセットアップ. 現在サポートされている Ruby サーフェスを介して、凍結された SDR マスターをアップロードします。実行前の見積もりを取得し、1 つのコンバージョンを送信します。変更されていない結果をダウンロードします。見た目の美しさを判断する前に、ファイルの長さ、サイズ、フレーム レート、オーディオの存在、および再生を検査します。破損したファイルまたは不一致のファイルは技術的な欠陥であるため、視覚的な比較に含めるべきではありません。
HDR が有効になっている HDR 対応ディスプレイを少なくとも 1 台と、通常の SDR ディスプレイまたは SDR 解釈を 1 台使用してください。各画面とオペレーティング システム設定にラベルを付けます。査読者は、どちらが勝つと予想されるかを知らされることなく A と B を確認し、独立して観察を記録する必要があります。
3画面の評価表
ビジュアルQCグリッド. 同じフレームを確認して、ハイライトの詳細、シャドウの分離、肌のトーン、製品の色、彩度、グラデーション、バンディング、動きの安定性、テキスト、および予期しないシフトを確認します。拒否されるたびにタイムコードとスクリーンショットを要求します。パスには、完全な ID と製品の事実に加えて、ターゲット ディスプレイに表示される配信上のメリットが必要です。場所や比較なしで「より鮮明に見える」だけでは十分ではありません。
基準 | パスルール | ハードストップ |
|---|---|---|
ハイライト | 過酷なクリッピングを発生させずに、より使いやすいディテールを実現 | 顔や製品の詳細が失われた |
肌 | 動作を通じてもっともらしく一貫性のあるもの | オレンジ、グレー、または変動するトーン |
製品の色 | 承認されたリファレンスと一致する | 素材やブランドカラーの変更 |
グラデーション | 納品表示もスムーズ | 新しいバンディングまたは輪郭加工 |
モーション/テキスト | 新たな不安定性はない | ちらつき、テキストの歪み、またはフレームのドロップ |
信用見積り. 計算するduration in seconds × 20 listed credits per second日付付きの見積もりについて。次に、許可された再試行に対する実際の料金を追加します。技術的な障害に明確な原因がある場合にのみ、1 回の変換バジェットと 1 回の診断再試行を設定します。承認された HDR クリップあたりのコストは、使用されたすべての Ruby クレジットを承認されたクリップで割ったものと等しくなります。普遍的な費用ではなく、サンプルのサイズと日付を報告します。
2系統納品のロールバック
最終的な選択は、ツールではなく配信ジョブに属します。 HDR ファイルは、保護された基準を満たし、目に見える利点が得られ、承認されたフォールバックを備えた HDR 対応の宛先がある場合にのみ保持してください。
納品決定. クライアント、プレーヤー、プラットフォーム、およびディスプレイ パスが正確なファイルでテストされたら、HDR を公開します。後で品質が向上しても現在の宛先が不明な場合に備えてアーカイブします。利点が無視できる場合、またはグレードによって保護された障害が発生する場合はスキップします。レビュー担当者、日付、目的地、決定、および証拠のリンクを 1 行に記録します。
SDRフォールバック. 承認された SDR マスターとプラットフォーム対応の SDR 派生ファイルを保持します。 HDR アップロードが拒否されたり、トーン マッピングが予期せずに行われたり、正しく表示されない場合は、期限近くに別の変換を急遽行うのではなく、正常であることがわかっているファイルに切り替えてください。アップロード後に提供されたページまたはアプリを開き、対象のデバイス上のローカル マスターと比較します。
アーカイブチェックリスト. オリジナルの概要、APOB プロンプトと入力、承認された SDR マスター、チェックサム、Ruby の見積もりと受領書、HDR 出力、ファイル検査、表示設定、QC グリッド、スクリーンショット、レビュー担当者のメモ、配信ファイル、および決定をアーカイブします。再確認してくださいRunwayモデルと価格ページ2026 年 9 月 20 日まで、またはアクセス、クレジット、サーフェス、またはサポートされる入力が変更された場合はそれより早く。
1 ページの決定: SDR ソースを承認します。 HDR 対応の宛先を確認します。 1 つのファイルを凍結します。クレジットを見積もる。一度変換します。ファイルを検査します。 HDR ディスプレイと SDR ディスプレイで比較します。アイデンティティ、製品、モーション、テキスト、色の失敗を拒否します。 SDR フォールバックを保持します。すべての証拠をアーカイブします。ワークフローは、配信の選択が説明可能であれば、たとえ正解が HDR をスキップすることであっても成功します。
情報源

最初にこれに「いいね」してください。

クレジットカードは不要です



















