# 画像・動画アスペクト比計算ツール：技術アーキテクチャと実践的エンジニアリング完全ガイド

現代のディスプレイエンジニアリング、デジタルシネマトグラフィ、コンピュータグラフィックス、そしてレスポンシブWebデザインにおいて、幾何学的な画面比率（アスペクト比）の厳密な管理は、破綻のない視覚体験を提供する上での根幹となる技術領域です。デジタルシネマ（DCI）向け劇場映画のマスタリング、アダプティブビットレートストリーミング（HLS/MPEG-DASH）のエンコードラダー構築、Cumulative Layout Shift（CLS）を根本から排除する流動的なCSSグリッドレイアウトの設計、さらには高リフレッシュレートのウルトラワイドモニター向けカスタム解像度設定に至るまで、アスペクト比の正確な計算とスケーリングはあらゆる制作パイプラインに直結しています。

アスペクト比（Aspect Ratio）とは、画像、動画フレーム、または表示キャンバスの「幅（Width）」と「高さ（Height）」の幾何学的な比例関係を定義する指標です。しかし、開発現場において生ピクセル解像度（1920×1080、3840×2160 等）と既約分数比率（16:9、4:3、21:9、16:10 等）、さらには動画コーデック特有のマクロブロック境界制約（Mod-2、Mod-8、Mod-16 等の割り切れルール）の間を相互変換する際、微小な丸め誤差によるサブピクセルレンダリングの不具合、画面端のチラつき、あるいはハードウェアエンコーダーのパイプラインクラッシュといった深刻なトラブルが頻発します。

ToolsAA 画像・動画アスペクト比計算ツール（Image & Video Aspect Ratio Calculator） は、直感的なリアルタイム アスペクト比計算機、業界標準の 16:9 解像度計算機、動画コーデック境界を自動補正する高精度スケーラー、そしてローカルメディアファイルのオフラインメタデータインスペクターを統合した、プロフェッショナルエンジニア・クリエイターのための次世代Webユーティリティです。

本ツールは完全なクライアントサイド実行モデル（"use client"）を徹底しています。すべての最大公約数（GCD）算出、連分数近似展開、Canvasを用いたレターボックス／ピラーボックスプレビュー処理は、お使いのブラウザ内サンドボックスメモリでのみ完結します。動画ファイルや画像データ、操作ログが外部サーバーへ送信されることは一切なく、極めて厳格なプライバシーと情報セキュリティを保証します。

# 包括的概要と実践的なエンジニアリングユースケース

数学的な基礎定義において、アスペクト比は幅（$W$）と高さ（$H$）の比率として表されます。

$$\text{アスペクト比 (Aspect Ratio)} = \frac{\text{幅 } (W)}{\text{高さ } (H)}$$

歴史的に、映画やテレビ放送はトーマス・エジソンのサイレント映画時代の $4:3$（$1.33:1$）や、ハリウッド黄金期を支えたアカデミー比率（$1.375:1$）など、機械的なフィルム開口部（アパーチャ）に縛られた固定比率を採用してきました。しかし、今日のデジタル環境では、PCモニター、テレビ、スマートフォン、折りたたみ端末、超広角サイネージなど、極めて多様な水平・垂直・正方形・シネマスコープジオメトリが混在しています。

+-----------------------------------------------------------------------------------------+
|                        現代のディスプレイ・動画ジオメトリパイプライン                      |
|  32:9 スーパーウルトラワイド (5120x1440)  | 16:9 標準ワイドスクリーン (3840x2160, 1920x1080)   |
|  21:9 シネマウルトラワイド (3440x1440)    | 16:10 ノートPCディスプレイ (2560x1600, MacBook)   |
|  4:3 クラシック標準 (1024x768)           | 9:16 縦型ショート動画 (1080x1920, TikTok/Reels)   |
+-----------------------------------------------------------------------------------------+

# 開発・制作現場における重要ユースケース

• レスポンシブWebデザインとCLS（累積レイアウトシフト）の防止: W3C CSS Box Sizing Module Level 4 で策定された aspect-ratio: 16 / 9 プロパティを活用することで、画像や動画のリソースがネットワーク経由で読み込まれる前にブラウザが描画領域を事前確保し、Google Core Web Vitals の重要指標である Cumulative Layout Shift（CLS）を完全に排除します。
• アダプティブビットレートストリーミング（HLS / MPEG-DASH）のエンコードラダー設計: マスターソースから 1080p、720p、540p、360p などの複数階層（Rendition Tiers）を生成する際、全階層でアスペクト比を狂わせることなく、動画コーデックのマクロブロック境界（Mod-2 / Mod-16）に合致した偶数ピクセル解像度を厳密に維持する必要があります。
• マルチプラットフォーム向けSNSコンテンツ最適化: 撮影したマスター 4K UHD 映像（3840×2160、$16:9$）から、TikTok・Instagram Reels・YouTube Shorts 用の縦型動画（1080×1920、$9:16$）や、Instagram フィード用のポートレート写真（1080×1350、$4:5$）を歪みなく切り出し・リサイズします。
• ハードウェア・ゲーミング・マルチモニターの解像度最適化: $16:9$、$21:9$、$32:9$ などの超広角ゲーミングモニターにおいて、ネイティブパネル比率に合致したカスタム解像度の算出や、視野角（FOV: Field of View）計算、アスペクト比補正（黒帯レターボックスの付与）を正確に制御します。
• アナモフィックシネマトグラフィのデスクイーズ処理: アナモフィックレンズを用いて撮影された特殊な映像素材について、センサー縦横比（SAR: Storage Aspect Ratio）から上映アスペクト比（DAR: Display Aspect Ratio）へ復元するための光学圧縮倍率（$1.33\times$、$1.5\times$、$2.0\times$）の補正計算を行います。

# ゼロデータ漏洩を保証するクライアントサイド処理の優位性

従来の一般的なオンラインアスペクト比計算サービスや画像リサイズツールは、ユーザーが指定したファイルやパラメータをリモートサーバーにアップロードして処理を行うアーキテクチャが主流でした。しかしこの方式では、未公開のプロモーション映像、製品発表前の宣伝用バナー、社外秘のUIデザイン、プライベートな写真が外部サーバーに一時保存され、情報漏洩や SOC 2、GDPR、HIPAA などの厳格なコンプライアンス違反を引き起こす重大なリスクが存在します。

ToolsAAは、最先端のHTML5 Web API（Blob、URL.createObjectURL、Canvas API、HTMLVideoElement）を活用した 100% クライアントサイド処理（完全ブラウザ完結） を実現しています。ファイルデータはローカルブラウザのメモリ領域から一切外に出ず、ネットワーク通信ログにも記録されません。これにより、企業秘密や著作権保護対象のメディア資産でも安全に検証・計算が可能です。

# 技術アーキテクチャと内部動作原理

アスペクト比の約分、スケーリング、動画コーデック適合性チェック、ブラウザプレビューの裏側では、ユークリッド幾何数学、離散有理数近似、そして高度なビデオエンジニアリングの原則が機能しています。

# 1. ユークリッドの互除法（Euclidean Algorithm）による最大公約数（GCD）算出

任意のピクセル寸法 $(W, H)$ を既約分数比率 $(w:h)$ に縮約するためには、幅と高さをそれらの最大公約数（GCD: Greatest Common Divisor）で除算します。ユークリッドの互除法を用いることで、対数時間 $O(\log(\min(W, H)))$ という極めて高速なアルゴリズムでGCDを求められます。

$$\gcd(a, b) = \begin{cases} a & (b = 0) \\ \gcd(b, a \bmod b) & (b > 0) \end{cases}$$

たとえば、標準的なフルHD解像度（$1920 \times 1080$）の場合、剰余演算を繰り返すことで以下のように推移します。

$$1920 \bmod 1080 = 840$$ $$1080 \bmod 840 = 240$$ $$840 \bmod 240 = 120$$ $$240 \bmod 120 = 0 \implies \gcd(1920, 1080) = 120$$

幅と高さをそれぞれ 120 で除算すると、$\frac{1920}{120} = 16$、$\frac{1080}{120} = 9$ となり、標準的な 16:9 のアスペクト比が数学的に導出されます。

# 2. 連分数展開（Continued Fractions）による有理数近似

映画規格である シネマスコープ（CinemaScope）（$2.39:1$）や アメリカンビスタ（Academy Flat）（$1.85:1$）などは、整数比ではなく小数比率として表現されます。さらに、市販の 「21:9」ウルトラワイドモニター は、実際には単純な $21/9 \approx 2.3333$ ではなく、シネマ規格に合わせた $64:27$（$2.37037\dots$）や $43:18$（$3440\times 1440$ 相当、$2.3888\dots$）のパネルが採用されているという業界のマーケティング命名上の乖離が存在します。

ToolsAAでは、任意の実数や小数を既約分数に逆引きするため、連分数展開法（Continued Fractions Expansion Method） を採用しています。実数 $x$ を以下のような連続した分数の連鎖として表現します。

$$x = a0 + \cfrac{1}{a1 + \cfrac{1}{a2 + \cfrac{1}{a3 + \dots}}}$$

ここで各係数 $a_k$ は整数部分を表し、剰余の逆数を再帰的に取得していきます。たとえば $2.37037\dots$ を展開する場合：

1. $a_0 = \lfloor 2.37037 \rfloor = 2$ （残り $0.37037$）
2. $1 / 0.37037 = 2.7000 \implies a_1 = 2$ （残り $0.7000$）
3. $1 / 0.7000 = 1.4285 \implies a_2 = 1$ （残り $0.4285$）
4. $1 / 0.4285 = 2.3333 \implies a_3 = 2$ （残り $0.3333$）
5. $1 / 0.3333 = 3.0000 \implies a_4 = 3$ （剰余 $0$）

この係数配列 $[2; 2, 1, 2, 3]$ から近似分数（Convergents）$pk / qk$ を復元すると、最終的に厳密な有理数 $\frac{64}{27}$ に収束します。許容誤差 $\epsilon \le 10^{-5}$ を設けることで、ユーザーが入力した任意の小数比率から、背後にあるハードウェア標準の幾何比率を瞬時に同定します。

# 3. 動画コーデックのマクロブロック境界と割り切れ制約（Divisibility Constraints）

動画エンコードやトランスコードのパイプラインにおいて、任意寸法のピクセルを指定すると、エンコーダーが致命的なクラッシュを引き起こすか、意図しないパディングによる描画崩れが生じます。

• クロマサブサンプリング（YUV 4:2:0）と Mod-2 制約: 一般的なWeb動画ストリーミング（H.264、H.265、VP9、AV1）では、データ圧縮のため人間の視覚特性を利用して色差成分（$U, V$）の解像度を輝度成分（$Y$）の縦横それぞれ $1/2$ に間引く $YUV 4:2:0$ 形式が採用されます。そのため、解像度の幅および高さは必ず 2 で割り切れる偶数（Mod-2） でなければなりません。奇数ピクセル（例: $720 \times 405$）を指定すると、色差プレーンの分割計算が破綻します。
• マクロブロックアライメントと Mod-16 制約: 旧来の H.264（AVC）規格では、映像フレームを $16 \times 16$ ピクセルの「マクロブロック」に分割してDCT変換や動き補償を行います。高さが 16 の倍数でない場合（例: 1080p の高さ 1080 は $1080 / 16 = 67.5$ で割り切れない）、エンコーダー内部で 1088 ピクセルへの拡張パディング（Mod-16 アライメント）が実行され、レターボックスの端に緑色のノイズ線が現れたり、古いハードウェアデコーダーで再生不能になる原因となります。
• HEVC / AV1（CTU）と Mod-8 制約: 最新の HEVC や AV1 では、最大 $64 \times 64$ や $128 \times 128$ のコーディングツリーユニット（CTU）を採用し、再帰的な四分木（Quadtree）分割を行います。最適なエンコード効率と並列処理性能を担保するため、最低でも Mod-8（場合によっては Mod-4）の倍数に解像度を揃えることが推奨されます。

# 4. DAR vs. SAR vs. PAR：アナモフィック変換の幾何モデル

プロフェッショナルな映像技術では、3種類のアスペクト比概念を厳格に区別して管理します。

$$\text{DAR (Display Aspect Ratio)} = \text{SAR (Storage Aspect Ratio)} \times \text{PAR (Pixel Aspect Ratio)}$$

$$\text{DAR} = \left(\frac{W{\text{storage}}}{H{\text{storage}}}\right) \times \left(\frac{\text{PAR}x}{\text{PAR}y}\right)$$

• SAR（Storage Aspect Ratio / 記録アスペクト比）: 実際にセンサーやファイル内に格納されている水平・垂直の生ピクセル数の比率（例: NTSC DVD の $720 \times 480$）。
• PAR（Pixel Aspect Ratio / 画素アスペクト比）: 個々のピクセルの物理的な縦横形状。PCディスプレイや現代のフルHDは正方形ピクセル（$\text{PAR} = 1.0$）ですが、アナモフィックレンズや過去の放送規格では長方形ピクセルが使用されます。
• DAR（Display Aspect Ratio / 表示アスペクト比）: 最終的に人間の視聴者が見る画面の幾何比率（例: $16:9$ や $2.39:1$）。アナモフィックレンズ（$1.33\times$、$1.5\times$、$2.0\times$ 等）を使用した場合、スクイーズされた映像を水平方向に拡大展開（デスクイーズ）して正しい DAR を再現します。

# 5. ブラウザネイティブ Web API による高速メタデータ抽出とCanvasレンダリング

ToolsAAのメディアインスペクションエンジンは、最新のブラウザ標準APIを活用して安全かつ低遅延な解析を行います。

• オブジェクトURL（URL.createObjectURL）: ローカルで選択されたファイルを読み込む際、ブラウザの内部メモリプールを指す一時的な Blob URI（blob:https://...）を生成します。ファイルをサーバーへアップロードすることなく、即座にネイティブ要素から参照可能です。
• HTML5 メディア要素: ヘッドレス（非表示）の new Image() および document.createElement('video') インスタンスを生成し、loadedmetadata イベントを通じてメタデータヘッダーから自然寸法（naturalWidth/naturalHeight、videoWidth/videoHeight）をミリ秒単位で抽出します。
• HTML5 Canvas レターボックス／ピラーボックス幾何計算: 取得したメディア寸法 $(W{\text{src}}, H{\text{src}})$ をターゲットプレビュー領域 $(W{\text{canvas}}, H{\text{canvas}})$ にフィッティングさせるため、アスペクト比を歪めない等比拡大縮小率 $s$ と描画オフセット $(X{\text{offset}}, Y{\text{offset}})$ を計算します。

$$s = \min\left(\frac{W{\text{canvas}}}{W{\text{src}}}, \frac{H{\text{canvas}}}{H{\text{src}}}\right)$$ $$W{\text{draw}} = W{\text{src}} \times s, \quad H{\text{draw}} = H{\text{src}} \times s$$ $$X{\text{offset}} = \frac{W{\text{canvas}} - W{\text{draw}}}{2}, \quad Y{\text{offset}} = \frac{H{\text{canvas}} - H{\text{draw}}}{2}$$ 上下または左右に生じた余白は、黒帯（Letterbox / Pillarbox）としてCanvasのGPUバッファ上に即時ラスタライズされます。

• 即時メモリガベージコレクション: 寸法抽出とプレビュー描画が完了した直後、URL.revokeObjectURL() を即座に呼び出してメモリポインタを解放し、ブラウザのRAM消費を最小限に抑制します。

# ステップ・バイ・ステップ実践チュートリアル

ToolsAAのインターフェースを用いた、解像度の計算、スケーリング、動画エンコード用アライメント、およびメディア検証の具体的な操作手順を解説します。

# ステップ 1: 解像度の入力または標準プリセットの選択

ツール画面上部の 「計算機（Calculator）」 タブを開きます。 基準となる幅（Width）と高さ（Height）の入力フィールドに数値を入力します（例: 幅 1920、高さ 1080）。あるいは、画面に並ぶ代表的な標準プリセットボタンをクリックして即座に呼び出します。

• 16:9: フルHDテレビ、PCモニター、YouTube標準
• 9:16: TikTok、Instagramリール、YouTubeショート、スマホ全画面縦型
• 21:9: ウルトラワイドシネマモニター、映画館ワイドスクリーン
• 4:3: クラシックCRT、iPad、レトロゲーム
• 16:10: MacBook Pro、ビジネス向け作業用モニター
• 1:1: Instagram正方形フィード、SNSプロフィールアイコン
• 4:5: Instagramポートレート投稿（最大表示領域）
• 2.39:1: アナモフィックシネマスコープ（劇場映画標準）

# ステップ 2: 基準寸法のロックと目的解像度のスケーリング計算

ストリーミング配信のマルチ画質配信（トランスコーディングラダー）や、特定のコンテナ幅に合わせた画像リサイズを行う場合：

1. 「幅をロック（Lock Width）」 または 「高さをロック（Lock Height）」 のトグルスイッチを有効化します。
2. スケーリングしたい目標寸法を入力します（例: 幅をロックした状態で幅に 1280 を入力）。
3. 計算エンジンが比率を厳密に保ったまま対応する高さ（720）を瞬時に算出し、総ピクセル数（$921,600\text{ ピクセル}$）、メガピクセル換算（$0.92\text{ MP}$）、および小数比率（$1.7778$）を表示します。

# ステップ 3: 動画コーデック向け丸めモード（Rounding Mode）の設定

動画エンコードやFFmpegでのバッチ処理を想定している場合は、ドロップダウンメニューから目的の 丸めモード（Rounding Mode） を選択します。

• 偶数丸め（Round to Even / mod 2）: $YUV 4:2:0$ クロマサブサンプリングを利用するWeb動画の必須設定。奇数ピクセルを隣接する偶数へ自動補正します。
• Mod-4 / Mod-8: 高効率なモバイル動画配信やAV1/HEVCコーデックの推奨設定。
• Mod-16: 古いハードウェアエンコーダーやベースライン H.264 プロファイルのクラッシュ防止設定。

# ステップ 4: ローカルメディアファイルのセキュアなインスペクション

手元にある画像や動画の実アスペクト比を直接確認したい場合は、「ファイル解析（File Inspector）」 タブに切り替えます。 ローカル環境から任意の画像ファイル（.png、.jpg、.webp、.svg、.avif）または動画ファイル（.mp4、.webm、.mov）を破線のドロップゾーンにドラッグ＆ドロップします。ブラウザ内メモリ上で即座にネイティブ解像度と既約アスペクト比が算出され、プレビューが表示されます。外部サーバーへのアップロードは発生しません。

# ステップ 5: プロダクションコードとCSSルールのワンクリックエクスポート

画面右側の 「エクスポート（Export）」 パネルから、開発現場ですぐに使えるコードスニペットをコピーします。

• モダン CSS 宣言:

```css aspect-ratio: 16 / 9; width: 100%; object-fit: cover; ```

• Tailwind CSS ユーティリティクラス:

aspect-video または任意値記法 aspect-[16/9]

• FFmpeg リサイズフィルターコマンド:

```bash -vf "scale=1920:1080:forceoriginalaspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2" ```

# プロダクション実装コード（TypeScript / JavaScript & Python）

Webアプリケーションやバックエンドのトランスコード自動化スクリプトに組み込める、外部依存性ゼロ（Zero-Dependency）のプロダクション実装コードです。ユークリッドの互除法、コーデック境界アライメント、および寸法計算アルゴリズムを網羅しています。

# モダン TypeScript / JavaScript 実装

/**
 * コーデック境界アライメントモードの型定義
 */
export type CodecRoundingMode = "none" | "even" | "mod8" | "mod16";

/**
 * 計算結果インターフェース
 */
export interface AspectRatioResult {
  ratio: string;         // "16:9" などの既約文字列表現
  decimal: number;       // 1.7778 などの小数比率表現
  gcd: number;           // 最大公約数
  isEven: boolean;       // Mod-2 適合フラグ
}

export interface ScaledDimensionResult {
  width: number;
  height: number;
  totalPixels: number;
  megapixels: string;
}

/**
 * ユークリッドの互除法を用いた最大公約数 (GCD) の算出
 * @param a 幅ピクセル値
 * @param b 高さピクセル値
 * @returns 最大公約数（整数）
 */
export function calcGCD(a: number, b: number): number {
  let [x, y] = [Math.abs(Math.round(a)), Math.abs(Math.round(b))];
  while (y !== 0) {
    const temp = y;
    y = x % y;
    x = temp;
  }
  return x || 1;
}

/**
 * 幅と高さからアスペクト比および各種幾何パラメータを計算
 */
export function calcAspectRatio(w: number, h: number): AspectRatioResult {
  if (w <= 0 || h <= 0) {
    throw new Error("幅および高さは正の数値である必要があります。");
  }

  const d = calcGCD(w, h);
  const ratioStr = `${w / d}:${h / d}`;
  const decimalVal = Number((w / h).toFixed(4));
  const isEven = (w % 2 === 0) && (h % 2 === 0);

  return {
    ratio: ratioStr,
    decimal: decimalVal,
    gcd: d,
    isEven,
  };
}

/**
 * 比率を固定したまま指定寸法へスケーリング（コーデック割り切れ制約対応）
 */
export function scaleDimension(
  targetWidth: number | null,
  targetHeight: number | null,
  ratioWidth: number,
  ratioHeight: number,
  mode: CodecRoundingMode = "even"
): ScaledDimensionResult {
  if (ratioWidth <= 0 || ratioHeight <= 0) {
    throw new Error("比率の基準値は正の数値である必要があります。");
  }

  // コーデック境界アライメント関数
  const align = (val: number): number => {
    const rounded = Math.round(val);
    switch (mode) {
      case "even":
        return rounded % 2 === 0 ? rounded : rounded + 1;
      case "mod8":
        return Math.round(rounded / 8) * 8;
      case "mod16":
        return Math.round(rounded / 16) * 16;
      case "none":
      default:
        return rounded;
    }
  };

  let w: number;
  let h: number;

  if (targetWidth !== null) {
    w = align(targetWidth);
    h = align((w * ratioHeight) / ratioWidth);
  } else if (targetHeight !== null) {
    h = align(targetHeight);
    w = align((h * ratioWidth) / ratioHeight);
  } else {
    throw new Error("targetWidth または targetHeight のいずれかを指定してください。");
  }

  const totalPixels = w * h;
  const megapixels = (totalPixels / 1_000_000).toFixed(2);

  return {
    width: w,
    height: h,
    totalPixels,
    megapixels,
  };
}

# モダン Python 3.10+ 実装

"""
画像・動画アスペクト比スケーリングおよびFFmpegコマンド生成スクリプト
Python 3.10+ 標準ライブラリのみを使用（依存パッケージなし）
"""

import math
from typing import Literal, Optional, Tuple

CodecMode = Literal["none", "even", "mod8", "mod16"]

def calc_aspect_ratio(w: int, h: int) -> Tuple[str, float, int]:
    """
    指定された幅と高さから既約分数アスペクト比、小数比率、GCDを返します。
    """
    if w <= 0 or h <= 0:
        raise ValueError("幅と高さは 1 以上の整数を指定してください。")
        
    divisor = math.gcd(w, h)
    ratio_str = f"{w // divisor}:{h // divisor}"
    decimal_val = round(w / h, 4)
    return ratio_str, decimal_val, divisor

def scale_dimension(
    target_w: Optional[int],
    target_h: Optional[int],
    rw: int,
    rh: int,
    mode: CodecMode = "even"
) -> Tuple[int, int, str]:
    """
    比率を維持したままスケーリングを行い、FFmpeg用のフィルター文字列を生成します。
    """
    def align(val: float) -> int:
        r = round(val)
        if mode == "even":
            return r if r % 2 == 0 else r + 1
        elif mode == "mod8":
            return round(r / 8) * 8
        elif mode == "mod16":
            return round(r / 16) * 16
        return r

    if target_w is not None:
        final_w = align(float(target_w))
        final_h = align((final_w * rh) / rw)
    elif target_h is not None:
        final_h = align(float(target_h))
        final_w = align((final_h * rw) / rh)
    else:
        raise ValueError("target_w または target_h のいずれかを指定する必要があります。")

    # FFmpegの高品質Lanczosリサイズ用フィルタ文字列
    ffmpeg_filter = f"scale={final_w}:{final_h}:flags=lanczos"
    return final_w, final_h, ffmpeg_filter

if __name__ == "__main__":
    # 使用例: 4K UHDソースから720p相当のMod-2安全な解像度を計算
    ratio_label, decimal_ratio, gcd_val = calc_aspect_ratio(3840, 2160)
    print(f"アスペクト比: {ratio_label} (係数: {decimal_ratio}, GCD: {gcd_val})")

    scaled_w, scaled_h, vf_cmd = scale_dimension(
        target_w=1280, target_h=None, rw=16, rh=9, mode="even"
    )
    print(f"スケーリング結果: {scaled_w}x{scaled_h} | FFmpeg: -vf \"{vf_cmd}\"")

# 現場で頻発する落とし穴・エッジケースとトラブルシューティング

解像度計算やアスペクト比変換を伴う実務開発において、エンジニアが直面しやすい代表的な落とし穴とその技術的解決策をまとめました。

# 1. FFmpegで発生する「width not divisible by 2」エラーとYUV 4:2:0の制約

• 症状: 動画のトランスコード時に -vf "scale=720:-1" などの自動スケールを指定した際、width not divisible by 2 (720x405) というエラーが出力され処理が異常終了する。
• 原因: ソース動画のアスペクト比によって計算された高さ（405）が奇数になり、一般的な動画配信規格である $YUV 4:2:0$ クロマサブサンプリングの色差プレーン（縦横半分）の割り切れ条件を満たせないため。
• 解決策: FFmpegのスケールフィルターにおいて、-1 の代わりに -2 を指定します（例: scale=720:-2）。これにより、FFmpegはアスペクト比を維持しつつ、自動計算される側の寸法を最も近い偶数ピクセル（この場合は 406） に安全に丸めます。

# 2. CSS aspect-ratio におけるサブピクセルレンダリングと1pxの背景チラつき

• 症状: コンテナ要素に aspect-ratio: 16 / 9 を設定した際、ブラウザのズーム操作や特定解像度において、要素の境界線に1ピクセルの隙間や背景の透過漏れ（フリッカー）が発生する。
• 原因: ブラウザのレンダリングエンジン（Blink / WebKit）がレイアウトツリーを計算する際、幅から計算された高さが小数点付きのサブピクセル値（例: 341.333px）となり、テクスチャのラスタライズ時に丸め誤差が生じるため。
• 解決策: 該当の画像や動画要素に対して transform: translateZ(0) や backface-visibility: hidden を適用してGPUコンポジターレイヤーに昇格させるか、親コンテナに overflow: hidden を設定して端数の描画領域外への食み出しを防止します。

# 3. マーケティング呼称「21:9」と真の幾何学比率（64:27 / 43:18）の混同

• 症状: 21:9 用として制作した全画面グラフィックやUIキャンバスを市販のウルトラワイドモニターに表示すると、左右または上下に予期せぬ微小な黒帯（ピラーボックス）が挿入される。
• 原因: 「21:9」は家電・ディスプレイメーカーによる商業用マーケティング名称であり、純粋な $21 \div 9 \approx 2.3333$ の比率を持つ製品はほぼ存在しません。実際のハードウェアパネルは、UWHD（2560×1080）で $64:27$（$2.37037$）、UWQHD（3440×1440）で $43:18$（$2.3888$）の比率で設計されています。
• 解決策: アプリケーション側で画面比率を判定・最適化する際は、単純な $21/9$ でハードコードせず、ネイティブ解像度のピクセル比（$64:27$ または $43:18$）を個別ターゲットとしてハンドリングしてください。

# 4. HTML画像寸法属性（width / height）の省略による Cumulative Layout Shift (CLS)

• 症状: Webページの読み込み完了時に、画像が遅延ロードされた瞬間にコンテンツ全体が下方に押し下げられ、Core Web Vitals の CLS スコアが著しく悪化する。
• 原因: 画像の <img> タグに固有の寸法情報が記述されていない場合、ブラウザは画像ファイルのバイナリヘッダーを受信してデコードするまで表示領域の高さを $0\text{px}$ とみなすため。
• 解決策: HTMLタグ側に固有比率を示す width="1600" height="900" 属性を明示的に指定した上で、CSS側で以下のように流動的レイアウトを定義します。ブラウザはCSSをパースした瞬間にアスペクト比から高さを事前確保します。

```css img.responsive { width: 100%; height: auto; aspect-ratio: 16 / 9; } ```

# 5. アナモフィック撮影における SAR と DAR の混同による歪み

• 症状: シネマカメラでアナモフィックレンズを使用して撮影した映像素材を編集ソフト（Premiere、DaVinci Resolve）にインポートした際、人物の顔が横方向に不自然に細長く押しつぶされて表示される。
• 原因: センサーに記録された生データ（SAR）は光学的に横方向が圧縮された状態であるため、表示アスペクト比（DAR）へ復元するための「ピクセルアスペクト比（PAR）」設定がタイムラインで未適用になっている。
• 解決策: クリップの属性（Clip Attributes / Pixel Aspect Ratio）を開き、使用したアナモフィックレンズの倍率（例: $1.33\times$、$1.5\times$、$2.0\times$ Anamorphic）を明示的に指定してデスクイーズ（横方向の引き伸ばし補正）を実行します。

# 6. スケーリング計算における累積丸め誤差（アスペクト比ドリフト）

• 症状: 複雑なレスポンシブグリッドシステムやタイル型レイアウトにおいて、拡大縮小を繰り返すうちに最初のアスペクト比から徐々にズレが生じる。
• 原因: 浮動小数点数（Float）による割り算を途中で丸めた値を基準にして次の計算を行うことで、端数誤差が累積（Drift）するため。
• 解決策: 常に「最初のオリジナル寸法（$W{\text{orig}}, H{\text{orig}}$）」または「約分された整数比（$rw, rh$）」をベースにし、計算の最終ステップでのみ整数丸めを行う設計を徹底してください。

# 7. 高DPI（Retina）環境における devicePixelRatio とCanvasプレビューのボケ

• 症状: MacBook や高精細スマートフォン上でアスペクト比計算プレビューをCanvas描画した際、文字や幾何グリッドの輪郭がぼやけてシャープさに欠ける。
• 原因: CSS上の論理ピクセル（CSS Pixels）と物理デバイスピクセル（Physical Pixels）の比率である window.devicePixelRatio（通常 $2.0$ や $3.0$）が考慮されておらず、Canvasの内部バッファ解像度が等倍のまま拡大表示されているため。
• 解決策: Canvas要素の内部バッファ寸法（width / height 属性）に devicePixelRatio を乗算し、CSSスタイル上の表示サイズを固定した上で、コンテキストに ctx.scale(dpr, dpr) を適用してRetinaネイティブの高精細描画を保証します。

# 8. CSS Flexbox / Grid 内における aspect-ratio と min-height: auto の競合

• 症状: Flexboxコンテナ内の子要素に aspect-ratio: 16 / 9 を設定しても、比率が無視されて縦に引き伸ばされたり、極端に縮小されて正しく表示されない。
• 原因: Flexアイテムのデフォルト仕様である min-height: auto（または min-width: auto）が、コンテンツサイズや親コンテナのストレッチ挙動（align-items: stretch）と競合し、aspect-ratio の幾何計算をオーバーライドしてしまうため。
• 解決策: Flexアイテム側のプロパティとして min-height: 0（横並びの場合は min-width: 0）を明示的に指定し、デフォルトの最小寸法制約を解除して aspect-ratio を最優先で評価させます。

# 充実したFAQセクション

日本のWeb開発者、映像クリエイター、デザイナーから頻繁に寄せられる疑問について、技術的根拠に基づいて回答します。

# Q1: 任意のカスタム画像解像度から正確なアスペクト比を計算する数式とアルゴリズムは？

回答: 幅（$W$）と高さ（$H$）の最大公約数（GCD）をユークリッドの互除法で求め、それぞれの値をGCDで除算します。たとえば解像度が $1200 \times 800$ の場合、$\gcd(1200, 800) = 400$ となります。幅を 400 で割ると $3$、高さを 400 で割ると $2$ となるため、既約分数比率は 3:2 です。小数の比率は $\frac{1200}{800} = 1.5$ となります。

# Q2: FFmpegで動画をリサイズすると「height/width not divisible by 2」エラーが出るのはなぜですか？

回答: H.264 や H.265 などの動画コーデックでは、ファイルサイズ削減のために色差信号を間引く $YUV 4:2:0$ クロマサブサンプリングを採用しています。この方式では輝度プレーンに対して色差プレーン（$U, V$）が縦横 $1/2$ の解像度を持つため、幅や高さが奇数ピクセルの場合、半分の解像度（小数ピクセル）を物理的に表現できずエンコーダーが停止します。FFmpegのスケールフィルターでは -vf "scale=1280:-2" のように -2 を指定することで、アスペクト比を保ったまま自動的に直近の偶数解像度へ丸めることができます。

# Q3: 21:9 ウルトラワイドモニターの解像度は、なぜ計算すると「21÷9」にならないのですか？

回答: 「21:9」はマーケティング上の呼び名であり、正確な数学的比率ではありません。もし真の $21:9$ であれば小数は $2.3333\dots$ になります。しかし実際の製品パネルは、劇場のシネマスコープ規格（$2.35:1$ 〜 $2.39:1$）に近づけるため、UWHD（$2560\times 1080$）では 64:27（$2.3704$）、UWQHD（$3440\times 1440$）では 43:18（$2.3889$）という比率で作られています。グラフィック制作時は、実パネルの解像度から直接アスペクト比を検証することが不可欠です。

# Q4: 動画技術における DAR、SAR、PAR の違いと相互変換の公式は？

回答: DAR（Display Aspect Ratio）は最終的に視聴者が目にする画面比率（例: $16:9$）、SAR（Storage Aspect Ratio）はファイルに格納されている記録ピクセル数の比率（例: $720/480$）、PAR（Pixel Aspect Ratio）は個々のピクセルの物理的な縦横比です。これらの関係は以下の公式で表されます。

$$\text{DAR} = \text{SAR} \times \text{PAR}$$

正方形ピクセル（PAR = 1.0）の一般的なデジタルディスプレイでは $\text{DAR} = \text{SAR}$ となりますが、DVD規格やアナモフィックシネマ素材では長方形ピクセルが使用されるため、この変換式による補正が必要です。

# Q5: CSSの aspect-ratio プロパティを使ってレイアウトシフト（CLS）を完全に防ぐ方法は？

回答: 画像や動画要素に対して、CSSで aspect-ratio: 16 / 9; width: 100%; height: auto; を指定します。さらにHTMLタグ側にもオリジナルの width と height 属性（例: <img src="..." width="1920" height="1080">）を付与してください。これにより、ブラウザは画像データのダウンロードを開始する前のレンダリングツリー構築フェーズで正確な高さを事前計算・領域確保できるため、読み込み完了時のコンテンツのガタつき（レイアウトシフト）を 100% 抑止できます。

# Q6: 16:9 ワイドスクリーンの主要な標準解像度（HD、FHD、2K、4K、8K）と総画素数の一覧は？

回答: 代表的な $16:9$ 解像度と画素数は以下の通りです。

• 720p (HD): $1280 \times 720$（約 92 万画素 / $0.92\text{ MP}$）
• 1080p (FHD / フルHD): $1920 \times 1080$（約 207 万画素 / $2.07\text{ MP}$）
• 1440p (QHD / 2K): $2560 \times 1440$（約 369 万画素 / $3.69\text{ MP}$）
• 2160p (4K UHD): $3840 \times 2160$（約 829 万画素 / $8.29\text{ MP}$）
• 4320p (8K UHD): $7680 \times 4320$（約 3,318 万画素 / $33.18\text{ MP}$）

# Q7: ToolsAAのアスペクト比計算ツールで動画や画像を解析する際、外部サーバーへの通信やデータ漏洩はありますか？

回答: いいえ、一切ありません。ToolsAAは完全クライアントサイド実行アーキテクチャ（"use client"）で設計されています。ファイル解析はブラウザのローカルメモリ上でネイティブ API（URL.createObjectURL、HTMLVideoElement、Canvas）を使用して行われ、外部サーバーへのアップロード処理、APIリクエスト送信、リモートログ収集は一切実装されていません。インターネットから切断されたオフライン環境でも完全動作するため、社外秘のデザインデータや未公開映像でも安全に解析できます。

# Q8: H.264 や HEVC の動画エンコードにおいて、Mod-16 や Mod-8 などの割り切れ制約が重視される理由は？

回答: 古典的な H.264 コーデックでは、フレームを $16 \times 16$ ピクセルの「マクロブロック」単位で分割して離散コサイン変換や動き予測を実行します。解像度が 16 の倍数でない場合、ハードウェアエンコーダーは内部でパディング（黒帯や拡張ピクセル）を挿入する必要が生じ、これが原因で古い再生機器や車載プレイヤー等で再生エラーや端のノイズ線が発生します。また HEVC や AV1 のコーディングツリーユニット（CTU）でも、ブロックの対称分割を最適化してエンコード速度と圧縮効率を最大化するために、少なくとも Mod-8 の寸法にアライメントすることが強く推奨されます。

# 技術リファレンスマトリクス：標準ディスプレイ＆動画アスペクト比一覧

主要なデジタル機器、動画プラットフォーム、映画規格における解像度、小数比率、メガピクセル、コーデック適合性の比較表です。

# まとめ：高精度幾何スケーリングと完全クライアントサイド処理の価値

現代のビジュアルエンジニアリングにおいて、画像・動画の幾何学プロポーションの厳密な設計は、単なるデザイン上の見栄えにとどまらず、Core Web Vitals によるSEO評価、ビデオトランスコーダーの安定性、そしてユーザーエクスペリエンスを直接左右する極めて重要な工学的課題です。

解像度の端数丸めによるわずか 1 ピクセルの誤差であっても、映像パイプラインでのエンコード強制終了や、Webページにおける累積レイアウトシフト（CLS）といった実害を引き起こします。ユークリッドの互除法に基づくGCD約分と、ビデオコーデックのマクロブロック境界制約（Mod-2、Mod-8、Mod-16）を組み合わせた体系的な計算パイプラインを取り入れることで、あらゆるデバイスと配信環境において破綻のないメディアワークフローを構築できます。

ToolsAA 画像・動画アスペクト比計算ツール（Image & Video Aspect Ratio Calculator） は、高機能な アスペクト比計算機、正確な 16:9 解像度計算機、そして実務に即したコードエクスポート機能を統合し、これら複雑な数学的・工学的処理をブラウザ上でシームレスに提供します。

未公開のメディア資産やプライベートな制作ファイルを外部サーバーに一切アップロードしない 100% クライアントサイド・プライバシーアーキテクチャ（"use client"） のもと、高速かつ安全なアスペクト比計算・スケーリング環境をぜひ日々の開発・制作業務にご活用ください。