# Aspect Desk

> 1440 x 1080 is 16:9. The pixels are not square. Three numbers describe the shape of a
> picture and only two of them are ever looked at, so a tool that reads the width and the
> height and stops does not get a slightly wrong answer — it gets the other answer.

https://aspect-desk.skillsafe.ai/

## What it is

Five lanes over one canvas and the set of assets that have to sit on it, plus a **free
browser-side engine** that computes every shape. The engine costs nothing, needs no account,
and makes no network calls. Writing the report costs credits.

## The arithmetic

    storage aspect   width / height                     <- what the pixels count
    pixel aspect     how wide one pixel is              <- relative to its height
    display aspect   width x pixel aspect / height      <- the actual shape
    bars if fitted   1 - narrower / wider               <- on the long axis
    lost if filled   the same fraction                  <- on the other axis
    burned in        round(width x pixel aspect)        <- then nudged even for 4:2:0
    applied twice    the pixel aspect squared

## Figures that are exact, and surprising

- **1440x1080 counts as 4:3 and is 16:9.** Its pixels are 4/3 as wide as they are tall. Read
  the dimensions alone and you get the other answer, and 4:3 against 16:9 is as wrong as an
  aspect ratio can be.
- **It does not look like an error.** It looks like a slightly wrong crop, or faces that are a
  bit narrow, and it survives every review that is not a measurement. A PAL 4:3 insert is
  720x576, which counts as 5:4, and the 1.0667 squeeze is exactly what "narrow faces" means.
- **A file can state all three numbers and state them inconsistently.** When the declared
  display aspect and the computed one disagree, one of them is a lie and nothing in the file
  says which — so the same asset is a different shape in different applications.
- **Bars and cropping are the same fraction on opposite axes.** 4:3 inside 16:9 leaves 25% of
  the width in bars, and filling it costs 25% of the height. 1:1 costs 43.8% either way. 16:9
  into 9:16 costs 68.4%. The only real question is where the subject is.
- **But filling costs more than the crop.** The archive insert needs 1.88x enlargement to fit
  and 2.5x to fill, so a crop loses picture twice — once at the edges and once in sharpness.
- **Burning the correction in cannot hit the shape exactly.** NTSC 16:9 wants 853.33 pixels of
  width, can have 853, and 4:2:0 chroma then needs an even one — so it becomes 854, landing
  the shape at 1.7792 instead of 1.7778. Invisible once. It compounds.
- **Some of them are exact and it is luck, not design.** 1440 x 4/3 is exactly 1920; 720 x
  16/15 is exactly 768; 720 x 64/45 is exactly 1024. NTSC 16:9 is the one that is not.
- **Applying the correction twice distorts by the pixel aspect squared.** An asset already
  scaled to square pixels that still carries its original flag gets squeezed again: 1440x1080
  read twice comes out at 2.37:1. One tool did the right thing and did not clear the flag.
- **There are two families of standard pixel aspect, about two percent apart.** One set makes
  the round numbers come out on the 720 pixels that are stored; the MPEG-4 set describes the
  702 that are active. Both are correct, both are in the wild, and a file using one while
  declaring a shape from the other is not lying.

## The sheet

    CANVAS
    name   | the launch film timeline
    width  | 1920
    height | 1080
    par    | 1

    ASSETS
    a1 | the generated hero clip | 1440x1080 | par 4/3   | says 16:9
    a2 | the camera b-roll       | 1920x1080
    a3 | the archive insert      | 720x576   | par 16/15
    a4 | the logo animation      | 1000x1000

An asset row is `id | what it is | WxH`, then any of `par R` (as `4/3`, `4:3` or `1.3333`),
`says R` (the display aspect the file declares, checked against the computed one), and
`burned` (already scaled to square pixels — with a non-square `par` still on it, that is the
double-squeeze case).

**An omitted `par` means square is assumed**, and the assumption is reported rather than
hidden, because an asset that needed a correction and did not get one just looks like a
slightly wrong crop. The canvas takes `width`, `height` and its own `par`; a canvas with
non-square pixels means every asset corrects into the canvas's pixel aspect rather than into
square pixels, which is a different sum and one almost no tool does by default.

## The lanes

- `plan` - decide the canvas before the assets arrive
- `check` - what these assets do on this canvas (the primary lane)
- `shape` - which shape each thing actually is, and what a tool reading two of three gets
- `fit` - what fitting costs asset by asset, in bars against picture
- `deliver` - what ships, what a timeline decision settles, what needs the material again

## What it cannot do

It is arithmetic on declared numbers and **has not seen a picture**. It cannot tell a squeeze
from a raster: 4/3 is HDV, which stored 1440 pixels of a 1920-pixel picture, and it is also a
1.33x anamorphic lens — the same number. It cannot tell which of two disagreeing numbers is
right, only that they disagree. And it does not know where the subject is, so every
fit-against-fill figure is a fraction of the frame rather than a judgement about what is in it.

## Source

Lanes derived from the `video-generation` skill in
[bytedance/deer-flow](https://github.com/bytedance/deer-flow), which takes
`--aspect-ratio 16:9` and hands back a file. Asking for a ratio and receiving three numbers is
where this page starts. Not affiliated with or endorsed by the authors of that repository.

## API

https://aspect-desk.skillsafe.ai/api.html