An Archive Clip Looks Stretched. Check Pixel Shape Before Cropping It

The clip is authorized. The footage is the right footage. And the archivist's face is the wrong shape — too wide here, too narrow in another viewer, fine in the file browser and wrong the second it lands in your project.

The usual next move is to drag a crop handle or a scale slider until the face looks like a face. Don't. Not yet. What's wrong is not the picture. What's wrong is the assumption something is making about how the picture's samples should be laid out, and there's an order of operations that resolves it.

Here's the short version. A video file stores a grid of samples — a count across, a count down. It may also state how wide an individual sample is meant to be when displayed. Those are two different facts, and neither one is "the aspect ratio." Multiply them and you get a third fact: the shape of the picture you see. If your application assumes a different sample shape than the archive declared, the picture displays in the wrong proportions without a single pixel being damaged or moved. Correct the interpretation, verify the export, and leave the composition alone.

Record the source before trying to make it look right

Start by putting the delivered file somewhere it will not be overwritten, and writing down what you actually know about it. Not what it looks like. What's documented.

Storage dimensions are the sample grid: how many pixels across, how many down. A 1440 × 1080 file stores 1,440 samples per line on 1,080 lines. That's a count. It is not a shape, though people talk about it as one.

Pixel aspect ratio, sometimes called sample aspect, is the width-to-height of one individual sample as the source intends it to be displayed. A square-pixel file is 1:1. Archival and older broadcast material often isn't — one sample can be wider than it is tall, which is how a narrower grid carries a wider picture.

Display aspect ratio is the width-to-height of the picture once those samples are laid out as intended. This is what someone means when they say "it's a 16:9 clip."

Aperture is which region of the stored grid counts as picture. The full aperture is the entire stored raster. A clean or active aperture is a smaller defined region inside it. When a source declares one, the display shape comes out of that region rather than out of the raw stored count.

Frame rate and field order describe when samples were captured and how they're grouped. They are a separate question, with a separate investigation, and nothing in this article touches them.

Write these down separately, and write down where each number came from — delivery documentation, transfer notes, container metadata, an email from the archivist. A format name is not a record. "SD," "PAL," "1080p" and the rest are statements about a family of formats, not about the file in your project. Two files in the same family can carry different pixel aspects and different apertures.

Where the sources disagree, or go quiet, write "unknown" and mean it. The blank is a finding. Filling it with what seems likely is how a guess becomes a caption later.

One more thing to note in this phase: if two viewers disagree about the shape of the same file, that's a clue that at least one of them is deciding the sample shape for you — but it's not a verdict on which one is right. Some players honor pixel aspect. Some ignore it and show you the stored grid. The disagreement tells you the question is live, not what the answer is.

Compare storage geometry with declared display geometry

For a declared full aperture, the relationship is short enough to hold in your head:

display width  = stored width  × pixel width
display height = stored height × pixel height

Here's a paper comparison to make that concrete. It's a declared fixture, arithmetic on invented inputs — no frame file, project or export was produced for this piece. Which is exactly the point: the geometry below is known because the fixture defines it, not because the result looks pleasing.

Stored dimensions: 1440 × 1080. Declared pixel aspect: 4:3. Aperture: full.

Read as square pixels (1:1):

• width: 1440 × 1 = 1440
• height: 1080 × 1 = 1080
• ratio: 1440 : 1080 = 4:3

Read at the declared 4:3 pixel aspect:

• width: 1440 × 4 = 5760
• height: 1080 × 3 = 3240
• ratio: 5760 : 3240 = 16:9

The same 1,555,200 samples, two different pictures. The 16:9 display is exactly one-third wider than the 4:3 display, and the source only declared one of them. Under the square-pixel reading, the picture is a quarter narrower than the source intends — a squeezed face, a round thing rendered oval. Under the declared reading, it isn't.

Now the trap. The fixture's answer is defensible because the fixture states the pixel aspect. Yours probably won't arrive that clean. A face in frame is a sanity check at best: you don't know from looking whether the person was tall or the picture is being compressed. A circle is only decisive if you know independently that it was a circle on the day the footage was shot — which, with archive material, you usually don't. Assembling an argument out of faces and suns and archways produces an opinion about a shape, not a record of a source.

Aperture deserves its own warning before you transfer this arithmetic. The multiplication above used the whole stored grid. If the archive declares an active or clean aperture narrower than the stored raster, you multiply the aperture's width and height, not the file's sample count. That difference is small enough to look like rounding and large enough to turn a correct interpretation into a wrong one at the edges.

And if the archive declares both a pixel aspect and a display aspect, check that they agree at the declared aperture. If they don't, don't split the difference and don't pick the prettier one. An inconsistency between two documented numbers is itself the finding, and it belongs in the same request for clarification.

Change interpretation, not three unrelated properties

The software question comes after the geometry question, never before it. Once the archive tells you what the source is, you're asking your editing application to agree with the archive.

In Premiere Pro, the operation is Interpret Footage: select the clip in the Project panel and use Modify > Interpret Footage. That dialog holds properties of the source clip — pixel aspect ratio among them — rather than the arrangement of clips in a sequence. Adobe's documentation for the current desktop version, as of a check on 9 September 2026, describes pixel aspect separately from stored frame dimensions. A community post from 31 January 2021 describes an editor hitting exactly this symptom with SD material: the shape went wrong after the dimensions were interpreted. Treat that as one historical report of a symptom, not a bug report and not a diagnosis of your file.

Set the pixel aspect to what the archive declared. Where the dialog offers named entries rather than numbers, check what number each name carries before choosing it — a label saying "anamorphic" tells you a squeeze exists, not how much of one. Then notice what didn't change: the clip still stores 1440 × 1080 samples. Interpretation changes the mapping from samples to display. Nothing is resampled, nothing is discarded, and the change is reversible. And a glance at the rest of that dialog will show frame rate and field order sitting right there, inviting you to fix a shape problem with a timing control. Leave them. Changing the frame rate until the picture widens is not a fix.

Three operations get confused at this point, and they aren't interchangeable:

Interpreting changes how existing samples map onto a display rectangle. No new samples, no lost ones. This is the operation that addresses a geometry mismatch.

Resampling computes new samples — 1440 wide becomes 1920 wide, say. That may be genuinely needed later if a deliverable requires a different grid, but resampling doesn't establish the source's geometry, and doing it while the interpretation is wrong bakes the wrong shape into new pixels that now look intentional.

Cropping removes picture. It changes composition, permanently, in the derivative. It cannot tell you anything about the source's pixel shape. It can only hide the symptom behind a compositional loss you'll have to explain later.

There's a fourth, sneakier move: a non-uniform scale in the sequence, stretching the clip on one axis until it looks right. This will produce a correct-looking export. It also leaves the source interpretation wrong, lives in one sequence, and won't travel with the clip if a colleague opens the project. If your real complaint is geometry, the source interpretation is the durable place to fix it, and the scale can stay at 100%.

Which brings up the stopping point. If the notes and the metadata can't establish the geometry, stop. Two unknown clips don't average into one known clip, and matching your stretched source to another stretched source produces two consistent guesses. Ask the owner, precisely: what were the stored dimensions, the pixel aspect and the aperture of the delivered master, and which display shape was intended? That's a question an archive can answer, and the answer is the thing you actually need. A specific unresolved metadata request is a legitimate outcome of this whole exercise. A confident crop is not.

Check the sample that will actually be seen

Interpreting the source correctly is a claim about the file. The pitch sample is a different object, and it needs its own check.

Export the derivative and open it where it will be seen — the player your commissioner will use, on a screen someone will actually look at. Not only the editing preview. A program monitor routinely scales the picture to fit its own panel, and a full-screen viewer may letterbox; either can hide a stretch that is still sitting in the file. The preview is where you decide edits. It is not where you verify geometry.

Watch for three signatures:

• A second stretch. The picture is corrected in the timeline but wrong in the export, or wrong by a different amount than your arithmetic predicted. That's what applying a shape adjustment twice looks like — once where the file was interpreted and again in the sequence, or in something the file passed through before it reached you. Your notes should say whether anyone upstream already conformed it.
• An unexplained crop. Edges missing that shouldn't be. Check the sequence settings and any "scale to fill" behavior in the export before you conclude the archive delivered less picture than it said.
• An unsupported correction. The result looks right because you stretched it, and no document anywhere says the source ever looked that way.

Record the export settings and the viewing conditions next to the retained original: what you changed, where you watched it, what you saw. And be honest about the status of the comparison above — it's a paper exercise, described rather than demonstrated. No frame, project or export accompanies this article, and its arithmetic holds because the fixture defines its inputs. Run the same comparison on your actual authorized clip, and confirm that your installed version behaves the way its documentation says it does. If it doesn't, that's a finding too, and it goes in the same notes.

What you're left with, if this went well, isn't a clip that looks right. It's a clip whose shape you can defend: stored dimensions, declared pixel aspect, aperture, the interpretation you set, and a derivative you watched in the place it will be watched. If the archive stayed silent, it's the exact question you sent and the answer you're waiting on — which is a better deliverable than a plausible guess, because it can be resolved by someone who knows.

And whatever you write in the caption, don't write "corrected" because a face finally looks familiar. Write what the source says. If the source says nothing, write nothing and go ask.

Frequently asked questions

What should I check before cropping an archive clip that looks stretched?

Check the interpretation first, not the composition. A file stores a sample grid and may also declare how wide each sample should be displayed. If the application assumes a different sample shape than the archive declared, the picture can display in the wrong proportions even though no pixel was damaged or moved. Correct the interpretation, verify the export, and leave the composition alone.

Are storage dimensions the same as display aspect ratio?

No. Storage dimensions are the sample grid: how many pixels across and down. Pixel aspect ratio, or sample aspect, is the width-to-height of one sample as the source intends it to be displayed. Display aspect ratio is the shape of the picture once those samples are laid out. In the paper fixture, a 1440 by 1080 file read as square pixels gives 4:3, while the declared 4:3 pixel aspect gives 16:9 from the same samples.

Why are faces, circles, or suns not reliable proof of correct geometry?

They can be sanity checks at best. From looking, you do not know whether a person was tall or the picture is compressed. A circle is decisive only if you independently know it was a circle on the day the footage was shot, which archive material usually cannot establish. Building an argument from faces, suns, and archways produces an opinion about a shape, not a record of a source.

What should I do if the notes and metadata cannot establish the geometry?

Stop. Two unknown clips do not average into one known clip, and matching one stretched source to another produces two consistent guesses. Ask the owner precisely: what were the stored dimensions, the pixel aspect, and the aperture of the delivered master, and which display shape was intended? A specific unresolved metadata request is a legitimate outcome; a confident crop is not.

How do interpreting, resampling, cropping, and a non-uniform scale differ?

Interpreting changes how existing samples map onto a display rectangle; no new samples are made or lost, and the change is reversible. Resampling computes new samples and does not establish the source's geometry; doing it while interpretation is wrong can bake in the wrong shape. Cropping removes picture and changes composition permanently. A non-uniform sequence scale can make a correct-looking export, but it leaves the source interpretation wrong and lives only in that sequence.